SteelHead™ Deployment Guide : Optimization Techniques and Design Fundamentals : Auto-Discovery Protocol
  
Auto-Discovery Protocol
This section describes the SteelHead auto-discovery protocol. This section includes the following topics:
  • Original Auto-Discovery Process
  • Configuring Enhanced Auto-Discovery
    • Auto-discovery enables SteelHeads to automatically find remote SteelHeads and to optimize traffic with them. Auto-discovery relieves you of having to manually configure the SteelHeads with large amounts of network information.
    The auto-discovery process enables you to:
  • control and secure connections.
  • specify which traffic is optimized.
  • specify how remote peers are selected for optimization.
    • The types of auto-discovery are as follows:
  • Original Auto-Discovery - Automatically finds the first remote SteelHead along the connection path.
  • Enhanced Auto-Discovery (available in RiOS v4.0.x or later) - Automatically finds the last SteelHead along the connection path.
    • Most SteelHead deployments use auto-discovery. You can also manually configure SteelHead pairing using fixed-target in-path rules, but this approach requires ongoing configuration. Fixed-target rules also require tracking new subnets that are present in the network and for which SteelHeads are responsible for optimizing the traffic.
    You can use auto-discovery if the SteelHeads are deployed physically in-path or virtually in-path (such as WCCP or PBR). The following describes physically in-path SteelHeads, but the packet flow is identical with a virtual in-path deployment.
    For information about fixed-target in-path rules, see Fixed-Target In-Path Rules.
    Original Auto-Discovery Process
    The section describes how a client connects to a remote server when the SteelHeads have auto-discovery enabled. In this example, each SteelHead uses correct addressing and a single subnet.
    Figure 1‑1. The Auto-Discovery Process
    This example does not show asymmetric routing detection or enhanced auto-discovery peering.
    In the original auto-discovery process:
    The client initiates the TCP connection by sending a TCP SYN packet.
    The client-side SteelHead receives the packet on its LAN interface, examines the packet, discovers that it is a SYN, and continues processing the packet:
  • Using information from the SYN packet (for example, the source or destination address, or VLAN tag), the SteelHead performs an action based on a configured set of rules, called in-path rules. In this example, because the matching rule for the packet is set to auto, the SteelHead uses auto-discovery to find the remote SteelHead.
  • The SteelHead appends a TCP option to the packet TCP option field. This is the probe query option. The probe query option contains the in-path IP address of the client-side SteelHead. Nothing else in the packet changes, only the option is added.
    • The SteelHead forwards the modified packet (denoted as SYN_probe_query) out of the WAN interface. Because neither the source or destination fields are modified, the packet is routed in the same manner as if there was no SteelHead deployed.
    The server-side SteelHead receives the SYN_probe_query packet on its WAN interface, examines the packet, discovers that it is a SYN packet, and therefore searches for a TCP probe query. If found, the server-side SteelHead:
  • uses the packet fields and the IP address of the client-side SteelHead to determine what action to take, based on its peering rules. In this example, because the matching rule is set to accept (or auto, depending on the RiOS version), the server-side SteelHead communicates to the client-side SteelHead that it is the remote optimization peer for this TCP connection.
  • removes the probe_query option from the packet, and replaces it with a probe_response option (the probe_query and probe_response use the same TCP option number). The probe_response option contains the in-path IP address of the server-side SteelHead.
  • reverses all of the source and destination fields (TCP and IP) in the packet header. The packet sequence numbers and flags are modified to make the packet look like a normal SYN/ACK server response packet.
    • If no server-side SteelHeads are present, the server ignores the TCP probe that was added by the client-side SteelHead, responds with a regular SYN/ACK resulting in a pass-through connection, and sends the SYN/ACK.
    The server-side SteelHead transmits the packet to the client-side SteelHead. Because the destination IP address of the packet is now the client IP address, the packet is routed through the WAN just as if the server was responding to the client.
    The client-side SteelHead receives the packet on its WAN interface, examines it, and discovers that it is a SYN/ACK. The client-side SteelHead scans for and finds the probe_response field, and reads the in-path IP address of the server-side SteelHead. Now the client-side SteelHead knows all the parameters of the packet TCP flow, including the:
  • IP addresses of the client and server.
  • TCP source and destination ports for this connection.
  • in-path IP address of the server-side SteelHead for this connection.
    • The SteelHeads now establish three TCP connections:
  • The client-side SteelHead completes the TCP connection setup with the client as if it were the server.
  • The SteelHeads complete the TCP connection between each other.
  • The server-side SteelHead completes the TCP connection with the server as if it were the client.
    • After the three TCP connections are established, optimization begins. The data sent between the client and server for this specific connection is optimized and carried on its own individual TCP connection between the SteelHeads.
    Configuring Enhanced Auto-Discovery
    In RiOS v4.0.x or later, enhanced auto-discovery is available. Enhanced auto-discovery automatically discovers the last SteelHead in the network path of the TCP connection. In contrast, the original auto-discovery protocol automatically discovers the first SteelHead in the path. The difference is only seen in environments where there are three or more SteelHeads in the network path for connections to be optimized.
    Enhanced auto-discovery works with SteelHeads running the original auto-discovery protocol. Enhanced auto-discovery ensures that a SteelHead optimizes only TCP connections that are being initiated or terminated at its local site, and that a SteelHead does not optimize traffic that is transiting through its site.
    For information about passing through transit traffic using enhanced auto-discovery and peering rules, see Configuring Pass-Through Transit Traffic.
    To enable enhanced auto-discovery
  • Connect to the SteelHead CLI and enter the following commands:
    • enable
    configure terminal
    in-path peering auto