You manage Interceptor clusters under Manage > Topology: Clusters. Appliance clusters are sets of appliances collaborating to provide optimization in complex architectures. Clusters both distribute load across multiple appliances and provide high-availability failover capabilities. The SCC enables you to configure and manage clusters in a unified way.

Interceptors work in conjunction with SteelHeads. The topology you choose for your appliances defines the configurations of the Interceptor.

You configure Interceptors that aren’t in clusters the same way you configure SteelHeads. You define policies and apply them to a single Interceptor or groups of Interceptors.

We recommend that you use the SCC to manage appliance clusters for these reasons:

The SCC supports IPv6 addresses in load-balancing and in-path rules. The SCC doesn’t support VLAN segregation in Interceptor 4.0 and later. For details about the Interceptor, see the SteelHead Interceptor Deployment Guide or the SteelHead Interceptor User Guide.

You define a cluster under Manage > Topology: Clusters. A configuration wizard guides you through the initial configuration of a cluster. After you run the wizard, you can customize additional appliance cluster settings, such as modifying the topology or adding Interceptors or SteelHeads. You can add up to four path clusters using the configuration wizard.

Before configuring the system topology, read the deployment information available in the SteelHead Interceptor Deployment Guide.

The cluster configuration can automatically generate certain policy pages for appliances in the cluster.

Click + Add a New Cluster to expand the page, and then click + Add a New Cluster to expand the page. Click Launch Cluster Configuration Wizard to launch the wizard and display the Welcome page, and then click Next to display the Basic Cluster Settings page. These configuration options are available:

Specifies the name of the cluster.

Provides a description to help you administer the cluster. Descriptions must not use any character other than letters, numbers, underscore, space, or backslash (directory separator).

Connection forwarding defines how the appliance communicates with the other Interceptors or appliances in the communication list. For details about connection forwarding settings, see the SteelHead Interceptor User Guide.

Click Apply & Continue to display the Topology Settings page. These configuration options are available:

Specifies the topology you want to deploy:

If you’re using multiple Interceptors, configure them as part of the cluster.

For detailed information about topology settings, see the SteelHead Interceptor Deployment Guide.

Specifies your Interceptors.

For failover you deploy two Interceptors physically in-path on all of the same physical links, and each appliance is configured to act as a backup for the other appliance for the same network links. If one appliance goes down or needs maintenance, the failover appliance redirects the connections over those links. For details about configuring failover, see the SteelHead Interceptor User Guide.

Click Next to display Other Topology Settings page. These configuration options are available:

Specifies a unique name for the path label. Path labels must use characters that are alphanumeric, underscore, hyphen, or spaces.

Specifies a unique name for each selected Interceptor.

Click Apply & Continue to display the Add SteelHeads page, and then select the SteelHeads you want to add to the cluster and click Next to display the SteelHeads Labels page. Specify a unique label for each SteelHead, and click Apply & Continue to display the Summary page. Click Show Cluster Summary to review a summary of your configuration settings. Optionally, click the links on the Summary page to configure in-path and load-balancing rules. Click Close to close the wizard. The cluster is displayed in the clusters table.

After the new cluster is created, click Run cluster wizard to make any changes to the settings, including the cluster name. For details about editing a cluster, see Configuring path selection on Interceptor clusters.

You can configure cluster in-path rules under Manage > Appliances: Clusters. Click the cluster name to expand the page and display the cluster tabs, and then select the Cluster Pages tab to expand the page.

Select Inpath Rules (Interceptor) to display the Editing Cluster: <cluster name>, Inpath Rules (Interceptor) page.

These configuration options are available:

Specifies the type of rule:

Periodically sends an email reminder to evaluate in-path pass-through rules. Frequently, pass-through in-path rules are created as a temporary workaround for an acute problem. These rules often end up becoming permanent because the administrator forgets to remove them. This field is active only when you specify a pass-through rule. You can’t create notifications for other types of rules. By default, this option is enabled. Notifications are sent if one pass-through rule has this value enabled, even if other pass-through rules have this value disabled. Email is sent every 15 days.

The Email Settings: Send Reminder of Pass-through Rules via Email option must also be enabled for SteelHead policies for notifications to be sent. For details, see Email.

Specifies the source subnet:

Specifies one of these options for the destination subnet:

Specifies the destination port number, port label, or All.

Specifies Start, End, or a rule number from the drop-down list. Interceptors evaluate rules in numerical order starting with rule 1. If the conditions set in the rule match, then the rule is applied, and the system moves on to the next packet. If the conditions set in the rule don’t match, the system consults the next rule. For example, if the conditions of rule 1 don’t match, rule 2 is consulted. If rule 2 matches the conditions, it is applied, and no further rules are consulted.

In general, list rules appear in this order:

1. Deny 2. Discard 3. Pass-through 4. Fixed-target 5. Auto-Discover

The default rule, Auto-Discover, which optimizes all remaining traffic that hasn’t been selected by another rule, can’t be removed and is always listed last.

Describes the rule to facilitate administration.

Enables the rule by selecting the check box.

Specifies 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.

Pass-through traffic maintains any preexisting VLAN tagging between the LAN and WAN interfaces.

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.

Adds the rule to the list.

You can configure cluster load-balancing rules under Manage > Appliances: Clusters. Click the cluster name to expand the page and display the cluster tabs, and then Select the Cluster Pages tab to expand the page.

Select Load Balancing Rules to display the Editing Cluster: <cluster name>, Load Balancing Rules page.

Any changes made to the cluster configuration pages modify all the Interceptors after a cluster push.

Load-balancing rules define the characteristics by which traffic is selected for load-balancing and the availability of a LAN-side SteelHead for such traffic.

Load-balancing rules define the characteristics by which traffic is selected for load balancing and the availability of a local SteelHead for such traffic. Load balancing often involves Interceptor working together with SteelHeads.

Your load-balancing rules must account for these conditions:

This table describes how the Interceptor processes load-balancing rules.

When the Interceptor is running in standard mode, you can enable the Fair Peering feature for each load-balancing rule, including the default rule.

When the Fair Peering feature is enabled for a load-balancing rule, the target SteelHead cannot exceed a dynamically determined maximum number of remote SteelHeads. When that maximum is reached, peer connections are reassigned. For example, when the maximum limit for one local SteelHead is reached, the load shifts to another local SteelHead.

If a new remote SteelHead comes online, a new maximum value is dynamically computed. As a result, the Fair Peering feature ensures that all remote SteelHeads are always covered. This feature is an alternative to the default load-balancing algorithm which, when a new remote SteelHead is assigned to a local cluster, determines the appropriate local SteelHead to which the new connection should be directed.

Prior to using Fair Peering, be aware of these limitations:

Pressure monitoring provides details about the health of the local SteelHeads, so that the Interceptor can better manage and balance traffic. Pressure parameters that are measured include available memory, CPU utilization, and disk load. All three pressures are treated equally, and the Interceptor sends a consolidated message to indicate one of these states: normal, high, or severe.

The value is determined as follows:

The SteelHeads report displays the pressure values. When the pressure monitoring feature is enabled, pressures are reported but do not necessarily affect the load-balancing functionality of the Interceptor. However, when this feature is enabled together with the Fair Peering v2 (“capacity adjustment”) option, the Interceptor implements the pressure measurements into load balancing based on the credits available in each SteelHead.

Each SteelHead is assigned credits based on its model number. The credit is equivalent to the SteelHead size used in Fair Peering. The credits determine the percentage of total load a SteelHead can handle in the cluster.

When Fair Peering v2, pressure monitoring, and capacity adjustment are enabled, the pressure data from a SteelHead determines the credits assigned to it and, as a result, the percentage of connections assigned to that SteelHead. For example, if two SteelHeads (LSH1 and LSH2) have credits 250 and 750, respectively, then the Interceptor sends 25 percent of the load to LSH1 and 75 percent to LSH2.

Specifically, when pressure data changes, SteelHead credits are affected as follows:

Pressure readings are not polled. Rather, SteelHeads report only changes to pressure states.

When the path selection feature is enabled, service rules specify one or more SteelHeads to which unoptimized traffic is redirected.

The Interceptor uses a hashing mechanism to select the SteelHead. The hashing mechanism takes into account the weight of the SteelHead as derived from the connection capacity of the SteelHead. This method allows a SteelHead with a larger connection capacity to receive more redirected traffic than a SteelHead with a smaller connection capacity, assuming both SteelHeads were configured in the same service rule. The hash used to pick a SteelHead from the service rule that matches the traffic flow is derived from the SRC IP address, the DST IP address, the SRC Port, and the DST Port settings of the traffic flow.

When pressure monitoring is enabled, the weight of the SteelHead is adjusted as follows:

The weight of the SteelHead controls the number new connections and flows that will be redirected to the SteelHead. The weight does not change the connections that are already being redirected to the SteelHead.

The location of the Load Balancing Rules page depends on whether the appliance is running in standard mode or VLAN segregation mode:

In VLAN segregation mode, Fair Peering v2 is enabled by default, and it cannot be disabled. For this reason, the check box control for enabling Fair Peering v2 is not displayed on the Load Balancing Rules page when the Interceptor is running in VLAN segregation mode.

Enables the Fair Peering v2 feature across all load-balancing rules. The Fair Peering v2 feature ensures that no local SteelHead exceeds a dynamically determined maximum number of remote peers.

By default, the Interceptor selects the target SteelHead on the basis of peer affinity (based on which candidate SteelHead has been used to optimize connections to or from the remote site in the past).

If you enable Fair Peering v2, this global setting overrides any traditional Fair Peering enabled on a per-rule basis.

Fair Peering v2 is supported with Interceptor version 3.0 and later and local SteelHeads running RiOS 6.1.3 or later.

Provides more detailed information about the health of the local SteelHeads, to enable the Interceptor to better manage and balance traffic.

We recommend that you enable pressure monitoring only in conjunction with Fair Peering v2.

Reduces the number of new connections sent to local SteelHeads for which the Interceptor determines an unacceptable pressure value. For a local SteelHead with an unacceptable pressure value, this feature artificially and temporarily reduces the capacity of the SteelHead for Interceptor load-balancing calculations. As a result of using a downward-adjusted capacity for a particular SteelHead, the Interceptor moves existing paired peers from that SteelHead to less-used SteelHeads.

The Interceptor uses the artificially reduced capacity value for that Interceptor in load-balancing calculations until the SteelHead returns to a Normal pressure value.

Causes capacity reduction—once triggered for a local SteelHead that reaches an unacceptably high pressure value—to be permanent.

To disable permanent capacity adjustment of a SteelHead, you must issue a service restart on the Interceptor.

Displays the controls to add a new rule.

Specifies the type of rule from the drop-down list:

When path selection is enabled, if traffic matches the pass-through rule, the service rule table further evaluates the traffic.

Specifies one of these position from the drop-down list:

Enables email notification of pass-through rules. Specify the email address using the Email page.

This option is available for pass-through rules only and is enabled by default. This option is disabled for redirect rules.

Specifies a comma-separated list of SteelHead IP addresses 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.

The target SteelHeads are called cluster SteelHeads. The list you specify here must match the main IP addresses specified in the SteelHeads list.

If IPv6 connection forwarding is enabled, you can enter IPv6 addresses only. Use this format: x:x:x::x/xxx

Specifies the subnet IP address and netmask for the source network:

Specifies the subnet IP address and netmask for the destination network:

Specifies the destination port number, port label, or All. Click Port Label to go to the Networking > Network Services: Port Labels page for reference.

If you order rules so that traffic that is passed through, discarded, or denied is filtered first, All represents all remaining ports.

Specifies one of these options from the drop-down list:

Specifies a comma-separated list of SteelHead IP addresses (if you specify IP Address for the From Remote SteelHeads setting). You can enter either IPv4 or IPv6 addresses.

Specifies a VLAN identification number from 0 to 4094, 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.

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.

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.

Describes the rule.

Enables the traditional (v1) Fair Peering feature for the custom load-balancing rule.

If you enable traditional Fair Peering for this rule, this per-rule setting is overridden if Fair Peering v2 is enabled for load balancing.

Adds the new rule to the configuration. The new rule displays in the list at the top of the page.

Removes the selected rule. Select the check box next to the name and click Remove Selected Rules.

The default rule cannot be removed and is always listed last.

Moves the selected rules. Click the arrow next to the desired rule position; the rule moves to the new position.

The default rule cannot be reordered and is always listed last.

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 the SteelHead. This alarm provides the reason for the incompatibility and lists the incompatible Interceptors.

Before you configure path selection in a cluster deployment, these prerequisites must be met:

For detailed information about path selection limitations, see the SteelHead Interceptor User Guide, the SteelHead Interceptor Deployment Guide, and the SteelHead User Guide.

Path selection pushes have these requirements:

You can configure path selection and path selection rules under Manage > Topology: Clusters. Click the cluster name to expand the page and display the cluster tabs, and then choose Cluster Pages > Network Services to display the Editing Cluster page.

Select Enable Path Selection and click Apply, and then click + Add a New Service Rule to expand the page.

These configuration options are available:

Identifies 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 isn’t important; the rules merely use the two subnets and ports. Service rules only apply to unoptimized traffic.

Specifies how the system handles packets if the default uplinks go down from the drop-down list:

Specifies a traffic protocol from the drop-down list:

Specifies 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.

Specifies 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.

The target SteelHeads are called cluster SteelHeads.

Specifies any of these options from the drop-down list:

The rule type of a matching rule determines which action the Interceptor takes on the connection.

Provides a description of the rule.

Specifies 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.

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.

Adds the rule to the list.

Click Cluster Operations to display the operations you can perform on this cluster.

Select Push Cluster Configuration from the drop-down list. Click Push to push your settings.

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 and later, 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 an 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:

For detailed information about path selection cluster channels, see the SteelHead User Guide, the SteelHead Interceptor User Guide, and the SteelHead Interceptor Deployment Guide.

To configure path selection channels on Interceptor clusters, on the SteelHead you must enable connection forwarding multi-interface support on each Interceptor and SteelHead in the cluster. For details, see the SteelHead User Guide.

On the Interceptors, enable Fair Peering v2 under load-balancing rules, and restart service on the Interceptors. For details, see the SteelHead Interceptor User Guide.

Then configure your cluster on the SCC. For details, see Adding a cluster using the wizard. Create a site for each SteelHead in your cluster. For details, see About sites.

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.

(The remote site requires the remote subnet and the remote SteelHead peer. You don’t need to configure uplinks for the remote site.)

Enable path selection on your cluster. For details, see Configuring path selection on Interceptor clusters. Push the configuration settings for the path selection Interceptor cluster. For details, see Pushing cluster configuration settings. 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.

Restart the services on all the Interceptors. For details, see the SteelHead Interceptor User Guide.

RiOS 9.2 and Interceptor 5.5 and later support 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:

Perform this task to enable RPS on path selection clusters:

You can edit selected clusters under Manage > Topology: Clusters. Click the cluster name to expand the page and display the Edit Cluster tab, and then click the cluster name to expand the page and display the Edit Cluster tab.

Under Cluster Settings, click Run cluster wizard to display the wizard. Click Next to display the Basic Cluster Settings page. These configuration options are available:

Provides a comment to help you identify the cluster.

Renames the cluster.

Specifies the new name of the cluster.

Click Apply & Continue to display the Topology Settings page.

You can fetch cluster configuration settings for in-path and load-balancing rules under Manage > Appliances: Clusters.

Any changes made to the cluster configuration pages modifies all the Interceptors after a cluster push.

A role-based management user with read/write permissions for the Appliance Settings: Interceptor/Cluster role must also have read/write permissions for the Appliance Management: Policy Push role to fetch cluster configurations.

Click the cluster name to expand the page and display the cluster tabs, and then select the Cluster Utilities tab to expand the page. These configuration options are available:

Specifies the Interceptor from the drop-down list. The appliance must be connected to fetch the configuration settings.

Fetches the selected page.

Fetches the selected cluster pages.

You can push cluster configuration settings to Interceptors and SteelHeads under Manage > Appliances: Clusters.

You can also schedule the push to start at a specified date and time and restart the optimization service if required.

During cluster push, some enabled configuration settings from general policy and appliance configuration policies that are assigned to the appliance are pushed.

Cluster pushes fail on the SCC 8.6.0 through 9.2 and later when you attempt to change the IP address on the SteelHead in a cluster. You must first delete the path selection rules, load-balancing rules, and SteelHeads from the Interceptor, then push the cluster again from the SCC. For details, go to Knowledge Base article S28086. 

Click Cluster Operations to expand the page.

Select Push Cluster Configuration from the drop-down list. A cluster push fails if in-path interface appliance configuration for the Interceptor isn’t included in the policy push. You must configure host labels in a policy before you can perform cluster push.

These configuration options are available under Push cluster configuration:

Restarts the optimization.

Schedules the action for a later time and date. If this option isn’t selected, the action occurs the next time the appliance connects.

Pushes configuration settings to remote appliances. During a cluster push, some enabled configurations from the general policy and appliance configuration policies assigned to the appliance are pushed.

You can remove selected clusters under Manage > Appliances: Clusters. Select the check box next to the cluster name you want to remove. Click Remove Selected Clusters to remove the cluster from the table.