The mtr(my traceroute) command is a robust network diagnostic tool combining the functionality of the ping and traceroute commands.
Its output contains information about the entire route a packet takes from the source server from which originated to the destination server. It has a significant edge over its predecessors, as it not only carries the information they provide but also contains the response time and percentages for the network hops between the two machines(source and destination servers).
It has a vast array of flags that system administrators and users can use to alter the output it produces, influencing the data mtr emits to their needs. On very regular occasions, we at HostArmada may require the data of mtr or its Windows counterpart - WINmtr to investigate connectivity issues that occur from your end, towards our servers.
In this article, we will attempt to give you the basics of this command-line utility along with examples of certain situations allowing you to read the output correctly.
The most basic syntax of the command is as follows:
mtr <IP ADDRESS>/<HOSTNAME>
When you execute the command attaching an IP address or hostname, you will be redirected to its interface, which will be updated once per second or until you press the "q" button on your keyboard. We do recommend using the "report" mode of this command-line utility, as it provides sufficient data in a more easily readable format. To do that, please use the -r and the -w flags. The "-r" flag will "tell" the command to provide a report, while the "-w" flag will clear out the output:
[root@server ~]# mtr -rw google.com
Start: Wed Apr 15 14:00:04 2020
HOST: server.hostname.com Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:7e01::e6c7:22ff:fe1f:22c1 0.0% 10 0.9 1.3 0.9 2.0 0.0
2.|-- 2a01:7e01:b::1 0.0% 10 11.2 3.6 0.5 11.2 4.7
3.|-- de-cix.fra.google.com 0.0% 10 0.9 0.9 0.8 1.4 0.0
4.|-- 2001:4860:0:11df::1 0.0% 10 0.8 0.9 0.8 1.0 0.0
5.|-- 2001:4860:0:1::2171 0.0% 10 0.8 1.0 0.8 1.1 0.0
6.|-- fra15s29-in-x0e.1e100.net 0.0% 10 1.0 1.0 1.0 1.1 0.0
Each of the lines inside the data provided by the command will represent a hop. These hops are the nodes that each packet passes through to reach their destination. If you want to hide the hostnames that are presented in the output, you can add the --no-dns option.
Let's go over the last 7 columns and explains what they contain:
- Loss% - this shows the number of packets lost after each hop.
- Snt - The numbers of packets sent. The default will be 10.
- Last, Avg ,Best, Wrst - these columns show the measurement of the latency in milliseconds for each hop.
- StDev - provides the standard divergence between all the above latencies in each host. The higher this value is, the higher is the contrast between the measured latency.
To lower the numbers of packets sent, you may use the "-c" flag. Here is an example:
[root@server~]# mtr -rw -c5 google.com
Start: Wed Apr 15 14:18:38 2020
HOST: server.hostname.com Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:7e01::5287:89ff:fe40:a1c1 0.0% 5 1.4 1.1 0.9 1.4 0.0
2.|-- 2a01:7e01:c::1 0.0% 5 0.6 1.9 0.6 6.1 2.3
3.|-- 2a01:7e01:5::2 0.0% 5 0.7 0.8 0.6 0.9 0.0
4.|-- de-cix.fra.google.com 0.0% 5 1.0 0.9 0.8 1.0 0.0
5.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
6.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
7.|-- fra02s19-in-x0e.1e100.net 0.0% 5 0.9 1.0 0.9 1.0 0.0
This is the perfect example to also explain the "???" and the 100% loss indication on the 5th and 6th hop. If you see such output in your reports, do not be alarmed, as this does not suggest network problems. This is because the final destination which is on the 7th hop is reached with 0% loss. The 5th or 6th hops are most likely routed through residential or business routers which can sometimes cause misleading outputs.
Sometimes, you will face a situation where the hostnames will be represented by a "???" however, the column under the "Loss%" will show no packet loss. Here is an example:
[root@server ~]# mtr -rw -c5 google.com
Start: Wed Apr 15 14:18:38 2020
HOST: server.hostname.com Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:7e01::5287:89ff:fe40:a1c1 0.0% 5 1.4 1.1 0.9 1.4 0.0
2.|-- 2a01:7e01:c::1 0.0% 5 0.6 1.9 0.6 6.1 2.3
3.|-- 2a01:7e01:5::2 0.0% 5 0.7 0.8 0.6 0.9 0.0
4.|-- de-cix.fra.google.com 0.0% 5 1.0 0.9 0.8 1.0 0.0
5.|-- ??? 0.0% 5 0.8 1.0 0.9 1.0 0.0
6.|-- ??? 0.0% 5 0.8 1.0 0.7 7.0 0.0
7.|-- fra02s19-in-x0e.1e100.net 0.0% 5 0.9 1.0 0.9 1.0 0.0
In this case, you are dealing with a timeout. We cannot really say what is the reason for this, as there are literally a dozen issues that could trigger it. This does not indicate a packet loss, as seen from the output above and packets still reach their destinations.