Five Ways People Misread a Traceroute

Most traceroutes that look alarming are fine, and some that look fine are not. The five misreadings that send people chasing faults that do not exist.

A traceroute is the most widely run and most widely misread diagnostic on the internet.

Someone sees 40% loss at hop 6, concludes their ISP is broken, and opens a ticket. The ISP closes it, correctly, because hop 6 is fine — the router there deprioritised the diagnostic packets while continuing to forward transit traffic.

The tool is genuinely useful. But almost everything that looks like a problem in its output is not one, and the few things that matter are easy to walk past. This is what to actually look at.

Trace from outside your own connection

The MTR tool probes continuously from our servers, which can reveal intermittent loss and latency patterns that a single traceroute may miss. Column-by-column reference is here.

Run an MTR →

1. Treating mid-path loss as a fault

This is the big one, and it accounts for most false alarms.

HOST                        Loss%   Snt   Last   Avg  Best  Wrst
 1. 192.168.1.1              0.0%   100    0.4   0.5   0.3   1.2
 2. 10.x.x.x                 0.0%   100   11.2  12.1   9.8  24.0
 3. core1.isp.net           38.0%   100   14.7  15.2  12.1  41.3   ← alarming
 4. core2.isp.net            0.0%   100   15.9  16.4  13.0  38.7
 5. peer.transit.net         0.0%   100   28.4  29.1  25.2  55.9
 6. target                   0.0%   100   31.0  31.8  28.4  60.1

Hop 3 shows 38% loss. Hop 3 is fine.

Routers have two quite different jobs: forwarding packets, and generating ICMP replies about themselves. The first runs in dedicated hardware. The second runs on a general-purpose control CPU that is deliberately rate-limited, because responding to every probe on the internet would be a denial-of-service vector.

So a busy router drops replies about itself while forwarding your actual traffic untouched. That is a policy, not a fault.

As a practical rule: intermediate-hop loss becomes significant when it persists through the hops after it, and especially when it reaches the destination. Loss at one hop that clears afterwards is generally the router declining to answer — if packets were genuinely being dropped at hop 3, hops 4, 5 and 6 could not show 0%, since they are reached through hop 3.

The most important rule

Start with the destination, not the middle of the trace. The last hop is the one that describes what your traffic actually experiences. Intermediate hops only mean something in the context of what follows them.

Do instead: read the destination's loss figure first, then work backwards to find where a persistent pattern begins.

2. Reading only the outbound path

A traceroute shows the route from you to the destination. It does not show the route back.

Those are frequently different — internet routing is asymmetric by design, and each network chooses its own outbound policy independently. Return traffic can take an entirely different set of networks.

This matters because a fault on the return path is invisible to you. Your trace is clean, your ISP's trace is clean, and the problem is real. Every hop you see is being probed by your packets going out; the replies come back over a path nothing in your output describes.

A normal traceroute from your device cannot directly show the return path. Investigating that direction needs a measurement originating from the far end or another vantage point — which is what a reverse traceroute provides, and why it resolves a category of "everyone's tests are clean but it is still broken" cases.

Do instead: treat a clean outbound trace as covering one direction only, and test the return path before concluding the network is fine.

3. Assuming the path is stable

Networks load-balance. A single destination is often reachable by several equal-cost paths, and consecutive packets can take different ones.

In MTR this appears as a hop position that alternates between two hostnames, or as latency that swings between two clusters — say 20 ms and 60 ms — with nothing in between. That bimodal pattern is a signature of two paths, not of instability on one.

Run 1   →  A  →  B  →  C
Run 2   →  A  →  D  →  C
Run 3   →  A  →  B  →  C

Different traces do not automatically mean the network is unstable — they often mean traffic is being distributed across equal-cost paths, exactly as designed.

It also means a single traceroute is a sample, not a map.

Do instead: run it several times and compare, rather than treating one run as the route.

4. Trusting latency increases between hops

Rising latency along the path is expected — each hop is further away. What people misread is a jump.

A 60 ms jump between two consecutive hops is often a long physical link — a submarine cable, a transcontinental span — but do not infer geography from a single-hop increase alone. Queueing, response scheduling and the return path of that particular probe all contribute to what one hop reports.

What actually indicates a problem is latency that increases and stays elevated for every hop afterwards, particularly if it varies a lot between probes at the same hop. A single hop showing high latency while the next hop is lower is, again, control-plane scheduling on that one router rather than anything on the path.

Do instead: check whether the elevated latency persists to the destination before blaming the hop where it appeared.

 5. london.transit.net       12ms    ← 
 6. newyork.transit.net      88ms    ← +76ms, this is the Atlantic
 7. newyork-edge.net         89ms       normal from here

Nothing is wrong with that trace.

5. Expecting every hop to answer

Asterisks look like failures and usually are not.

 7. * * *
 8. * * *
 9. target.example.com       0.0%   100   42.1

Hops 7 and 8 did not reply. Hop 9 did — so packets clearly traversed them. Common reasons a hop stays silent:

• ICMP responses are disabled by policy, which is routine on backbone and security-conscious networks.
• The hop is inside an MPLS tunnel and is not visible as a hop at all.
• A firewall drops the probe type while permitting normal traffic.

Asterisks become significant when the silence continues all the way to the destination and the destination itself never answers. Then something is genuinely dropping traffic rather than declining to identify itself.

Do instead: check whether later hops and the destination respond before reading silence as failure.

Traceroute is not always using the same protocol

Traceroute is a technique, not a single protocol, and which probe it sends changes what you see. A firewall that drops one probe type while permitting another produces a trace that looks broken and is not.

Linux / macOS
  traceroute example.com            # UDP probes by default on many builds
  traceroute -I example.com         # ICMP Echo
  traceroute -T -p 443 example.com  # TCP SYN to port 443

Windows
  tracert example.com               # ICMP Echo

tracert on Windows and traceroute on Linux therefore do not necessarily test the same thing, which is a common source of "it works on my machine" disagreements between a user and their ISP.

If UDP fails but TCP to port 443 succeeds, that points at filtering of the probe type rather than a routing failure — and TCP probes to the port your application actually uses are usually the most representative test, because they travel the same path your real traffic does.

Which tool for which question

What a real problem looks like

Having covered what is not a fault, here is what is:

HOST                        Loss%   Snt   Avg
 1. 192.168.1.1              0.0%   100   0.5
 2. 10.x.x.x                 0.0%   100  12.1
 3. core1.isp.net            0.0%   100  15.2
 4. peer.transit.net        11.0%   100  29.4   ← starts here
 5. next.transit.net        11.0%   100  31.7   ← and continues
 6. target                  12.0%   100  33.1   ← reaches you

Loss appears at hop 4 and persists through every hop after it, including the destination. That is traffic actually being dropped, and hop 4 is where it begins.

Three qualifiers before acting on it:

• Reproduce it. Run several times across different hours. One bad run proves nothing, and congestion is time-dependent.
• Test a second destination on a different network. If loss appears on every path, the problem is nearer you. If only one destination is affected, it is likely a peering or transit issue.
• Check both directions, per point 2 above.

Turning it into something an ISP will act on

Support desks receive a great many traceroutes that show nothing. What distinguishes a ticket that gets escalated:

• Continuous probing, not a single run. MTR over several minutes; a one-shot traceroute is a snapshot.
• The destination's loss figure, stated plainly, not a mid-path number.
• Timestamps and repetition — the same test at several times of day, showing whether it is constant or congestion-linked.
• A control test to a different network, demonstrating the problem is not universal.
• Tested wired, with Wi-Fi eliminated as a variable.
• The destination, stated explicitly. "11–12% loss to 203.0.113.10 between 20:00 and 21:00, while a second destination stayed at 0%" is actionable. "I have packet loss" is not.

The guide to proving packet loss to an ISP covers how to assemble that. The short version: quoting a mid-path loss percentage is a good way to have a ticket closed without investigation, because the engineer reading it knows what those numbers usually mean.

Frequently asked questions

Why does traceroute show packet loss at one hop but not the next?

Because that router is rate-limiting the ICMP replies it generates about itself, while forwarding your traffic normally. If it were genuinely dropping packets, every subsequent hop would show loss too — they are only reachable through it.

Which hop's packet loss actually matters?

The last one, your destination. It describes what your traffic actually experiences. Mid-path figures only mean something when the loss continues through every hop after them.

What do the asterisks in a traceroute mean?

That hop did not reply. Usually ICMP is disabled by policy or the hop sits inside an MPLS tunnel. It only indicates a problem when asterisks continue all the way to the destination and it never answers.

Why does latency jump between two hops?

Almost always distance — a long-haul or submarine link between them. A jump alone is not a fault. What matters is whether the elevated latency persists to the destination and how much it varies between probes.

Is MTR better than traceroute?

For diagnosis, generally yes. Traceroute sends a few probes per hop and prints a snapshot; MTR probes continuously and reports loss and latency distribution over time, which is what catches intermittent problems. A single traceroute can easily miss a fault that appears in 5% of packets.

Why do the hops change between runs?

Load balancing. Multiple equal-cost paths exist to most destinations and packets are distributed across them, so consecutive runs can legitimately show different routes. Bimodal latency at one hop position is the usual sign.

Can traceroute prove packet loss?

Not on its own. A single traceroute sends only a few probes per hop, and the loss it reports at intermediate hops is frequently ICMP rate limiting rather than dropped traffic. Repeated probing with MTR, showing loss that reaches the destination and reproduces across several runs, is what constitutes evidence.

Why does ping work but traceroute fail?

Usually because they use different probes. Ping sends ICMP Echo, while traceroute on many systems sends UDP by default, and a firewall may permit one and drop the other. Trying traceroute -I for ICMP or traceroute -T -p 443 for TCP will often complete where the default fails.

Why does traceroute show a different route each time?

Load balancing. Most destinations are reachable over several equal-cost paths and packets are distributed across them, so consecutive runs legitimately differ. A hop position alternating between two hostnames, or latency clustering around two distinct values, is the usual sign.

Can traceroute show problems on the return path?

No — it only measures the route away from you. A fault on the return path is invisible in your own output, which is why a clean trace does not rule out a real problem. Seeing that direction requires a measurement from the far end or another vantage point.