For a SteelHead to optimize a TCP connection, it must detect all of the packets for that connection. When you use connection forwarding, multiple SteelHeads work together and share information about which connections are being optimized by each. With connection forwarding, the LAN interface forwards and receives connection-forwarding packets. This section includes the following topics:

SteelHeads that are configured to use connection forwarding with each other are known as connection-forwarding neighbors. If a SteelHead detects 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, that SteelHead stops optimizing new connections but continues to forward packets for TCP connections being optimized by its neighbors.

You can use connection forwarding in both physical in-path deployments and 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, it is easier to design 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 information about deployment best practices, see Best Practices for SteelHead Deployments.

Figure 2‑1 shows a site with multiple paths to the WAN. SteelHead A and SteelHead B can be configured as connection-forwarding neighbors. This ensures that if a routing or switching change causes TCP connection packets to change paths, either SteelHead A or SteelHead B can forward the packets back to the correct SteelHead.

For information about connection forwarding and MTU sizing, see Connection-Forwarding MTU Considerations.

The following example is based on the assumption that the SteelHeads have already been configured properly for in-path interception.

When SteelHead A begins optimizing a new TCP connection, it communicates this to SteelHead B, provides the IP addresses and TCP port numbers for the new TCP connection, and defines a dynamic TCP port on which to forward packets.

If SteelHead B detects a packet that matches the connection, it takes the packet, alters its destination IP address to be the in-path IP address of SteelHead A, alters its destination TCP port to be the specific dynamic port that SteelHead A specified for the connection, and transmits the packet using its routing table.

In most environments, Riverbed recommends that you configure connection-forwarding SteelHeads to send traffic to each other through the LAN side of the network. Generally, the LAN-side network equipment is connected through low-latency network equipment with more than sufficient connectivity, and the WAN-side equipment might not be directly connected. To make sure that the connection-forwarding neighbor SteelHead sends traffic to each of their in-path IP addresses through the LAN, install a static route for the addresses whose next hop is the LAN gateway device.

For information about connection forwarding in multiple WAN routers, see Configuring Basic Connection Forwarding.

By default, SteelHeads communicate with neighbor appliances over a single in-path interface, on whatever is the lowest-numbered, enabled interface. If reachability is lost across the single interface, then the connection-forwarding capabilities is degraded or broken.

The CLI command steelhead communication multi-interface enable allows all SteelHead neighbor in-path interface IP addresses to be visible to each peer. This visibility ensures neighbor communication if an interface fails. This command provides a level of interface redundancy; however, you can also think of the multiple-interface option as an improved version of the connection-forwarding protocol. Some additional features, such as the SteelHead Interceptor load-balancing functions, require you to enable multiple-interface support regardless of the number of interfaces enabled.

Connection-forwarding SteelHeads with multiple-interface support attempt to establish communication from every enabled in-path interface to every neighbor appliance in-path interface. Depending on traffic flow, you can forward optimized traffic between SteelHeads through any active in-path interfaces. Therefore, in typical environments, Riverbed recommends that all enabled and connected in-path interfaces on the SteelHeads be reachable by their connection-forwarding neighbors. Please consult Riverbed Professional Services or account team for environments in which reachability between neighbor in-path interfaces is limited.

By default, if a SteelHead loses connectivity to a connection-forwarding neighbor, the SteelHead stops attempting to optimize new connections. This behavior can be changed with the steelhead communication allow-failure CLI command. If the allow-failure command is enabled, a SteelHead continues to optimize new connections, regardless of the state of its neighbors.

For virtual in-path deployments with multiple SteelHeads, including WCCP clusters, you must always use connection forwarding and the allow-failure command. This is because certain events, such as network failures, and router or SteelHead cluster changes, can cause routers to change the destination SteelHead for TCP connection packets. When this happens, SteelHeads must be able to redirect traffic to each other to ensure that optimization continues.

For parallel physical in-path deployments, where multiple paths to the WAN are covered by different SteelHeads, connection forwarding is needed because packets for a TCP connection might be routed asymmetrically; that is, the packets for a connection might sometimes go through one path, and other times go through another path. The SteelHeads on these paths must use connection forwarding to ensure that the traffic for a TCP connection is always sent to the SteelHead that is performing optimization for that connection.

If the allow-failure command is used in a parallel physical in-path deployment, SteelHeads optimize only those connections that are routed through the paths with operating SteelHeads. TCP connections that are routed across paths without SteelHeads (or with a failed SteelHead) are detected by the asymmetric routing detection feature.

For physical in-path deployments, the allow-failure command is commonly used with the fail-to-block feature (on supported hardware). When fail-to-block is enabled, a failed SteelHead blocks traffic along its path, forcing traffic to be rerouted onto other paths (where the remaining SteelHeads are deployed).

For an example configuration, see Configuring Connection Forwarding with Allow-Failure and Fail-to-Block.

You can configure your SteelHeads to automatically detect and report asymmetry within TCP connections as seen by the SteelHead. Asymmetric route auto-detection does not solve asymmetry; it simply detects and reports it, and passes the asymmetric traffic unoptimized. For information about enabling asymmetric route auto-detection, see the SteelHead Management Console User’s Guide.

In general, Riverbed recommends that the maximum round-trip latency between connection forwarding SteelHeads is less than one millisecond.

You can deploy SteelHeads so that moderate latency exists between connection forwarding SteelHeads. Latency has an impact on the optimized traffic because each optimized connection requires communication between all connection forwarding SteelHead neighbors in order to share state about recognizing flows for redirection.

The longest round-trip latency between any two connection forwarding SteelHeads should be less than one-fifth of the round-trip latency to the closest optimized remote site. This ensures that connection forwarding communication does not cause connection setup time to be greater for optimized connections compared to unoptimized connections for the closest remote site. Deployments with round-trip latencies higher than 10 milliseconds between connection forwarding SteelHeads should only be implemented after a technical consultation with Riverbed.

For more details, see the SteelHead Management Console User’s Guide.