База знань

Network diagnosis with pingplotter

Pingplotter is a Windows program, similar to the traceroute command, that shows the path between a client and a server, but that does so in a much clearer fashion. A freeware version can be downloaded from

http://www.pingplotter.com

This picture shows an almost perfect path from the client to the server. The second column lists the packet loss, so the test packets that got lost. Since this example didn't have any packet loss this column is empty.

In the columns IP and DNSName the path that the test packets take can be traced. The path starts with the Munich provider M-Net, at hop 6 and 7 (at the peering node INXS) given to Noris and then finally in hop 9 (at the peering node NIX) given to the Hetzner network.

The columns Avg and Cur show the amount of time it takes a packet (in ms) to get to the hop: Avg is the average time, Cur shows the value of the last test packet.

At the end the the timing of the packet transmissions is shown graphically. "Outliers" can be quickly identified by the course of the red line. However, you can only draw limited conclusions from the position of the line: the black lines show the different between the fastest and slowest reply for the particular hop. If a hop responds particularly slowly however, then the red line moves to the left (since more space is needed to the right).

mtr

If you don't have Pingplotter then you can get the same basic functionality with the program mtr (WinMTR for Windows). How mtr works is described here.

Typical errors

It's "lagging"!

Ping times increase, terminal sessions become jerky and games become unplayable. The server is not always the culprit, though using pings as a diagnostic tool is not very helpful:

Pingplotter offers much better information:

One can immediately see that the error (in this simulation) is in the network of M-Netz. Starting with hop 4 there are significant delays, packets from hop 5 are partially discarded (which can in turn be contributed to an error in hop 4) and hop 6 introduces excessive delays. Fault patterns such as this can be caused by severe shortages, such as those incurred by DDoS attacks.

Packet loss

In this example the case is different: while there are many discarded packets starting at hop 10, the ping times of 37ms are in the normal range. This could be caused by a defective router or a faulty cable.

Everything is slow

Especially with DSL connections the following error screen is often seen:

This traceroute does not really show the problem. Pingplotter is again more helpful:

A high load as early as the second hop points to an overload of the private internet connection, which can be caused for example by sending large amounts of data via email, clogging up the upstream ADSL connection. File-sharing tools that suck up bandwidth in the background and have long since been forgotten could also be a problem. A clear picture of the problem can be found by performing a trace in the opposite direction:

Everything looks find (green), up until the router of the client answering too late. Conceivable problems would be either a disruption of the internet connection or an overloading of the router.

Packet losses, which aren't real

This is not actually a problem/mistake, since not answering test packets is normal for routers. Depending on the configuration of the router it will route packets but only reply to test packets if there is enough free computing power. As long as the following hops don't also show packet loss there is no cause for concern.

Asymmetrical routing

A fault diagnosis is relatively easy if the round trip between the client and the server follows the same path. However, often packets will take a different return route (this is caused by different requirements of the provider of the client and the server location).

The following animation (Flash plug-in required) illustrates the problem:

Error example

In the following example the Hetzner network seems to be the cause of the delays. Starting with the first Hetzner router ping times are significantly increased and packets are discarded:

Client ---> Server

Only when a trace route in the opposite direction is made is the real source of the error recognized:

Server ---> Client

In this case there was an error between two Level3 routers in Munich. The problem seemed to be with Hetzner since the packages up to hope 8 (noris) were successfully routed back. Test packets to the Hetzner network and back however took a different route back, resulting in the delay in Munich.