Tillman Hodgson, 3 February 2000
There are some basic network diagnostics that you can perform to help narrow the problem down. This applies to any vender's services, with appropriate jargon changes to match the technology used:
- Can you reach your gateway/router-of-last-resort? If you can't ping that all-important host, you aren't going to get anything through it. On a cablemodem, checking your block sync light would be the next step; on a dial-up, the telco connection; etc.
- If you can reach reach your gateway, can you reach beyond it? Run a traceroute -n (the -n prevents reverse name resolution, which slows things down considerably) to a public host that you know is up (I like using www.netscape.com). Are any of the hops at outrageous levels of latency or else not responding (includes by *'s)? If so, that's likely the problem. Run nslookup on the IP where the UDP packets are dying/slowing down to get the host's name. What network is that on? The owner of that network is the vender responsible for the problem (note that it could be the *next* hop ... routers are generally point-to-point connections, and either end being down could cause the problem).
- If everything looks clean on the traceroute, then everything is good up to layer 3 of the network ... it becomes an application layer problem or a host hardware problem. For example, I've seen ethernet cards that work fine as long as the load on them is no higher than an occassional ping packet (it turned out to an auto-port detection problem on a coax/RJ-45 combo card). I've also seen applications that rely on UDP for stuff that should really use TCP, and when a packet goes missing it would wait for a (lengthy) timeout to expire before resending it.