Upstream Provider Woes? Point the Ping of Blame - page 3

Network Admin's Best Tool

Figure 2. (Click for a larger image)

Here is a real-life example of tracking down problems with my own mail server. I use a hosting service, and they are very good. But lately I've had trouble receiving and sending mail. It takes a long time, and often times out. Figure 2 shows the output of the following command:

$ mtr mail.bratgrrl.com

This shows that the entire path from my PC to my mail server is a congested mess. Of particular interest are the first and last hops: router.ortelco.net shows 21% packet loss, and my mail server, venus.euao.com, shows a 36% packet loss. Should I send a LART to my service providers? Not quite yet. The next step is to run the same test at different times of day over the next couple of days. To generate nicely-formatted, copy-able output, add the -r flag, and limit the number of packets sent with the -c flag. Then store the output in a file:

$ mtr -r -c100 yahoo.com >> test.txt

Slap it into a cron job, running it every hour or so, and in a day or two you have a good snapshot of what is happening on a particular link. Suppose that this shows venus.euao.com is consistently dropping bales of packets; what comes next? Create a trouble ticket using the output of mtr to show the service provider that the problem is specific to their server, and not somewhere else downstream.

What if your external testing demonstrates no particular problems? Then you know you need to investigate your LAN for the source of your network troubles. mtr works on the inside just as well as the outside.