Network diagnostics with mtr
We all know about ping and traceroute, the two most basic network diagnostic tools available everywhere. There are ping and traceroute tools even online for free. Ping will give you statistics about the online presence, packet loss to be precise, and traceroute will give you information about the infrastructure used to get to your destination.
If you ping linux.org you will get the typical response where you can see what arrived at the destination and what not:
If you see packets that don’t get to the destination, those are counted as lost packets and show that there is a network connectivity issue somewhere. Where? You can’t tell from this command’s output. You can only see if there is a response from your target and how fast that response arrived.
If you want to see the network infrastructure used to get to linux.org, you will use traceroute:
I am using the -n parameter so we don’t get IPs resolved to their names as we don’t care about those right now. As you look at the traceroute output, we can see how we wan’t to reach linux.org at 172.70.248.5 from our home gateway, 192.168.68.1. The device we are querying from is asking about 172.70.248.5 and the query goes to my router at 192.168.68.1.
From my router it goes to my other router provided by my ISP. It’s a typical home situation: my ISP gave me a pretty bad router, so I just use it to channel traffic to my actual WiFi router. We can see this traffic happening in the traceroute output.
Next, the query goes into the ISP’s internal network: three rows of addresses starting with 10. We can peer into the ISP’s internal network and see how it’s laid out: there is a router at 10.0.0.1, one at 10.32.9.97 and one at 10.220.187.242. These are all covering more and more expansive areas: the first one probably covers my street or maybe the whole city, the next one either the neighborhood or the city and the final one either the city or the whole country. After that my query goes straight to UK at 80.81.193.129 and from there to my target, linux.org at 172.70.248.5.
Note that the output is very dynamic. One time you may get the above, the next time you will get something different. As Internet nodes drop and others become faster, every specific query will learn the path that gives the quickest answer. There are also DNS attacks that are able to route traffic from one safe node to a compromised one. It’s generally a good idea to keep track of route changes. Of course, there is nothing you can do if all traffic is suddenly routed through a weird country which makes no sense, but at least you know that the route changed and that it’s not the usual one. This may prompt you to monitor further and even evade the compromise using a VPN to another country.
What about mtr?
Enough about ping and traceroute. What’s the deal with mtr then? Well mtr combines both ping and traceroute in a result that gives you information not only about how and if the query gets to the destination, but also about what nodes from the traceroute path are problematic:
The output is continuous and mtr keeps pinging all of the route’s nodes. In this way you can see if there is an issue not just with the destination, but with each and every node from the path:
We can already see that the UK node 195.66.225.179 loses packets. This is not something new: for a long time, for every destination I tried, that node always loses packets. Of course I cannot fix it, it’s not even in my country, but at least I know that somewhere down that path, a node has connectivity issues. It could also be a simple ping throttling: we don’t know.
But sometimes we may detect something like this:
This time we see that we are losing packets right at our WiFi gatweay. This means my computer has trouble connecting to my home router. Why would that be? Well in my case, I know that my computer is very far away from the WiFi router so that must be the case. In other instances, you could apply other techniques to see what is wrong with your WiFi reception. You could even switch to a wired connection if the situation becomes more pressing.
Note that even though I am losing packets in my home network, mtr is smart enough to compare pings with the rest of the node list and it’s able to figure out that every other route hop is fine. The trouble lies in my home network alone.
Another example:
The situation above shows a more worrying situation. This time, not only I have issues in my home network, but mtr detects issues in the ISPs network too. As we saw above, the addresses starting with 10 are internal ISP hardware. They could be routers or servers: we don’t know. The issue we see here is common when the ISP experiences technical difficulties. This time mtr is unable to understand if the issues are just with the ISP or even with the target address, linux.org.
Here we are at the end of another article. The mtr command helped me a lot and since I found it I use it all the time. I don’t even bother anymore with ping. Using mtr I just get a lot more information packed in a single output. And of course, in all examples I used the -n switch to skip name resolution. If you don’t provide the option you will get an even nicer output.
That’s all for now. Don’t hesitate to use the comments section for any clarification or if you wish I detailed some aspects more. I would like to make the article as useful as possible for everybody. See you next time!
