Understanding MTR and Traceroute: Why Packet Loss on Transit Hops Usually Is Not a Problem

Network diagnostic tools like MTR and traceroute are powerful, but they are also widely misunderstood. One of the most common confusions is the appearance of packet loss on an intermediate hop. Customers often interpret this as a sign of service degradation or routing issues, but in most cases, it is completely normal and does not affect real traffic.

This article explains how MTR and traceroute work, how routers process diagnostic packets, and how to correctly interpret reports that show packet loss on transit hops.

1. How MTR and Traceroute Actually Work

Both tools discover the path to a destination by sending probe packets with increasing TTL (Time To Live):

• TTL 1 reaches the first router, which responds with ICMP Time Exceeded.
• TTL 2 reaches the second router.
• The process continues until the probes reach the final destination.

MTR repeats these probes continuously and aggregates latency, jitter, and packet loss statistics for each hop.

Important Note

Intermediate routers are not sending your traffic to themselves. They only generate ICMP responses when the TTL expires. These responses are extra work for the router, unrelated to actual traffic forwarding.

2. Why Routers Drop or Ignore MTR and Traceroute Probes

Modern network routers forward customer traffic using high-speed ASICs or hardware forwarding engines. This part of the router is extremely fast and works independently of the router’s CPU.

However, ICMP responses generated by traceroute and MTR are created by the control plane CPU, not the ASIC.

This means:

• Forwarding of your real traffic happens in hardware.
• Responses to diagnostic tools happen in software.
• The router CPU may rate limit or deprioritize ICMP to protect itself.

When a router is busy or has rate limiting policies applied, it may simply choose not to reply to some traceroute or MTR probes. Your actual data traffic continues to pass through at line rate.

This is normal and expected.

3. Common Reasons for Packet Loss on Transit Hops

3.1. ICMP Rate Limiting

Routers often limit the number of ICMP packets they will generate per second. If the limit is reached, additional probes are silently dropped.

3.2. Control Plane Protection

Large carriers almost always implement policies that throttle or deprioritize diagnostic traffic.

3.3. CPU Prioritization

Routers prioritize routing operations, BGP updates, and customer forwarding, not diagnostic replies. If the CPU is busy, traceroute replies are the first to be dropped.

3.4. Load Balancing

Probes may take different load-balanced paths, and some routers or line cards simply do not respond consistently.

3.5. Security Policies

Some transit networks intentionally suppress TTL-expired ICMP messages to reduce reconnaissance or minimize unnecessary workload.

4. When Packet Loss on a Hop Does Not Indicate a Problem

A key rule for reading MTR:

If packet loss appears on an intermediate hop, but the next hop and the final destination show 0 percent loss, then there is no real network issue.

Example:

• Hop 5: 40 percent loss in MTR output
• Hop 6: 0 percent
• Destination: 0 percent

This means hop 5 simply chose not to reply to some probes. It forwarded the traffic correctly.

This is cosmetic loss and does not affect customer traffic in any way.

5. When Packet Loss Does Indicate a Real Issue

Real packet loss will follow a predictable pattern:

• Loss begins at a certain hop.
• Loss continues for all subsequent hops.
• Loss is visible at the final destination.

This suggests congestion, a faulty link, or another upstream issue at or beyond the hop where the problem begins.

Other indicators of actual problems:

• Consistently elevated latency beginning at a specific hop.
• Loss that correlates with high traffic hours.
• Loss observed only at the destination host (indicating the host itself is overloaded).

6. Summary

• MTR and traceroute rely on ICMP responses that are handled by the router CPU, not the forwarding ASIC.
• Routers regularly rate limit or deprioritize ICMP to protect the control plane.
• Packet loss at intermediate hops is usually cosmetic and does not reflect real traffic issues.
• Only packet loss that continues through to the final hop indicates a possible network problem.

If you see loss in the middle of the path but the destination shows stable performance, this is normal behavior and not a cause for concern.