This chapter describes out-of-path deployments and summarizes the basic steps for configuring them. This chapter includes the following sections:

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.

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.

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.

Although the ease of deploying an out-of-path SteelHead might seem appealing, there are serious disadvantages to this method:

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.

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.

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.

In this example, you configure: