All SteelHeads ship with at least one pair of ports that are used for in-path deployments. This pair of ports forms the logical in-path interface. The logical in-path interface acts as an independent, two-port bridge, with its own IP address. This section includes the following topics:

Figure 9‑2 shows the SteelHead logical in-path interface and how it is physically connected to network devices in a single subnet, in-path deployment.

The simplest in-path SteelHead has two IP addresses:

Several types of network interface cards (bypass cards) are available for SteelHeads. The desktop SteelHeads have network bypass functionality built in. With 1U and 3U systems, you can choose the type of bypass card. SteelHeads can have both copper and fiber Ethernet bypass cards.

For information about bypass cards, see the Network and Storage Card Installation Guide on the Riverbed Support site.

An IP address is required for each SteelHead in-path interface. When using correct addressing or port transparency, the IP address must be reachable by remote SteelHeads for optimization to occur.

In some environments, the link between the switch and the router might reside in a subnet that has no available IP address. You can use the following solutions to accommodate the IP address requirement:

With RiOS v5.0.x or later, you can deploy SteelHeads so that the in-path interface IP address is not actually used. This deployment option can be useful for integrating with certain network configurations, such as NAT. However, an IP address must be configured for each enabled in-path interface.

For information about correct addressing, port transparency, and full transparency, see WAN Visibility Modes. For more information about deploying a SteelHead into an existing network, see the Riverbed Knowledge Base article SteelHead Deployment onto an Existing /30 Network at https://supportkb.riverbed.com/support/index?page=content&id=S14964.

Almost all in-path deployments require the configuration of a default gateway for the in-path interfaces. A physical in-path SteelHead might need to transmit packets from its in-path interface to any:

You must configure an in-path gateway if any of these devices is on a different subnet from the in-path interface.

In small branches, where a SteelHead is physically placed between an access switch and a router or firewall, and all hosts are on the same subnet, then the in-path default gateway must use the same IP address that the local hosts use—that of the router or firewall. With this configuration, the SteelHead uses the gateway as the Layer-2 next hop when transmitting to remote hosts or SteelHeads, and uses MAC address discovery through ARP when transmitting packets to the local hosts.

In larger branches, where the SteelHead are deployed between two Layer-3 devices (for example, between a Layer-3 switch and a WAN-side router), then the SteelHead can be configured with a specific in-path gateway, static routes, and simplified routing to ensure that it always transmits packets to the optimal next hop. Although it is impossible to generalize for all environments, a typical configuration for locations that minimize packet ricochet and ensure the best performance:

Some environments require different settings or additional configuration. For more information, see the Riverbed Support site at https://support.riverbed.com.