Enables the SteelHead to continue to optimize connections when one or more of the configured neighbors is unreachable.

None

For virtual in-path deployments with multiple SteelHeads, including WCCP clusters, connection forwarding and the allow-failure feature must always be used. 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 insure 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 feature is used in a parallel physical in-path deployment, SteelHeads only optimize 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 feature 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 details about configuring the allow-failure with the fail-to-block feature, see the SteelHead Deployment Guide.

The no command option disables this feature.

SteelHead CX, SteelHead EX, SteelHead-v, SteelHead-c