About peering rule settings

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.

These configuration options are available to add, move, or remove a peering rule:

Displays the controls for adding a new peering rule.

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.

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.

Specifies an IP address and mask for the traffic source. You can also specify wildcards:

Specifies an IP address and mask pattern for the traffic destination.

You can also specify wildcards:

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

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

You can also specify wildcards:

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:

Indicates the peering rule doesn’t determine whether the server SteelHead is present for the particular destination IP address and port combination.

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

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

Specifies the type of cloud acceleration peering rule. 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 specifies the server-side SteelHead redirects to the cloud connections when the client-side SteelHead tries to optimize with the SteelHead SaaS.

• Pass Through specifies 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.

Specifies a description to help you identify the peering relationship.

When you add the 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.