<id> | Policy ID number. |
rulenum <rule-number> | Specifies the rule number to edit: 1-N or start or end. |
srcaddr <subnet> | Specifies the source subnet in the format XXX.XXX.XXX.XXX/XX. |
dstaddr <subnet> dstport <port> | Specifies the destination subnet and port. For the subnet address, use the format XXX.XXX.XXX.XXX/XX. For the port, you can specify a single port (number), a port label, or all to specify all ports. |
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 SteelHead Mobile 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. |
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 SteelHead Mobile. • 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. |
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. |
neural-mode <mode> | Enables neural framing in the SteelHead Mobile. 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 SteelHead Mobile 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 SteelHead Mobile (where the connection is initiated). The server-side SteelHead must also support WAN visibility. • correct - Turns WAN visibility off. Correct addressing uses SteelHead Mobile 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 SteelHead Mobiles 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 SteelHead Mobiles. Note: 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 SteelHead Mobiles 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 - Specify to set the WAN visibility option to none. Important: 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 detailed information about how to configure WAN visibility, see the SteelHead Management Console User’s Guide and the *. |
description <description> | Specifies a description of the rule. |