About Peering, Autodiscovery, In-Path Rules, and Service Ports
SteelHead appliances generally operate in pairs, accelerating network traffic between them. Typical deployments, where remote client systems communicate with servers and other resources in data centers, place client-side appliances at remote sites and branch offices and server-side appliances in the data center. The client-side appliances establish trusted peer relationships with those on the server-side. In cloud or SaaS deployments, client-side appliances peer with server-side appliances in the cloud or with the SaaS Accelerator service. In this way, appliances intercept traffic from client systems to the data center, cloud, or SaaS service and back, optimizing it according to their configurations.
Higher capacity SteelHead models can support 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 appliance’s data store and restart the service.
Peering can be controlled manually through peering rules, but autodiscovery offers an automated approach to connecting appliances. Peering rules, typically set on server-side appliances, work together with in-path rules, typically set on client-side appliances.
When appliances are deployed in-path, they are placed in the direct path, or same subnet, of client systems and the data center resources with which they communicate. In-path rules define the appliance’s behavior when it receives initial connection requests (TCP SYN packets) from client systems. These rules allow fine-grained control of traffic over in-path links.