Configuring Path Selection on Interceptor Clusters
This section describes how to configure path selection on Interceptor clusters. It includes these sections:
The SCC extends path selection to operate in Interceptor cluster deployments, providing high-scale and high-availability deployment options. An Interceptor cluster is one or more Interceptors collaborating with one or more SteelHeads to select uplinks dynamically.
Path selection ensures that the right traffic travels to the right path by choosing a predefined WAN gateway for traffic flows in real-time, based on availability. In path selection, you define a path, called an uplink, by specifying a WAN egress point and providing a direction for the egressing packets to take.
SteelHeads select uplinks based on path selection rules and instruct the Interceptor to steer the WAN-bound packets to the chosen uplink. The Interceptor redirects all connections that are path selected to the SteelHead for the lifetime of the connection, including UDPv4 and TCPv4 optimized and unoptimized connections.
Path selection requires compatible configurations on all appliances in the cluster. When path selection is enabled on an appliance in the cluster while not enabled on another, the system considers the cluster to be incompatible and raises an alarm on theSteelHead. This alarm provides the reason for the incompatibility and lists the incompatible Interceptors.
Configuring Path Selection in Cluster Deployments
Before you configure path selection in a cluster deployment, these prerequisites must be met:
• You must be using Interceptor 5.0 or later, RiOS 9.1 or later on the SteelHead, and SCC 9.1 or later.
• You must enable connection-forwarding multi-interface support on each Interceptor and each SteelHead.
• You must make sure that the WAN router does not ricochet packets destined for a remote destination. That is, configure the WAN router to send packets to the WAN (to prevent WAN-bound packets from ricocheting through the LAN).
• You must configure the appropriate subnet-side rules on each SteelHead.
• You must define the accurate subnet in the local site on each SteelHead.
• You must enable fair-peering v2 (FPv2) on each Interceptor.
• The Interceptor must be Layer-2-adjacent to the WAN-edge routers.
For detailed information about path selection limitations, see the SteelHead Interceptor User’s Guide, the SteelHead Interceptor Deployment Guide, and the SteelHead Management Console User’s Guide for SteelHead CX.
Path Selection Push Prerequisites
Path selection pushes have these requirements:
• On the SteelHead, the path selection sites and uplinks must be configured before performing a cluster push on the SCC.
• The in-path interface page on the Interceptor must be configured with the gateway IP address before you perform a cluster push.
• If path selection is disabled on all appliances in cluster, the cluster push is performed without pushing the PSIC channels.
• If path selection is disabled on SteelHeads and enabled on Interceptors in the cluster, or vice a versa, the cluster push fails because it causes connection forwarding to fail.
• If path selection is enabled on all appliances, perform the cluster push along with the PSIC channels.
To configure path selection and path selection rules
1. Choose Manage > Topology: Clusters to display the Clusters page.
2. Click the cluster name to expand the page and display the cluster tabs.
3. Select Cluster Pages > Network Services to display the Editing Cluster page.
Figure: Enabling Path Selection
4. Select Enable Path Selection and click Apply.
5. Click + Add a New Service Rule to expand the page.
Figure: Adding Service Rules
6. Complete the configuration as described in this table.
Control | Description |
Service Rule | Service rules identify the nonoptimized TCP and UDP connections used for path selection or for identifying specific traffic to be passed-through to the SteelHead. Service rules act like load-balancing rules for optimized traffic with one notable exception: the traffic is bidirectional so the source or destination is not important; the rules merely use the two subnets and ports. Service rules only apply to unoptimized traffic. |
Type | Specify how the system handles packets if the default uplinks go down from the drop-down list: • Redirect - Redirects connections to a SteelHead. This is the default value. Typically, you configure a redirect rule for source and destination addresses and ports you want to optimize in the Riverbed system. A separate set of load-balancing rules determines the SteelHead to which the connection is to be redirected. • Pass-through - Passes through traffic unoptimized. For example, you might use pass-through rules to handle HTTP traffic on port 80. |
Protocol | Specify a traffic protocol from the drop-down list: • TCP - Specifies the TCP protocol. Supports TCP-over-IPv4 only. • UDP - Specifies the UDP protocol. Supports UDP-over-IPv4 only. • Any - Specifies all TCP- and UDP-based protocols. This is the default setting. |
Subnet 1/2
Port or Port Label | Specify endpoints for subnet 1 and subnet 2 connections. Use this format: XXX.XXX.XXX.XXX/XX You can specify all or 0.0.0.0/0 as the wildcard for all traffic. |
Local SteelHeads | Select the local SteelHeads from the list to which traffic can be redirected. If a rule matches, connections are redirected to the first SteelHead in the list that has capacity for new connections. If no rule matches, peer affinity applies. If there is no existing peer affinity, the connection is redirected to the SteelHead with the least number of current connections. Note: The target SteelHeads are called cluster SteelHeads. |
Position | Select any of these options from the drop-down list: • Select Start to insert the rule at the start of the list. • Select End to inserts the rule at end of the list. • Select a rule number. The rule type of a matching rule determines which action the Interceptor takes on the connection. |
Description | Specify a description of the rule. |
VLAN Tag ID All Paths/Per Path | Specify a VLAN identification number, or All to apply the rule to all VLANs, or Untagged to apply the rule to nontagged connections. Pass-through traffic maintains any preexisting VLAN tagging between the LAN and WAN interfaces. Note: To complete the implementation of VLAN tagging, you must set the VLAN tag IDs for the in-path interfaces that the Interceptor uses to communicate with other Interceptors. • All Paths - Specify a VLAN identification number from 0 to 4094, or All to apply the rule to all VLANs, or Untagged to apply the rule to nontagged connections. • Per Path - Select to configure a per path VLAN. – Path 1 - Select to specify a VLAN Tag ID from 0 to 4094, or All to apply the rule to all VLANs, or Untagged to apply the rule to nontagged connections. |
Add | Adds the rule to the list. |
Remove Selected | Select the check box next to the name and click Remove Selected Rules. The default rule cannot be removed and is always listed last. |
Move Selected Rules | Moves the selected rules. Click the > next to the desired rule position; the rule moves to the new position. Note: The default rule cannot be reordered and is always listed last. |
7. Click Cluster Operations to display the operations you can perform on this cluster.
Figure: Pushing Path Selection Rules
8. Select Push Cluster Configuration from the drop down list.
9. Click Push to push your settings.
Configuring Channels on Interceptor Clusters
To operate efficiently, path selection on Interceptor clusters requires that cluster channels are set up between the SteelHeads and Interceptors. Cluster channels are traditionally configured on the SteelHead. In SCC 9.2 you can now configure the path selection channels using a site’s uplinks and push the configuration to the appliances. The path-selection cluster channel is automatically configured during the cluster push.
When configuring uplinks on the SteelHead for path selection in a Interceptor cluster, the uplink gateway need not be a Layer 2 hop away from the SteelHead, but it must be a Layer 2 hop away from one or more Interceptors in the cluster.
Each SteelHead must be aware of which Interceptor it can use to reach a particular uplink. You accomplish this by configuring a channel that acts as an overlay tunnel between the SteelHead and the Interceptor. This channel allows the SteelHead to reach an uplink. One or more channels must be configured for every uplink. After the SteelHead has this information, RiOS uses the Riverbed encapsulation protocol (RBEP) when communicating with an Interceptor neighbor.
Path selection with Interceptor cluster deployments assumes that:
• every WAN edge gateway in the network must be defined in the uplink configuration on the SteelHead, and at least one Interceptor must be a Layer 2 hop away from each of those uplink gateways.
• every packet to or from an uplink gateway passes at least one Interceptor in the cluster.
• the uplink gateway does not ricochet any WAN-bound packets toward the LAN, and the SteelHead must have an accurate local site subnet configuration so that the LAN-bound traffic is not path selected.
• the default gateway configuration on the Interceptor can be either on the LAN side or WAN side.
• the path selection WAN gateway configuration on the SteelHead will always be on the WAN side of the Interceptor.
• if the Interceptor default gateway is on the LAN side, you will have to manually configure the PSIC channels.
For detailed information about path selection cluster channels, see the SteelHead Management Console User’s Guide for SteelHead CX, the SteelHead Interceptor User’s Guide, and the SteelHead Interceptor Deployment Guide.
To configure path selection channels on Interceptor clusters
1. On the SteelHead, you must enable connection forwarding multi-interface support on each Interceptor and SteelHead in the cluster. For details, see the SteelHead Management Console User’s Guide for SteelHead CX.
2. On the Interceptors, enable Fair Peering v2 under load-balancing rules, and restart service on the Interceptors. For details, see the SteelHead Interceptor User’s Guide.
4. Create a site for each SteelHead in your cluster. For details, see
Defining Sites.
5. Define the uplinks all local sites. For local sites define the gateway IP address and the interface. There must be at least one path selection channel configured for every uplink.
Figure: Defining Uplinks for Cluster Channels
(The remote site requires the remote subnet and the remote SteelHead peer. You do not need to configure uplinks for the remote site.)
Pushing the cluster configuration establishes the channel between the SteelHead, Interceptor, and the gateway IP address. For detailed information about path selection push prerequisites, see
Path Selection Push Prerequisites.
8. Restart the services on all the Interceptors. For details, see the SteelHead Interceptor User’s Guide.
Improving Performance for Interceptor Path Selection Clusters
RiOS 9.2 and Interceptor 5.5 introduces receive packet steering (RPS) to improve throughput performance on Interceptor path selection clusters. Received packet steering (RPS) distributes the traffic load across Interceptors resulting in better throughput performance. You enable RPS using the Interceptor or SteelHead CLI. This feature has these restrictions:
• Path selection must be enabled on the SteelHead and the SCC.
• XBridge cannot be enabled.
• This feature must be configured via the Interceptor or SteelHead CLI. For detailed information, see the Riverbed Command-Line Interface Reference Manual.
To enable RPS on path selection clusters
1. On the SteelHead or Interceptor in configuration mode. For details, see the Riverbed Command-Line Interface Reference Manual.
2. To enable RPS to improve throughput on Interceptor path selection clusters, at the system prompt enter:
rps enable
You can disable RPS using the no rps enable command.
3. To view RPS status, at the system prompt enter:
show rps