Connecting a SteelHead with a Gateway

SteelConnect and SteelHead integrate with an automatic and seamless service chain for SD-WAN and WAN optimization, providing SD-WAN to SteelHead CX xx70s (or virtual SteelHeads) and WAN optimization to SteelConnect users. The combined products provide a smooth transition from WAN optimization to hybrid networking to SD-WAN.

One of the powerful features of a SteelConnect gateway is its ability to steer applications over a preferred path, as described in Balancing traffic using traffic rules. A SteelConnect gateway and a client-side SteelHead CX deployed on a local network work together to identify, classify, and steer traffic flows. The SteelHead CX optimizes connections, classifies the traffic, and sends application identification information to the gateway. The gateway selects a traffic path based on the application ID provided by the SteelHead CX and steers the traffic over the selected path.

Intelligent path selection is one of the primary benefits of a gateway working with a SteelHead CX xx70. Other benefits include:

By default, SteelConnect compatibility is disabled on the SteelHead CX and disabled globally for an organization in the SteelConnect Manager. SteelHead compatibility must be enabled on both appliances for autodiscovery. You can disable SteelHead compatibility on a specific gateway within an organization.

You can enable or disable SteelHead compatibility for a specific gateway. For details, see Enabling SteelHead compatibility on the gateway automatically.

For details on SteelHead CX CLI commands, see the Riverbed Command-Line Interface Reference Manual. For details on the SteelHead CX xx70, see the SteelHead User’s Guide.

A SteelConnect gateway is compatible with a physical or virtual in-path SteelHead CX when the gateway is running SCM 2.5 or later and the SteelHead CX is running RiOS 9.5 or later.

The SteelConnect gateway watches for marked SYN packets from a SteelHead CX. After it sees one, it polls the SteelHead CX for availability. When the SteelHead CX receives a poll from a compatible SteelConnect gateway in the network path, the two appliances form a persistent TCP connection monitored by a heartbeat. The appliances discover each other and connect automatically using a TCP JavaScript Object Notation (JSON) control channel.

After the SteelHead CX connects with a gateway, it uses the Network Services Header (NSH) protocol to send generic routing encapsulated (GRE) metadata to the gateway on the inner connection between the appliances. The metadata preserves the client and server IP address and port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. When the gateway receives the encapsulated metadata, it deencapsulates it and selects the best path based on the application information received.

The SteelHead CX and SteelConnect gateway connection automatically disables path selection on the SteelHead CX, and it enables path selection on the SteelConnect gateway. In addition, enabling SteelHead compatibility on the SteelHead automatically turns on application inspection and identification. For details, see Balancing traffic using traffic rules.

If the SteelHead CX connection is lost, the gateway tries to reconnect three times and logs the messages for each attempt. It will try to connect again when it receives another probe from the same SteelHead CX.

For the SteelHead CX to connect with a gateway, firewalls need to allow Riverbed TCP options. The SteelHead CX can’t locate a gateway if a firewall strips out the TCP options from optimized packets. You can configure the firewall to ignore or prevent stripping out the TCP option. The Riverbed Support site has Knowledge Base articles that show example configurations to allow discovery through different firewall types.

When the gateway receives metadata about traffic flows from the SteelHead CX, it classifies them based on the current available information. It updates classification decisions based on any new information it receives. The gateway processes traffic flows as follows:

•When the gateway receives the application ID for the optimized connection, it uses it to classify the traffic flow according to the traffic rules.

•When the gateway has no information about the optimized connection, the traffic flow reverts to the default traffic rule. The default rule is a catch-all rule that you can edit to fit your needs. See To create a traffic rule.

These limitations apply to SteelHead compatibility deployments:

•When the SteelHead uses fixed-target rules, WAN optimization works fine; however, the SteelHead can’t apply traffic rules because the gateway doesn’t have visibility into the flow.

By default, SteelHead compatibility is enabled globally for an organization; this topic explains how to reenable it after it has been disabled.

After connecting a gateway with a SteelHead, you can view the event log to see more detail regarding when the LAN-side SteelHeads are connected and communicating (or when the connection is dropped).

On the SteelHead, events such as the gateway connecting with the SteelHead appear in the user log. For details, see the SteelHead User’s Guide.