TECHNICAL DEEP DIVE · 9 min read · Updated 2026-05-27

Traceroute & Network Routing: How Data Travels the Internet

From your machine, through your ISP, across the internet backbone, into a data center — one hop at a time.

By the Check.Systems team

The question traceroute answers

When you load a web page, your packets don't teleport. They hop from router to router across networks owned by different companies, sometimes crossing oceans, before arriving at the destination server. traceroute answers one simple-sounding question: what path did my packet actually take, and how long did each step take?

That seemingly small piece of information is the basis of almost every network-troubleshooting decision. Is the problem your Wi-Fi, your ISP, the backbone, or the destination? A single trace usually tells you within seconds.

How traceroute works under the hood

Traceroute is a clever hack on top of a normal IP feature called TTL — Time To Live. Every IP packet carries a TTL counter in its header. Linux and macOS set the initial TTL to 64; Windows uses 128. Each router that forwards the packet decrements the TTL by one. If the TTL hits zero before the packet reaches its destination, the router that just decremented it to zero drops the packet and sends back an ICMP "Time Exceeded" message — including its own IP address as the source.

TTL was designed to stop packets from looping forever in a misconfigured network. Traceroute weaponises it for discovery. Here's the trick:

Send a packet to the target with TTL=1. The very first router decrements it to 0, drops it, and replies. You now know the IP of hop 1.
Send another packet with TTL=2. The first router decrements to 1 and forwards it. The second router decrements to 0 and replies. You know hop 2.
Keep going — TTL=3, TTL=4, TTL=5 — until the packet finally reaches the destination, which replies differently (an ICMP Echo Reply or a TCP/UDP response) and the trace ends.

Different implementations use different probe packets. Classic Unix traceroute sends UDP packets to high port numbers. Windows tracert uses ICMP Echo Requests. Modern tools like mtr and tcptraceroute can use TCP SYN packets to a specific port — useful when firewalls drop ICMP and UDP but allow TCP on port 443.

Reading a traceroute output

A traceroute output is one line per hop. Each line shows the hop number, the responding router's IP (and reverse-DNS hostname if available), and three round-trip time measurements — most tools send three probes per hop by default.

 1  192.168.1.1 (router.lan)              1.2 ms   1.1 ms   1.3 ms
 2  10.55.12.1 (cgnat-gw.isp.example)     9.4 ms   8.9 ms   9.1 ms
 3  72.14.203.18 (core1-dal.isp.example)  14.6 ms  14.2 ms  14.8 ms
 4  4.69.144.218 (ae-2.r01.dllstx.bb.net) 22.1 ms  21.9 ms  22.3 ms
 5  * * *
 6  104.16.132.5 (cloudflare-edge)        23.4 ms  23.1 ms  23.0 ms

Reading top to bottom: hop 1 is your home router (RFC 1918 address — 192.168.1.1). Hop 2 is your ISP's customer-facing gateway, often a CGNAT box. Hops 3 and 4 are the ISP's regional and national backbone routers — note the hostnames usually encode location codes (dllstx = Dallas, TX). Hop 5 didn't respond. Hop 6 is the CDN edge serving the destination.

Latency should generally climb as you move further from home — but only modestly. Big jumps tell a story: a 5 ms hop followed by a 180 ms hop usually means the packet just crossed an ocean or a satellite link. Latency that drops at a later hop is normal — some routers deprioritise replying to traceroute probes, so their reported time is inflated, not the actual path delay.

Asterisks don't always mean a problem

A * * * line means no reply was received within the timeout. That's often not a real fault — many backbone routers are configured to rate-limit or completely drop ICMP Time Exceeded responses for security and CPU reasons. The packet is still being forwarded normally; the router simply chooses not to reply. The give-away: if the very next hop responds fine, the asterisks were cosmetic. A real path break shows asterisks all the way down from a given hop with no recovery.

BGP, autonomous systems, and how the internet picks paths

No single entity decides how internet traffic flows. Every large network — ISPs, cloud providers, universities, big content companies — runs its own Autonomous System (AS), identified by a number like AS13335 (Cloudflare), AS15169 (Google), or AS7922 (Comcast). There are roughly 75,000 active ASes today.

These ASes talk to each other using the Border Gateway Protocol (BGP). The conversation is conceptually simple: each AS announces to its neighbours "I can reach the following IP prefixes, and here is the path of ASes the traffic will travel through to get there." That path is called the AS_PATH. When your ISP receives multiple announcements for the same prefix from different neighbours, it picks the one it considers best — usually preferring shorter AS_PATHs, cheaper links, or paths from specific preferred peers.

The upshot: the path your packet takes is the cumulative result of independent business decisions made by every network it crosses. There's no central map. Each router knows only "for this destination, hand the packet to this next neighbour" — and trusts the rest of the system to figure it out from there.

To map an IP back to its AS, you can use a WHOIS lookup or the Team Cymru ASN service: whois -h whois.cymru.com " -v 1.1.1.1". The easier path is to use the WHOIS tool or the IP lookup tool on this site — both surface the owning ASN and organisation in the result.

Your ISP, peering, and transit

ISPs connect to the rest of the internet in two ways. Transit is when one network pays another to carry its traffic anywhere on the internet — your small regional ISP probably buys transit from a larger backbone provider. Peering is when two networks of similar size agree to exchange traffic between their customers directly, usually for free (settlement-free peering), at a shared physical location called an Internet Exchange (IX).

This explains a common puzzle. You ping a server that's "geographically close" but the latency is awful. The reason: your ISP and the destination's ISP have no direct peering relationship. Your packets are taking a detour through a transit provider — possibly out of your city, into a different metro, and back — because that's the only commercial path that exists. The internet is a logical topology, not a geographic one.

CDNs and anycast

Content delivery networks like Cloudflare, Fastly, and Akamai use a trick called anycast. The same IP address — say 1.1.1.1 — is announced via BGP from hundreds of physical locations around the world simultaneously. Each network's routers automatically pick the topologically nearest announcement. The result: when you query 1.1.1.1, you reach the Cloudflare server in your city, while someone in Tokyo reaches a completely different physical box on the exact same IP.

Anycast is why your traceroute to a CDN-hosted site is usually short — five or six hops total. You're not crossing the internet to a single origin; you're popping into the CDN's nearest edge, and the CDN handles the long-haul portion privately on its own backbone.

Common traceroute puzzles

Asymmetric routing — the path from you to the server is often different from the path back. Each direction is chosen independently by BGP. Traceroute only shows the forward path; high latency reported on a hop may actually be caused by a slow return path you can't see from one end.
MPLS tunnels — some carriers use MPLS to label-switch traffic across their backbone. Routers inside the tunnel may or may not decrement TTL, so a multi-hop backbone segment can appear as a single hop, or as several hops all reporting suspiciously similar latency.
Hop suppression — firewalls and security middleboxes commonly drop ICMP Time Exceeded entirely. You'll see a run of asterisks, then the trace resumes. The traffic is fine; the trace just can't see those hops.
Last-hop blackhole — many servers don't respond to ICMP at all. The trace shows asterisks at the final hop indefinitely even though HTTP works fine. Use tcptraceroute or mtr --tcp --port 443 to trace using TCP SYN instead.

Using traceroute for real troubleshooting

When something feels wrong with a connection, traceroute is the second tool to reach for (after a quick ping). What to look for:

Where does latency jump? If hop 2 (your ISP gateway) is already 80 ms, the problem is your local link or Wi-Fi. If everything's fine until hop 6 and then it spikes, the issue is upstream and not yours to fix.
Does the path leave your country? If you're streaming from a "local" service but traceroute shows hops in another continent, the destination isn't actually local — geo-IP databases mislabel a lot of CDN edges.
Does the trace die at a particular hop and stay dead? That hop or the link just past it is broken. Note the ASN by looking up the last responding IP — that tells you whose network the problem is on.
Run several traces over time. One bad trace proves nothing; intermittent loss at hop 4 across 20 traces over an hour is a real problem worth reporting to your ISP with evidence.

For a broader workflow combining ping, traceroute, DNS, and packet capture, see the network diagnostics guide.

Try it: trace a host now

Run a live traceroute from this server to any public hostname or IP. You'll get back the full hop list and per-hop latency in a few seconds.

→ Open the traceroute tool

Pair it with the IP lookup tool on interesting hops to see which AS owns each router along the path. Following the AS_PATH from your ISP, to a transit provider, to the destination's network is the clearest way to build intuition for how the internet actually fits together.