Mini-guide: how to actually read MTR output

How to actually read MTR output

MTR lies to you. Not on purpose, but everyone treats it like gospel and then wonders why their "network issue" was actually their own firewall!

Here's the 30-second version. MTR sends ICMP probes. Each hop decrements TTL. When TTL hits zero, that hop spits back an ICMP Time Exceeded. The latency you see is ROUND TRIP to that hop, not "time through" to the destination.

Common trap: hop 5 shows 200ms. Everyone blames hop 5. But hop 6, 7, 8 are fine? Then hop 5 is rate-limiting ICMP replies, not actually slow. It prioritizes real traffic over your probe packets.

What could go wrong:

• Asymmetric routing
• MPLS tunnels hiding true paths
• ICMP de-prioritization
• Your own egress filter catching replies

Always check reverse MTR. Always run tcptraceroute as sanity check.

WARNINGS: never expose MTR results publicly without scrubbing your

Back in 1987 we had nothing this elegant for path analysis. We used the Google to look up AS paths and called the NOC on a rotary phone. You young folks do not know how good you have it. One thing you missed: watch for the SAME hop repeating, that means a routing LOOP and you should panic appropriately. Also the Facebook never loads right when MTR shows loss at hop 2, in my experience.

Rate_limiting = "not actual congestion"
Trust_single_hop = False
Cattle_not_pets = True

`olespete` is `correct` about `asymmetric paths`. `Kubernetes` clusters `especially` suffer `here` because `your` `pod` `egress` `and` `ingress` `may` `traverse` `entirely` `different` `AS` `paths` depending `on` `which` `node` `scheduler` `placed` `you` `on`. `cattle` `not` `pets`: `if` `one` `path` `is` `sus`, `terminate` `and` `let` `deployment` `spin` `fresh`.

I run mtr-exporter in a container scraping every target every 30s, Grafana dashboard showing history, all behind traefik with authelia for auth. Takes maybe 20 minutes to set up and you own the data. No trusting some SaaS with your path diagnostics. The compose file is trivial, three services, I can share if anyone wants. Point is: own your tools, own your visibility.

RFC 792 defines ICMP, RFC 1393 traceroute via IP option (deprecated), modern practice follows RFC 4884 for extended headers. AS path visibility depends on whether hops expose their interface IPs or use RFC 1918 space internally. I see this daily on prefix 203.0.113.0/24 which traverses three ASes before hitting my edge.

[your host] --+-- [AS64500 edge] --+-- [IXP fabric] --+-- [AS64501 core]
| 1.2ms | 0.4ms | 12ms
+-- [backup path, cold potato] -----------------------+

If you do not own an ASN, your visibility ends where your provider's policy says it ends. Complaining about "hop 5" when you cannot see the BGP communities applied there is amateur hour.

This tool Important for troubleshooting but server down since 3 hours and MTR show all green. I blame wrong hop for hours because ICMP rate limited and I not know. Since yesterday I learn this the hard way. My provider Contabo say "network fine" and MTR agree but application broken. Now I tcptraceroute always, no trust MTR alone. Important lesson: one tool never enough.