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.
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.
MUD WTR is your new coffee alternative. With 1/7th the caffeine of coffee, mud gives you natural energy & focus without the jitters or crash. Mud is filled with adaptogens & organic ingredients lauded by cultures old & young for their health & performance benefits.
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:
sudo apt install mtr-tiny
yum install mtr
brew install mtr
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.
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
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.
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.
The output of an MTR report can be quite confusing at first look. Here's an example:
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.
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:
At times, residential gateways can report packet loss incorrectly.
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.
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.
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.
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:
You may also see packets sent in a loop, with alternating IP addresses presented for several hops.
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.