How to read a traceroute output

Traceroute is the diagnostic tool every network engineer reaches for first when something is slow or broken. Run it and you get a wall of IP addresses and numbers that looks like nothing. But the output is dense rather than confusing — each column has an exact meaning, and once you've read a few traces you start seeing the internet as a physical thing: cables, routers, continents.

This post walks through that output line by line. By the end you'll know what every column says, what the asterisks mean, and what patterns are worth paying attention to.

What traceroute actually does

When you send a packet across the internet, it passes through a series of routers between your computer and the destination. Each router is a "hop". Traceroute is a trick that gets each hop to identify itself, one at a time.

The trick relies on a field in every IP packet called the TTL — Time To Live. It starts at some number and each router decrements it by one as it forwards the packet. When a router receives a packet with TTL=1 and has to decrement it to zero, it drops the packet and sends back an ICMP "Time Exceeded" message to the original sender — helpfully including its own IP address.

Traceroute exploits this by sending a probe with TTL=1 first. The first router hits zero and replies, revealing itself. Then TTL=2, which reaches the second router. Then TTL=3, and so on, until the probe reaches the actual destination. The result is an ordered list of every router along the path.

The command

On Linux and macOS:

traceroute google.com

On Windows:

tracert google.com

On some Linux distributions, tracepath is available as an alternative that doesn't require root privileges.

One difference worth knowing: macOS and Linux default to UDP probes; Windows uses ICMP echo requests. Some routers block one type but pass the other, so the same path can look different depending on which OS you run the command from. If you're getting a lot of timeouts on Linux, adding -I switches to ICMP mode: traceroute -I google.com.

Reading the output, column by column

A typical trace looks something like this:

traceroute to google.com (142.250.80.46), 30 hops max
 1  192.168.1.1                    1.2 ms   1.0 ms   1.1 ms
 2  10.0.0.1                       8.4 ms   9.1 ms   8.7 ms
 3  *                              *        *
 4  72.14.215.1                   14.2 ms  15.0 ms  14.5 ms
 5  108.170.246.33                16.1 ms  16.3 ms  16.0 ms
 6  lga34s31-in-f14.1e100.net     18.3 ms  18.1 ms  18.2 ms

Column 1 — the hop number. Just a counter. Hop 1 is the first router your packets touch; hop 6 is the sixth. Most traces to a nearby destination are 10–15 hops. Transatlantic connections often run 20 or more.

Column 2 — hostname or IP. The address that sent back the "Time Exceeded" reply. If a reverse DNS record exists for the IP, traceroute resolves it and shows the hostname; otherwise you see the raw IP. You can pass -n to skip DNS resolution and show IPs only, which is faster.

Columns 3–5 — round-trip times. Traceroute sends three probe packets to each hop. These three numbers are the round-trip times in milliseconds for each of those probes. Three probes rather than one gives you a quick feel for consistency — if two are 14 ms and one is 140 ms, that single outlier is probably a queue spike rather than a structural problem.

What the asterisks mean

Hop 3 in the example above shows * * *. This means the router at that hop didn't respond within the timeout period. There are a few reasons this happens:

• The router deliberately ignores traceroute probes. This is extremely common inside carrier and corporate networks. Generating ICMP replies for every traceroute probe that passes through has a measurable performance cost on high-speed routers, so many operators simply rate-limit or disable it. The router is still forwarding your traffic — it just won't acknowledge the probe.
• A firewall is filtering the reply. Even if the router would respond, a firewall downstream or at the router itself may block outbound ICMP.
• The probe was genuinely lost. Less common, but happens on congested or lossy links.

The key thing: * * * at an intermediate hop almost never means the network is broken there. If the hops after it are responding, traffic is getting through fine. Traceroute keeps incrementing TTL and sending probes past any silent hop — the silent ones just don't report back.

Where asterisks become meaningful is when they appear at every remaining hop from some point onward. That suggests you've hit a point where traffic is being dropped — either the destination is unreachable, or a firewall is blocking all probes beyond that point.

The first few hops

Hop 1 in virtually every home traceroute is your local router — the device that NATs your private network to your public IP. It will show a private address like 192.168.1.1 or 10.0.0.1. These addresses come from the reserved ranges defined in RFC 1918 and only exist inside your local network.

Hop 2 is usually your ISP's first gateway. Latency jumps here from under 2 ms (local) to somewhere between 5 and 20 ms depending on your connection type and how far you are from the nearest ISP infrastructure.

By hop 3 or 4, you're typically out of your ISP's last-mile network and onto regional backbone infrastructure. The hostnames often become more descriptive here — names like be3006.ccr42.jfk02.atlas.cogentco.com are standard practice for backbone carriers, encoding their own network identity and the router's location into the DNS record.

Patterns worth recognising

The CDN shortcut. If you traceroute to a major website — netflix.com, cloudflare.com, a news site — you'll often see only 4 or 5 hops total, and the final couple belong to a CDN's network. Latency at the destination might be under 10 ms even though the site's servers are geographically "far away". This isn't magic: the CDN has a point of presence close to you, and the content is cached there. The trace isn't going to California or Ireland — it's going to a data centre two cities over.

The transcontinental jump. Look for a hop where latency suddenly increases by 50–80 ms or more. That's almost certainly an undersea cable or a very long terrestrial fibre link doing real geographic work. A jump from 20 ms to 100 ms somewhere in the middle of a trace to a European destination from North America is the transatlantic crossing. Geolocation databases can sometimes tell you where a hop is, but the latency jump itself is the clearest signal.

The apparent backwards hop. Occasionally you'll see a hop with higher latency than the one after it — hop 7 at 45 ms, hop 8 at 32 ms. This looks broken but usually isn't. Traceroute measures round-trip time, and the return path may not be symmetric with the forward path. The reply from hop 7 travelled a longer return route than the reply from hop 8 did. The actual forward latency through both hops was probably fine. Don't blame hop 7.

The slow hop that isn't slow. Some routers de-prioritise generating ICMP replies relative to forwarding regular traffic. A router that shows 200 ms on a traceroute probe may be passing your actual TCP traffic through in 5 ms — it just treated the probe as low priority. The hop's latency in a traceroute reflects how the router handles probe packets, not necessarily how it handles your traffic. Again: use the final destination's round-trip time to measure real end-to-end performance.

What hostnames reveal

When traceroute resolves a hostname for a hop, that hostname is often a goldmine of information. Network operators name their routers systematically, encoding geography, equipment type, and their own identity.

A hop named ae-12-3.bear1.atlanta1.level3.net tells you: this is an aggregated ethernet port (ae-12), on a backbone edge router (bear1), in Atlanta, on Level 3's network. A hop named be3006.ccr42.jfk02.atlas.cogentco.com tells you: a backbone core router (ccr), in JFK (New York), on Cogent's network.

Not every operator is this descriptive — some use purely numeric names, or no reverse DNS at all — but the major carriers are. Read enough traceroutes and you start recognising network identifiers on sight: level3.net, cogentco.com, ntt.net, telia.net. These are Tier 1 backbone networks, and most long-distance internet traffic passes through at least one of them. For a deeper look at how these networks relate to each other, the ASN explainer covers the Tier 1/2/3 structure.

For any hop where the hostname doesn't tell you enough, you can paste the IP into the IP lookup tool to see the ASN and organisation name directly.

What traceroute can't tell you

A few limitations to keep in mind before drawing conclusions from a trace.

You only see the forward path. Traceroute shows the route your probes took from your machine to the destination. The return path — how replies travel back to you — may be entirely different, and traceroute has no visibility into it. Asymmetric routing is normal. A trace from New York to London might go via one transatlantic cable; the replies might come back via a different one.

The path can change between runs. BGP routing tables are dynamic. Run traceroute twice to the same destination five minutes apart and you may see different intermediate hops, especially on long intercontinental paths where multiple equal-cost routes exist and load balancing shifts traffic between them.

Loss at an intermediate hop isn't end-to-end loss. If hop 6 shows packet loss but the destination shows none, the loss is in traceroute's probe handling at that router, not in the actual traffic path. End-to-end loss matters; intermediate hop loss is mostly noise unless it correlates with the final hop behaving poorly too.