•  For parallel physical in-path deployments, where multiple paths to the WAN are covered by different SteelHead Interceptors, 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 SteelHead Interceptors on these paths must use connection-forwarding to ensure that the traffic for a TCP connection is always sent to the SteelHead appliance that is performing optimization for that connection.

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

•  For physical in-path deployments, the allow-failure feature is commonly used with the fail-to-block feature (on supported hardware). When the fail-to-block feature is enabled, a failed SteelHead Interceptor blocks traffic along its path, forcing traffic to be rerouted onto other paths (where the remaining SteelHead Interceptors are deployed). For details about configuring the allow-failure feature and the fail-to-block feature, see the SteelHead Deployment Guide.

•  For virtual in-path deployments with multiple SteelHead Interceptors, including WCCP clusters, the connection forwarding and the allow-failure features must always be used. This is because certain events, such as network failures, and router or cluster changes, can cause routers to change the destination SteelHead Interceptor for TCP connection packets. When the destination changes, the SteelHead Interceptors must be able to redirect traffic to the SteelHead appliance to ensure that optimization continues.