What MTR Is Actually Doing
At its core, `mtr` (My Traceroute) combines the path-finding of `traceroute` with the continuous polling of `ping`. It sends out a series of packets with an incrementally increasing Time-to-Live (TTL) value. Each router, or "hop," along the path decrements
the TTL. When the TTL hits zero, the router sends back an "ICMP Time Exceeded" message, revealing its place in line. MTR then repeats this process, collecting stats like latency and packet loss for every hop. This continuous nature is what makes it so powerful for spotting intermittent issues, but it's also the first source of confusion. You're not just seeing a static path; you're watching a live performance of the network's response to a constant stream of probes.
The Packet Loss Mirage
The most common pitfall is panicking over packet loss at an intermediate hop. You run an `mtr` and see a router in the middle of the path showing 20% loss, and alarms go off. But then, every subsequent hop shows 0% loss. This is rarely a real problem. Many high-capacity routers are configured to deprioritize or rate-limit the very ICMP packets `mtr` uses for its tests. The router's main job is forwarding actual user traffic (the data plane), which it does with specialized, high-speed hardware. Responding to your diagnostic probes is a low-priority task handled by its much busier main CPU (the control plane). As long as the loss doesn't persist to the final destination, that scary red number is usually just the router telling you it has better things to do than answer your pings. The only time to worry is when packet loss starts at a hop and continues all the way to the end.
Decoding Latency Spikes and Jumps
Another head-scratcher is latency. You might see a sudden jump from 10ms at hop 4 to 150ms at hop 5, but then the latency stays at 150ms for the rest of the path. This doesn't mean hop 5 is slow; it means the physical distance or network medium changed significantly after that hop. For example, the packet may have just crossed an ocean. The key is to look for a sustained increase that carries through to the end. A single, isolated spike in the "Last" or "Wrst" column that doesn't affect the "Avg" (average) is often just a momentary hiccup or, again, the router's control plane being briefly busy. What matters is the final average latency and whether it meets your application's needs.
When the Path Isn't What It Seems
Two advanced concepts often trip up even the experts: asymmetric routing and TCP-based probes. First, the path from you to a server is not always the same as the path back. Your `mtr` report only shows the outbound route. If the problem is on the return path, your test won't see it, leading to a frustrating dead end. This is why it's crucial to get a bidirectional MTR—one from the source to the destination and another from the destination back to the source—to get a complete picture. Second, `mtr` uses ICMP packets by default, but your web browser or SSH session uses TCP. Some networks treat these protocols differently. If you suspect a firewall is blocking traffic, running `mtr` in TCP mode (`mtr --tcp`) can provide a more accurate test of the actual application traffic path.
Making MTR Work For You
To use `mtr` effectively, think of it as a provider of clues, not absolute answers. First, let it run for at least a few minutes (or use the report mode with a higher cycle count, like `mtr -r -c 100`) to gather a meaningful sample size. Focus on the patterns: Is packet loss consistent all the way to the end? Does latency jump and stay high? Always consider the return path by getting a trace from the other direction if possible. And if the final hop shows 100% loss but your application is working, it's likely just a firewall or server configuration that's set to ignore ICMP probes, which is perfectly normal. By understanding these nuances, you can move from simply running the command to truly interpreting the story it tells about your network connection.
