Out-of-Path Deployments
Out-of-Path Deployments
This chapter describes out-of-path deployments and summarizes the basic steps for configuring them. This chapter includes the following sections:
•  Overview of Out-of-Path Deployment
•  Limitations of Out-of-Path Deployments
•  Configuring Out-of-Path Deployments
For information about the factors you must consider before you design and deploy the SteelHead in a network environment, see Choosing the Right SteelHead Model.
Note: Riverbed refers to WCCP and PBR deployments as virtual in-path deployments. This chapter discusses out-of-path deployments, which do not include WCCP or PBR deployments.
This chapter requires that you be familiar with the installation and configuration process for the SteelHead. For details, see the SteelHead Installation and Configuration Guide.
Overview of Out-of-Path Deployment
In an out-of-path deployment, only a SteelHead primary interface is required to connect to the network. The SteelHead can be connected anywhere in the LAN. An out-of-path SteelHead deployment does not have a redirecting device. You configure fixed-target in-path rules for the client-side SteelHead. The fixed-target in-path rules point to the primary IP address of the out-of-path SteelHead. The out-of-path SteelHead uses its primary IP address when communicating to the server. The remote SteelHead must be deployed either in a physical or virtual in-path mode.
Figure: A Fixed-Target In-Path Rule to an Out-of-Path SteelHead Primary IP Address shows an out-of-path deployment.
An out-of-path deployment is generally located on the server-side and is often described as a server-side out-of-path deployment.
You can achieve redundancy by deploying two SteelHeads out-of-path at one location, and by using both of their primary IP addresses in the remote SteelHead fixed-target rule. The fixed-target rule allows the specification of a primary and a backup SteelHead. If the primary SteelHead becomes unreachable, the remote SteelHeads use the backup SteelHead until the primary comes back online. If both out-of-path SteelHeads in a specific fixed-target rule are unavailable, the remote SteelHead passes through this traffic unoptimized. The remote SteelHead does not look for another matching in-path rule in the list.
You can use RiOS data store synchronization between the out-of-path SteelHeads for additional benefits in case of a failure. For details, see RiOS Data Store Synchronization.
You can also implement load balancing with out-of-path deployments by using multiple out-of-path SteelHeads and configuring different remote SteelHeads to use different target out-of-path SteelHeads.
You can target an out-of-path SteelHead for a fixed-target rule. You can do this simultaneously for physical in-path and virtual in-path deployments, and is referred to as a hybrid deployment.
For information about fixed-target in-path rules, see Fixed-Target In-Path Rules.
Limitations of Out-of-Path Deployments
Although the ease of deploying an out-of-path SteelHead might seem appealing, there are serious disadvantages to this method:
•  Connections initiated from the site with the out-of-path SteelHead cannot be optimized.
•  Servers at the site detect the optimized traffic coming not from a client IP address, but from the out-of-path SteelHead primary IP address.
•  In an out-of-path deployment, the primary interface cannot use DHCP.
In certain network environments, a change in the source IP address can be problematic. For some commonly used protocols, SteelHeads automatically make protocol-specific adjustments to account for the IP address change. For example, with CIFS, MAPI, and FTP, there are various places where the IP address of the connecting client can be used within the protocol itself. Because the SteelHead uses application-aware optimization for these protocols, it is able to make the appropriate changes within optimized connections and ensure correct functioning when used in out-of-path deployments. However, there are protocols, such as NFS, that cannot function appropriately when optimizing in an out-of-path configuration.
Important: If you use out-of-path deployments, ensure correct operation by carefully selecting which applications you optimize. Even with protocols in which RiOS specifically adjusts for the change in source IP address on the LAN, there might be authentication, IDS, or IPS systems that generate alarms when this change occurs.
Because of the disadvantages specific to out-of-path deployments, and the requirement of using fixed-target rules, out-of-path deployment is not as widely used as physical or virtual in-path deployments. Out-of-path is primarily used as a way to rapidly deploy a SteelHead in a site with very complex or numerous connections to the WAN.
Configuring Out-of-Path Deployments
Figure: A Fixed-Target In-Path Rule to an Out-of-Path SteelHead Primary IP Address shows a scenario in which fixed-target in-path rules are configured for an out-of-path SteelHead primary interface.
Note: This section provides the basic steps for out-of-path network deployments. It does not provide detailed procedures. Use this section as a general guide.
Figure: A Fixed-Target In-Path Rule to an Out-of-Path SteelHead Primary IP Address
In this example, you configure:
•  SteelHead A with a fixed-target in-path rule specifying that traffic destined to a particular web server at the data center is optimized by the out-of-path SteelHead B.
•  The TCP connection between the out-of-path SteelHead, SteelHead B, and the server uses the SteelHead primary IP address as the source, instead of the client IP address.
To configure a basic out-of-path deployment
1. On SteelHead A, connect to the CLI and enter the following commands:
configure terminal
in-path rule fixed-target target-addr dstaddr dstport 80 rulenum end
2. On SteelHead B, connect to the CLI and enter the following commands:
configure terminal
out-of-path enable