If your VPS server is running into network issues, MTR, also known as My traceroute, can prove a vital tool. Using it, you can generate a detailed report to pass on to a support agent or study yourself.

What is MTR?

MTR is a popular networking tool that provides the features of traceroute and ping in a single, lightweight program. To provide a detailed output, it sends ICMP packets to a target server and listens to the responses of their expiry.

MTR sends packets with increasing TTLs so that it can examine the full route a packet takes to its destination. While doing so, it collects data about the responsiveness, state, and connection of the intermediate hosts, providing a robust look at the links between them.

How to install MTR and generate an MTR report

MTR is available on all major desktop OSes, including Windows, Mac, and Linux. It's worth noting, however, that the Windows client is a port of MTR, known as "WinMTR". Here's how to get each:

  • Linux:
    • Debian/Ubuntu: sudo apt install mtr-tiny
    • CentOS/Fedora/RHEL: yum install mtr
  • Windows:
  • MacOS:
    • Homebrew: brew install mtr
    • MacPorts: port install mtr

We generally recommend generating reports both to and from your VPS if possible. Though it's not common, MTR may detect errors from one direction but not other. This is because the route between two hosts can vary depending on the host's location and surrounding internet infrastructure.

Create an MTR report on Linux or MacOS

Generating an MTR report on Unix-based systems is done through the terminal. Let's use the situation we run into most commonly as an example: network issues between a local PC and a VPS host.

To test the connection to the VPS, we would run the following command via MTR on our local PC:

mtr -rw 12.34.567.890

The -rw option enables reports (r), and full hostname output (w). Naturally, you would replace the IP address in this case with your server IP. However, you can also define a website if required, like so:

mtr -rw bitlaunch.io

Now to check the connection from the VPS to our local PC so we can cover the full range of possibilities:

mtr -rw 098.76.543.210

Change the IP address to that of your local PC, which you can find with a simple DuckDuckGo search.

If the tool detects no packet loss, it may be necessary to increase the frequency at which it sends packets. To do so, we can use the c option to modify the number of packets that are sent and recorded:

sudo mtr -rwc 50 -rw 12.245.678.90

Create an MTR report on Windows

Creating an MTR report on Windows is even easier and is managed directly from WinMTR's UI. Enter the IP or domain name of the target host in the "Host" bar, then press Start. WinMTR will continue sending packets until you press the Stop button.

WinMTR_qY0xRPf9Vm

You can export the information as a report with the Export TEXT or Export HTML buttons. If there's still no packet loss reported, you can up the frequency at which it sends packets by changing the Interval field. Here you can also adjust the maximum number of hosts and the ping size.

WinMTR_dSU7soG3uB

Understanding an MTR Report

The output of an MTR report can be quite confusing at first look. Here's an example:

HOST: 602a742c7437d20001bb8851   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 45.61.138.1                 0.0%    10   15.1  17.4   6.7  47.8  11.6
  2.|-- 10.10.10.253                0.0%    10    0.8   0.9   0.7   1.8   0.3
  3.|-- 77.67.124.45                0.0%    10    9.2  13.3   0.7  36.9  14.4
  4.|-- ae21.cr10-lon1.ip4.gtt.net  0.0%    10    0.8   3.3   0.8  16.4   4.9
  5.|-- 72.14.221.145               0.0%    10    1.6   1.6   1.5   2.0   0.1
  6.|-- 209.85.249.187              0.0%    10    1.6   1.7   1.5   1.9   0.1
  7.|-- 74.125.242.83               0.0%    10    2.1   2.2   2.0   2.6   0.2
  8.|-- 72.14.237.53               80.0%    10    2.0   2.0   2.0   2.1   0.1
  9.|-- 108.170.237.242            70.0%    10   24.3  17.0   7.3  24.3   8.7
 10.|-- 72.14.236.18               30.0%    10   10.1  16.5  10.0  51.1  15.3
 11.|-- 209.85.249.33              70.0%    10   40.2  41.8  40.1  45.0   2.8
 12.|-- 108.170.232.251             0.0%    10   41.8  41.5  41.3  41.8   0.1
 13.|-- 216.239.42.23               0.0%    10   41.9  41.9  41.5  42.2   0.2

The most important thing to know is that each numbered line represents a hop. The Loss% column shows the percentage of packets that were lost at each hop. Snt naturally shows the number of packets sent in total. The remaining four columns are a bit less intuitive, displaying the latency in milliseconds in various ways. Last shows the latency of the last packet sent and average the average of all packets sent. Best and Wrst show the shortest and longest time for a round trip packet to the host.

In most cases, then, you'll just be using the Avg column. However, there are some situations where you may not want to. The final column, StDev, helps to make that assessment, displaying the standard deviation of latencies for each hop. If it's high, this indicates that the average may not be accurate given the small sample size of 10 packets.

Typically, if you're testing from your local PC or VPS server and there's high loss or latency in the first few steps, it's an issue with your ISP. If the issue presents itself towards the end of the list, it's more likely to be a problem with the host. If it falls in the middle, it may, unfortunately, be difficult to address. It's more likely an infrastructural problem along the route that you and the operator will have a limited ability to address.

That said, it's worth noting that in some cases the packet loss and ping values you see may be the server rate limiting ICMP traffic. This is often the case if you see packet loss on one hop followed by 0% loss on the next. If you see packet loss on multiple hops in succession, it's more likely the packet loss is genuine. Whatever the case, bear in mind that a small amount of packet loss (<10%) is unlikely to seriously affect your experience.

Common issues

While some issues MTR flags will require contacting your provider, you can fix others at home or on the VPS with minimal technical knowledge. Others are simply misleading or don't present the full picture. Here are some examples we see frequently:

Misleading residential router reports

At times, residential gateways can report packet loss incorrectly.

HOST: 602a742c7437d20001bb8851   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 45.61.138.1                 0.0%    10   15.1  17.4   6.7  47.8  11.6
  2.|-- ???                       100.0%    10    0.8   0.9   0.7   1.8   0.3
  3.|-- 77.67.124.45                0.0%    10    9.2  13.3   0.7  36.9  14.4
  4.|-- ae21.cr10-lon1.ip4.gtt.net  0.0%    10    0.8   3.3   0.8  16.4   4.9
  5.|-- 72.14.221.145               0.0%    10    1.6   1.6   1.5   2.0   0.1
  6.|-- 209.85.249.187              0.0%    10    1.6   1.7   1.5   1.9   0.1
  7.|-- 74.125.242.83               0.0%    10    2.1   2.2   2.0   2.6   0.2
  8.|-- 72.14.237.53                0.0%    10    2.0   2.0   2.0   2.1   0.1
  9.|-- 108.170.237.242             0.0%    10   24.3  17.0   7.3  24.3   8.7
 10.|-- 72.14.236.18                0.0%    10   10.1  16.5  10.0  51.1  15.3
 11.|-- 209.85.249.33               0.0%    10   40.2  41.8  40.1  45.0   2.8
 12.|-- 108.170.232.251             0.0%    10   41.8  41.5  41.3  41.8   0.1
 13.|-- 216.239.42.23               0.0%    10   41.9  41.9  41.5  42.2   0.2

You can see that our second hop reports a packet loss of 100%, but there's no packet loss after that point. This suggests the result is an error, rather than an actual issue.

The destination server's firewall is configured incorrectly

In some cases, it can appear that packets are not reaching the remote server when in reality it's that the remote server isn't sending a response.

HOST: 602e3bfa7437d20001bb88b8                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- 38.39.201.65                                0.0%    10    1.4   1.3   1.0   1.9   0.3
2.|-- 10.57.57.1                                  0.0%    10    1.2   1.1   0.9   1.4   0.2
3.|-- 10.10.6.1                                   0.0%    10    0.9   0.8   0.7   1.0   0.1
4.|-- 81.20.67.129                                0.0%    10    1.5   1.4   1.3   1.6   0.5
5.|-- ae-19.r25.amstnl02.nl.ntt.net             100.0%    10    0.0   0.0   0.0   0.0   0.0

This can happen if the networking or iptables aren't configured correctly on the remote host. The host may drop ICMP packets as a result and be unable to reply. To be sure this is the case, you must compare the MTR report to previous ones to check if the hop that has 100% loss is the final destination. This can be difficult if you don't have a report available from before the issue started, but it's worth keeping in mind.

Poorly configured ISP router

The problem can sometimes present itself on the ISP's end. This will often be characterized by several rows of question marks that aren't followed by a final destination IP:

HOST: 602e3bfa7437d20001bb88b8    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 38.39.201.65               0.0%    10    1.5   1.6   1.1   4.6   1.1
  2.|-- 10.57.57.1                 0.0%    10    1.5   1.2   0.9   1.5   0.2
  3.|-- 10.10.6.1                  0.0%    10    0.9   1.6   0.7   7.7   2.2
  4.|-- ae1-1989.cr4-ams2.ip4.gtt  0.0%    10    1.1   7.3   0.8  45.1  14.4
  5.|-- ae15.cr6-ams1.ip4.gtt.net  0.0%    10   12.1   7.6   1.3  23.7   8.2
  6.|-- 72.14.208.136              0.0%    10    1.4   7.2   1.0  55.4  17.0
  7.|-- 108.170.241.205            0.0%    10    1.7   1.8   1.6   2.2   0.2
  8.|-- 216.239.43.27             50.0%    10    1.5   1.6   1.5   1.8   0.1
  9.|-- 108.170.238.165            0.0%    10    2.5   2.9   2.1   7.0   1.5
 10.|-- 209.85.248.41              0.0%    10    2.3   2.2   2.0   2.3   0.1
 11.|-- ???                        0.0%    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                        0.0%    10    0.0   0.0   0.0   0.0   0.0
 13.|-- ???                        0.0%    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                        0.0%    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                        0.0%    10    0.0   0.0   0.0   0.0   0.0

You may also see packets sent in a loop, with alternating IP addresses presented for several hops.

Most issues are temporary

If you do discover network issues via MTR, it's worth noting that the majority of network issues do not persist for a long period. In many cases, the service provider will already be aware of the problem and working to resolve it by the time you contact them. Additionally, no amount of maneuvering by the provider can override factors like your physical distance from the server or network congestion.

We've only covered the basics of MTR today, and won't dive into use of TCP/UDP packets, jitter diagnosis, and other MTR functionality just yet. However, if you do experience extended and unexpected degradation, a baisc MTR report may aid your support agent. While they won't expect you to be able to interpret it yourself, it offers them valuable data they can use to diagnose the issue.

If you do note network problems that are affecting your VPS usage, please reach out to BitLaunch support to see if we can help.

Not a part of BitLaunch yet? Sign up today and talk to support for free credit.