Overview of the SteelHead Interceptor

Feature	Description
Connection tracing	Connection tracing allows you to identify the SteelHeads to which the SteelHead Interceptor has forwarded specific connections. Connection tracing also allows you to debug failing or unoptimized connections or failing pass-through path-selection connections (if the path selection feature is enabled). Note: For details on setting connection tracing, see the SteelHead Interceptor User’s Guide.
EtherChannel deployment	The SteelHead Interceptor can operate within an EtherChannel deployment. In an EtherChannel deployment, all the links in the channel must pass through the same SteelHead Interceptor. These two configurations are supported: up to four channels with two links per channel group, or up to two channels with four links per channel group.
Failover	You can configure a pair of SteelHead Interceptors for failover. In the event that one SteelHead Interceptor goes down or requires maintenance, the second SteelHead Interceptor configured for failover ensures uninterrupted service. Note: For details on setting failover, see the SteelHead Interceptor User’s Guide. You can configure a SteelHead Interceptor 9350 as the failover appliance for a SteelHead Interceptor 9600 if you enable the 9350-mode on the SteelHead Interceptor 9600. The 9350-mode is enabled by using the appliance operating-mode 9350 command. Note: For more information about the appliance operating-mode 9350 command, see the Riverbed Command-Line Interface Reference Manual.
In-path rules	When the SteelHead Interceptor intercepts a SYN request to a server, the in-path rules you configure determine the subnets and ports for traffic to be optimized. You can specify in-path rules to pass through, discard, deny traffic, or to forward and optimize it. In the case of a data center, the SteelHead Interceptor intercepts SYN requests when a data center server establishes a connection with a client that resides outside of the data center. In the connection-processing decision tree, in-path rules are processed before load-balancing rules. Only traffic selected for forwarding proceeds to load-balancing rules processing. Traffic selected for pass-through proceeds to service rule processing if path selection is enabled. Note: For details on setting in-path rules and path selection, see the SteelHead Interceptor User’s Guide.
Intelligent forwarding	Intelligent forwarding prevents the SteelHead Interceptor from forwarding the same packet to the SteelHead more than once. This feature prevents loops in case the packet that was already processed is routed through the SteelHead Interceptor again.
Interceptor monitoring	Cluster SteelHead Interceptors include both failover pairs deployed in a serial configuration and SteelHead Interceptors deployed in a parallel configuration to handle asymmetric routes. Asymmetric routing can cause the response from the server to be routed along a different physical network path from the original request, and a different SteelHead Interceptor can be on each of these paths. When you deploy SteelHead Interceptors in parallel, the first SteelHead Interceptor that receives a packet forwards the packets to the appropriate SteelHead.
Link state detection and link state propagation	The SteelHead Interceptor monitors the link state of devices in its path, including routers, switches, interfaces, and in-path interfaces. When the link state changes for a device that is part of a bridge, the link state change is propagated to the other devices on the bridge as well.
Load-Balancing Rules	For connections selected by an in-path redirect rule, the SteelHead Interceptor distributes the connection to the most appropriate SteelHead based on rules you configure, intelligence from monitoring cluster SteelHeads, and the RiOS connection distribution algorithm. The SteelHead Interceptor combines two approaches to load balancing: • Peer affinity - The SteelHead Interceptor sends the connection to the local SteelHead with the most affinity (that is, the local SteelHead that has received the greatest number of connections from the remote SteelHead). • Round-robin distribution - Instead of checking the SteelHeads in order of most to least peer affinity, the SteelHeads are checked for availability in round-robin order starting with the one after the SteelHead that received the last connection from that rule. Note: Round-robin distribution can be enabled using the CLI only. It cannot be configured using the GUI. Note: For details on setting load-balancing rules (including information on Fair Peering V2 as it relates to load balancing), see the SteelHead Interceptor User’s Guide.
Peer affinity	Peer affinity refers to an established connection relationship between remote and cluster SteelHeads. Affinity-based load balancing matches traffic from a remote SteelHead to a specific cluster SteelHead based on a previous connection between them. Note: If no local SteelHead is currently handling the remote SteelHead, then the SteelHead Interceptor directs the traffic to the SteelHead with the lowest connection count. If the SteelHead with the best peer affinity is unavailable, the SteelHead Interceptor attempts to use the SteelHead with the next best affinity.
Port labels	Port labels enable you to apply rules to a range of ports. The SteelHead Interceptor provides port labels for secure and interactive ports, and for Riverbed Technology (RBT) ports. You can create additional labels as needed.
Path selection	RiOS 9.1.0 and later extends path selection to operate in SteelHead Interceptor cluster deployments, providing high-scale and high-availability deployment options. A SteelHead Interceptor cluster is one or more SteelHead Interceptors collaborating with one or more SteelHead appliances to select paths dynamically in complex architectures working together as a single solution. You can configure service rules to specify whether UDP traffic flows should be subject to path selection (that is, redirected to a SteelHead appliance or relayed without being path selected). Note: For details on enabling path selection and configuring service rules, see the SteelHead Interceptor User’s Guide.
Reporting	The SteelHead Interceptor reporting feature allows you to generate interface counter reports, generate diagnostic reports (to check CPU utilization, memory paging, and system logs), and export data.
SteelHead monitoring	Cluster SteelHeads are the pool of SteelHeads for which the SteelHead Interceptor monitors capacity and balances load. To assist in deployment tuning and troubleshooting, the SteelHead Interceptor can monitor SteelHeads for connectivity, health, and load balancing (if pressure monitoring is enabled).
System status	The Dashboard displays system status information such as the system uptime, service uptime, SteelHead Interceptors, and SteelHead connections.
VLAN tagging	The SteelHead Interceptor supports VLAN-tagged connections in VLAN-trunked links. The SteelHead Interceptor supports VLAN 802.1q. Note: The SteelHead Interceptor does not support the Cisco InterSwitch Link (ISL) protocol.

Feature	Description
Allow failure	Allow failure ensures optimized traffic. When contact between two designated SteelHead Interceptors is lost, the remaining SteelHead Interceptor keeps forwarding connections to ensure that optimization continues. In a parallel configuration, consider enabling this feature if no asymmetric routing is expected in the network. Also note that in a parallel configuration using path selection, pass-through traffic will not be able to use path selection if the SteelHead Interceptor is disconnected. In a serial configuration, redundancy is provided by default. This feature is configured in the Networking > Network Services: In-Path Interfaces page. For details, see the SteelHead Interceptor User’s Guide.
Cluster SteelHead Interceptor	When this feature is enabled, SteelHead Interceptors notify each other when they intercept specific packets. For example, during a connection setup phase, when SteelHead Interceptor A receives a SYN packet, it notifies SteelHead Interceptor B, so that when SteelHead Interceptor B sees the SYN/ACK, it forwards it to the appropriate SteelHead. (During the data phase, both SteelHead Interceptors pass subsequent connections directly to the appropriate SteelHeads.)
Fail-to-block	When fail-to-block is enabled, a failed SteelHead Interceptor blocks any network traffic on its path, as opposed to passing it through. In a parallel configuration, fail-to-block should be enabled to force all traffic through a cluster SteelHead Interceptor, thereby enabling optimization to continue. This feature is configured in the Networking > Networking: In-Path Interfaces page. For details, see the SteelHead Interceptor User’s Guide.
Fail-to-wire (bypass)	When fail-to-wire (bypass) is enabled, a failed SteelHead Interceptor passes through network traffic. In a serial or quad configuration, fail-to-wire should be enabled to pass all traffic through to the cluster or failover SteelHead Interceptor, thereby enabling optimization to continue. This feature is configured in the Networking > Networking: In-Path Interfaces page. For details, see the SteelHead Interceptor User’s Guide.
Failover	Failover enables you to specify a failover counterpart. When failover is configured, a failover SteelHead Interceptor takes over for a failed SteelHead Interceptor. In a serial configuration, you configure the serial SteelHead Interceptors for mutual failover. For details, see the SteelHead Interceptor User’s Guide.

Riverbed CLI configuration requirements	Software system requirements
One of the following: • An ASCII terminal or emulator that can connect to the serial console (9600 baud, 8 bits, no parity, 1 stop bit, and no flow control) • A computer with a Secure Shell (SSH) client that is connected by an IP network to the appliance primary interface	Secure Shell (SSH). Free SSH clients include PuTTY for Windows computers, OpenSSH for many UNIX and UNIX-like operating systems, and Cygwin.

Riverbed component	Software requirements
Interceptor Management Console	Any computer that supports a web browser with a color image display. The Management Console has been tested with the following browsers: • Mozilla Firefox 10.0 and 31 ESR • Microsoft Internet Explorer 7.0, 8.0, and 9.0 • Google Chrome JavaScript and cookies must be enabled in your web browser.