mtr vs traceroute: Packet Loss

“I see 80% packet loss on hop 4!” — and you’re wrong.

You’re staring at a traceroute output, and somewhere in the middle of the path to your VPN server, packets are dropping like someone unplugged a router. You fire off an angry ticket to your ISP. They respond 4 hours later: “Our monitoring shows no loss on that circuit.”

They’re not gaslighting you. Traceroute is just lying to you by accident.

Here’s the thing: traceroute was designed in 1987 to answer one question — “what hops exist between here and there?” — not “what’s the packet loss on each hop?” But everyone uses it to diagnose loss anyway, and the results are almost always misleading. By the time you see loss in traceroute output, you’ve already blamed the wrong ISP, the wrong router, and possibly rebooted your entire home lab for nothing.

Enter mtr: My Traceroute. It does the same job as traceroute but with continuous probing, better statistics, and — most importantly — it forces you to stop misinterpreting what you’re seeing.

This is a guide to reading packet loss like an oncall engineer, understanding why intermediate hops show 80% loss that doesn’t matter, and knowing when you actually have a real problem versus ICMP rate limiting on someone’s firewall.

How Traceroute Actually Works (the part they leave out)

Traceroute sends packets with a gradually increasing TTL (Time To Live) value. When a packet hits a hop, that hop decrements the TTL by 1. When TTL reaches 0, the router sends back an ICMP “TTL Exceeded” message.

By sending packets with TTL=1, then TTL=2, then TTL=3, traceroute builds up a list of which routers are on the path. It’s clever. It’s also 1987-era clever, which means it has some nasty blind spots.

Here’s the problem: traceroute doesn’t know if the routers on that path are dropping packets. It only knows those routers exist. When a router sends back the “TTL Exceeded” reply, it doesn’t mean the packet was delivered to the destination — it just means the router is alive.

Worse, intermediate routers often rate-limit ICMP replies. This is a security feature. Your ISP’s core router might be configured to respond to only 1-in-10 ICMP echo requests, or to not respond to traceroute probes at all. So when you run traceroute and see * * * on some hop, that doesn’t mean the hop is down — it usually means the hop is being polite by not flooding your terminal with ICMP replies.

If you’re looking at a traceroute output where hop 4 shows 80% loss and hop 5 and beyond show 100% loss, your first instinct is correct: something’s wrong. But it’s not necessarily wrong at hop 4. It could be that hop 4 simply rate-limits ICMP, so it’s ignoring 80% of your probes. The packet you care about — the one trying to reach your destination — might have passed through just fine.

And that’s the rule that actually matters:

Only the loss on the final hop (your destination) is real loss. Everything else is probably noise.

Enter mtr: The Continuous Probe

mtr fixes this by running continuous probes to each hop over 30+ seconds, collecting statistics like loss percentage, latency (Last, Avg, Best, Worst, StDev), and packet counts. This gives you:

1. Enough samples to see real patterns — If a hop is legitimately dropping packets, you’ll see consistent loss across hundreds of probes.
2. Time to see if loss is intermittent — A one-off spike looks different from chronic loss.
3. A clearer picture of what matters — If the destination (final hop) shows 0% loss, the end-to-end connection is fine, even if hop 4 shows 50% loss.

The output looks like this:

Host                                   Loss%   Snt Last   Avg  Best Wrst StDev
1. 192.168.1.1                          0.0%    15  2.1   2.8   1.9  4.2  0.8
2. 10.0.0.1                             0.0%    15  5.3   6.1   4.9  8.2  1.1
3. isp-gw.example.com                  45.0%    15 12.4  14.2  10.1 22.5  4.0
4. isp-core1.example.com               48.0%    15 18.9  19.5  17.2 25.3  2.7
5. 203.0.113.50                         0.0%    15 24.1  25.0  23.8 27.5  1.2
6. vpn-endpoint.example.com             0.0%    20 28.3  29.1  27.1 31.2  1.3

Read this like a detective. Hops 1–2: clean. Hops 3–4: scary-looking 45–48% loss. But hops 5–6 (closer to the destination, ending at your actual target): 0% loss.

Translation: The ISP’s core routers are rate-limiting ICMP replies to probes, but they’re forwarding the actual traffic just fine. Your connection is fine. Stop blaming the ISP.

Understanding the mtr Report Format

Each column tells you something:

• Loss%: Percentage of probes that got no reply from this hop. Not the same as packet loss on your actual traffic.
• Snt: Number of probes sent to this hop. More probes = more reliable statistics.
• Last: Latency of the most recent probe.
• Avg: Average latency across all probes.
• Best: Lowest latency seen.
• Wrst: Highest latency seen.
• StDev: Standard deviation (jitter indicator — higher = flakier).

When you’re reading this, focus on:

1. Does the final hop show 0% loss? If yes, stop reading. Your connection works.
2. Does loss increase as you move toward the destination? If no, loss is probably ICMP rate limiting, not real packet loss.
3. Is the final hop’s latency reasonable? You care about that number, not the latency at hop 4.

The Asymmetric Routing Gotcha

Here’s a sneaky one: the path your packets take to reach a destination might not be the same path they take coming back.

When you run mtr example.com, you’re seeing the outbound path — the hops between you and example.com. But the return traffic might bounce through completely different routers. If one direction has an issue, you’ll see it in your mtr from that direction, but not the other way.

This is why oncall engineers run mtr from both ends:

# On your home lab
mtr -c 100 vpn-endpoint.example.com

# SSH into the VPN endpoint and run
mtr -c 100 your-public-ip

If you’re seeing loss only in one direction, you’ve just narrowed the problem to half the network. If both directions are clean, the problem isn’t network loss — it’s the application or the VPN itself.

ICMP vs TCP: Choosing Your Probe Protocol

By default, mtr uses ICMP (the same as ping and classic traceroute). But many networks rate-limit or block ICMP. Your ISP might rate-limit ICMP to you, or a corporate firewall between you and your VPN server might drop ICMP entirely.

If you’re seeing loss or timeouts that don’t match reality, try TCP probes instead:

# Use TCP probes on port 443 (HTTPS)
mtr -T -P 443 -c 100 vpn-endpoint.example.com

The -T flag tells mtr to use TCP SYN packets. The -P 443 specifies the destination port. Most firewalls won’t rate-limit TCP SYN probes the way they rate-limit ICMP, so you’ll get cleaner data.

If TCP probes show 0% loss but ICMP probes show 50%, congratulations: an intermediate network is deliberately blocking or rate-limiting ICMP, which is fine for your actual traffic (which is TCP/UDP).

JSON Mode for Shipping to Observability

If you’re running mtr as part of a larger troubleshooting automation or you want to ship the data into an observability pipeline (Prometheus, Grafana, Splunk, whatever), use JSON output:

# Run for 100 probes, output as JSON
mtr -j -c 100 vpn-endpoint.example.com > mtr-report.json

The JSON output is clean and machine-readable:

{
  "report": {
    "mtr_version": "0.95",
    "timestamp": "2026-06-13T12:00:00Z",
    "from": "home-lab.example.com",
    "to": "vpn-endpoint.example.com",
    "packets": 100,
    "probe_ipprotocol": "IP4",
    "hops": [
      {
        "count": 1,
        "host": "192.168.1.1",
        "loss": 0.0,
        "snt": 100,
        "last": 2.5,
        "avg": 2.7,
        "best": 2.1,
        "wrst": 4.2,
        "stdev": 0.6
      },
      {
        "count": 2,
        "host": "10.0.0.1",
        "loss": 0.0,
        "snt": 100,
        "last": 6.1,
        "avg": 6.3,
        "best": 5.1,
        "wrst": 8.5,
        "stdev": 0.8
      }
    ]
  }
}

You can pipe this into jq, parse it in Python, feed it to your monitoring stack, whatever. Much easier than parsing the terminal output.

Reading a Real ISP Problem

After all that, what does actual packet loss look like in mtr?

It looks like this: loss starts at one hop and stays at every hop after that.

Host                                   Loss%   Snt Last   Avg  Best Wrst StDev
1. 192.168.1.1                          0.0%    50  2.1   2.8   1.9  4.2  0.8
2. 10.0.0.1                             0.0%    50  5.3   6.1   4.9  8.2  1.1
3. isp-gw.example.com                   0.0%    50 12.4  14.2  10.1 22.5  4.0
4. isp-core1.example.com               25.0%    50 18.9  19.5  17.2 25.3  2.7
5. 203.0.113.50                        25.0%    50 24.1  25.0  23.8 27.5  1.2
6. vpn-endpoint.example.com            25.0%    50 28.3  29.1  27.1 31.2  1.3

See that? Clean through hop 3, then 25% loss starting at hop 4, and it persists through hops 5 and 6. That’s real loss. The ISP’s core router (hop 4) is actually dropping packets, not rate-limiting ICMP. Your email is going to be angrier than before, but now you can point to this data and the ISP can’t pretend you’re wrong.

Common False Positives (and how to rule them out)

ISP ICMP rate limiting: Loss on intermediate hops, 0% on destination. Rule it out: Run TCP probes with -T.

Corporate firewall rate limiting: Sudden jump in loss at the boundary of the corporate network, drops to 0% after. Rule it out: Run from a different network (mobile hotspot, different ISP). If loss persists, it’s not the firewall.

Your own gateway rate limiting: Loss on hop 1, clean after. Rule it out: SSH into the gateway and check its iptables rules or firewall logs. Or just live with it — it’s usually intentional.

Asymmetric routing: Loss in one direction, not the other. Rule it out: Run mtr from both ends.

NAT or carrier-grade NAT: Hops behind a NAT sometimes don’t reply to ICMP at all, showing as *. Rule it out: It’s not loss, it’s invisibility. TCP probes usually see through it.

MPLS or segment routing: Some carriers use MPLS and hide their internal topology. Hops show as IP addresses from weird ranges, or all show the same latency. Rule it out: Ask your ISP. Or just ignore it if your destination has 0% loss.

Your Oncall Debugging Checklist

You’re paged. Latency is high or packets are dropping somewhere. Here’s the flow:

1. Run ICMP mtr — mtr -c 100 destination-host
2. Check the final hop — Is loss 0%? If yes, you’re probably fine. Stop here.
3. If destination shows loss — Run TCP mtr to the same destination on port 443 (or whatever port you care about):

   mtr -T -P 443 -c 100 destination-host

4. If TCP shows 0% but ICMP shows loss — ICMP is being rate-limited. Not your problem.
5. If both show loss — You have real packet loss. Continue.
6. Find where loss starts — Scan upward through hops. When does loss first appear?
7. Run mtr from the other end — SSH into the destination and mtr back to you.
8. If loss is one-way — Problem is on that one path. If it’s both ways, problem is the link between you and the destination.
9. Ship JSON output to a ticket — mtr -j -c 200 host > mtr-report.json. Include it in your ticket. Include the timestamp.

Why mtr Wins

Traceroute shows you the path. That’s useful for topology discovery, but useless for loss diagnosis.

mtr shows you the path and gives you statistics about what’s happening on each hop. It runs continuous probes, so you get enough samples to tell signal from noise. It gives you options (ICMP vs TCP, JSON output) so you can adapt to different networks and automation needs.

Most importantly, mtr forces you to think differently about loss. Instead of “packet loss on hop 4 = problem at hop 4,” you learn to ask “does the destination have loss?” If not, everything between you and the destination is working fine, even if it looks scary in the middle.

That’s the oncall mindset: only the numbers that matter matter. Everything else is noise.

TL;DR

• traceroute shows topology. mtr shows statistics.
• Only the destination’s loss is real loss. Everything else is probably ICMP rate limiting.
• Use -T -P 443 if intermediate hops are suspicious.
• Run mtr from both ends if you suspect asymmetric routing.
• Output JSON with -j and ship it to your monitoring stack.
• When you see loss on the final hop that persists across multiple runs, then you call the ISP.

Related Reading

• Fail2ban vs CrowdSec: Blocking the Bots Actually Smartly
• iperf3 + nload: Network Diagnosis
• NFS vs SMB vs SSHFS vs WebDAV for Home Lab
• Proxmox NAT Bridge: One IP, Many VMs
• Suricata vs Snort: Network Intrusion Detection That Actually Works