About regular and enhanced automatic discovery
With enhanced automatic discovery, the Edge automatically finds the furthest appliance peer in a network and optimization occurs there. By default, enhanced autodiscovery is enabled. When enhanced autodiscovery is disabled, the Edge uses regular autodiscovery. With regular autodiscovery, the Edge 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 Edge automatically finds the furthest appliance in a network and optimization occurs there. For example, if you had a deployment with four appliances (A, B, C, D), where D represents the appliance that is furthest from A, the Edge automatically finds D. This feature simplifies configuration and makes your deployment more scalable.
The SteelHead (in the cloud) (SteelHead-c) does not use automatic peering. When you run a server in the cloud, you deploy the SteelHead-c to be the furthest SteelHead in the network because the Discovery Client on the server is configured to use the SteelHead-c automatically. When you run a client in the cloud, and there are multiple SteelHeads in the path to the server, the SteelHead-c is selected for optimization first. You can enable automatic peering on the remote SteelHeads to make the SteelHead-c 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 appliances to reach their final destination. Enhanced autodiscovery for cascading appliances detects when more than two appliances are present between the client and the server and automatically chooses the two outside appliances, optimizing all traffic in between. |
Serial Cluster Deployments | You can provide increased optimization by deploying two or more appliances 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 SteelFusion Edge is reached, that appliance stops intercepting new connections. This behavior allows the next appliance 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 appliance in a cluster not to intercept connections between themselves. You configure peering rules that define what to do when a SteelFusion Edge receives an autodiscovery probe from another appliance. 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 that require all connections from a client to be optimized by one appliance, 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 SteelFusion Edge model deployed in the cluster. The bandwidth capability does not increase because the cluster contains multiple appliances. Note: If the active Edge 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 appliance. 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.
2. Under Settings, complete the configuration as described in this table.
Control | Description |
Enable Enhanced Auto-Discovery | Enables enhanced autodiscovery. With enhanced autodiscovery, the SteelFusion Edge automatically finds the furthest appliance along the connection path of the TCP connection, and optimization occurs there. For example, in a deployment with four appliances (A, B, C, D), where D represents the appliance that is furthest from A, the SteelFusion Edge automatically finds D. This feature simplifies configuration and makes your deployment more scalable. By default, enhanced autodiscovery peering is enabled. Without enhanced autodiscovery, the SteelFusion Edge uses regular autodiscovery. With regular autodiscovery, the SteelFusion Edge finds the first remote appliance along the connection path of the TCP connection, and optimization occurs there. For example, if you had a deployment with four appliances (A, B, C, D), where D represents the appliance that is furthest from A, the Edge 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 appliance 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 appliances to accommodate large client deployments. The RiOS data store maintains the peers in groups of 1,024 in the global peer table. Riverbed recommends enabling the extended peer table if you have more than 4,000 peers. By default, this option is disabled and it is unavailable on appliance models that do not 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 save your settings permanently.
Peering rules
Peering rules control SteelFusion Edge behavior when it sees probe queries.
Peering rules are an ordered list of fields a SteelFusion Edge 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 appliance. 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 do not match, then the rule is not applied and the system moves on to the next rule. For example, if the conditions of rule 1 do not 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 SteelFusion Edge takes on the connection.
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 Edge is bypassing because it could not 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 Edge cannot 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 SteelFusion Edge attempts to automatically discover certificate matches for servers answering on port 443. For all connections that match, the SteelFusion Edge performs both enhanced autodiscovery (finding the nearest and farthest appliance 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 SteelFusion Edge 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 SteelFusion Edge is not using automatic autodiscovery, this has the same effect as the Accept peering rule action. If automatic autodiscovery is enabled, the appliance only becomes the optimization peer if it is the last appliance in the path to the server. • Accept - Accepts peering requests that match the source-destination-port pattern. The receiving SteelFusion Edge responds to the probing appliance and becomes the remote-side appliance (that is, the peer appliance) for the optimized connection. • Passthrough - Allows pass-through peering requests that match the source and destination port pattern. The receiving appliance does not respond to the probing appliance, 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 do not 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 Edge 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 appliance. If more than one in-path interface is present on the probing appliance, apply multiple peering rules, one for each in-path interface. The peer client-side appliance 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 appliance. 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 does not determine whether the server appliance 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 do not appear on the bypassed servers list. The appliance 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 is no SSL certificate for the server or for any other SSL handshake failure. The appliance passes the connection through unoptimized without affecting connection counts. Riverbed recommends 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 data center appliance in a back-hauled deployment to configure which connections coming from a branch SteelFusion Edge (with SaaS enabled but with redirect disabled) should be optimized with the SaaS. Select one of these rule types from the drop-down list: • Auto - The data center appliance redirects to the cloud connections when the branch Edge tries to optimize with SaaS. • Pass Through - The data center appliance does not redirect to the cloud connections when the branch Edge tries to optimize with the SaaS. If the branch Edge does not have the SaaS enabled, or if it is not trying to optimize the SaaS connection, the value of this field is irrelevant on the data center appliance. |
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. |
1. Click Save to save your settings permanently.
Preventing an unknown (or unwanted) appliance from peering
Enhanced autodiscovery greatly reduces the complexities and time it takes to deploy appliances. It works so seamlessly that occasionally it has the undesirable effect of peering with appliances on the Internet that are not in your organization's management domain or your corporate business unit. When an unknown (or unwanted) appliance 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 an appliance receives an autodiscovery probe from the unknown appliance.
To prevent an unknown appliance 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 appliance 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 do not know the network subnet for the remote location, there is 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 appliance receives an autodiscovery probe, it checks the peering rules first (from top to bottom). If it matches the first Accept rule, the local appliance peers with the other appliance. If it does not match the first Accept rule, the local appliance checks the next peering rule, which is the pass-through rule for all other traffic. In this case, the local appliance just passes through the traffic, but it does not peer with the other appliance.
After you add the peering rule, the unknown appliance 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