Typically, multiple WAN routers are used at locations where redundancy or high availability is important. With multiple routers, the loss of a single WAN link, or a single WAN router, does not prevent hosts at the locations from reaching WAN resources. SteelHeads can be deployed and configured to maintain the high availability for network access. Additionally, multiple SteelHeads can be deployed and configured so that a SteelHead failure allows new connections to be optimized.

This section covers the following sections:

If one or more SteelHeads are deployed to cover all the links between the LAN switches and the WAN connecting routers, connection forwarding is not required. These deployments are referred to as serial deployments, and they can use multiple SteelHeads (in a Primary and Backup Deployments or Serial Cluster Deployments) to achieve optimization high availability.

If it is impossible or impractical to have all the WAN links covered by a single SteelHead, multiple SteelHeads are used. They must have connection forwarding configured. These deployments are known as parallel deployments. High availability for optimization is achieved by using either the connection forwarding fail-to-block configuration, or by using primary and backup, or serial clustering on each of the parallel links to the WAN.

For more information about connection forwarding, see Connection Forwarding. For more information about fail-to-block mode, see Fail-to-Block Mode.

Riverbed recommends that you use designs that do not require connection forwarding (that is, serial designs) whenever possible. Serial designs require less configuration, and are easier to troubleshoot, than parallel designs. If you need a parallel design, a deployment using the SteelHead Interceptor might have several advantages, including policy-based load-balancing and failover handling.

Using the WAN- or LAN-side HSRP IP address improves the likelihood that optimized connections survive a network outage. To plan this you must understand how the SteelHead learns and reacts to changes in the network. Keep in mind that there are many different network design possibilities, and it is not possible to explain all the caveats here.

By default, the SteelHead uses simplified routing, which learns the association between IP addresses and MAC addresses, and Address Resolution Protocol (ARP), which learns associations between IP addresses and MAC addresses on the same subnet as the in-path interface and MAC addresses.

The SteelHead also builds a table of MAC addresses to the LAN or WAN interface, based on the Ethernet frames that cross through the SteelHead in-path interface. Using these tables, the SteelHead learns which destination MAC address to use for packets the SteelHead originates and the corresponding interface on which to transmit the packet. For example, if local hosts are on the same subnet as the SteelHead in-path interfaces and the WAN routers are using HSRP, the transmitting in-path interface learns all local IP addresses on the same subnet to MAC address, through ARP, through the LAN interface. The SteelHead learns remote IP address-to-MAC address relationships from simplified routing = destination-only through the WAN interface. If the SteelHead has not learned the IP address-to-MAC address relationship through simplified routing or ARP, it follows its default gateway.

When the network experiences an outage, the SteelHead in-path interface that transmits for the connection does not react to the change in the network until there has been a change in the flow of traffic through the transmitting in-path interface. After the flow of traffic changes, the SteelHead in-path interface can learn that the destination is available through the opposite interface (WAN now goes to LAN). For example, using the default simplified routing setting, a SteelHead learns that a remote IP address is associated with the MAC address of the primary WAN router that owns the HSRP virtual MAC. When the primary router WAN circuit fails, the primary router can decrement its HSRP priority and the standby router can preempt the primary router to assume control of the HSRP virtual MAC. When this happens, the transmitting interface learns the HSRP MAC through the LAN interface and can continue transmitting traffic across the WAN for optimized connections.

On the other hand, if the transmitting interface learned the remote IP-to-MAC relationship as the physical interface of the primary router then it needs to detect a packet ricochet to learn that the path across the WAN is actually through the LAN interface. Also, you might need to consider any TCP connections that the SteelHead originates, such as the OOB splice. You can use the protocol connection lan on-oob-timeout drop command.

In certain scenarios, existing optimized connections do not survive: for example, if there is a failure between the SteelHead and a directly connected device, such as the cable is damaged or a device lost power. When a directly connected device fails, the first-hop redundancy protocol such as HSRP detects the failure and a standby device can assume the primary role. However, some features on the SteelHead, such as link state propagation, can also detect the failure and stop connectivity in the associated interface (if the failure affects LAN0_0 then WAN0_0 also stops connectivity). The result is that all paths from the in-path interface that transmit for the optimized connection are in a down state and the optimized connections do not continue. Most applications restart new connections. Link state propagation provides feedback to other devices of the failure, and network protocols can more quickly detect the failure.

The choice of a default gateway is very important in locations with multiple WAN routers. In addition to choosing a default gateway (and simplified routing) that minimizes packet ricochet, HSRP or similar protocols can be used to ensure the loss of a single WAN router does not prevent the SteelHead from transmitting packets over the WAN. Most WAN devices that support HSRP or similar protocols have a link tracking option that allows them to relinquish the HSRP virtual IP address if a WAN link fails; this option should be used when possible.

The following section describes best practices for serial SteelHead deployments at locations with multiple routers. Each of the following scenarios can be modified to use multiple SteelHeads, either in primary and backup or serial cluster configurations. This section covers the following scenarios:

Figure 9‑11 shows a topology consisting of two routers, a single Layer-2 switch, and one SteelHead with a 4-port card. The client and the SteelHead are in the same subnet. The client uses the HSRP virtual IP as its default gateway (10.0.0.1).

In this environment, the in-path gateway for both the inpath0_0 and inpath0_1 interfaces must point to the HSRP virtual IP (10.0.0.1). You do not need to enable simplified routing as the client is on the same subnet as the SteelHead.

Figure 9‑12 shows a topology in which there are two routers, two Layer-2 switches, and one SteelHead with a 4-port card. The client and the SteelHead are in the same subnet. The client uses the HSRP virtual IP as its default gateway (10.0.0.1).

In this environment, the in-path gateway for both the inpath0_0 and inpath0_1 interfaces must point to the HSRP virtual IP (10.0.0.1). You do not need to enable simplified routing because the clients are on the same subnet as the SteelHead.

Figure 9‑13 shows a topology in which there are two routers, a single Layer-3 switch, and a single SteelHead with a 4-port card. The client and the SteelHead are in different subnets. The client is using the Layer-3 switch as its default gateway. The Layer-3 switch does not having any routing protocols configured and relies on the default route to reach other subnets. The default route uses the HSRP IP address as the next hop.

In this environment, the in-path gateway on the inpath0_0 and inpath0_1 interface must use the Layer-3 switch as its default gateway (10.0.0.11) while configuring simplified routing to populate its table based on destination MAC address (CLI command: in-path simplified routing dest-only).

Figure 9‑14 shows a topology in which there are two routers, two Layer-3 switches, and a single SteelHead with a 4-port card. The clients and the SteelHead are in different subnets. The clients are using the Layer-3 switches as their default gateways. The Layer-3 switches do not have any routing protocols configured and relies on the default route to reach other subnets. The default route uses the HSRP IP address as the next hop.

In this environment, the in-path gateway on the inpath0_0 and inpath0_1 interface must use the HSRP address of the Layer-3 switches as its default gateway (10.0.0.254) while configuring simplified routing to populate its table based on destination MAC address (CLI command: in-path simplified routing dest-only).

Connect to the CLI and enter the following commands:

The following section describes best practices for parallel SteelHead deployments at locations with multiple routers. Each of the scenarios that follow can be modified to use additional SteelHeads for each path to the WAN, using either the primary and backup or serial cluster configurations. If you are using multiple SteelHeads on each path, every SteelHead at the location must be configured as a connection-forwarding neighbor for every other SteelHead at the location. This section covers the following scenarios:

This example requires you to have configured your cabling and duplex according to the recommendations described in Cabling and Duplex.

This example makes the following assumptions:

For information about connection forwarding, see Connection Forwarding.

This example requires you to have configured your cabling and duplex according to the recommendations described in Cabling and Duplex.

The following example represents the minimum steps required to configure a SteelHead deployment in which connection forwarding is configured, and both fail-to-block and allow-failure are enabled. This example does not include configuration instruction for features such as the management interface, DNS, and SNMP.

This example makes the following assumptions:

For information about connection forwarding, see Connection Forwarding.

Figure 9‑16 shows a topology in which there are two routers, two Layer-2 switches, and two SteelHeads at the remote location. The client and the SteelHeads are all in the same subnet. The client uses the HSRP virtual IP as its default gateway (10.0.0.1).

In this environment, the in-path gateway on both SteelHeads must point to the HSRP virtual IP (10.0.0.1). You do not need to enable simplified routing because the client is on the same subnet as the SteelHead. You must configure connection forwarding between the two SteelHeads. The connection forwarding path must use the LAN interface of the SteelHeads.

Figure 9‑17 shows a topology in which there are two routers, two Layer-3 switches, and two SteelHeads at the remote location. The clients and the SteelHeads are in different subnets. The clients use the Layer-3 switch as the default gateway. The Layer-3 switch does not having any routing protocols configured and relies on the default route to reach other subnets. The default route uses the HSRP IP address as the next hop.

In this environment, the in-path gateway on both SteelHeads must use the HSRP address of the Layer-3 switches as its default gateway (10.0.0.254) while configuring simplified routing to populate its table based on destination MAC address (CLI command: in-path simplified routing dest-only). You must configure connection forwarding between the two SteelHeads. The connection forwarding path must use the LAN interface of the SteelHeads.

Figure 9‑18 shows a topology similar to Figure 9‑17, but each router has two links going back to the Layer­ 3 switches totaling four links. Each link between the router and switch are independent /29 bit networks. You can configure dynamic routing protocols so that traffic can flow inbound or outbound. You can use this network design to prevent the loss of a single Layer-3 switch from cutting connectivity to the attached router. To ensure traffic is routed to the partner SteelHead during a failure, you can use the two in-path interfaces and deploy the SteelHeads in parallel, (requires larger model than 150, 250 or 550), with connection forwarding, and fail-to-block.

The clients and the SteelHeads are in different subnets and simplified routing is enabled (in-path simplified routing dest-only). To ensure connection forwarding traffic is sent to the LAN side, Riverbed recommends that you configure each in-path interface default gateway to point to the LAN side, the Layer­ 3 switch.

You can configure and deploy routers in an endless number of variations, for example:

Regardless of the variations, the same deployment logic applies. The SteelHeads must cover all the desired paths of traffic to be optimized. You can use up to 10 supported in-path interfaces on the larger SteelHeads. If you have parallel SteelHeads, follow the same simplified routing and connection forwarding guidelines in this section. For information about serial clusters, see Serial Cluster Deployments.