Pings And Traceroutes

If you run a server, one issue you will likely face is networking problems. Fortunately there are a number of tools that can help find the source of these problems and find a resolution. In this article we’ll have a look through a few of them, and explain how they work so you can see how you can use them to resolve your problems.

What is Ping?

The first one we’ll be looking at is ping. Ping is a tool that sends a message to a computer – the default simply requests a response from the target computer when it receives the request. Ping will time how long it takes the request to arrive, which is how we determine the latency between two computers from, often called the ping time. For gaming and internet streaming a high latency will result in reduced performance. On Linux systems, the default ping command will send one ping request every second to the given destination, and will continue to do so until you stop it. On Windows systems, ping will send one ping a second for a maximum of 4 pings. The basic command usage is the same on both Linux and Windows:
ping example.com
By sending multiple pings it can also help with another problem – that being intermittent connectivity loss. When the ping is ended it will show a summary of the ping packets sent, the responses received, and how many (or a percentage) that were lost, or for which no response was received. If everything is working fine there will be 0 packet loss, but if the server is offline completely you will have 100% packet loss. If you get something in the middle then there’s likely to be a more complicated problem elsewhere.

Guide to Traceroutes

Unfortunately the internet is made up of lots of networks talking to each other through routers. Similar to how your home network connects to your ISP’s network through a router, your ISP will have a router that connects them to other networks, and there can be a number of networks between your computer and the computer you are pinging. This means that once you have established that you have an issue with packet loss or high latency, you then need to find out where this is happening. This is where the traceroute tool comes in.
Traceroute makes use of a feature of the ping tool. When a ping request is sent, one of the parameters is the time to live or (TTL) value. Every time a router passes this ping packet onto another network, this value is reduced by 1. When that number reaches 0 the last device responds to the ping request that the destination couldn’t be found. This is designed to prevent pings circulating networks indefinitely if the destination is offline, or if there are network loop issues that may send the ping in a circle. Traceroute sends a series of pings towards the destination computer starting with a TTL of 1, and increasing it after each response until it finally reaches the destination computer. This allows it to show the route that the ping packet takes across the internet by highlighting all the routers on the way. The routers that the packets pass through between the start and the destination are referred to as hops.

Addressing Latency

The standard traceroute response shows a list of all the hops that the packet goes through, and the latency time of each hop. What this shows is something of a snapshot of time with the responses for when that traceroute was made. My traceroute, or mtr, is an alternative traceroute tool that incorporates the functions of traceroute with the thought process of ping. When run, it will work out the traceroute and then will indefinitely ping each of the points on the route. This can help show the sources of issues that are intermittent such as latency spikes or packet loss.
Something to note when reading mtrs and traceroutes is that due to the large quantity of ping traffic floating about, many routers on the internet are configured to treat ping requests to them with a far lower priority than passing traffic on towards the next hop. So you may find some routers in the middle of the route show higher packet loss or latency than the router following it  This would generally indicate that the router is not dealing with your ping requests to it in a timely fashion, rather than meaning it is the source of problems you may be seeing connecting to your destination.
                         My traceroute  [v0.87]
Thinkpad-Yoga (0.0.0.0)                             Fri Dec  8 11:56:57 2017
Resolver error: No error returned but no answers given. of fields   quit
                                   Packets            Pings
Host                             Loss%   Snt   Last   Avg  Best  Wrst StDev

1. <redacted>                     0.0% 15 1.0   0.9   0.6   1.1   0.0
2. <redacted>                     0.0% 15 1.9   1.7   1.5   1.9   0.0
3. ???
4. <redacted>                     78.6% 15   10.1   9.5   9.2  10.1   0.0
5. <redacted>                     0.0% 15 9.2   9.4   9.0  10.6   0.3
6. core3-hu0-7-0-8.faraday.ukcore.b  0.0% 15 9.3   9.7   9.3  10.9   0.3
7. 213.137.183.36                 0.0% 15 9.2  10.1   8.6  23.7   3.8
8. ixp1-xe-11-0-0-0.us-ash.eu.bt.ne  0.0% 15   93.7  96.3  93.5 117.4   6.9
9. ???
10. 152.195.64.133                 0.0% 14   89.1  89.3  89.0  89.6   0.0
11. 93.184.216.34                  0.0% 14   89.4  89.3  89.0  89.6   0.0

Analyzing Results

Above I’ve provided an example MTR between my computer and example.com, redacting the details of the near edge to my system. As you can see, the routers at hop number 3 and 9 don’t respond at all to any requests and are labelled as “???” because of it. The router at hop 4 shows high packet loss, but as the router directly afterwards – and the rest of the trace – show no packet loss, it means that this is simply the router not wanting to respond to pings, rather than an issue affecting the rest of the route. We can also see the latency increase between hops 7 and 8 and subsequent hops also show increased latency so we can read in that this place would be the cause of the latency change. In this instance it would be a hop from Europe to the US and is an expected latency increase.