About peering and peering rules

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.

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 an 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 an Edge receives an autodiscovery probe from another appliance. You can deploy serial clusters on the client-side or server-side of the network. 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 Guide. A serial cluster has the same bandwidth specification as the Edge model deployed in the cluster. The bandwidth capability does not increase because the cluster contains multiple appliances. If the active Edge in the cluster enters a degraded state because the CPU load is too high, it continues to accept new connections.

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 an 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 an Edge receives an autodiscovery probe from another appliance.

You can deploy serial clusters on the client-side or server-side of the network.

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

A serial cluster has the same bandwidth specification as the Edge model deployed in the cluster. The bandwidth capability does not increase because the cluster contains multiple appliances.

If the active Edge in the cluster enters a degraded state because the CPU load is too high, it continues to accept new connections.