This chapter explains the network services capability when SteelHeads are deployed in an Interceptor cluster. Interceptor clusters allow you to scale the number of SteelHeads deployed for optimization. When coupled with network services, Interceptor clusters provide the ability to redirect optimized and pass-through traffic for centralized visibility and control. You can choose to select the path for optimized and pass-through traffic, redirect all or some traffic for visibility, and apply the QoS marking for optimized and pass-through traffic.

This chapter includes the following sections:

You must be familiar with the path selection sections in the SteelHead Interceptor User’s Guide, the SteelHead Deployment Guide - Protocols and the SteelCentral Controller for SteelHead Deployment Guide. These guides provide a thorough foundation for path selection.

The Interceptor network services feature extends the path selection feature when SteelHeads are deployed in an Interceptor cluster. The key to understanding this feature is that the SteelHead is no longer deployed physically in-path in an Interceptor cluster. This deployment means you must explicitly configure the SteelHead-to-Interceptor in-path interfaces that can reach the gateway IP address in its uplink configuration. Figure: Interceptor cluster deployed in-path shows a serial Interceptor cluster that is deployed in-path and connecting to two WAN edge routers.

Figure: Interceptor cluster deployed in-path shows Interceptor inpath0_0 interfaces connect to the MPLS WAN edge router and inpath0_1 interfaces connect to the INET WAN edge router. The switch is configured as a Layer-3 device and is the gateway for any hosts at the site.

The SteelHead is configured with two uplinks in the site configuration: one uplink to reach the network called MPLS connected to the MPLS WAN edge router and the other uplink to reach the network called INET connected to the INET WAN edge router.

After the Interceptor and SteelHead have the standard connection forwarding configuration applied and path selection is enabled, then the SteelHead requires a configured path selection channel to properly select the path for optimized and pass-through traffic. The SCC simplifies this process by pushing out the configuration necessary to all the devices in the cluster. Path selection channel is how the SteelHead ties an Interceptor in-path interface to the gateway IP address in the uplink for the network.

Figure: Uplinks shows the uplinks configured on the SteelHead. MPLS_Uplink1 uses a gateway of 172.16.191.1 and Internet_Uplink1 uses a gateway of 172.16.192.1.

The SteelHead is a Layer-3 hop away from the gateway IP addresses configured in the uplink and therefore cannot guarantee that traffic is sent to the selected path. The path selection channel ties the gateway IP address in the uplink to the Interceptor in-path interface.

Figure: Channel settings shows the path selection channels configured on the SteelHead. The channels are pushed from the SCC to the appliances in the cluster automatically.

The SteelHead has two possible path selection channels to reach the gateway IP address through two Interceptor in-path interfaces. Only one of the path selection channels is active. The active channel is determined randomly. The SteelHeads in the cluster are not required to use the same path selection channel.

The Interceptors in the cluster already redirect optimized TCP connections to the SteelHead. To redirect other types of IPv4 traffic, the Interceptor uses a Network Services Table that you configure. This table acts much like load-balancing rules for optimized traffic with one notable exception: Traffic is bidirectional so the source or destination is not important; merely the two subnets and/or ports are used.

Choose Networking > Network Services: Network Services Table to display the Network Services Table. For more information, see the SteelHead Interceptor User’s Guide.

The Interceptor network services feature allows you to redirect all or some of the IPv4 traffic (UDP, optimized TCP, pass-through TCP, and preexisting connections) to the SteelHeads in the cluster. This redirection allows you to enable SteelFlow or NetFlow export for the traffic on the SteelHead. You can use QoS marking rules or path selection rules to set the DSCP marking on the SteelHead. You can also select the path based on the path selection policy on the SteelHead. These configurations provide key capabilities with the Interceptor network services feature, namely visibility through flow export and control through path selection and QoS marking. A path selection rule does not have to select a path for flow export to be applied. For example, the SteelHead can report flows with a path selection action to relay the traffic onto the same path through the same Interceptor in-path interface that originally redirected traffic for the connection.

This feature creates the following general use cases. The Interceptors:

These use cases are not mutually exclusive, meaning that you can configure some or all the use cases.

Interceptor path selection is compatible with a single Interceptor or all of the cluster types: serial, parallel, and quad. You can place the SteelHeads on the WAN side or LAN side of the Interceptors. The Interceptors in the cluster can redirect IPv4 traffic of the following types:

Interceptor path selection needs the following requirements:

Path selection has the following limitations:

The following concepts provide further information on the Interceptor path selection feature:

The Interceptors in the cluster are required to use fair peering v2 for optimized connections in the cluster. This mechanism remains in place and does not change with the use of Interceptor path selection.

For more information about fair peering v2, see SteelHead selection.

Interceptors in the cluster use a different logic for pass-through traffic when selecting a SteelHead. First, larger SteelHeads receive more traffic than smaller SteelHeads in the cluster. The Interceptors use a mechanism to distribute the load similar to a WCCP hash. SteelHeads in the cluster that are capable of handling more optimized TCP connections are the key factor that the Interceptors use when calculating the distribution.

Second, the Interceptors attempt to keep traffic for a TCP connection on the same SteelHead. The main purpose is to ensure a single SteelHead processes all the packets for a TCP connection to make sure the SteelHead can use deep packet inspection (DPI) for any path selection rules to detect the application.

Pressure monitoring for WAN optimization operates as normal. There is no new pressure monitoring for path selection, but the Interceptor does consider the current pressure of the SteelHead when calculating the distribution of pass-through TCP connections and UDP traffic. If a SteelHead is in high pressure, then the Interceptors consider that SteelHead at 50 percent of its normal operating capacity and adjust the distribution accordingly. If the SteelHead is in severe pressure, then no new pass-through TCP connections or UDP traffic are redirected to that SteelHead.

The Interceptors in a cluster communicate with each other to maintain a consistent status of connections. This state is considered to be the steady state during normal operation. When an Interceptor has gone down, the cluster is in a nonsteady state.

The nonsteady state is temporary but crucial to consider for path selection decisions. When the cluster is in a temporary nonsteady state, pass-through TCP connections use only header-based rules for path selection decisions. Header-based rules refers to matching traffic using the IP and TCP header information rather than application identification through deep packet inspection (DPI).

An important point is that Interceptor path selection differs from WAN optimization with the use of the allow-failure setting. The allow-failure setting instructs Interceptors in the cluster whether they should or should not redirect new connections when one of the parallel Interceptor peers (or pair of failover Interceptor peers) is down. Interceptor path selection ignores this setting for pass-through traffic. When a parallel Interceptor peer is down, the remaining Interceptors bypass any new pass-through TCP connection and UDP traffic. If availability is required when an Interceptor in the cluster fails, then consider deploying a quad cluster.

The Interceptor and SteelHeads apply an additional packet header when redirecting connections. As such, the Interceptor and SteelHead adjust the TCP MSS field in SYN and SYN/ACK packets to lower the overall size of the data field in order to avoid fragmentation. Also for connections that require fragmentation during redirection to the SteelHead, the Interceptor periodically send out fragmentation-needed messages to the local host to instruct the host to reduce the size of packets to accommodate the additional header. If neither of these mechanisms work, then the Interceptor can fragment packets when redirecting to the SteelHead. This redirection provides a fail-safe in case the TCP MSS or fragmentation-needed messages are not honored.

Interceptors leverage Xbridge in 10G environments to scale to higher throughput, but you must disable Xbridge to use Interceptor network services.

Interceptor 5.5 and later enable the Interceptor to scale to higher throughput environments by more intelligently steering packets to the CPU cores.

You enable the higher throughput by using the CLI command rps enable. You do not need a service restart.

For more information on throughput and applicability, contact your account team.

The order of rule processing remains the same for connections that are optimized. In-path rules on the Interceptor are used to intercept SYN packets on the LAN interface for optimization and load-balance rules select a SteelHead. Load-balance rules also apply to TCP autodiscovery packets on the WAN interface. If the connection is passed through or preexisting, then the Network Services Table is consulted.

Figure: Workflow of rule processing shows how rules are processed when path selection is configured.

Overall the packet flow for optimized connections remains very similar to normal configuration with the notable exception when the SteelHead is selecting a new path for traffic to be delivered over the WAN. The SteelHead encapsulates the optimized WAN traffic with a new GRE-like header to direct the traffic to the specific Interceptor in-path interface to reach the desired gateway IP address.

The packet flow for pass-through traffic requires the SteelHead to choose between the following actions:

The Interceptor network services feature requires that all the Interceptors in the cluster have the same configuration including the connection forwarding configuration. To minimize the number of service restarts required, We recommend the following workflow to enable Interceptor path selection:

Interceptor network services is one component in overall network services configuration. You must configure the rest of the components of the path selection feature such as the topology (including the sites and networks), applications, and path selection rules. In particular, the uplinks use a gateway IP address that is Layer-2 adjacent to an Interceptor in-path IP address. Knowing the gateway IP address and the Interceptor in-path IP address is necessary.

Remember that after the Interceptor network services is available, you define the Network Services Table for all pass-through TCP and UDP traffic. We recommend configuring the same Network Services Table rules on all Interceptors in the cluster, but the rules do not have to be the same for the target SteelHeads.

Depending on the network topology, you can deploy SteelHeads in an Interceptor cluster to use many uplinks in an Interceptor cluster. The reason is because the path selection channels can connect a SteelHead to any Interceptor in-path interface in the cluster. Figure: Interceptor quad cluster example shows a quad Interceptor cluster.

In this topology, the SteelHead in the cluster has two uplinks to the MPLS network: one through the serial Interceptor pair of Interceptor1 and Interceptor2, and another through the serial Interceptor pair of Interceptor3 and Interceptor4. Likewise, the SteelHead has two uplinks to reach the INET network.

In total there are four uplinks configured on the SteelHead. There is a total of eight path selection channels to configure on the SteelHead, as each uplink has two Interceptor in-path interfaces it can use.

When you configure a path selection rule, the SteelHead can have a maximum of three different uplinks with a final action to relay.

In this example (Figure: Path selection channels), as there are four actions to take for traffic, the SteelHead can use MPLS_Uplink1, MPLS_Uplink2, and Internet_Uplink1 in a path selection rule followed by the implicit action that Internet_Uplink2 is used for the relay action provided the routing topology does reconverge to use the final path.