About failover management
If three consecutive pings are missed, the system considers the path to be unavailable, and selects the backup path. Every application has a default and a prioritized set of backup paths. Should the default path be unavailable, the higher-priority backup is instantly used (and then the lower one if needed). Operators can block certain types of applications when the primary path becomes unavailable, with a goal of reserving the remaining available bandwidth for more critical applications. As soon as the default path becomes available, traffic is routed back to it.
Fail-to-wire mode
All SteelHead models and in-path network interface cards support a fail-to-wire (also known as bypass) mode. In the event of a failure or loss of power, the SteelHead goes into bypass mode and the traffic passes through uninterrupted. Many in-path network interface cards (NICs) also support a fail-to-block mode in which case if there’s a failure or loss of power, the SteelHead LAN and WAN interfaces power down and stop bridging traffic. The default failure mode is fail-to-wire mode.
If there’s a serious problem with the SteelHead or it’s not powered on, it goes into bypass mode to prevent a single point of failure. If the SteelHead is in bypass mode, you are notified in these ways:
• The Intercept/Bypass status light on the bypass card is triggered. For detailed information about bypass card status lights, see the appendixes that follow.
• The Dashboard of the Management Console displays the Critical health icon next to the appliance name.
• SNMP traps are sent (if you have set this option).
• The event is logged to system logs (syslog).
• Email notifications are sent (if you have set this option).
When the fault is corrected, new connections receive optimization; however, connections made during the fault aren’t optimized. To force all connections to be optimized, enable the kickoff feature. Generally, connections are short-lived and kickoff is not necessary. For detailed information about enabling the kickoff feature, see the SteelHead User Guide and the SteelHead Deployment Guide.
When the SteelHead is in bypass mode the traffic passes through uninterrupted. Traffic that was optimized might be interrupted, depending on the behavior of the application-layer protocols. When connections are restored, they succeed, although without optimization.
In an out-of-path deployment, if the server-side SteelHead fails, the first connection from the client fails. After detecting that the SteelHead is not functioning, a ping channel is setup from the client-side SteelHead to the server-side SteelHead. Subsequent connections are passed through unoptimized. When the ping succeeds, processing is restored and subsequent connections are intercepted and optimized.
For detailed information about the ping command, see the Riverbed Command-Line Interface Reference Manual.
Fail-to-block mode
In fail-to-block (also known as disconnect) mode, if the SteelHead has an internal software failure or power loss, the SteelHead LAN and WAN interfaces power down and stop bridging traffic.
When fail-to-block mode is enabled, a failed SteelHead blocks traffic along its path, forcing traffic to be rerouted onto other paths (where the remaining SteelHeads are deployed). This is only useful if the network has a routing or switching infrastructure that can automatically divert traffic off of the link once the failed SteelHead blocks it.
You can use this mode with connection-forwarding, the allow-failure CLI command, and an additional SteelHead on another path to the WAN to achieve redundancy. For more information, see the Riverbed Command-Line Interface Reference Manual.
You set fail-to-block mode in the SteelHead CLI. For detailed information, see the SteelHead Deployment Guide.