Deploy MTR to Pinpoint and Purge Network Mayhem
While seeing a connection struggle to reach your server can be a frustrating experience, solving it can be even more maddening. Fortunately, to find out what is going awry within your network, you can use a handy and readily available tool: MTR, otherwise known as My Traceroute.
Many times a slow-connection culprit won’t be your server or home computer, but a completely different part of the connection, one that is outside of your control. Typically, this bottleneck could be very tough to pinpoint, unless you deploy MTR.
MTR sends packets of data through the network from one point to another (typically, your local computer and your remote server). It then tracks the time it takes for those packets to travel between each “hop” along the way to the destination. When MTR determines that a certain hop is the source of packet loss or delay, you’ll know which server is responsible for your obstructed connection.
Here’s how to load and run MTR so you can alleviate network issues when necessary and keep network paths clear.
Install MTR
You can install MTR on a Linux system using one of the following sets of commands based on what distribution you run:
Debian/Ubuntu:
apt-get update
apt-get upgrade
apt-get install mtr-tiny
CentOS/Fedora:
yum update
yum install mtr
Arch Linux:
pacman -Sy
pacman -S mtr
Additionally, you can install MTR on your local OSX or Windows computer, which will more often assist you in diagnosing balky connections, starting from your personal location.
OSX can install MTR via Homebrew or Macports, so choose one of the following two commands based on your environment:
brew install mtr (Homebrew)
Or
port install mtr (Macports)
For Windows, you will want to use a separate program called WinMTR to perform these diagnoses. You can download this software here: https://sourceforge.net/projects/winmtr/
Prepare an MTR Report
You run MTR in one direction from your source network to the destination you have selected. Keep in mind that it is best practice not to run MTR while connected to a proxy, as this can modify results.
To determine a potential throughput issue within a network connection, you’ll want to have an MTR designated for each direction. This means you run MTR from your computer to your Linode, save that report, and then run MTR from your Linode to your computer and save that report, too. Compare the reports and get the whole network picture to help determine just where the disruption lay.
To run MTR on a Linux/OS X computer, type the following command in a terminal (replace [ip_address] with the address of the target):
mtr --report [ip_address]
Running an MTR report on Windows with WinMTR is just as easy. Follow Microsoft’s graphical user interface and subsequent directions in the application, and then provide your target IP address. Voila! You’ll have a network diagnosis report in your hands.
Read an MTR Report
The image above is what a typical MTR report will look like.
The left-most column shown displays the IP address of the host at the hop that MTR has analyzed. The seven columns to the right tell you the following:
- Loss%: The percent of packet loss experienced at this hop.
- Snt (Sent): The amount of packets sent to this hop.
- Last: The latency (in seconds) of the last packet sent to this hop.
- Avg (Average): The average of the latency (in seconds) of all packets sent to this hop.
- Best: The smallest latency (in seconds) of a packet sent to this hop.
- Wrst (Worst): The longest latency (in seconds) of a packet sent to this hop.
- StDev (Standard Deviation): The standard deviation of the latencies sent to this host, showing consistency in the results.
When diagnosing a problem in the connection, you’ll want to look for packet loss in the Loss% column, or for a sudden jump in latency, reflected in the last 5 columns. Determining an issue is hardly ever black and white, and will be open to much personal interpretation from the network analyst. Nevertheless, certain tips can help you better understand the results:
- When you see a single hop (anywhere except for the destination) show any packet loss, while the subsequent hop does not show any packet loss, take caution. It doesn’t mean you’ve found the source of the problem. Packet loss can be erroneously reported because certain routers can limit transmission rates, skewing MTR results. Rest assured, the connection is most likely fine.
- Legitimate packet loss must carry through an entire MTR report, from blockage point to end hop. For example, an MTR report with 8 total hops indicates a 60% loss at hop 4, and hops 5 through 8 report the same 60% loss. This means a cumulative 60% packet loss that originated at hop 4 persists through the remaining hops. Bet the house that the problem can be found at hop 4.
Keeping these two tips in mind, the above report shows an interesting result. On item 3, a 60% loss begins at hop 3, but eventually improves to 50% loss at hop 5, and then 40% loss at the final 3 hops.
How much packet loss is actually occurring here? The answer would be 40% because that is the amount that carries through to the final hop. Whenever packet loss improves at later hops, you read the better percentage. Thus, your investigation in a network issue would begin at hop 3, where MTR reported the first packet loss.
Had the loss at hop 7 instead jumped to 80%, exceeding all previous packet losses, then your total packet loss would be 80%. This could be attributed to 40% at hop 3, and an additional 40% at hop 7. Investigate both hops, in this case, for bottlenecks.
Regarding packet latency, that seen in every hop will be longer than the previous because every subsequent hop is farther from the source than the preceding one. (Latency is measured to each hop from the source, not between hops.) Generally latency growth will be linear, with small increases when the hops are close together, and larger when the hops are farther apart. (Don’t be surprised if you see a significant jump in latency at a hop on an intercontinental connection.)
Nevertheless, sometimes a change in latency can seem abnormal. Then, it’s up to you to determine the cause and location. Using the MTR report and its five columns of latency data will help you troubleshoot the issue.
Once the issue is determined, it could — unfortunately — reside beyond your control. Based on the host of the hop, the pinch could be with your ISP or router. Or, it could be on the part of your hosting company. If the issue is determined to be between either your ISP, router, or host, little can you do to mitigate it. It will take professional attention.
The best solution to such an extreme obstruction would be to migrate your VPS to a different datacenter in the hope of getting networked on a new route. The server could be operating just fine when connected to a number of other locations. However, chances are good that any network issues will get fixed quickly; after all, small network issues occur all the time, but typically adversely affect only a small subset of routes.
Armed with MTR, you’ll be able to pinpoint and diagnose networking issues to find out exactly what is causing a slow connection and resolving it.
