About Peering, Autodiscovery, In-Path Rules, and Service Ports : About in-path rules
  
About in-path rules
When a client-side appliance receives a new SYN packet, it checks the packet’s fields (such as source or destination subnet, IP address, VLAN tag, and TCP port) against its in-path rules. If a match is found, the appliance follows the settings in the rule. In-path rules apply only when SYN packets are received on the LAN (physical in-path) or WAN (virtual in-path) interface.
By default, appliances use autodiscovery to connect to peer appliances for any connections that aren't secure, interactive, or default Riverbed ports. The appliance will automatically find and connect to a peer server-side appliance if available.
In-path rules do not affect established connections. To apply new rules, you must reset the connections.
The appliance checks incoming connection requests in order, starting with rule 1. If rule 1 matches, it is applied, and the system moves on to the next packet. If rule 1 doesn’t match, the appliance checks rule 2, and so on.
Rules are listed in order of their specified priority. Expand a rule to access its settings. In general, list rules in this order, placing rules that use domain labels below others:
1. Deny
2. Discard
3. Pass-through
4. Fixed-Target
5. Auto-Discover
The default rule accelerates all traffic that doesn't match any other rules. It cannot be removed and is always listed last. It applies to all IPv4 and IPv6 addresses, using autodiscovery for WAN visibility.
Auto Discovery rules use autodiscovery to check if a remote SteelHead can optimize the connection initiated by the SYN packet.
Fixed target rules skip autodiscovery and use a specified remote appliance for acceleration. At least one remote peer must be configured, and you can specify multiple peers or backup peers. IPv6 is supported.
Fixed-target (packet mode optimization) is similar to fixed target rules, but it supports acceleration for various transport protocols (v4 and v6 TCP and UDP) using SDR and LZ optimization. However, performance is reduced since the appliance doesn’t proxy or predict applications when using this method.
Packet-mode optimization rules are unidirectional, meaning it only accelerates traffic from the client-side appliance to the server-side appliance. For bidirectional traffic, you need to set up two rules: one on the client-side and one on the server-side appliance.
Avoid using the All IP option for source and destination subnets.
Packet-mode optimization works with physical in-path, virtual in-path with WCCP/PBR, and primary-backup deployments. It is not supported in out-of-path, serial cluster, or SteelHead Interceptor deployments.
IPv6 addresses and routes are required for each interface, unless optimizing UDP traffic.
Packet-mode optimization must be enabled under General Service Settings, requiring a service restart. Connections appear in the Current Connections report and Connection History report. Optionally, you can run the show flows command for additional details.
Pass-through rules let traffic pass through the appliance without acceleration. They can be used to exclude specific subnets from acceleration. An appliance in bypass mode will pass all traffic without optimizing it.
Discard rules silently drop SYN packets that match the rule. Similar to how routers or firewalls filter traffic, the connection initiator won't know that the packet was dropped until the connection times out.
Deny rules drop SYN packets and send a message back to the source, resetting the connection. This provides feedback to the initiator that the connection is disallowed. The settings for discard and deny rules are similar.
About Peering, Autodiscovery, In-Path Rules, and Service Ports
About in-path rule settings
About default in-path rules