<id> | Policy ID number. |
<rule-number> | Rule number to edit: 1- <n>, start, or end. |
srcaddr <subnet> | Specifies the source subnet. IPv4 and IPv6 addresses are supported. |
src-subnet <source-label> | A labeled group of subnets that you can apply a single in-path rule to. |
dstaddr <subnet> dstport <port> | Specifies the destination subnet and port. IPv4 and IPv6 addresses are supported. For the port, you can specify a single port (number), a port label, or all to specify all ports. |
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—Specify ssl to enable SSL preoptimization processing for traffic via SSL secure ports. • oracle-forms—Specify oracle-forms to enable preoptimization processing for the Oracle Forms browser plug-in. • oracle-forms+ssl—Specify to enable preoptimization processing for both the Oracle Forms browser plug-in and SSL encrypted traffic through SSL secure ports on the client-side Client Accelerator. • 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. |
optimization <policy> | Specifies an optimization policy: • normal—The normal optimization policy is the default. The normal process performs LZ compression and SDR. • sdr-only—Turns off LZ compression. • sdr-m—Performs data reduction entirely in memory, which prevents the Client Accelerator 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 performs LZ compression. • none—Turns off LZ compression and SDR. |
latency-opt <policy> | Specifies a latency-optimization policy: • citrix—Always use 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. • http—Performs HTTP optimization on connections matching this rule. • normal—Performs HTTP optimization on ports 80, 8080, and (with SSL preoptimization) 443. This is the default setting. • outlook-anywhr—Always use Outlook-Anywhere optimization on the connection. • none—Do not perform latency optimization on connections matching this rule. |
cloud-accel <mode> | Applies only if you have subscribed to a Software as a Service (SaaS) platform. 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. Specify one of these modes: • auto—If the in-path rule matches, the connection is optimized by the Riverbed SteelHead Cloud Accelerator (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 except when the _cloud-accel-saas host label is used. To use cloud acceleration with domain labels, we recommend placing the domain label rules lower than cloud acceleration rules in your rule list so the cloud rules match before the domain label rules. |
neural-mode <mode> | Enables neural framing in the Client Accelerator. 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 use 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. • dynamic—Dynamically adjust the Nagle parameters. The Client Accelerator picks the best algorithm to use by learning, which algorithm is best and adapting if the traffic characteristic changes. • never—Never use 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—Base 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. 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. |
wan-visibility <mode> | Enables WAN visibility, which pertains to how packets traversing the WAN are addressed. There are three types of WAN visibility modes: correct addressing, port transparency, and full address transparency. You configure WAN visibility on the client-side Client Accelerator (where the connection is initiated). The server-side SteelHead must also support WAN visibility. • correct—Turns WAN visibility off. Correct addressing uses Client Accelerator 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—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 Client Accelerators 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 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 Client Accelerators. Port transparency provides only server port visibility. It does not provide client and server IP address visibility, nor does it provide client port visibility. |
• full—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 Client Accelerators 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-visibility <mode> | • 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—Specify to set the WAN visibility option to none. 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. |
description <description> | Specifies a description of the rule. |