Contact
Site: US UK AU |

How to interpret MTR results

How to interpret MTR results

Overview
This article provides the basics of interpreting MTR results and how to avoid some of the common pitfalls during analysis.

If you require assistance installing and running MTR, refer to How to install and use MTR.

Problem

It is far easier to generate a traceroute than to interpret one. Even engineers commonly misread traceroutes. Because almost every operating system (OS) affords an easy way to initiate a traceroute, untrained individuals tend to see problems when none exist. 

Solution

The first part of the solution involves using My traceroute (MTR) over traceroute because the former combines traceroute data with ping output. This produces a more thorough data sample than traceroute alone, but this superior data sample is only as good as the interpreter.

Though a detailed analysis of MTR reports is beyond the scope of this article, it is worthwhile to learn how to avoid common ways of misreading them.

The basics

MTR output provides data on two factors: packet loss and latency. MTR reports only generate a traceroute in one direction, but the inbound route and the outbound route typically differ from each other. Therefore, if you ask our Support Team to investigate such an issue, they may require your public IP address to generate an outbound MTR from one of our facility servers.

Note that the first few hops along any route usually represent your ISP, which is the location from which the test was run. The final hops represent the destination location’s ISP. The hops between these groups reflect the internet routers between the two networks. Note that if you are sending an MTR to a Nexcess server, the destination ISP will be Nexcess.

Packet loss

Packet loss tracks the percentage of packets that failed to reach their destination. In general, a single network hop with packet loss on a traceroute is not a cause for concern. Figure 1 shows such a traceroute, with hop 9 showing packet loss.


Figure 1. Single occurrence of packet loss.

A single hop showing packet loss is rarely an indication of a malfunctioning device along the route. Other more likely causes include ISP rate limits, and, on occasion, a busy router CPU.

Furthermore, small occurrences of packet loss throughout a route are usually benign. Figure 2 shows an example of ISP rate-limiting resulting in minimal packet loss (Figure 2). 


Figure 2. Minimal packet loss from ISP rate-limiting.

Figure 3 shows significant packet loss from hops 8 - 13, indicating a serious problem. Identifying the cause of this problem requires additional investigation and considerable knowledge. If this problem does not resolve itself within 30 minutes, contact our Support Team and attach the MTR report.


Figure 3. Significant and pervasive packet loss.

Network latency

Even under ideal conditions, latency increases with every hop. As long as these increases remain within expectations, there is no cause for concern. The potential causes of high latency are extensive, but include mis-configured routers, congestion, and service types, among many others. In general terms, anything under 100 milliseconds (ms) is ideal, but transcontinental hops will tend to exceed this time.

However, as shown in Figure 4, one outlying latency spike does not indicate a problem. In Figure 4, the latency spikes at hop 6, but drops significantly afterward. In this case, the results suggest no effect to the overall service. Always examine the latency to the final hop along the route when analyzing MTR results.


Figure 4. Latency spike.

Figure 5 shows a potentially more significant problem, with high latency starting at hop 8 and persisting through subsequent hops. This suggests some kind of issue with the router at that hop.


Figure 5. Persistent high latency.

Resolving issues

Most issues detectable by MTR will resolve themselves within a few hours. If a problem is significant, you can often rely on your service provider to detect and resolve the issue. Chances are, if you noticed it, then the provider’s monitoring team is already working to resolve it if it is a local issue. If the problem is widespread, then the Internet community is likely working on a solution.

If you experience extended connectivity problems, contact our Support Team and send all relevant MTR reports. When referring to hops within the reports, identify hops by number shown in the HOST column. Our Support Team can attempt to route around some problems, but in some cases, a better route will be unavailable.

For 24-hour assistance any day of the year, contact our Support Team by email or through the Client Portal.

Article Rating (No Votes)
Rate this article
  • Icon PDFExport to PDF
  • Icon MS-WordExport to MS Word
 
Attachments Attachments
There are no attachments for this article.
Related Articles RSS Feed
What is SOAP?
Added on Tue, Jan 6, 2015
How to flush Memcached
Added on Mon, Apr 30, 2018
Facility Access Policy (OTR)
Added on Mon, Jan 22, 2018
How to request and revoke facility access (MEL, TMR)
Added on Wed, Feb 28, 2018
How to transfer domains
Added on Wed, Nov 23, 2016
How to flush Redis
Added on Thu, Apr 7, 2016
What are the benefits of dedicated IP addresses?
Added on Thu, Jan 14, 2016
What is the DMCA?
Added on Mon, Dec 29, 2014
How to decompress files in gzip
Added on Tue, Jan 6, 2015
How to request and revoke facility access - OTR
Added on Mon, Jan 22, 2018