Linux for Network Engineers: Network Path Analysis with mtr

By March 25, 2020Linux

mtr stands for “My Traceroute” and, in a nutshell, it’s traceroute on steroids. They both work the same way: a host sends probing packets to routers, measures and reports latency and packet loss.

mtr takes that to the next level by giving you the ability to run the probe packets continuously and produce statistics and baselines automatically over the number of probing packets.


To install it on Debian based Linux hosts you just have to type:

If your host doesn’t already have the libraries that mtr depends on, you may need up to 60MB of disk space for the installation.

In most systems, that won’t be a problem, but it’s something to keep in mind.

How it Works

There are two main types of information it provides: packet loss and latency per hop. As an example, let’s run mtr against If you type mtr, mtr launches an interactive console and runs continuously until you decide to stop it by pressing ‘q’.

Here is what each column displays:

1st column: The IP or name of each hop
2nd column: Percentage of packet lost per hope
3rd column: Number of packets sent
4th column: Latency as measured on the last packet sent
5-8th column: Average, best, worst and standard deviation of the latency for each hop

mtr has the limitations of the traceroute: if a route has rate limiting or completely rejects ICMP traffic, then mtr (and traceroute) will display a high packet loss, but in reality normal data traffic might not experience any loss.

In the above example, on the second hop we see a packet loss of 27.9% on my home router (, which would raise an alert. On hop 3, we see a 3.7% packet loss, which tells us that the 27.9% packet loss we see on hop 2 is most likely due to ICMP rate limiting by the router and not actual packet loss.

Compare that with the columns 11-20: we see that the packet loss after hop 11 is at least as high as 21.3%. That tells us that the packet loss is real, and the subsequent hops are impacted by the packet loss on hop 11 as well as whatever other new losses come into play. Of course, part of the packet loss can be ICMP rate limiting as well.

Other options

To get more details on the available mtr options you can read either the manual with  man mtr or press ‘h’ during the interactive console. Among others, you are able to run mtr with a predetermined number of packets and print a report at the end with mtr --report. You can specify the interval between each packet and the packet size with mtr --interval 2.

During the interactive console if you hit the option ‘j’ (j stands for jitter) you get the following output:

Now the jitter information is visible per hop in terms average, geometric mean, and others. The jitter information can be really useful when troubleshooting VoIP issues where latency and jitter play a big role.