About Regular and Enhanced Automatic Discovery
With enhanced automatic discovery, the SteelHead automatically finds the furthest SteelHead peer in a network and optimization occurs there. By default, enhanced autodiscovery is enabled. When enhanced autodiscovery is disabled, the SteelHead uses regular autodiscovery. With regular autodiscovery, the SteelHead finds the next appliance in the group and optimization occurs there.
In some deployments, enhanced autodiscovery can simplify configuration and make your deployments more scalable. When enhanced autodiscovery is enabled, the SteelHead automatically finds the furthest SteelHead in a network and optimization occurs there. For example, if you had a deployment with four SteelHead (A, B, C, D), where D represents the appliance that is furthest from A, the SteelHead automatically finds D. This feature simplifies configuration and makes your deployment more scalable.
The SteelHead (in the cloud) doesn’t use automatic peering. When you run a server in the cloud, you deploy the SteelHead (in the cloud) to be the furthest SteelHead in the network because the Discovery Client on the server is configured to use the SteelHead (in the cloud) automatically. When you run a client in the cloud, and there are multiple SteelHeads in the path to the server, the SteelHead (in the cloud) is selected for optimization first. You can enable automatic peering on the remote SteelHeads to make the SteelHead (in the cloud) peer with the furthest SteelHead in the network.
We recommend enhanced autodiscovery for the deployments described in this table.
Deployment Type | Description |
Serial Cascade Deployments | Cascade configurations enable optimal multisite deployments where connections between the client and the server might pass through intermediate SteelHeads to reach their final destination. Enhanced autodiscovery for cascading SteelHeads detects when more than two SteelHeads are present between the client and the server and automatically chooses the two outside SteelHeads, optimizing all traffic in between. |
Serial Cluster Deployments | You can provide increased optimization by deploying two or more SteelHeads back-to-back in an in-path configuration to create a serial cluster. Appliances in a serial cluster process the peering rules you specify in a spill-over fashion. When the maximum number of TCP connections for a SteelHead is reached, that appliance stops intercepting new connections. This behavior allows the next SteelHead in the cluster the opportunity to intercept the new connection, if it has not reached its maximum number of connections. The in-path peering rules and in-path rules tell the SteelHead in a cluster not to intercept connections between themselves. You configure peering rules that define what to do when a SteelHead receives an autodiscovery probe from another SteelHead. You can deploy serial clusters on the client-side or server-side of the network. Note: For environments that want to optimize MAPI or FTP traffic which require all connections from a client to be optimized by one SteelHead, we strongly recommend using the master and backup redundancy configuration instead of a serial cluster. For larger environments that require multiappliance scalability and high availability, we recommend using the Interceptor to build multiappliance clusters. For details, see the SteelHead Interceptor Deployment Guide and the SteelHead Interceptor User’s Guide. Note: A serial cluster has the same bandwidth specification as the SteelHead model deployed in the cluster. The bandwidth capability doesn’t increase because the cluster contains multiple SteelHeads. . Note: If the active SteelHead in the cluster enters a degraded state because the CPU load is too high, it continues to accept new connections. |
For details about these deployment types, see the SteelHead Deployment Guide.
Extending the Number of Peers
RiOS supports a large number of peers (up to 20,000) per SteelHead. We recommend enabling the extended peer table if you have more than 4,000 peers. After enabling extended peer table support, you must clear the RiOS data store and stop and restart the service. See
Configuring Peering.
Configuring Peering
You display, add, and modify autodiscovery peering settings in the Optimization > Network Services: Peering Rules page. You can also enable extended peer table support.
To enable enhanced autodiscovery
1. Choose Optimization > Network Services: Peering Rules to display the Peering Rules page.
Figure: Peering Rules Page
2. Under Settings, complete the configuration as described in this table.
Control | Description |
Enable Enhanced Auto-Discovery | Enables enhanced autodiscovery. With enhanced autodiscovery, the SteelHead automatically finds the furthest SteelHead along the connection path of the TCP connection, and optimization occurs there: for example, in a deployment with four SteelHeads (A, B, C, D), where D represents the appliance that is furthest from A, the SteelHead automatically finds D. This feature simplifies configuration and makes your deployment more scalable. By default, enhanced autodiscovery peering is enabled. Without enhanced autodiscovery, the SteelHead uses regular autodiscovery. With regular auto-discovery, the SteelHead finds the first remote SteelHead along the connection path of the TCP connection, and optimization occurs there: for example, if you had a deployment with four SteelHeads (A, B, C, D), where D represents the appliance that is furthest from A, the SteelHead automatically finds B, then C, and finally D, and optimization takes place in each. IPv6 connections using enhanced autodiscovery use an inner IPv4 channel to the peer SteelHead over a TCP connection. Your network configuration must support IPv4 for use with the inner channels between SteelCentral Controller for SteelHead Mobile. For detailed information about deployments that require enhanced autodiscovery peering, see the SteelHead Deployment Guide. |
Enable Extended Peer Table | Enables support for up to 20,000 peers on high-end server-side SteelHeads (CX models 5055 and 7055) to accommodate large SteelHead client deployments. The RiOS data store maintains the peers in groups of 1,024 in the global peer table. We recommend enabling the extended peer table if you have more than 4,000 peers. By default, this option is disabled and it’s unavailable on SteelHead models that don’t support it. Note: Before enabling this feature you must have a thorough understanding of performance and scaling issues. When deciding whether to use extended peer table support, you should compare it with a serial cluster deployment. For details on serial clusters, see the SteelHead Deployment Guide. After enabling this option, you must clear the RiOS data store and stop and restart the service. |
3. Click Apply to apply your settings. If you have enabled Extended Peer Table Support, a message tells you to clear the RiOS data store and restart the service.
4. Click Save to Disk to save your settings permanently.
Peering Rules
Peering rules control SteelHead behavior when it sees probe queries.
Peering rules are an ordered list of fields a SteelHead uses to match with incoming SYN packet fields (for example, source or destination subnet, IP address, VLAN, or TCP port) as well as the IP address of the probing SteelHead. This feature is especially useful in complex networks.
Peering Rules List
The Peering Rules page displays a list of peering rules. The list contains the default peering rules and any peering rules you add.
The system evaluates the rules in numerical order starting with rule 1. If the conditions set in the rule match, then the rule is applied. If the conditions set in the rule don’t match, then the rule isn’t applied and the system moves on to 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.
The Rule Type of a matching rule determines which action the SteelHead takes on the connection.
Figure: Default Peering Rules
About the Default Peering Rules
The default peering rules are adequate for typical network configurations, such as in-path configurations. However, you might need to add peering rules for complex network configurations. For details about deployment cases requiring peering rules, see the SteelHead Deployment Guide.
Note: We recommend using in-path rules to optimize SSL connections on destination ports other than the default port 443. For details, see
Configuring In-Path Rules.
• The default peering rule number 1 with the SSL incapable flag matches any SSL connection whose IP address and destination port appear in the list of bypassed clients and servers in the Networking > SSL: SSL Main Settings page. The bypassed list includes the IP addresses and port numbers of SSL servers that the SteelHead is bypassing because it couldn’t match the common name of the server’s certificate with one in its certificate pool. The list also includes servers and clients whose IP address and port combination have experienced an SSL handshake failure. For example, a handshake failure occurs when the SteelHead can’t find the issuer of a server certificate on its list of trusted certificate authorities.
After a server or client appears in the bypassed servers list, follow-on connections to the same destination IP and port number always match rule number 1.
• The default peering rule number 2 with the SSL capable flag matches connections on port 443 that did not match default peering rule number 1. The SteelHead attempts to automatically discover certificate matches for servers answering on port 443. For all connections that match, the SteelHead performs both enhanced autodiscovery (finding the nearest and farthest SteelHead pair) and SSL optimization.
To configure a peering rule
1. To add, move, or remove a peering rule, complete the configuration as described in this table.
Control | Description |
Add a New Peering Rule | Displays the controls for adding a new peering rule. |
Rule Type | Determines which action the SteelHead takes on the connection. Select one of these rule types from the drop-down list: • Auto - Allows built-in functionality to determine the response for peering requests (performs the best peering possible). If the receiving SteelHead is not using automatic autodiscovery, this has the same effect as the Accept peering rule action. If automatic autodiscovery is enabled, the SteelHead only becomes the optimization peer if it’s the last SteelHead in the path to the server. • Accept - Accepts peering requests that match the source-destination-port pattern. The receiving SteelHead responds to the probing SteelHead and becomes the remote-side SteelHead (that is, the peer SteelHead) for the optimized connection. • Passthrough - Allows pass-through peering requests that match the source and destination port pattern. The receiving SteelHead doesn’t respond to the probing SteelHead, and allows the SYN+probe packet to continue through the network. |
Insert Rule At | Determines the order in which the system evaluates the rule. Select Start, End, or a rule number from the drop-down list. The system evaluates 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 rule: for example, if the conditions of rule 1 don’t match, rule 2 is consulted. If rule 2 matches the conditions, it’s applied, and no further rules are consulted. The Rule Type of a matching rule determines which action the SteelHead takes on the connection. |
Source Subnet | Specify an IP address and mask for the traffic source, or you can specify All-IP as the wildcard for all IPv4 and IPv6 traffic. Use these formats: xxx.xxx.xxx.xxx/xx (IPv4) x:x:x::x/xxx (IPv6) |
Destination Subnet | Specify an IP address and mask pattern for the traffic destination, or you can specify All-IP as the wildcard for all IPv4 and IPv6 traffic. Use these formats: xxx.xxx.xxx.xxx/xx (IPv4) x:x:x::x/xxx (IPv6) Port - Specify the destination port number, port label, or all. |
Peer IP Address | Specify the in-path IP address of the probing SteelHead. If more than one in-path interface is present on the probing SteelHead, apply multiple peering rules, one for each in-path interface. The peer client-side SteelHead IP address is IPv4 only. |
SSL Capability | Enables an SSL capability flag, which specifies criteria for matching an incoming connection with one of the rules in the peering rules table. This flag is typically set on a server-side SteelHead. Select one of these options from the drop-down list to determine how to process attempts to create secure SSL connections: • No Check - The peering rule doesn’t determine whether the server SteelHead is present for the particular destination IP address and port combination. • Capable - The peering rule determines that the connection is SSL-capable if the destination port is 443 (irrespective of the destination port value on the rule), and the destination IP and port don’t appear on the bypassed servers list. The SteelHead accepts the condition and, assuming all other proper configurations and that the peering rule is the best match for the incoming connection, optimizes SSL. • Incapable - The peering rule determines that the connection is SSL-incapable if the destination IP and port appear in the bypassed servers list. The service adds a server to the bypassed servers list when there’s no SSL certificate for the server or for any other SSL handshake failure. The SteelHead passes the connection through unoptimized without affecting connection counts. We recommend that you use in-path rules to optimize SSL connections on non-443 destination port configurations. |
Cloud Acceleration | Use cloud acceleration in peering rules on a server-side SteelHead in a back-hauled deployment to configure which connections coming from a client-side SteelHead (with the SteelHead SaaS enabled but with redirect disabled) should be optimized with the SteelHead SaaS. Select one of these rule types from the drop-down list: • Auto - The server-side SteelHead redirects to the cloud connections when the client-side SteelHead tries to optimize with the SteelHead SaaS. • Pass Through - The server-side SteelHead doesn’t redirect to the cloud connections when the client-side SteelHead tries to optimize with the SteelHead SaaS. If the client-side SteelHead doesn’t have the SteelHead SaaS enabled, or if it’s not trying to optimize the SteelHead SaaS connection, the value of this field is irrelevant on the server-side SteelHead. |
Description | Specify a description to help you identify the peering relationship. |
Add | Adds a peering rule to the list. The Management Console redisplays the Peering Rules table and applies your modifications to the running configuration, which is stored in memory. |
Remove Selected Rules | Select the check box next to the name and click Remove Selected Rules. |
Move Selected Rules | Select the check box next to the rule and click Move Selected Rules. Click the arrow next to the desired rule position; the rule moves to the new position. |
2. Click Save to Disk to save your settings permanently.
Preventing an Unknown (or Unwanted) SteelHead from Peering
Enhanced autodiscovery greatly reduces the complexities and time it takes to deploy SteelHeads. It works so seamlessly that occasionally it has the undesirable effect of peering with SteelHeads on the Internet that aren’t in your organization's management domain or your corporate business unit. When an unknown (or unwanted) SteelHead appears connected to your network, you can create a peering rule to prevent it from peering and remove it from your list of peers. The peering rule defines what to do when a SteelHead receives an autodiscovery probe from the unknown SteelHead.
To prevent an unknown SteelHead from peering
1. Choose Optimization > Network Services: Peering Rules.
2. Click Add a New Peering Rule.
3. Select Passthrough as the rule type.
4. Specify the source and destination subnets. The source subnet is the remote location network subnet (in the format xxx.xxx.xxx.xxx/xx). The destination subnet is your local network subnet (in the format xxx.xxx.xxx.xxx/xx).
5. Click Add.
The peering rule passes through traffic from the unknown SteelHead in the remote location.
When you use this method and add a new remote location in the future, you must create a new peering rule that accepts traffic from the remote location. Place this new Accept rule before the Pass-through rule.
If you don’t know the network subnet for the remote location, there’s another option: you can create a peering rule that allows peering from your corporate network subnet and denies it otherwise. For example, create a peering rule that accepts peering from your corporate network subnet and place it as the first rule in the list.
6. Create a second peering rule to pass through all other traffic.
When the local SteelHead receives an autodiscovery probe, it checks the peering rules first (from top to bottom). If it matches the first Accept rule, the local SteelHead peers with the other SteelHead. If it doesn’t match the first Accept rule, the local SteelHead checks the next peering rule, which is the pass-through rule for all other traffic. In this case, the local SteelHead just passes through the traffic, but it doesn’t peer with the other SteelHead.
After you add the peering rule, the unknown SteelHead appears in the Current Connections report as a Connected Appliance until the connection times out. After the connection becomes inactive, it appears dimmed. To remove the unknown appliance completely, restart the optimization service.
Related Topics