steelhead communication enable

You enable connection forwarding only in asymmetric networks; that is, in networks in which a client request traverses a different network path than the server response. The default port for connection forwarding is 7850.

To optimize connections in asymmetric networks, packets traveling in both directions must pass through the same client-side and server-side SteelHead. If you have one path from the client to the server and a different path from the server to the client, you need to enable in-path connection forwarding and configure the SteelHeads to communicate with each other. These SteelHeads are called neighbors and exchange connection information to redirect packets to each other. Neighbors can be placed in the same physical site or in different sites, but the latency between them should be small because the packets traveling between them are not optimized.

If there are more than two possible paths, additional SteelHeads must be installed on each path and configured as neighbors. Neighbors are notified in parallel so that the delay introduced at the connection set up is equal to the time it takes to get an acknowledgment from the furthest neighbor.

When you enable connection forwarding, multiple SteelHeads work together and share information about what connections are optimized by each SteelHead. With connection forwarding, the LAN interface forwards and receives connection forwarding packets.

SteelHeads that are configured to use connection forwarding with each other are known as connection forwarding neighbors. If a SteelHead sees a packet belonging to a connection that is optimized by a different SteelHead, it forwards it to the correct SteelHead. When a neighbor SteelHead reaches its optimization capacity limit, that SteelHead stops optimizing new connections, but continues to forward packets for TCP connections being optimized by its neighbors.

You can use connection forwarding both in physical in-path deployments and in virtual in-path deployments. In physical in-path deployments, it is used between SteelHeads that are deployed on separate parallel paths to the WAN. In virtual in-path deployments, it is used when the redirection mechanism does not guarantee that packets for a TCP connection are always sent to the same SteelHead. This includes the WCCP protocol, a commonly used virtual in-path deployment method.

Typically, you want to configure physical in-path deployments that do not require connection forwarding. For example, if you have multiple paths to the WAN, you can use a SteelHead model that supports multiple in-path interfaces, instead of using multiple SteelHeads with single in-path interfaces. In general, serial deployments are preferred over parallel deployments. For details about deployment best practices, see the SteelHead Deployment Guide.