About in-path rules

When a client-side appliance with in-path rules receives a new SYN packet, the appliance attempts to match SYN packet fields—source or destination subnet, IP address, VLAN tag, TCP port—to its in-path rules. When it finds a match, the appliance treats the packet according to the settings specified in the rule. In-path rules are used only when SYN packets arrive on the LAN interface (physical in-path) or on the WAN interface (virtual in-path).

By default, appliances apply autodiscovery to connections from all IP addresses and ports that aren’t secure, interactive, or default Riverbed ports automatically finds peer. Autodiscovery automatically finds and connects a peer server-side appliance, if one exists.

In-path rules have no effect on connections that are already established. You’ll need to reset connections if you want them to match with new rules.

The appliance attempts to match rules to incoming connection requests in numerical order starting with rule 1. If the conditions set in the rule match the incoming SYN packet, then the rule is applied and the system moves on to evaluate the next packet. If the conditions set in the rule don’t match, the system consults the next rule. For example, if the conditions of rule 1 don’t match, rule 2 is consulted. If rule 2 matches the conditions, it’s applied, and no further rules are consulted.

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:

The default rule, which accelerates all traffic that has not been matched to another rule, can’t be removed and is always listed last. It maps to all IPv4 and IPv6 addresses and uses autodiscovery with correct addressing as the WAN visibility mode.

Auto Discovery rules use autodiscovery to determine if a remote SteelHead is able to optimize the connection attempting to be created by this SYN packet.

Fixed target rules skip the autodiscovery process and use a specified remote appliance as an acceleration peer. Requires at least one configured remote peer. Optionally, specify multiple peers and backup peers. IPv6 is supported.

Fixed-target (packet mode optimization) are similar to fixed target rules, with the advantage that they accelerate applications over a diverse set of transport protocols, including v4 and v6 TCP and UPD, using SDR and LZ optimization. The disadvantage is reduced performance, because the appliance doesn’t proxy or perform intelligent application prediction when using those acceleration methods.

Packet-mode optimization rules are unidirectional; a rule on the client-side appliance accelerates traffic to the server-side appliance only. Define two rules, one on the client-side appliance and one on the server-side appliance, to accelerate bidirectional traffic.

Compatible with physical in-path, virtual in-path with WCCP/PBR, and master-backup deployments. Out-of-path, serial cluster, and SteelHead Interceptor deployments not supported.

Requires that packet-mode optimization is enabled under General Service Settings. Requires service restart. Connections appear in the Current Connections report and Connection History report. Optionally, you can run the show flows command.

Passthrough rules pass through traffic on the connection without accelerating it. Use pass-through rules to exclude subnets from acceleration. An appliance in bypass mode passes through all traffic.

Discard rules drop SYN packets silently. The appliance filters out traffic that matches the discard rules. This process is similar to how routers and firewalls drop disallowed packets: the connection-initiating device has no knowledge that its packets were dropped until the connection times out.

Deny rules drop SYN packets, send messages back to sources, and reset TCP connections. Using an active reset process rather than a silent discard allows connection initiators to know that their connections are disallowed. The settings for discard rules and deny rules are the same.