Physical In-Path Deployment Configuration Examples
The following section describes common deployment options. This section includes the following topics:
Configuring a Basic Physical In-Path DeploymentConfiguring a Physical In-Path with Dual Links DeploymentConfiguring a Serial Cluster Deployment with Multiple LinksConfiguring a Basic Physical In-Path Deployment
The simplest physical in-path SteelHead deployment is also the most commonly deployed.
Figure 9‑4. Simple, Physical In-Path Deployment
Basic steps to perform before you deploy a physical in-path SteelHead
Determine the speed for the:
switch interface.router interface.SteelHead primary interface.SteelHead WAN interface.SteelHead LAN interface.Riverbed recommends the following speeds:
Fast Ethernet interfaces - 100 Mb full duplexGigabit interfaces - 1000 Mb full duplexDetermine the IP addresses for the SteelHead. A SteelHead that is deployed in a physical in-path mode requires two IP addresses, one each for the:
SteelHead in-path interface.SteelHead primary interface (used for managing the SteelHead).In addition to using the primary interface for management purposes, you can also use the auxiliary (AUX) interface or the in-path management interface to manage the SteelHead. The AUX interface is another physical interface on the SteelHead, and the in-path management interface is a virtual interface that is associated to the SteelHead in-path interfaces.
When you configure the AUX interface, you cannot have it in the same subnet as the primary interface.
Each one in-path management interface has one in-path interface. For example, inpath0_0 has a corresponding mgmt0_0 interface, inpath0_1 has a corresponding mgmt0_1 interface, and so on. Any connections destined to the in-path management interface are not optimized, and these connections do not appear in the Current Connections report.
The following are characteristics of the in-path management interface:
Must be in its own subnetCannot share the same subnet with any other interfaces on the SteelHead (this includes other in-path interfaces)Is accessible from either the LAN side or WAN sideUses the main routing table and is always upSupports 802.1Q and processes only packets destined to its VLAN ID (if you configure one)Manually configure the speed for the:
switch interface.router interface.SteelHead primary interface.SteelHead WAN interface.SteelHead LAN interface.Configure the appropriate default gateway for the primary and in-path interfaces:
Primary port gateway IP - Specify the primary gateway IP address. In-path gateway IP - Specify the IP address for the in-path gateway. If you have a router (or a Layer-3 switch) on the LAN side of your network, specify this device as the in-path gateway. Make sure that you have simplified routing enabled. Using
Figure 9‑4 as your environment, the following task includes the minimum steps required to configure the simplest physical in-path SteelHead deployment.
The example requires that you have configured your cabling and duplex according to the recommendations described in
Cabling and Duplex.
To configure the SteelHead for basic physical in-path deployment
On the SteelHead, connect to the CLI and enter the following commands:enable
configure terminal
interface inpath0_0 ip address 10.0.0.2 /24
ip in-path-gateway inpath0_0 10.0.0.1
interface primary ip address 10.0.0.3 /24
ip default-gateway 10.0.0.1
in-path enable
Configuring a Physical In-Path with Dual Links Deployment
This example requires that you have configured your cabling and duplex according to the recommendations described in
Cabling and Duplex.
Figure 9‑5 shows a physical in-path with dual links SteelHead deployment.
Simplified routing removes any packet ricochet that occurs when the SteelHead sends traffic to the 10.0.5.0/24 LAN.
Figure 9‑5. Physical In-Path with Dual Links Deployment
The following SteelHead CLI commands are the minimum commands required to configure the physical in-path SteelHead with dual links. These commands do not include the configuration of features such as duplex, alarms, SNMP, and DNS.
To configure a SteelHead physically in-path with dual links
On SteelHead 1, connect to the CLI and enter the following commands:
enable
configure terminal
interface inpath0_0 ip address 10.0.1.3 /24
ip in-path-gateway inpath0_0 10.0.1.2
interface inpath0_1 ip address 10.0.2.3 /24
ip in-path-gateway inpath0_1 10.0.2.2
in-path enable
in-path peering auto
in-path simplified routing all
write memory
restart
Configuring a Serial Cluster Deployment with Multiple Links
This example requires that you have configured your cabling and duplex according to the recommendations described in
Cabling and Duplex.
Figure 9‑6 shows a serial cluster deployment with multiple WAN links. Each of the links are on different subnets, but they might also be in the same subnet.
Link state propagation is enabled between the SteelHeads. For details, see the SteelHead Management Console User’s Guide.
Figure 9‑6. Physical In-Path, Multiple Link Serial Cluster Deployment
The following SteelHead CLI commands are the minimum commands required to configure a serially clustered SteelHead deployment with multiple WAN links. These commands do not include the configuration of features such as duplex, alarms, and DNS.
To configure serially clustered SteelHeads with multiple WAN links
On SteelHead 1, connect to the CLI and enter the following commands:
enable
configure terminal
interface inpath0_0 ip address 10.0.1.4 /24
ip in-path-gateway inpath0_0 10.0.1.2
interface inpath0_1 ip address 10.0.2.4 /24
ip in-path-gateway inpath0_1 10.0.2.2
in-path enable
in-path peering auto
in-path simplified routing dest-only
in-path peering rule pass peer 10.0.1.3 rulenum end
in-path peering rule pass peer 10.0.2.3 rulenum end
write memory
restart
On SteelHead 2, connect to the CLI and enter the following commands:
enable
configure terminal
interface inpath0_0 ip address 10.0.1.3 /24
ip in-path-gateway inpath0_0 10.0.1.2
interface inpath0_1 ip address 10.0.2.3 /24
ip in-path-gateway inpath0_1 10.0.2.2
in-path enable
in-path simplified routing dest-only
in-path peering auto
in-path peering rule pass peer 10.0.1.4 rulenum end
in-path peering rule pass peer 10.0.2.4 rulenum end
write memory
restart