Just to spread a little more accurate technical information on this issue:
The issue that was reported and still may be impacting select Cox Communications broadband users (reportedly mostly in Nevada and Kansas) apparently seems to be the result of some ICMP filtering that Cox has implemented within their network. Specifically, ICMP Type 3, Code 4 (datagram too big) appears to be getting dropped at points within their network affecting apparently a few fixed service areas. This block may have been put in to place by Cox for some security purpose, however what it is doing in reality is breaking a process known as Path MTU Discovery (PMTUd), which is used to calculate the highest supported maximum transmission unit (packet size) between two given end hosts, such as a user on their home computer and the server they are accessing across the Internet. With PMTUd not working properly for some clients, web servers at Mojohost may believe that an affected client can support a larger MTU (for example 1500, the standard Ethernet MTU) than they may be able to in reality, such as if they can only support an MTU of 1472 because of a PPPoE connection or VPN or something similar which would add overhead to a packet thus effectively lowering their MTU, etc.
Diagnosing this issue is fairly straightforward. Users can complete normal traceroutes and pings, since they all (by default) use very small packets to function -- far below the MTU. Users may even be able to open an FTP or SSH session with their server. However, if any protocol they're using attempts to send large packets which approach or are at the MTU, and that MTU was miscalculated between the server and client due to a PMTUd failure, large packets would be dropped before reaching the client, causing pages not to load, transfers to freeze up, etc.
We are (and have been) attempting to reach a *competent* Level-2/3 NOC technician at COX via one of our clients who is experiencing this issue, and is a direct COX customer. Unfortunately, we have no direct relationship with COX Communications ourselves, and they won't talk to us directly if we call their published NOC support numbers.
There is a temporary *work-around* that clients impacted by this problem may use to allow access to a server while this problem continues, and that would be to manually lower their MTU value for their network connection. In most cases, setting an MTU value of 1460 or 1400 on a workstation that cannot access one of our servers should permit access until the underlying problem has been corrected by Cox. There may be a *slight* degradation in performance by implementing this suggestion that would normally only be seen on large long-lived file transfers due to the maximum packet size decreasing by 40 or 100 bytes (depending on which value you used), so if you implement this work-around, we advise resetting your MTU to its previous value (probably 1500) once the Cox issue has been confirmed as resolved.
Here is a link to change your network connection MTU on the Windows XP/2000/03/Vista platform:
http://www.windowsreference.com/wind...03-2000-vista/
Some other information regarding this problem can be found at:
http://www.netheaven.com/pmtu.html
http://tools.ietf.org/html/rfc2923
http://support.microsoft.com/kb/159211/
As mentioned above, we have reports from users that the problem is resolved. If anyone is still having a problem, please contact me directly or call 888-345-MOJO and press 1.
Sincerely,
Brad Mitchell