This page contains a number of TCP-oriented settings, including which ports are accelerated, TCP window scaling limits, connection timeouts, etc. The individual setting are listed below.
There are two tuning settings: the WAN scale limit and the LAN scale limit. These set the TCP scaling option between the two Appliances (See RFC 1323). The default LAN scale limit is 16, corresponding to a 64 KB (2^16 bytes) advertised window. The default WAN scale limit is 23, corresponding to an 8 MB (2^23 bytes) advertised window.
These values rarely need to be changed from their defaults, though in WANs with a very high bandwidth-delay product, the WAN scale limit may need to be increased, while on a WAN with a very low bandwidth-delay product, the WAN scale limit may need to be decreased. The rule of thumb is to have a WAN scale limit that is at least 2-3 times the bandwidth-delay product.
For example, a 200 Mbps link with a 500 ms RTT has a bandwidth-delay product of 100,000,000 bits. Doubling this gives 200,000,000 bits, or 25,000,000 bytes. This is larger than the default 8 MB window. Increasing the WAN scale limit to 23 (225 bytes or 32 MB) would accommodate this.
Increasing these limits under other circumstances will not increase performance and will only waste memory.
Idle accelerated connections should time out eventually, as they consume system resources. This entry gives the idle time that must elapse before the appliance closes a connection. If the application sends keep-alive packets, these will reset the idle timer. Such connections will never be closed by the connection timeout mechanism.
Some links see thousands of half-closed connections that never become fully closed. These may eventually overflow the appliance’s connection table. The Active Connections page can identify half-closed connections. If the problem cannot be fixed at its source, shortening the idle timeout can eliminate the problem.
When using address translation with the ftp or rshell (rsh/rcp/rexec) protocols, the agent performing the address translation must be protocol-aware. FTP control ports and rshell control ports define which ports are used with these two protocol groups. If you use nonstandard ports for these protocols, adding the port numbers the special ports list will allow them to work in proxy mode.
Ports in this range can be used as ephemeral ports only by specific applications.
Virtual inline mode allows a router to send packets to the appliance and receive packets back from it.
There are two slight variations of this forwarding. The first is to forward packets to the default gateway. The second is to forward them to the Ethernet address they came from. Both have the potential to create routing loops. Policy-based routing is required to prevent router loops. See Virtual Inline Mode.
Acceleration takes place between two Appliances. If three or more Appliances are used in series, the link will not be accelerated end-to-end. Instead, the link between Appliances 1 and 2 will be accelerated, but not between Appliances 2 and 3.
Appliances with the Enable Daisy-Chained Units option set will detect when they are in the middle of a chain, and pretend that such connections are non-accelerated. This guarantees that the two endpoint Appliances will both see an accelerated connection.
Daisy-chaining is not recommended for hardboost links.
This specifies the maximum size of the TCP portion of a packet. This defaults to 1380 bytes. If you have a VPN that encapsulates packets inside another header (as PPTP and IPSec VPNs do), you may need to reduce this to prevent packet fragmentation. Reducing the MSS to 1340 will usually accomplish this.
Both the Default MSS and Maximum MSS fields should always be set to the same value.
The Forwarding Loop Prevention option allows the same packet to traverse appliances twice without causing trouble. In most deployments, this does not happen, but sometimes it is unavoidable. Passing the same packet through the same appliance multiple times, or through more than one appliance in the same group, can cause problems.
Allows specific IP ranges to be either included into or excluded from CIFS acceleration.
Not recommended for new installations.
This allows any internal Appliance parameter to be set to an arbitrary value. This is generally done only at the request of Support.
For example, the bandwidth limit can be set 1,000 kbps by putting "SlowSendRate" in the Setting field and “1000 K/S” in the Value field.
You can also query the current setting of a parameter by filling in the Setting field but leaving the Value field blank.