Learn the basics of interpreting results provided by the My Traceroute (MTR) tool 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.
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 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 24/7 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 your Client Portal.
