How to Read a Traceroute: Hops, Latency, and What Asterisks Mean

What Traceroute Shows You (and What It Doesn't)

Traceroute maps the sequence of routers (hops) that packets traverse between your machine and a destination host, measuring round-trip time (RTT) to each hop along the way. This gives you a picture of the network path and where delays or failures occur.

What traceroute reveals:

• The number of hops between source and destination
• The IP address and sometimes hostname of each router along the path
• Round-trip latency to each hop (typically three measurements per hop)
• Where in the path packets are being dropped or significantly delayed
• Which network or ISP owns each segment of the path

What traceroute does not reveal:

• Return path routing — packets may take a completely different path back to you, meaning asymmetric routing can skew your latency readings
• Application-layer problems (HTTP errors, TLS failures, DNS resolution issues)
• Whether a service is actually functioning correctly at the destination
• Packet loss on paths where routers deprioritise ICMP (a very common false positive)

Understanding these limitations upfront prevents the most common traceroute misinterpretations.

How Traceroute Works: TTL and ICMP Time Exceeded

Every IP packet has a Time to Live (TTL) field — a counter that decrements by 1 at each router. When TTL reaches zero, the router discards the packet and sends an ICMP "Time Exceeded" message back to the source. Traceroute exploits this mechanism deliberately.

The process works as follows:

1. Traceroute sends a probe packet with TTL set to 1. The first router decrements it to 0, discards the packet, and sends back an ICMP Time Exceeded message. Traceroute records that router's IP and the round-trip time.

2. The next probe has TTL set to 2. It passes through the first router (TTL becomes 1), reaches the second router (TTL becomes 0), which sends back a Time Exceeded. Traceroute records hop 2.

3. This continues, incrementing TTL by 1 each time, until the destination host is reached — which sends back an ICMP Port Unreachable or Echo Reply instead of Time Exceeded, signalling the end.

By default, traceroute sends three probes per TTL value. This is why each hop shows three latency measurements rather than one.

ℹ️ Note: On Windows, tracert uses ICMP Echo Request packets by default. On Linux and macOS, traceroute uses UDP packets by default. This distinction matters because some firewalls block UDP but not ICMP, or vice versa — which can cause artificially different results between operating systems for the same path.

Reading the Output: Columns Explained

A typical traceroute output looks like this:

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)          1.243 ms   1.102 ms   1.089 ms
 2  10.50.0.1 (10.50.0.1)              8.441 ms   8.387 ms   8.312 ms
 3  xe-0-0-2.cr1.lon1.isp.net          12.33 ms   12.41 ms   12.29 ms
 4  ae-14.r01.lon01.backbone.net       14.87 ms   14.93 ms   15.01 ms
 5  74.125.50.149 (google-peer.net)    15.22 ms   15.18 ms   15.31 ms
 6  * * *
 7  142.251.49.43 (google-internal)    16.05 ms   15.98 ms   16.12 ms
 8  93.184.216.34 (example.com)        89.44 ms   89.51 ms   89.38 ms

Here is what each element means:

Column 1 — Hop number. The sequential position of this router in the path. Hop 1 is always your local gateway (home router or office firewall). The final hop is the destination.

Column 2 — Hostname and/or IP address. The reverse DNS hostname of the router, if available, followed by its IP in parentheses. Many backbone routers have descriptive hostnames that identify the carrier and location — xe-0-0-2.cr1.lon1.isp.net tells you this is a core router (cr1) in London (lon1) operated by a specific ISP.

Columns 3–5 — Three RTT measurements. Round-trip time in milliseconds for each of the three probe packets sent to this hop. These should be relatively consistent. Large variation between the three values at a single hop suggests jitter or congestion at that router.

💡 Tip: Use our Traceroute tool to run a traceroute from an external vantage point — this tells you whether a path problem is specific to your network or visible from the public internet.

Annotated real-world output

 1  192.168.1.1          1.2 ms   1.1 ms   1.1 ms   # Your local gateway — should be <2ms
 2  10.50.0.1            8.4 ms   8.4 ms   8.3 ms   # ISP CPE / first hop outside your network
 3  cr1.lon1.isp.net    12.3 ms  12.4 ms  12.3 ms   # ISP core router — latency jump expected here
 4  ae-14.backbone.net  14.9 ms  14.9 ms  15.0 ms   # Backbone transit — consistent, healthy
 5  google-peer.net     15.2 ms  15.2 ms  15.3 ms   # Peering point between ISP and Google
 6  * * *                                            # Google internal router filtering ICMP probes
 7  google-internal     16.0 ms  16.0 ms  16.1 ms   # Traffic resumes — hop 6 asterisks are benign
 8  example.com         89.4 ms  89.5 ms  89.4 ms   # Destination — ~90ms transatlantic, expected

What High Latency at a Hop Means (and When to Worry)

Latency increases across the path are expected and normal — every additional router adds processing time, and physical distance adds propagation delay (roughly 1ms per 200km in fibre). What matters is not the absolute latency at any given hop but the pattern of latency across the full path.

When a latency spike is not a problem

If latency jumps significantly at one hop but then remains at that new level for all subsequent hops, the increase represents a genuine network characteristic of that segment — a transatlantic crossing, a slower link, or a peering point. The destination still reaches its final latency cleanly. This is healthy.

 4  domestic-backbone    15 ms   # Normal domestic path
 5  transatlantic-cable  85 ms   # +70ms — transatlantic crossing, completely expected
 6  us-landing-point     86 ms   # Consistent from here — not a problem
 7  destination.com      88 ms   # Destination reached cleanly

When a latency spike is a problem

If latency spikes at one hop and then drops back down at subsequent hops, the spike is almost certainly caused by that router de-prioritising ICMP probe packets under load — it's handling transit traffic normally but responding to traceroute probes slowly. This is not a network problem.

If latency spikes at one hop and continues to climb at every subsequent hop, the congestion or problem is real and originates at or before that hop.

What Asterisks (*) Mean — and When to Ignore Them

Asterisks (*) appear when a hop does not respond to traceroute probes within the timeout window. They are one of the most misread elements in traceroute output.

There are two distinct causes of asterisks, with very different implications:

Cause 1: The router filters ICMP/UDP probes (benign — very common)

Many routers — particularly internal backbone routers and cloud provider infrastructure — are configured to drop or deprioritise ICMP Time Exceeded responses. They continue forwarding transit traffic normally; they simply don't respond to traceroute probes. This is a firewall/rate-limiting policy, not a network failure.

How to identify benign asterisks: Traffic reaches the hops after the asterisk row, and the final destination responds. The asterisks are in the middle of the path, not at the end.

 5  peering-point.net    15 ms   15 ms   15 ms
 6  * * *                                        # ICMP filtered — router is working fine
 7  cdn-node.cloudflare  16 ms   16 ms   16 ms   # Traffic continues — hop 6 was benign
 8  destination.com      17 ms   17 ms   17 ms   # Destination reached

💡 Tip: Asterisks at a middle hop followed by successful responses at subsequent hops are almost always caused by ICMP filtering — not packet loss. Do not report these to your ISP as packet loss.

Cause 2: Genuine packet loss or an unreachable hop (real problem)

If asterisks appear at a hop and every subsequent hop also shows asterisks, the path has broken at that point. Either there is a routing failure, the destination is unreachable, or a firewall is blocking all traffic to the destination.

 7  isp-core-router      22 ms   22 ms   22 ms
 8  * * *                                        # No response
 9  * * *                                        # No response
10  * * *                                        # No response — path broken at hop 8

How to distinguish the two: Run a Ping Test to the destination simultaneously. If ping succeeds but traceroute shows trailing asterisks, the destination is reachable and the asterisks at the end are simply ICMP filtering at the target. If ping also fails, the destination is genuinely unreachable.

Detecting Network Problems with Traceroute

Finding the failure hop

When a network path is broken, the failure hop is the last hop that responds before a continuous run of asterisks begins. Everything before that hop is working. The problem is at that hop or between it and the next.

 9  transit-router-a     45 ms   45 ms   46 ms   # Last responding hop
10  * * *                                        # Failure begins here
11  * * *
12  * * *                                        # Destination unreachable

In this example, the problem is between transit-router-a (hop 9) and whatever router occupies hop 10. Use ASN Lookup on the IP at hop 9 to identify which network owns that segment — this tells you which carrier to contact.

Identifying routing loops

A routing loop appears as a sequence of the same IP addresses repeating across multiple hop numbers with increasing latency. This is a BGP or OSPF misconfiguration where packets are being forwarded back and forth between two routers indefinitely.

12  router-a.example.net   120 ms
13  router-b.example.net   125 ms
14  router-a.example.net   130 ms   # Same as hop 12 — loop
15  router-b.example.net   135 ms   # Same as hop 13 — loop

Identifying asymmetric routing

If the outbound latency profile looks healthy but users report slow connections or high latency from their perspective, the return path may be the problem. Traceroute only shows the outbound path. Use a remote traceroute from a tool at the destination's region back to your IP to check the return path.

Traceroute Differences Across Operating Systems

The same network path can produce noticeably different traceroute output depending on the operating system and the protocol used.

Running traceroute on each platform

# Linux / macOS — standard UDP traceroute
traceroute example.com

# Linux / macOS — ICMP mode (sometimes gets through firewalls that block UDP)
traceroute -I example.com

# Linux / macOS — TCP traceroute on port 80 (useful for web server path tracing)
traceroute -T -p 80 example.com

# Windows
tracert example.com

# Windows — skip reverse DNS (faster output)
tracert -d example.com

# MTR — continuous combined diagnostics (Linux/macOS)
mtr example.com

# MTR — report mode (non-interactive, good for logging)
mtr --report example.com

The protocol choice matters when firewalls are involved. If traceroute (UDP) shows asterisks that traceroute -I (ICMP) does not, a firewall is blocking UDP probes specifically. If TCP traceroute on port 443 succeeds but ICMP fails, HTTPS traffic is routed differently to port-specific traffic.

Traceroute vs Ping: When to Use Each

These tools are complementary, not interchangeable. Knowing which to reach for first saves time during incident diagnosis.

Use ping when:

• You need to confirm basic reachability to a destination
• You want to measure consistent round-trip latency over time
• You're checking whether a specific host is up or down
• You want a simple packet loss percentage

Use traceroute when:

• Ping fails and you need to find where in the path the problem is
• Latency is higher than expected and you need to identify which segment is responsible
• You suspect a routing change has occurred (new path, new carrier)
• You're escalating to an ISP and need to show them exactly which hop is the problem

Use MTR (combined) when:

• You need sustained monitoring of a path over time — not just a snapshot
• You want per-hop packet loss statistics alongside latency
• You're documenting an intermittent problem for an ISP or carrier escalation

For path-level context on any IP address or hop you identify, use our ASN Lookup to see which autonomous system and carrier owns that address — essential information when escalating to an upstream provider.

See also our Ping Test Explained guide for a deep dive into interpreting ping output, and our Understanding ASN Routing guide for the broader context of how traffic is routed between networks.

Frequently Asked Questions

Next Steps

If your traceroute confirms a path problem but you need to identify which carrier or network owns the failing hop, run an ASN Lookup on the IP address at the last responsive hop — this identifies the autonomous system and gives you the right contact for escalation.

For sustained path monitoring rather than a one-time snapshot, use MTR (mtr example.com) which combines traceroute and ping into a continuously updating per-hop report — ideal for documenting intermittent issues.

Read our Ping Test Explained guide for the complementary perspective on packet-level diagnostics, and browse all network guides on DNSnexus for related tools and techniques.

Related Guides

• Ping Test Explained: What Latency, TTL, and Packet Loss Actually Tell You
• Understanding ASN Routing: How Traffic Moves Between Networks