This chapter discusses different types of Interceptor deployments. Typical Interceptor deployments have multiple Interceptors and SteelHeads, and usually all appliances have more than one enabled and configured in-path interface. This chapter includes the following sections:

You can use multiple Interceptors to ensure that optimization occurs even when there are multiple, physically separated paths to the WAN or to ensure that optimization continues during a planned or unplanned Interceptor outage. Use multiple SteelHeads to ensure redundancy or to specify that certain applications, subnets, and hosts are optimized by different SteelHeads.

Designing an Interceptor deployment requires not only configuring the relationship between the Interceptors and SteelHeads, but also understanding how data is exchanged between the SteelHead and Interceptors, and how this data exchange interacts with the existing network, security, and monitoring infrastructure.

This section discusses SteelHead placement and configuration and includes the following topics:

The Interceptor can redirect packets for optimization to up to 25 clustered SteelHeads. For details on how to configure the process that an Interceptor uses to determine which SteelHead to use when redirecting traffic, see Traffic Redirection. For details on VLAN segregation limitations, see Feature compatibility and limitations.

You can’t use SteelHeads in an Interceptor cluster simultaneously with other deployment methods. For example, a SteelHead can’t be both a member of an Interceptor cluster while also a part of a WCCP cluster.

In addition to redirected packets, Interceptors and SteelHeads communicate using TCP connections (TCP destination port 7850 by default) between their in-path interface IP addresses. Because the information exchanged on these connections is vital during autodiscovery, if there is heavy congestion on the LAN network between cluster members, contact your Riverbed account team or Riverbed Support for assistance to use DSCP marking to prioritize cluster traffic.

Figure: SteelHead placed on either the WAN or LAN side of the Interceptor shows how to connect SteelHeads to the local network on either the LAN or WAN side of the Interceptor. For most deployments, LAN-side SteelHead placement minimizes the amount of traffic that traverses the Interceptor. You can’t cable the SteelHead directly to the Interceptor.

In general, placing SteelHeads on the LAN side of the Interceptor typically minimizes the amount of traffic that the Interceptor must handle for optimized traffic. For LAN-side SteelHead placement, the local-host-to-remote-host traffic and reduced SteelHead-to-SteelHead traffic traverse the Interceptor, versus the bidirectional unreduced LAN-side traffic between the SteelHead and the local hosts.

In virtual in-path Interceptor deployments, don’t deploy the SteelHeads in situations in which the traffic traverses a router-redirecting interface. This configuration causes traffic from the SteelHead to be unnecessarily redirected back to the Interceptor.

For more details on virtual in-path Interceptor deployments, see Unsupported virtual in-path Interceptor deployment.

The SteelHead and Interceptor in-path IP addresses can be on the same or different subnets. The actions taken to redirect traffic are the same during autodiscovery and optimization. Unlike when you use WCCP to redirect traffic to a SteelHead, there is no resource use or MTU concerns from having the SteelHead and Interceptor in-path IP addresses on different subnets.

A SteelHead can have multiple in-path interfaces configured, which means that the SteelHead Interceptor can use multiple IP addresses to reach the same SteelHead. Before SteelHead Interceptor 6.5 and SteelHead 9.6, the SteelHead Interceptor could only redirect traffic to one in-path interface on the SteelHead. Essentially, the SteelHead Interceptor used an active/backup method when selecting an in-path interface for redirecting traffic to the SteelHead.

In SteelHead Interceptor 6.5, all configured in-path interfaces can be used in an active/active method. To use the active/active method, the SteelHead Interceptor must have the main-ip address and the additional‑IP addresses configured for the SteelHead, along with enabling support for multiple SteelHead links.

The IP address of the interface is logically associated with the in-path interface, but physically, the WAN interface is actually cabled to the network, as shown in Figure: Example deployment of a SteelHead with two configured in-path interfaces.

If the IP address for that interface becomes unreachable, the Interceptor tries to reach every SteelHead IP address from each of the Interceptor’s in-path interfaces before considering the SteelHead entirely inaccessible.

If a SteelHead in-path interface fails or becomes unreachable from the Interceptor, any existing connections that were being optimized by the SteelHead with that in-path interface are either reset or timed out, depending on the application in use.

When you configure the Interceptor load-balancing rules, only configure a single in-path IP address per SteelHead in the rule set. For example, an Interceptor can have all of the in-path IP addresses of the SteelHeads configured as a SteelHead cluster, but only the inpath0_0 IP address is used in the load-balancing rules.

The SteelHeads in a cluster have each clustered Interceptor configured as a connection-forwarding neighbor, using the steelhead communication commands. Each clustered SteelHead typically has each Interceptor inpath0_0 IP address configured as the clustered SteelHead main-ip and other Interceptor in‑path interfaces configured as additional IP addresses. Don’t configure one clustered SteelHead to know anything about the other clustered SteelHead.

You can use the RiOS data store synchronization between any local pair of SteelHeads, including SteelHead pairs in an Interceptor cluster. You typically perform data synchronization when the load-balance configuration on the Interceptors causes similar traffic to be sent to the pair of SteelHeads.

The SteelHeads in an Interceptor cluster don’t need to be the same model. The Interceptor can make redirection decisions that account for different SteelHead capacities. For details, see Traffic Redirection.

You can deploy the Interceptor at sites with firewalls, intrusion prevention systems (IPS), intrusion detection systems (IDS), or other network security and monitoring devices. Design the Interceptor deployment so that these devices aren’t located in the flow of redirected packets between the Interceptor and SteelHead, because the redirected packets might either prevent the security devices from properly tracking flows or generate unnecessary alarms. Place the network security or monitoring devices on the WAN or LAN side of the complete Interceptor and SteelHead cluster.

If you use a firewall or other security device as a Layer-3 next hop for the Interceptor or SteelHead, configure the routing and default gateway configuration on the Interceptor and SteelHead so the firewall detects all or none of the packets associated with the autodiscovery process.

For details on packet flow between the SteelHead and Interceptors, see Traffic Redirection. For details on routing and default gateways, see Default gateway and routing configuration.

This section demonstrates how to apply placement guidelines for firewalls, SteelHeads, and Interceptors. It includes the following topics:

Figure: An example of a site using firewalls to perform deep packet inspection shows a site where firewalls are used to perform connection tracking and deep packet inspection on traffic arriving from the WAN, and they also must detect the nonoptimized, or native, data for any optimized traffic.

We don’t recommend the firewall, SteelHead, and Interceptor placements shown in Figure: Example of how not to deploy an Interceptor and Figure: SteelHead deployed on the WAN side of the Interceptor.

Figure: Example of how not to deploy an Interceptor shows Interceptors placed outside the firewalls and LAN infrastructure. The SteelHeads are placed on the LAN side of the Interceptor, as recommended.

The SteelHead placement in Figure: Example of how not to deploy an Interceptor is disruptive for the firewalls for at least two reasons:

Figure: SteelHead deployed on the WAN side of the Interceptor shows the Interceptors are deployed as before, but the SteelHeads are now placed on the WAN side of the Interceptor. This placement prevents the firewalls from detecting any Interceptor-to-SteelHead traffic, and the firewalls can detect the native form of any optimized connection. We don’t recommend this configuration because placing SteelHeads logically on the WAN side of the Interceptor typically forces more traffic through the Interceptor than the alternative.

We recommend the firewall, SteelHead, and Interceptor placement shown in Figure: Best firewall, SteelHead, and Interceptor relative deployment option. This figure shows that the Interceptors can cover all of the paths to and from the WAN; the SteelHeads are on the LAN side of the Interceptor, and the firewalls detect the LAN-side traffic so that they can perform all necessary content inspection.

This section discusses relationships between multiple Interceptors. This section includes the following topics:

There are several reasons to deploy more than one Interceptor at the same site:

If you deploy more than one Interceptor per site, you must configure each Interceptor to interact with every other Interceptor in one of two ways:

You can configure the Interceptor to be either a serially connected failover Interceptor acting as a backup for the same network paths, or an Interceptor cluster that covers different network paths or is used in a virtual in-path cluster.

You can configure Interceptor clusters in both serial and parallel deployments. For details, see Deploying quad Interceptors. However, you can configure only serial Interceptors for mutual failover. Interceptors communicate with each other through TCP connections (with a default destination port 7860) using their in-path interface IP addresses. We recommend that you use the default gateway and routing setup to ensure LAN-side next hops to reach other Interceptor in-path interfaces if they are on different subnets.

Because the information exchanged on these connections is vital during autodiscovery, you can manually configure the DSCP markings. This configuration might be beneficial in environments where the LAN infrastructure can recognize and prioritize traffic based on DSCP values. If there is heavy congestion on the LAN network connecting between Interceptors and SteelHeads, contact your Riverbed account team or Riverbed Support for assistance to use DSCP marking to prioritize cluster traffic.

You must deploy failover Interceptors physically in-path on all of the same physical links. Failover Interceptors share information about any flows that are being redirected, as well as information about flows that are going through the autodiscovery process.

For a failover Interceptor configuration with multiple in-path interfaces, you must configure the IP addresses for all interfaces. We recommend that you enable the multi-interface configuration option, even if you use only a single in-path interface.

If a failover Interceptor becomes unavailable, either due to network connectivity issues or because one Interceptor has suffered a failure, the remaining Interceptor continues to redirect packets for existing optimized connections and for any new connections, so that autodiscovery (and potential optimization) can occur.

Serial failover Interceptors are similar to SteelHeads in a serial cluster, in which even in normal operation both Interceptors are actively redirecting traffic.

You can configure only one failover Interceptor per Interceptor. For details on how failover Interceptors communicate, see Traffic Redirection.

Clustered Interceptors, formerly called redirect peers, share information about any flows that are redirected or are going through the autodiscovery process. You deploy clustered Interceptors physically in-path on different physical links or within a virtual in-path cluster. In version 3.0 and later, you can configure clustered Interceptors in the Interceptor Management Console in the Networking > Network Services: SteelHead Interceptor page or in the CLI using the interceptor commands.

You must configure clustered Interceptors with multiple in-path interfaces to have the IP addresses for all interfaces, and you must enable the multi-interface option. (We recommend that you enable the multi-interface option, even if only a single in-path interface is used.)

An Interceptor might have many clustered Interceptors configured. Although there is no hard limit to the number of clustered Interceptors supported, the communication required per Interceptor during autodiscovery acts as a limiting factor to the maximum number. Riverbed tests up to eight clustered appliances per Interceptor. For details on how Interceptor clusters communicate, see Traffic Redirection.

If any clustered Interceptor becomes unavailable, another Interceptor continues to redirect packets for new and existing optimized connections. When an Interceptor redirects packets for autodiscovery on newly established connections, the Interceptor is controlled by a configuration setting called redirect allow-failure.

Avoid using redirect operations in your network design if you use the allow-failure setting to ensure continuing redirection, so that this doesn’t result in asymmetric routing without traffic redirection. For details, see Cluster member failures.

Figure: Example of an unsupported Interceptor deployment shows an example of an unsupported deployment. Interceptors 1 and 2 can’t be failover Interceptors because they aren’t deployed on all of the same in-path links. They can’t be clustered Interceptors because they have a common in-path link.

If an Interceptor that is part of a cluster fails, the impact on the cluster and optimization depends on whether you:

When an Interceptor fails or becomes unreachable, any remaining failover and clustered Interceptors continue to redirect packets for existing optimized connections to the appropriate SteelHead cluster. Enabling redundancy is useful for unplanned failures and for planned maintenance that might require disabling the failed Interceptor or temporarily removing it from the network.

If the failover appliance of an Interceptor becomes unavailable, either due to network connectivity issues or because the failover Interceptor has suffered a failure, the Interceptor continues to redirect packets for existing optimized connections, as well as for any new connections, so that autodiscovery (and potential optimization) can occur.

Figure: Failure of a failover Interceptor shows Interceptor 1 with failover Interceptor 2. You typically configure fail-to-wire mode (instead of fail-to-block) on Interceptors with failover, so that traffic continues to reach remaining failover Interceptors for redirection.

You can configure how Interceptor clusters react to an Interceptor failure. Figure: Failure of a cluster Interceptor shows failed Interceptor 1 with Interceptor 2. If you configure Interceptor 1 for fail-to-block, then all links to or from the WAN pass through Interceptor 2 after the failure. If you configure Interceptor 1 for fail-to-wire, there are links to and from the WAN without redirection coverage after the failure. TCP connections that are routed asymmetrically across links without redirection can’t be optimized. Therefore, an Interceptor must be able to detect if the unavailability of another appliance implies that there are links without redirection coverage.

If any clustered Interceptor becomes unavailable, another Interceptor continues to redirect packets for existing optimized connections. When that appliance redirects packets for autodiscovery on newly established connections, it is controlled by a configuration setting called redirect allow-failure. This setting is similar to the allow-failure feature on SteelHeads.

After a clustered Interceptor is unavailable, another Interceptor forwards packets for autodiscovery if the allow-failure setting is enabled. If the allow-failure setting is disabled, the Interceptor doesn’t redirect new connections until you:

The default setting for redirect allow-failure is disabled. You can configure the redirect allow-failure setting with the interceptor communication allow-failure enable command.

If a SteelHead fails or becomes unreachable, then an Interceptor stops redirecting packets for any optimized connections that were owned by the SteelHead. An Interceptor stops redirecting packets to the SteelHead for autodiscovery.

For details on the allow-failure feature on the SteelHead, see the SteelHead Deployment Guide. For details on how to use multiple SteelHeads for redundancy, see Traffic Redirection.

The Interceptor relationships and failure reaction features are typically combined in several ways for actual Interceptor deployments. You can deploy Interceptor clusters in the following ways:

Figure: Three primary types of Interceptor deployments: series, parallel with fail-to-block, and quad shows the three primary physical in-path types of deployments: series, parallel with fail‑to-block, and quad. In each of these deployment types, optimization of existing and new connections can continue despite the failure of any single Interceptor.

In a series deployment, you install two Interceptors. You configure each Interceptor as the failover Interceptor for the other. Use the default fail-to-wire mode on all Interceptors. Optimization for existing and new connections can continue despite the failure of a single Interceptor.

In a parallel with fail-to-block deployment, you install two Interceptors and configure each as part of the same cluster. In both Interceptors, you disable the fail-to-wire mode and enable the allow-failure option. When an Interceptor fails, it prevents traffic from flowing through its in-path links. You can use this deployment when a network uses a routing or switching protocol that can cause the traffic flow after a failure to continue only along the remaining available paths to the WAN.

In a quad deployment, you install four Interceptors. For each Interceptor, you configure one failover Interceptor and two neighbors, using the default fail-to-wire mode on all Interceptors. In this deployment, optimization for existing and new connections can continue despite the failure of any single Interceptor; if two Interceptors fail, optimization continues as long as the two failed Interceptors aren’t failover peers.

If two Interceptors that are failover peers fail, there is still a path to the WAN, but redirection doesn’t occur on the path. The remaining Interceptors continue to redirect packets for optimized connections, but don’t redirect packets for any new connections. We recommend that in most quad deployments you don’t use the interceptor communication allow-failure enable command.

An exception to this best practice is when you expect a network device to fail, in that a serial pair of Interceptors in a quad cluster are disabled, and the only remaining path to the WAN is covered by the unaffected serial pair in the quad cluster. For example, Figure: Interceptor quad deployment shows that if one of the LAN routers were to fail, the only remaining available path is through the unaffected serial pair of Interceptors. To support this type of scenario, you can consider using the interceptor communication allow-failure enable command similar to how you use the command in a parallel deployment. Note the corresponding command for the SteelHead (steelhead communication allow-failure).

Compared to the parallel deployment, an Interceptor failure in a quad deployment doesn’t cause traffic routing or switching patterns to change, while still allowing optimization to continue.

We recommend that you use the debug validate deployment command when you configure a quad deployment. This command verifies that all devices in the cluster are appropriately configured with each other’s information.

You can use an octal deployment when a quad cluster or more than two Interceptors in parallel aren’t sufficient. For example, diverse cable paths require more than a pair of serial Interceptors, or if you are using fail-to-wire.

In an octal deployment, you install eight Interceptors. For each Interceptor you configure one failover Interceptor and six neighbors, using the default fail-to-wire mode on all Interceptors. In the octal deployment, optimization for existing and new connections continue despite the failure of any single Interceptor; if two Interceptors fail, optimization continues as long as the two failed Interceptors aren’t failover peers.

If two Interceptors that are failover peers fail, there is still a path to the WAN, but redirection doesn’t occur on the path. The remaining Interceptors continue to redirect packets for optimized connections, but they don’t redirect packets for any new connections.

In most octal deployments, we recommend that you don’t use the interceptor communication allow-failure enable command. An exception to this best practice is when you expect a network device to fail; in that a serial pair of Interceptors in a octal cluster are disabled, and the only remaining path to the WAN is covered by the unaffected serial pairs in the octal cluster. For example, Figure: Interceptor octal deployment shows that if one of the Layer-3 LAN clouds failed, the only remaining available path is through the unaffected serial pair of Interceptors. To support this type of scenario, you can consider using the interceptor communication allow-failure enable command similar to how you use the command in a parallel deployment. The corresponding command for the SteelHead is steelhead communication allow-failure.

Compared to a parallel deployment, an Interceptor failure in an octal deployment doesn’t cause traffic routing or switching patterns to change, and it continues to allow traffic optimization.

We recommend that you use the debug validate deployment command when you configure an octal deployment. This command verifies that all devices in the cluster are appropriately configured with each other’s information.

In a virtual in-path Interceptor cluster, you install two or more Interceptors in a cluster as neighbor Interceptors rather than failover Interceptors. Configure each Interceptor as a neighbor for the others and enable the interceptor communication allow-failure enable command. Unlike physical in-path clusters, virtual in-path clusters rely on the redirecting network device to determine failover to remaining Interceptors. For instance, Interceptors deployed with WCCP have the same time-out period of up to 30 seconds before a router recognizes an Interceptor failure.

In a virtual in-path SteelHead cluster, you must plan carefully to determine what traffic is redirected to the SteelHeads. You must often use mask assignment or multiple service groups with WCCP, and you can use multiple next hops and different permit sequences with PBR. The main advantage of using virtual in-path Interceptors instead of direct virtual in-path SteelHeads is that the Interceptor intelligent load-balancing algorithms are still used to determine SteelHead redirection. It isn’t as critical to plan which Interceptor receives what traffic, because all Interceptors in the cluster exchange information and redirect consistently to the SteelHeads.

You can choose a cluster type depending on the:

Series deployments provide single failure redundancy. In dual failures, traffic continues to flow to the WAN on the original network path. Series deployments can’t be used when:

Parallel with fail-to-block deployments also provide single failure redundancy and are used when there are more in-path links than can be covered with a single Interceptor. If the data traversing through all of the links to the WAN exceed the specifications of a single Interceptor model, then you can use a parallel with fail-to-block deployment to reduce the amount of data any single Interceptor would process during normal operation. When an Interceptor fails, these deployments alter the path of data in the network and cause remaining Interceptors and links to process all of the data to the WAN.

Quad deployments provide single Interceptor failure redundancy. Dual Interceptor failure redundancy is possible if the failed Interceptors aren’t failover peers. If you configure the Interceptors as failover peers, then a path to the WAN doesn’t have redirection coverage. In this case, the asymmetric route detection of the SteelHead still functions, but for some asymmetric flows, the SteelHeads recognize asymmetry due to initial application connection failures. In any single Interceptor failure scenario, all flows continue to be optimized, and new connections continue to go through autodiscovery. A single Interceptor failure doesn’t cause the alteration of the path of data to the WAN.

For most physical in-path deployments, we recommend series deployments. If there are too many WAN links for a series deployment, we recommend quad deployment. The quad deployment handles failure more efficiently than the parallel with the fail-to-block option, both for single and double Interceptor failures.

You can deploy virtual in-path deployments for data center environments in which you can’t have or don’t want physical in-line devices, but you need SteelHead-aware load balancing. For most environments, physical in-path deployments are recommended.

In an Interceptor topology, the Interceptors communicate with other Interceptors and SteelHeads, while the SteelHeads communicate with only the Interceptors. Load-balancing rules govern the communication between the Interceptor and SteelHead. You don’t need to configure a specific CLI command: allow-failure or no allow-failure.

The following table shows the Interceptor and SteelHead connection forwarding settings for allow-failure given an Interceptor topology.