Cisco LocalDirector 400 Series

Troubleshoot Untranslated Packets in Front of the LocalDirector

Document ID: 12434

Updated: Jan 31, 2006



This document provides information on how to troubleshoot untranslated packets in front of the LocalDirector.



There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.


For more information on document conventions, refer to the Cisco Technical Tips Conventions.


Packets may be found in front of the LocalDirector with the source IP address of the real IP address of the servers instead of the virtual address. These packets belong to sessions opened by external clients to the LocalDirector's virtual addresses, and they are usually packets belonging to a normal TCP connection termination (FIN) or connection reset (RST) sequence. Because these packets are just part of a closing session, no connectivity issues are experienced.

This become more visible in configurations where the servers use a private IP address, the virtual uses a public address, and the gateway is a firewall and not a router. In this case, a message might be logged by the firewall advising that an unexpected source IP address has been received from the internal network.

LocalDirector Architecture

In order to understand the reasons for this behavior, a brief description of the LocalDirector's architecture is provided in this section.

When a client opens a connection to a virtual address, an identifier for the flow is entered into the translation table. These entries contain all the information about the flow in order to track it and make the necessary manipulations to the next packets. These entries have a life cycle and when the TCP session has come to an end, they are normally removed to avoid waste of memory resources.

In practice, the LocalDirector keeps looking at the session traffic and when it sees specific session termination packets, it removes the entries from the translation table.

The LocalDirector removes the translation entries when it either sees a standard connection termination (FIN) or a connection reset (RST).

In some scenarios, depending on the topology implemented, network delays, the implemented TCP stacks, and the applications, retransmission of some late packets of a closing session arrive to the LocalDirector when the entry in the translation table has already been removed. In this case, the LocalDirector bridges these packets untranslated, causing the symptoms described at the beginning of this document.

An in-depth analysis of this situation always requires that a simultaneous sniffer trace be taken on the front and on the back of the LocalDirector. By backward following a TCP session that ended with an untranslated packet, it is possible to clearly see the cause of this behavior.

Once the cause is determined, the next step is to consider whether this is causing an issue or not. Very few packets will actually be seen in this state, and they do not actually cause a problem beyond the possible generation of a reset packet back to the sender. The worst case may be warning messages logged by the firewall.


If this issue is affecting your network, these are possible solutions:

  • Issue delay command.

  • Secure the LocalDirector by issuing the secure command.

  • Access-lists (ACLs) might be applied on the gateway.

The delay command causes the the LocalDirector to keep the translation entry for five more minutes (this value cannot be changed) in the translation table after a standard TCP connection termination or a connection reset have been seen. Adding this command allows the LocalDirector to correctly translate late packets, but may consume excessive LocalDirector resources (especially in very loaded environments). This happens because of the increased time the translation entry must be kept in memory.

The secure command causes the LocalDirector to block all the traffic going through the LocalDirector that do not have an entry in the translation table. This must be considered in case the internal servers need to contact devices beyond the LocalDirector in the local network. A typical example might be a DNS server used by the internal servers for reverse lookup of a client IP address requesting content.

If the gateway is a router and not a firewall, an ACL might be applied on it to block the untranslated packets.

For more information about the delay and secure commands, refer to the LocalDirector command descriptions for the release version you are using.

Related Information

Updated: Jan 31, 2006
Document ID: 12434