How to not misinterpret MTR results
Article Number: 1312 | Rating: 5/5 from 1 votes | Last Updated: Mon, Jun 11, 2018 at 11:40 AM
How to not misinterpret MTR results
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.
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 relatively simple to learn how to avoid the most common ways of misreading them.
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 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.
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 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.
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 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.
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.
There are no attachments for this article.
What is GeoIP?
Added on Fri, Oct 31, 2014
How to find a development partner
Added on Mon, Feb 16, 2015
What is the DMCA?
Added on Mon, Dec 29, 2014
How to request and revoke facility access - OTR
Added on Mon, Jan 22, 2018
What is SOAP?
Added on Tue, Jan 6, 2015
How to change SSH passwords from the CLI
Added on Thu, Feb 8, 2018
How to transfer domains
Added on Wed, Nov 23, 2016
What is Git?
Added on Mon, Sep 15, 2014
Colocation Access Card Request Form
Added on Tue, Oct 6, 2015
How to request and revoke facility access (MEL, TMR)
Added on Wed, Feb 28, 2018