How to Use Traceroute

Ping tells you whether a destination is reachable. Traceroute tells you how you reach it—every router along the way, how long each hop takes, and exactly where things go wrong when they do.

The Clever Hack Behind Traceroute

Every IP packet carries a Time To Live (TTL) value. Despite the dramatic name, it's just a counter. Each router that handles your packet decrements TTL by one. When TTL hits zero, the router doesn't forward the packet—it destroys it and sends back an error message: "Time Exceeded."

This mechanism exists to prevent packets from circling the Internet forever if routing goes wrong. But traceroute turns this self-defense mechanism into a mapping tool.

Here's the trick:

1. Send a packet with TTL=1. The first router decrements it to zero, destroys it, and sends back "Time Exceeded"—revealing that router's address.
2. Send a packet with TTL=2. It survives the first router but dies at the second, which confesses its location.
3. Keep increasing TTL until packets finally reach the destination.

Packets that would normally die quietly are forced to send back a confession of where they perished. By timing how long each confession takes to arrive, traceroute builds a complete map of latency at every hop.

Running Traceroute

# Linux/macOS
traceroute example.com

# Windows (note the different name)
tracert example.com

# Works with IP addresses too
traceroute 8.8.8.8

Reading the Output

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)  1.234 ms  1.156 ms  1.089 ms
 2  10.20.30.1 (10.20.30.1)  8.445 ms  8.392 ms  8.334 ms
 3  ae-1.core1.nyc.example.net (203.0.113.1)  12.567 ms  12.501 ms  12.445 ms
 4  ae-2.core2.nyc.example.net (203.0.113.2)  13.234 ms  13.178 ms  13.123 ms
 5  * * *
 6  example.com (93.184.216.34)  22.345 ms  22.289 ms  22.234 ms

Each line is one hop. The three numbers are round-trip times for three separate probes—traceroute sends multiple packets to each hop to catch inconsistencies.

The first hop is your local router, usually in the 192.168.x.x or 10.x.x.x range with sub-millisecond latency. The next few hops are your ISP. The middle hops are backbone routers—the cryptic names like "ae-1.core1.nyc" often encode geographic location (nyc = New York City). Final hops belong to the destination's network.

What the Asterisks Mean

Asterisks don't necessarily mean packets are being dropped. They mean that hop didn't respond to the probe.

Many routers are configured to silently ignore traceroute probes while still forwarding your actual traffic. The router in hop 5 above is doing its job—it just won't admit it. The fact that hop 6 responds proves packets are getting through.

Asterisks only indicate a real problem when traceroute never recovers—when every hop after a certain point shows * * * and you never reach the destination.

Finding Where Problems Occur

Latency should increase gradually as packets travel further. Watch for:

Sudden jumps: If hop 5 shows 15ms and hop 6 shows 150ms, the link between them is where delay is introduced. This might be geographic distance (crossing an ocean adds 100-200ms), a congested link, or inefficient routing.

Geographic anomalies: Router names often contain city codes. Traffic from New York to Boston shouldn't route through Los Angeles. If it does, someone's routing is misconfigured.

Network boundaries: When hostname patterns change—say, from "comcast.net" to "level3.net" to "amazon.com"—you're watching packets move between different organizations' networks. Problems at these boundaries are common and usually outside your control.

The failure point: When traceroute stops getting any responses and never reaches the destination, you've found where connectivity breaks down. This is the hop whose operators you'd need to contact.

Platform Differences That Matter

Linux and macOS use UDP packets by default. Windows uses ICMP (like ping). Some routers treat these differently, so results can vary by platform.

To make Linux/macOS behave like Windows:

sudo traceroute -I example.com

The -I flag switches to ICMP, which can help when firewalls block UDP.

Useful Options

# Send more probes per hop (better for spotting inconsistency)
traceroute -q 10 example.com

# Limit maximum hops
traceroute -m 15 example.com

# Increase timeout for slow networks
traceroute -w 5 example.com

What Traceroute Can't Tell You

The return path: Traceroute shows how packets get to the destination. The path back might be completely different. If you're troubleshooting slow downloads, the problem might be on the return path that traceroute doesn't see.

Load-balanced paths: Modern networks spread traffic across multiple parallel routes. Different traceroute probes might take different paths, making results look inconsistent even when everything is working fine.

Application-level issues: Traceroute operates at the network layer. If your web application is slow but traceroute looks fine, the problem is higher up—maybe the server is overloaded, or DNS is slow, or TLS negotiation is taking too long.

Filtered networks: Many networks block traceroute entirely or rate-limit ICMP responses. You'll see asterisks even when connectivity is perfect. This is increasingly common as networks prioritize security over debuggability.

When Traceroute Earns Its Keep

Traceroute shines when ping shows a problem exists but you need to know where. It reveals whether the issue is in your local network, your ISP, the backbone, or the destination's network. This knowledge tells you who to call.

It's also valuable for understanding routing decisions. If your traffic to a nearby server is taking a 3,000-mile detour, traceroute will show you. If your ISP is routing everything through a congested exchange point, you'll see latency spike at a specific hop.

For continuous monitoring rather than one-time diagnosis, consider mtr, which combines ping and traceroute into a real-time display. But for understanding the path packets take and finding where they struggle, traceroute remains the essential tool.