MTR, Traceroute, and the Myth of the "Scary Hop"

Or: Why That 40 Percent Packet Loss You Saw at Hop 5 Is Probably Just Messing With You

If you’ve ever run MTR or traceroute and felt your heartbeat spike at the sight of a hop showing packet loss… congratulations, you’re officially a network engineer in training. Also: relax. Most of the time, that hop is not broken, burning, smoking, or plotting against you.

Let’s walk through how these tools work, why routers sometimes ignore your probes like a busy cat ignoring its owner, and when it’s actually time to panic (spoiler: not often).

What MTR Really Does — And Why Routers Roll Their Eyes at It

Both traceroute and MTR work by sending probe packets with increasing TTL (Time To Live) values. When a router sees a TTL hit zero, it replies with ICMP Time Exceeded, revealing its presence in the path.

MTR then keeps sending these probes over and over, building a pretty table of latency and loss for every hop.

So far, so good.

But here’s the fun part: routers forward your real traffic using hardware ASICs – crazy fast silicon that does nothing but push packets at line rate. ICMP replies, however? Those come from the router’s CPU, also known as the «I have more important things to do than deal with your MTR spam» unit.

Why You Sometimes See Packet Loss on Transit Hops

1. ICMP rate limiting

Routers often allow only a certain number of ICMP replies per second. If MTR sends too many probes – hop says «nope.»

2. Control plane protection

Carriers protect their CPUs like sysadmins protect their coffee mugs. Diagnostic traffic is the first to get throttled.

3. CPU prioritization

Actual tasks like BGP updates, routing decisions, neighbor relationships, and forwarding packets are simply more important.

4. Load balancing weirdness

Your probes may take a different path than your real traffic. Some hops might not bother replying.

5. Security policies

Some networks intentionally suppress replies to avoid reconnaissance. Because yes, hackers love MTR too.

So… Is That Packet Loss Real or Just Cosmetic Noise?

Here’s the rule every sysadmin ultimately tattoos onto their soul:

If an intermediate hop shows packet loss, but the NEXT hop and the FINAL destination do not – everything is fine.

That hop is just ignoring your pings. Your real traffic is passing through smoothly at full speed.

Example:

• Hop 5: 40 percent loss
• Hop 6: 0 percent
• Destination: 0 percent

This means hop 5 is just not responding consistently to probes… but it is forwarding packets correctly.

Translation: Do not panic. Do not write to support. Do not declare a global outage in your Discord server.

When Panic Mode Should Be Activated

Real network issues follow a pattern:

• ✔ Loss appears starting at hop X
• ✔ Loss continues on hop X+1
• ✔ Loss is visible at the final destination

If the destination shows loss, then yes – something somewhere is unhappy.

Other legit warning signs:

• Latency spikes starting at a specific hop
• Loss patterns that match peak traffic hours
• Loss only at the destination host (hello overloaded server)
• The path suddenly reroutes through geographically weird places

Quick Visual Guide

• Loss at middle hop only: Good. Router is busy. Life is normal.
• Loss beginning at middle hop and continuing to the end: Potential upstream issue. Investigation time.
• Loss only at the final hop: The server might be overloaded or rate limiting ICMP. Your network is fine.
• Latency jump at a hop but no loss: It might be a backbone router prioritizing real traffic. Completely normal.

Why This Happens All Day Every Day

Routers are designed to forward packets at insane speeds. Responding to your MTR probes is basically a side gig. If they’re busy keeping the internet alive, they may skip replying – and that’s exactly what they should do.

If routers spent all day responding to MTR and traceroute, the internet would collapse faster than your VPS when you rm -rf / on the wrong machine.

When In Doubt, Check the Final Hop

The destination is what matters.
Not hop 3.
Not hop 8.
Not that spooky hop that shows 60 percent loss but still forwards everything like a champ.

If the final hop shows stability – you’re good.
If the final hop shows loss – now we’re cooking with fire.

Final Thoughts

MTR is fantastic, but it’s also a tool that’s easy to misread. Intermediate hop packet loss is usually cosmetic and meaningless. Only loss that continues to the final destination matters.

So next time MTR scares you with some red lines at hop 5, remember:

• The internet is not melting
• Your connection is probably fine
• That router is simply choosing not to talk to you
• Panic mode is optional and rarely necessary

Except when it is. Then panic responsibly.