How to Generate an MTR Report

What is an MTR?

This guide is intended to document how you can run an MTR (My TraceRoute) to collect information relating to a network error or disruption, which can be reported to our Support team. When possible, please provide an MTR when submitting a Support Case, otherwise you may experience a delay in the processing of your support request. 

MTR provides an enhancement over basic diagnostic tools such as "ping" and "traceroute/tracert" by providing additional information in relation to the network paths (often called hops) taken during communication. An MTR will also continuously provide data about the connection and responsiveness of each hop while the report is processed. 

Installing and Running an MTR

MTR is available on most platforms, but we'll specifically cover Linux, Windows, and Unix (MacOS). 

Linux

Depending on your package manager, install the mtr package. For example: 

Debian/Ubuntu

apt update
apt install mtr

RHEL (Red Hat)/CentOS/Fedora

yum update
yum install mtr

Windows

The Windows variant of MTR is made available through a program called WinMTR. Refer to their sourceforge article for a download link. 

Unix (MacOS)

If you utilise homebrew on your Mac, you can install MTR with: 

brew install mtr

Generating the MTR Report

With MTR installed, you are now in a position to run an MTR report which can be provided to the team. We've provided recommended commands to run below on a Unix/Linux environment: 

 mtr -rwc 50 <destination IP>

This command comprises:

• "mtr" the command to run
• "-" to indicate to pass through flags to the command
• "r" to generate the mtr in a report format
• "w" to show the full hostname of each 'hop' where available
• "c X" to indicate to send X number packets. By default, an MTR report will only send 10. We recommend 50, which will take around a minute. 

Here is an example command, and output. The destination for this MTR is a Google DNS IP. You should replace this with the host you are investigating. 

mtr -rwc 50 8.8.8.8


Start: Fri Jun 19 02:09:49 2020
HOST: sau-12345-cs.servercontrol.com.au            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vl3005.sw-6-19.as45671.net.au                 0.0%    50    0.8   6.8   0.8 224.4  31.5
  2.|-- vl3000.sw-6-5.as45671.net.au                  0.0%    50    1.5   5.4   1.1 166.3  23.4
  3.|-- rtif-203.26.198.100-31.es-6-1.as45671.net.au  0.0%    50    0.4   0.8   0.4   2.2   0.3
  4.|-- 203.26.198.42                                 0.0%    50    0.6   1.0   0.4  13.7   2.0
  5.|-- 100.64.105.5                                  0.0%    50    0.6   1.0   0.4   6.9   1.2
  6.|-- as15169.nsw.ix.asn.au                         0.0%    50   14.8   3.0   0.8  22.9   4.1
  7.|-- 108.170.247.49                                0.0%    50    2.2   2.5   2.0   5.5   0.6
  8.|-- 142.250.224.189                               0.0%    50    1.9   2.4   1.8   8.5   1.0
  9.|-- dns.google                                    0.0%    50    0.7   1.0   0.7   4.3   0.5

This MTR traversed several hops, saw no packet loss, and arrived at the destination 100% of the time. 

We strongly recommend that you also generate an MTR from the destination host, in-effect showing the "return path". From this host, set the destination address to your original source. This could be your Office or Home Static IP Address (also called a WAN or Public IP). 

The Windows WinMTR program generates a similar report, but some functionalities may not be available.

Interpreting the Report

Now that you have two reports (from your host to the destination host AND the destination host to your host), you can review the data in the report. 

In the example provided above, multiple "hops" were encountered which represents network devices on the Internet. This could be a router, Layer 3 switch or any other device that has an IP address and routes traffic.

Investigating Packet Loss

If you are experiencing packet loss, or believe you have an ongoing network disruption, you may find the MTR report is reporting lost packets during transit.

It is very important to note that some networking devices rate limit or de-prioritise ICMP (ping) traffic, affecting the result shown on the MTR. If you find a single "hop" reports 100.0 in the Loss% column, but this is not seen elsewhere in the report, this is an indication of rate limited ICMP. 

Here is a modified example to the one provided earlier: 

Start: Fri Jun 19 02:09:49 2020
HOST: sau-12345-cs.servercontrol.com.au            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vl3005.sw-6-19.as45671.net.au                 0.0%    50    0.8   6.8   0.8 224.4  31.5
  2.|-- vl3000.sw-6-5.as45671.net.au                  0.0%    50    1.5   5.4   1.1 166.3  23.4
  3.|-- rtif-203.26.198.100-31.es-6-1.as45671.net.au  0.0%    50    0.4   0.8   0.4   2.2   0.3
  4.|-- 203.26.198.42                                 0.0%    50    0.6   1.0   0.4  13.7   2.0
  5.|-- 100.64.105.5                                  0.0%    50    0.6   1.0   0.4   6.9   1.2
  6.|-- as15169.nsw.ix.asn.au                         0.0%    50   14.8   3.0   0.8  22.9   4.1
  7.|-- 108.170.247.49                                60.0%    50    2.2   2.5   2.0   5.5   0.6
  8.|-- 142.250.224.189                               60.0%    50    1.9   2.4   1.8   8.5   1.0
  9.|-- dns.google                                    40.0%    50    0.7   1.0   0.7   4.3   0.5

In this example, packet loss is encountered at hops 7, 8 and 9. This continues throughout the rest of the "hops" and only 40% of packets are sent and returned from the destination host. 

As previously mentioned, it is important to get an MTR from both directions, as loss could only be occurring on returned packets. 

Also Read