This section describes the SteelHead failure modes. This section includes the following topics:

All SteelHead models and in-path network interface cards support fail-to-wire mode. In the event of a disk failure, a software crash, a runaway software process, or even loss of power to the SteelHead, the LAN and WAN ports that form the logical in-path interface become internally connected as if they were the ends of a crossover cable, thereby providing uninterrupted transmission of data over the WAN.

Certain in-path network interface cards also support a fail-to-block mode, where in the case of a failure or loss of power, the SteelHead LAN and WAN interfaces completely lose link status, blocking traffic and forcing it to be rerouted onto paths where the remaining SteelHeads are deployed. The default failure mode is fail-to-wire mode.

For a list of in-path network interface cards or bypass cards that support fail-to-block mode, see Fail-to-Block Mode.

If a SteelHead transitions to fail-to-wire or fail-to-block mode, you are notified in the following ways:

Fail-to-wire mode allows the SteelHead WAN and LAN ports to serve in the same was as an Ethernet crossover cable. In fail-to-wire mode, SteelHeads cannot view or optimize traffic. Instead, all traffic is passed through the SteelHead unoptimized.

All SteelHead in-path interfaces support fail-to-wire mode. Fail-to-wire mode is the default setting for SteelHeads.

When a SteelHead transitions from normal operation to fail-to-wire mode, SteelHead circuitry physically moves to electronically connect the SteelHead LAN and WAN ports to each other, and physically disconnects these two ports from the rest of the SteelHead. During the transition to fail-to-wire mode, device linked to the SteelHead momentarily disconnect and then immediately connect again. After the transition, traffic resumes flowing as quickly as the connected devices are able to process it. For example, spanning-tree configuration and routing-protocol configuration influence how quickly traffic resumes flowing. Traffic that was passed‑through is uninterrupted. Traffic that was optimized might be interrupted, depending on the behavior of the application-layer protocols. When connections are restored, the traffic resumes flowing, although without optimization.

After the SteelHead returns to normal operation, it transitions the SteelHead LAN and WAN ports out of fail-to-wire mode. The devices connected to the SteelHead perceive this as another link state transition. After they are back online, new connections that are made are optimized. However, connections made during the failure are not optimized.

To force all connections to be optimized, you can enable the kickoff feature. This feature resets established connections to force them to go through the connection creation process again. For this reason, before enabling the kickoff feature in production deployments, you must understand and accept that all TCP connections are reset. Generally, connections are short lived and kickoff is not necessary.

For information about enabling the kickoff feature, see Kickoff and Automatic Kickoff Features and the SteelHead Management Console User’s Guide.

When a SteelHead transitions to fail-to-wire mode, the transition can have an effect on devices connected to the SteelHead. For example, one common implication pertains to the spanning-tree protocol. In many physical in-path deployments, the SteelHead LAN port is connected to an Ethernet switch, and the SteelHead WAN port is connected to a router.

When a SteelHead transitions from bridging mode to failure mode, a switch might force the port that is connected to the SteelHead to go through the 30- to 45-second, nonforwarding states of spanning tree. This can result in packet delay or packet loss.

You can resolve this issue by making configuration modifications on your switch. Depending on your switch vendor, there are many different methods to alleviate this issue, ranging from skipping the nonforwarding states (for example, running the spanning-tree portfast command on Cisco switches), to using newer 802.1d STP protocols that converge faster on link transitions.

RiOS v5.0.x or later has this mode transition issue only when the SteelHead experiences a power loss. RiOS v4.1 and earlier has this transition state issue when the SteelHead experiences a power loss, software failure, or when the optimization service is restarted.

Some network interfaces support fail-to-block mode. In fail-to-block mode, if the SteelHead has an internal software failure or power loss, the SteelHead LAN and WAN interfaces power down and stop bridging traffic. Fail-to-block mode is useful only if the network has a routing or switching infrastructure that can automatically divert traffic from the link after the failed SteelHead blocks it. You can use fail-to-block 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 about connection forwarding and fail-to-block, see Configuring Connection Forwarding with Allow-Failure and Fail-to-Block.

Check the Network and Storage Card Installation Guide on the Riverbed Support site for a current list of SteelHead in-path interfaces that support fail-to-block mode.

This section shows common failure mode configurations using the CLI.