rulenum <rule-number> | Specifies the rule number to edit: 1-N or start or end. |
target-address <ip-address> | Specifies the target appliance address for this rule. For the network address, use the format XXX.XXX.XXX.XXX for IPv4 or X:X:X::X/XXX for IPv6. |
target-address target-port <port> | Specifies a single port (number), a port label, or all to specify all ports. |
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 label rules lower than cloud acceleration rules in your rule list so the cloud rules match before the domain label rules. We recommend positioning 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. |
backup-address <ip-address> | Specifies a backup appliance address for this rule (if any). For the network address, use the format XXX.XXX.XXX.XXX for IPv4 or X:X:X::X/XXX for IPv6. |
backup-port <port> | Specifies a backup port: single port (number), a port label, or all to specify all ports. |
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 MAPI connection, define an in-path rule with the destination port 7830 and set its optimization policy. |
preoptimization <policy> | Specifies a preoptimization policy: • ssl - Specifies ssl to enable 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. Important: Make sure you specify 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. |
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 use 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. |
neural-mode <mode> | 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 will experience 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. |
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. |
description <description> | Specifies a description to facilitate 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. |
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. |