Product Documentation

Initial Troubleshooting

May 28, 2013
You should test newly installed appliances to verify that they are providing acceleration, and, if not, discover the cause of the difficulty.
  • Cabling or duplexing problems
  • Inability to connect in virtual inline mode
  • Compressed throughput that is no greater than uncompressed throughput
  • Complete absence of accelerated connections
Cabling and Duplexing Problems
Note: On CloudBridge VPX, the VPX virtual machine cannot discover the speed and duplex mode of the physical Ethernet ports, so troubleshooting must be done with the aid of the hypervisor.
Ethernet cabling errors and full-duplex/half-duplex issues are the most common sources of installation problems. This is particularly true of 10/100 Mbps Ethernet links. The two biggest sources of trouble are:
  • The incorrect use of straight-through vs. cross-over cables, which causes a total loss of connectivity on 10/100 Mbps links.
  • Links where one side is forced to 100 Mbps full-duplex, and the other is set to Auto-negotiate. A flaw in the Fast Ethernet standard results in the Auto side choosing 100 Mbps HALF-duplex in this case. The link works, but at greatly reduced performance. This can happen at the actual link to the appliance, but long-standing cases are often discovered elsewhere in existing networks, where they have gone unnoticed because past performance expectations have been low.

Start by verifying that you can connect to the local appliance at its management IP address (using pings or browsing to the management interface). In inline mode, verify that you can connect through the appliance to outside systems.

Cannot Connect in Virtual Inline Mode
If LAN-to-WAN connectivity is lost in a virtual inline installation, check for the following causes:
  • Cabling errors.
  • Router misconfiguration. Router loops or other configuration problems might be preventing successful establishment of connections.
Compressed Throughput Is No Greater than Uncompressed Throughput
This generally happens if the LAN and WAN ports are reversed on the Configuration: Links page.
No Transfers are Accelerated
If transfers succeed but are not accelerated (the Monitoring: Usage Graph page does not show the bandwidth as accelerated bandwidth or shows no bandwidth usage at all), your firewall or router might be overly aggressive about blocking connections, and be rejecting accelerated traffic because it has unusual TCP options. See Firewall Considerations.
Other possible problems depend on which forwarding mode you are using:
  • Inline mode- If the bandwidth is not shown as accelerated bandwidth, an appliance is not enabled, or the remote appliance is not installed, or at least one unit is not on the path taken by the data. If no bandwidth usage is shown at all, the local appliance is not on the path taken by the data (check your cabling and routing tables).
  • Virtual inline or WCCP mode- If the traffic does not appear at all on the appliance’s usage graph, the router is not routing the traffic through the appliance. Check your configuration.
Windows Filesystem (CIFS) Transfers Are Not Accelerated
A lack of acceleration on Windows filesystem (CIFS) transfers is usually caused by one of the following:
  • Persistent connections- Only connections that are started after Acceleration is enabled are accelerated. CIFS connections are very persistent, and it is usually necessary to dismount and remount the file system on the client (or reboot) before acceleration can occur. To see the full effects of acceleration, restarting the file server is the quickest method of guaranteeing that all the old connections have closed, though this is disruptive in a production environment.
  • Security signing- A Windows server option called signing adds authentication data to CIFS transfers. Signing prevents the CIFS protocol from being optimized, unless the Appliance has joined a Windows domain. See Joining the Windows Domain for CIFS/MAPI Enhancements. To accelerate this traffic, either join the Windows domain or disable signing on your servers. See To change the server's setting to allow CIFS acceleration.
A log message is created when this happens:
CIFS Session from client <ip> to server <ip> cannot be accelerated for CIFS due to: server security settings.
Accelerated Connections Run, then Stall
This is typically a problem when a VPN or other tunnel adds so much additional header/trailer data to the packets that they become fragmented. Many networks have broken or poorly functioning fragmentation machinery, and the connection stalls, with no further data reaching the application, in spite of retransmissions over the link, after a series of full-sized packets is fragmented.

This happens on a per-connection basis, and non-bulk-transfer connections (such as SSH terminal sessions) are often not affected.

The log of the receiver-side appliance unit might contain large numbers of "TCP Checksum Error" messages.

The appliance already uses a reduced MSS to make room for its own headers and those of other equipment, but this needs to be reduced further if these problems are seen.

To fix this problem, two packet-size parameters need to be reduced. In most cases, reducing DefaultMss and MaximumMss to 1340 bytes (from their default of 1380) should resolve the VPN fragmentation problem. However, to find the proper MSS value that needs to be set, refer to the following article:

The MSS value can be changed on the Configuration: Tuning page. Setting DefaultMss and MaximumMss to 1340 should solve the VPN hang problem.