How to Read a Traceroute: What the Output Actually Tells You

A traceroute tells a story about a network path — if you know how to read it

The output of a traceroute looks like a table of numbers. Most people glance at it and aren't sure what they're supposed to notice. A network engineer looks at the same output and immediately identifies where latency is being introduced, which hop is overloaded, whether a routing anomaly is happening, and whether the destination is experiencing trouble at its end.

The difference is knowing what patterns mean something versus what patterns are normal and expected.

How traceroute works

Traceroute exploits the TTL (Time to Live) field in IP packets. Every IP packet has a TTL — when a router forwards a packet, it decrements the TTL by 1. When TTL reaches 0, the router discards the packet and sends an ICMP "Time Exceeded" message back to the sender.

Traceroute sends packets with incrementing TTL values:

• TTL=1: the first router decrements to 0, discards the packet, and sends an ICMP Time Exceeded. We learn hop 1's IP and round-trip time.
• TTL=2: passes hop 1, reaches hop 2, which sends the ICMP Time Exceeded.
• And so on until the destination is reached.

Each "hop" in the output corresponds to one router in the path. The latency shown for each hop is the round-trip time from your machine to that hop — not the incremental time added by that hop.

Reading the output

A typical traceroute output:

 1  192.168.1.1          1.2 ms   1.1 ms   0.9 ms
 2  100.64.0.1           8.4 ms   8.2 ms   8.5 ms
 3  ae0.edge1.london.isp.net  11.3 ms  10.9 ms  11.0 ms
 4  ae2.core1.london.isp.net  12.1 ms  11.8 ms  12.2 ms
 5  195.66.224.125       14.8 ms  14.5 ms  14.9 ms
 6  185.71.118.0          22.3 ms  22.1 ms  22.4 ms
 7  * * *
 8  target.example.com   45.2 ms  44.8 ms  45.3 ms

Column 1: hop number Columns 2–4: round-trip time for three separate probe packets (or * for no response)

What asterisks mean

* * * at a hop does not mean the hop is down. It means that hop doesn't respond to ICMP (or UDP, depending on which probe type is used). Many routers de-prioritise or block traceroute probes to reduce load from constant internet scanning.

Normal asterisks:

• A hop with * * * followed by the next hop responding: the router is silently blocking probes but forwarding traffic normally.
• The final few hops before a successful response sometimes show asterisks: the destination responds but intermediate hops block.

Abnormal asterisks:

• All remaining hops showing * * * after a specific point: traffic is being blocked, lost, or the path reaches a dead end.
• Asterisks at the destination itself (while other hops respond): the destination is filtering ICMP but the path is fine. Or the destination is unreachable.

Common traceroute patterns and what they mean

Normal latency accumulation

Hop 1:  1ms
Hop 2:  8ms
Hop 3: 11ms
Hop 4: 12ms
Hop 5: 23ms
Hop 6: 45ms

Latency increases gradually across hops. This is normal — each hop adds propagation delay as the packet travels further. No individual hop causes a dramatic jump.

The single high-latency hop that doesn't affect subsequent hops

Hop 3:  12ms
Hop 4: 120ms   ← spike
Hop 5:  15ms   ← back to normal

This almost always means hop 4 is rate-limiting ICMP probes — it's adding the probes to a low-priority queue, making the RTT to hop 4 appear high. But since hops 5 and beyond are faster, the spike doesn't represent actual path latency. Traffic flows through hop 4 normally; only the probe measurement is delayed.

This is the most common traceroute misinterpretation. An isolated high-latency hop that isn't followed by elevated latency on subsequent hops is not a problem.

Persistent latency increase

Hop 5:  15ms
Hop 6:  18ms
Hop 7:  95ms   ← transatlantic jump
Hop 8: 100ms
Hop 9: 102ms

When latency jumps significantly at one hop and stays elevated for all subsequent hops, that hop is where the latency is being introduced. Hop 7 is likely the transatlantic link (going from a European POP to a US endpoint) — the ~80ms jump is consistent with a transatlantic round trip (~40ms one way × 2).

This pattern shows where in the path long-distance propagation occurs.

Routing anomaly (route asymmetry)

Hop 8: ae2.de-cix.example-carrier.net   12ms
Hop 9: ae2.lon-backbone.example-carrier.net   85ms
Hop 10: ae2.de-cix.example-carrier.net   90ms

Traffic appearing to go from DE-CIX (Frankfurt) to London and then back to DE-CIX indicates a routing anomaly — traffic is taking a suboptimal path. This could be a misconfigured routing policy or a temporary reroute around a fault.

High packet loss at destination

If the destination hop shows high variance across the three probes — one fast, one medium, one timeout — or consistently high RTT compared to the previous hop, the problem is likely at or near the destination. Could be server overload, rate limiting, or a network problem at the destination's end.

ICMP traceroute vs. TCP traceroute

Standard traceroute (on Windows: tracert) uses ICMP. Linux traceroute uses UDP by default, with ICMP available via -I flag. tcptraceroute and Nmap's traceroute use TCP.

Why it matters: firewalls often block ICMP but allow TCP 80 or 443. A TCP traceroute to port 443 passes through firewalls that would block ICMP probes, giving a more accurate path picture for HTTPS traffic.

If standard traceroute shows blockage at hop N but you can successfully access the destination, try tcptraceroute destination 443 — this probes using the same protocol the actual traffic uses.

Traceroute from multiple locations

A traceroute from your machine shows the path from your network. The path in the other direction (destination to you) may be completely different — internet routing is often asymmetric. If a problem only affects traffic in one direction, you need a traceroute from the destination end.

Online tools (traceroute.catchpoint.com, mtr.cloudflare.com, and similar) run traceroutes from distributed probes worldwide — useful for diagnosing whether a path problem is local to your network or global.

How to use the Traceroute tool on sadiqbd.com

1. Enter the hostname or IP
2. Run — the tool sends probe packets and maps each hop
3. Look for:
   • Where latency increases consistently (the hop introducing delay)
   • Isolated high-latency hops that don't affect subsequent hops (ICMP rate limiting — usually not a real problem)
   • Asterisks followed by normal responses (router blocks probes but forwards traffic)
   • Persistent asterisks from a specific hop onward (traffic being blocked or lost)

Frequently Asked Questions

Why does my traceroute to a website show fewer hops than I expected? Some networks use MPLS (Multi-Protocol Label Switching) for internal routing — these hops don't decrement TTL normally and are invisible to traceroute. What appears as hop 4 and hop 6 might actually have several routers in between.

Why does traceroute sometimes show different results on repeated runs? Internet routing is dynamic. Load balancing, BGP routing changes, and different probe results all cause variation. Multiple traceroutes to the same destination may show different paths.

What is MTR and is it better than traceroute? MTR (Matt's Traceroute / My TraceRoute) combines traceroute and ping — it runs continuously and shows cumulative statistics (packet loss percentage, jitter) per hop. It's more informative for persistent network investigation. mtr --report destination gives a clean report.

Is the Traceroute tool free? Yes — completely free, no sign-up required.

Traceroute output rewards attention. The patterns — where latency accumulates, what asterisks indicate, what a single high-latency hop actually means — become readable quickly, and the tool becomes genuinely diagnostic rather than just producing a wall of numbers.

Try the Traceroute tool free at sadiqbd.com — map the network path to any host and identify where latency and packet loss originate.