in-path rule auto-discover

srcaddr <ip-address>	Specifies the source subnet IP address and netmask. Use the format XXX.XXX.XXX.XXX/XX for IPv4 and X:X:X::X/XXX for IPv6.
srcaddr all-ip	Specifies all IPv4 and all IPv6 addresses. This is the default.
srcaddr all-ipv4	Specifies all IPv4 addresses.
srcaddr all-ipv6	Specifies all IPv6 addresses.
dstaddr <ip-address>	Specifies the destination subnet IP address and netmask. Use the format XXX.XXX.XXX.XXX/XX for IPv4 and X:X:X::X/XXX for IPv6.
dstaddr all-ip	Specifies all IPv4 and all IPv6 addresses. This is the default.
dstaddr all-ipv4	Specifies all IPv4 addresses.
dstaddr all-ipv6	Specifies all IPv6 addresses.
dstport <port>	Specifies a single port (number), a port label, or all to specify all ports. If you are using domain labels, specifying all defaults to ports 80 and 443 for optimization.
dst-domain <domain-label>	Specifies a destination domain label for this rule. You configure the domain label settings using the domain-label command. When you add a domain label to an existing in-path rule that is using all-ip you must change the destination address to all-ipv4. Domain labels are only compatible with IPv4. Domain labels and cloud acceleration are mutually exclusive. To use cloud acceleration with domain labels, place the domain labels rules lower than cloud acceleration rules in your rule list so the cloud rules match before the domain label rules. Best practice is to position domain label rules as the last in the list, so RiOS matches all previous rules before matching the domain label rule. We recommend using host labels as the destination IP address for a rule configured with domain labels. The host label limits the connections for the extra processing needed for the domain label check. If you rely on the default rule in the in-path rule set for optimization and would like to incorporate domain-label optimization, see the SteelHead Deployment Guide for best practices. Enter an empty string, represented by two quotation marks (""), to remove a domain label.
dst-host <host-label>	Specifies a destination host label for this rule. You configure the host label settings using the host-label command. A destination IP address and host label cannot be specified in the same rule. A host label can be used instead of a destination IP address. Enter an empty string, represented by two quotation marks (""), to remove a host label.
preoptimization <policy>	Specifies a preoptimization policy: • ssl - Enables SSL preoptimization processing for traffic via SSL secure ports. • oracle-forms - Enables preoptimization processing for the Oracle Forms browser plug-in. This policy is not compatible with IPv6. • oracle-forms+ssl - Enables preoptimization processing for both the Oracle Forms browser plug-in and SSL encrypted traffic through SSL secure ports on the client-side SteelHead. This policy is not compatible with IPv6. • none - Preoptimization processing is set to none by default. If SSL or Oracle Forms preoptimization processing is turned on and you want to turn it off for a port, specify none. In RiOS 6.0 and later, traffic to port 443 always uses a preoptimization policy of SSL, even if an in-path rule on the client-side SteelHead sets the preoptimization policy to None. To disable the SSL preoptimization for traffic to port 443, you can either: – disable the SSL optimization on the client or server-side SteelHead. or – modify the peering rule on the server-side SteelHead by setting the SSL capability control to No Check. Note: Make sure you set latency-opt to none to ensure that SSL connections are optimized. For Citrix latency optimization to work, set the preoptimization policy to the preoptimization ssl option.
optimization <policy>	Specifies an optimization policy: • normal - Performs LZ compression and SDR. This is the default optimization policy. • sdr-only - Turns off LZ compression. • sdr-m - Performs data reduction entirely in memory, which prevents the SteelHead from reading and writing to and from the disk. Enabling this option can yield high LAN-side throughput because it eliminates all disk latency. • compr-only - Turns off SDR but perform LZ compression. • none - Turns off LZ compression and SDR. To configure optimization policies for the FTP data channel, define an in-path rule with the destination port 20 and set its optimization policy. Setting QoS for port 20 on the client-side SteelHead affects passive FTP, while setting the QoS for port 20 on the server-side SteelHead affects active FTP. To configure optimization policies for the Messaging Application Protocol Interface (MAPI) connection, define an in-path rule with the destination port 7830 and set its optimization policy.
latency-opt <policy>	Specifies a latency-optimization policy: • citrix - Always uses Citrix optimization on connections matching this rule. Citrix optimizations are ICA/CGP over SSL optimizations. For Citrix latency optimization to work, set the preoptimization policy to the preoptimization ssl option. This policy is not compatible with IPv6. • http - Performs HTTP optimization on connections matching this rule. • normal - Performs HTTP optimization on ports 80, 8080, and (with SSL pre-optimization) 443. This is the default setting. • outlook-anywhr - Always uses Outlook-Anywhere optimization on the connection. • exchange-auto - Automatically detects MAPI transport protocols (Autodiscover, Outlook Anywhere, and MAPI over HTTP) and HTTP traffic. • none - Does not perform latency optimization on connections matching this rule.
vlan <vlan-tag-id>	Specifies the VLAN tag ID (if any). The VLAN identification number is a value with a range from 0 to 4094. Specify 0 to mark the link untagged.
neural-mode <policy>	Enables neural framing in the SteelHead. Enabling neural framing makes your WAN more efficient by gathering data to select the optimal packet framing boundaries for SDR. If you specify a neural mode, your network experiences a trade-off between the compression and SDR performance, and the latency added to the connection. For different types of traffic, one algorithm might be better than others. Specify one of the following modes: • always - Always uses the Nagle algorithm. This is the default setting (always wait 6 ms). All data is passed to the codec which attempts to coalesce consume calls (if needed) to achieve better fingerprinting. A timer (6 ms) backs it up and causes leftover data to be consumed. Neural heuristics are computed in this mode but are not used. This mode is not compatible with IPv6. • dynamic - Dynamically adjusts the Nagle parameters. The SteelHead picks the best algorithm to use by learning what algorithm is best and adapting if the traffic characteristic changes. This mode is not compatible with IPv6. • never - Never uses the Nagle algorithm. All the data is immediately encoded without waiting for timers to fire or application buffers to fill past a specified threshold. Neural heuristics are computed in this mode but are not used. • tcphints - Bases the setting on TCP hints. If data is received from a partial frame packet or a packet with the TCP PUSH flag set, the encoder encodes the data instead of immediately coalescing it. Neural heuristics are computed in this mode but are not used. This mode is not compatible with IPv6. To configure neural framing for an FTP data channel, define an in-path rule with the destination port 20 and set its optimization policy. To configure neural framing for a MAPI connection, define an in-path rule with the destination port 7830 and set its optimization policy.
cloud-accel <mode>	Specifies a cloud-acceleration action mode for this rule. After you subscribe to a SaaS platform and enable it, ensure that cloud acceleration is ready and enabled. If cloud acceleration is enabled, then by default, connections to the subscribed SaaS platform will be optimized by the SteelHead SaaS. You do not need to add an in-path rule unless you want to optimize specific users and not others. Then, select one of these modes: • auto - If the in-path rule matches, the connection is optimized by the SCA connection. • passthru - If the in-path rule matches, the connection is not optimized by the SteelHead SaaS, but it follows the rule’s other parameters so that the connection might be optimized by this SteelHead with other SteelHeads in the network, or it might be passed through. Domain labels and cloud acceleration are mutually exclusive. To use cloud acceleration with domain labels, place the domain label rules lower than cloud acceleration rules in your rule list so the cloud rules match before the domain label rules.
web-proxy <mode>	Specifies the web proxy optimization mode for this rule: • auto - Automatically directs all Internet-bound traffic destined to a public IP address on ports 80 and 443 through the web proxy. This is the default setting. An in-path cloud acceleration rule (cloud_accel <mode> option) for SaaS takes priority over a web proxy auto mode rule when they are configured together. Only IPv4 addressing is supported. When auto is enabled on an Auto Discover rule, and the SteelHead is prioritizing the traffic through the web proxy, the full or port transparency WAN visibility modes have no impact. When the traffic cannot be prioritized through the web proxy, autodiscovery will occur and the full or port transparency modes will be used. • force - Forwards any IP address and port matching this rule to the web proxy service. This is a pass-through rule. No address in an SCA server list is web proxied unless the web-proxy force mode is configured. • none - Does not direct traffic matching this rule through the web proxy service. Web proxy enables a client-side appliance with an autodiscovery or pass-through rule to use a single-ended web proxy to transparently intercept all traffic bound to the Internet. Enabling the web proxy improves performance by providing optimization services such as web object caching and SSL decryption to enable content caching and logging services. You can use host labels and domain labels to define more granular traffic with the web proxy service.
wan-visibility <mode>	Enables WAN visibility, which pertains to how packets traversing the WAN are addressed. RiOS 5.0 or later offers three types of WAN visibility modes: correct addressing, port transparency, and full address transparency. You configure WAN visibility on the client-side SteelHead (where the connection is initiated). The server-side SteelHead must also support WAN visibility (RiOS 5.0 or later). • correct - Turns off WAN visibility. Correct addressing uses SteelHead IP addresses and port numbers in the TCP/IP packet header fields for optimized traffic in both directions across the WAN. This is the default setting. • port - Enables port address transparency, which preserves your server port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. Traffic is optimized while the server port number in the TCP/IP header field appears to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields. Use port transparency if you want to manage and enforce QoS policies that are based on destination ports. If your WAN router is following traffic classification rules written in terms of client and network addresses, port transparency enables your routers to use existing rules to classify the traffic without any changes. Port transparency enables network analyzers deployed within the WAN (between the SteelHeads) to monitor network activity and to capture statistics for reporting by inspecting traffic according to its original TCP port number. Port transparency does not require dedicated port configurations on your SteelHeads. Note: Port transparency only provides server port visibility. It does not provide client and server IP address visibility, nor does it provide client port visibility.
wan-visibility <mode> (cont)	• full - Full address transparency preserves your client and server IP addresses and port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. It also preserves VLAN tags. Traffic is optimized while these TCP/IP header fields appear to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields. If both port transparency and full address transparency are acceptable solutions, port transparency is preferable. Port transparency avoids potential networking risks that are inherent to enabling full address transparency. For details, see the SteelHead Deployment Guide. However, if you must see your client or server IP addresses across the WAN, full transparency is your only configuration option.
	If you specify full, further specify one of the following options: • wan-vis-opt fwd-reset - Enables full address transparency and also sends a reset between the probe response and inner SYN. The reset ensures that the packet header uses the same IP address and port numbers as the initial client and server connection. Because the reset creates a fresh inner connection, you can use full transparency in systems with firewalls that perform stateful packet inspection to track the connection state. • none - Sets the WAN visibility option to none. Note: Enabling full address transparency requires symmetrical traffic flows between the client and server. Should any asymmetry exist on the network, enabling full address transparency might yield unexpected results, up to and including loss of connectivity. For details about how to configure WAN visibility, see the SteelHead Management Console User’s Guide and the SteelHead Deployment Guide.
description <description>	Specifies a description to facilitate communication about network administration.
auto-kickoff enable	Enables kickoff, which resets established connections to force them to go through the connection creation process again. If you enable kickoff, connections that exist when the optimization service is started and restarted are disconnected. When the connections are retried they are optimized. Generally, connections are short lived and kickoff is not necessary. It is suitable for certain long-lived connections, such as data replication, and very challenging remote environments. For example, in an environment with 128 Kbps and 1.5 seconds of latency, you might want to use kickoff to interrupt an HTTP download so that your other traffic is optimized. In a remote branch-office with a T1 and a 35 ms round-trip time, you would want connections to migrate to optimization gracefully, rather than risk interruption with kickoff. RiOS 6.5 provides two ways to enable kickoff: globally and per in-path rule. In most deployments, you do not want to set automatic kickoff globally because it disrupts all connections. When you enable kick off for an in-path rule, once the SteelHead sees any packets that match the IP and port specified in the rule, it sends an RST packet to the client and server maintaining the connection to try to close it. Next, it sets an internal flag to prevent any further kickoffs until the optimization service is once again restarted. By default, auto kickoff per in-path rule is disabled. Note: Specifying automatic kickoff per in-path rule enables kickoff even when you disable the global kickoff feature. When global kickoff is enabled, it overrides this setting. You set the global kickoff feature using the Reset Existing Client Connections on Start Up feature, which appears on the Configure > Optimization > General Service Settings page.
auto-kickoff disable	Disables kickoff. By default, auto kickoff per in-path rule is disabled.
rule-enable true	Enables an in-path rule.
rule-enable false	Disables an in-path rule.
rulenum <rule-number>	Specifies the order in which the rule is consulted: 1-N or start or end. The rule is inserted into the list at the specified position. For example, if you specify rulenum as 3, the new rule will be #3, the old rule #3 will become #4, and subsequent rules, if any, will also move down the list. Specify start for the rule to be the first rule and end for the rule to be the last rule. If you do not specify a rule number, the rule is added to the end of the list.