The Traceroute That Gaslit Me for 4 Hours

Traceroute is one of those commands that every network engineer learns on day one.
It feels simple: packets leave your device, hit a series of routers, and eventually arrive at the destination.
So why did a single traceroute leave me staring at * * * for four hours, questioning my entire understanding of routing?

This article is both a therapy session and a technical guide: we’ll explore why traceroute sometimes “lies,” how to properly interpret it, and the modern ways to verify paths without losing your sanity.

A Quick Refresher: How Traceroute Works

Traceroute uses a simple trick:

• It sends packets with an increasing Time to Live (TTL).
• Each router along the path decrements the TTL by 1.
• When TTL hits 0, the router sends back an ICMP Time Exceeded message.

This lets you see each “hop” between your device and the destination.

Key Point: Traceroute isn’t actually testing application reachability. It’s testing how routers respond to TTL expirations. That’s why it can be both insightful and misleading.

The Case of the Vanishing Hops

Here’s the traceroute that broke me:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max
 1  192.168.1.1 (192.168.1.1)  1.2 ms
 2  * * *
 3  edge.isp.net (203.0.113.5)  12.3 ms
 4  * * *
 5  8.8.8.8 (8.8.8.8)  18.9 ms