About In-Path Rules
In-path rules are used only when a connection is initiated. Because connections are usually initiated by clients, in-path rules are configured for the initiating, or client-side, appliance. In-path rules determine appliance behavior with SYN packets.
In-path rules are an ordered list of fields an appliance uses to match with SYN packet fields (for example, source or destination subnet, IP address, VLAN, or TCP port). Each in-path rule has an action field. When a SteelHead finds a matching in-path rule for a SYN packet, the appliance treats the packet according to the action specified in the in-path rule.
In-path rules are used only in these scenarios:
• TCP SYN packet arrives on the LAN interface of physical in-path deployments.
• TCP SYN packet arrives on the WAN0_0 interface of virtual in-path deployments.
Both of these scenarios are associated with the first, or initiating, SYN packet of the connection. Because most connections are initiated by the client, you configure your in-path rules on the client-side appliance. In-path rules have no effect on connections that are already established, regardless of whether the connections are being optimized.
In-path rule configurations differ depending on the action. For example, both the fixed-target and the autodiscovery actions allow you to choose what type of optimization is applied, what type of data reduction is used, what type of latency optimization is applied, and so on.
RiOS includes fixed-target, packet-mode optimization in-path rules. The appliance treats the packets for packet-mode optimization rules differently from the in-path rules described in this overview.
RiOS also includes TCPv4 and UDPv6 traffic optimization and connection or flow reporting for packet-mode optimization.
For details on IPv6 deployment options, see the SteelHead Deployment Guide.
You can configure optional settings to support a variety of deployment needs, including:
• Optimization Policies—Optimize connections using scalable data reduction, compression, both, or none.
• VLAN Tags—Apply a rule to a specific VLAN or all VLANs.
• Preoptimization Policies—Special handling required for Oracle Forms over SSL support.
• Latency Policies—Set to normal, none, or HTTP to support HTTP traffic. Special handling required for Oracle Forms over SSL support.
• Neural Framing Requirements—Specify never, always, TCP Hints, or Dynamic.
• WAN Visibility—Preserve TCP/IP address or port information.