Using traceroute to Trace a Network Path

Going a Step Beyond Ping

While ping only confirms whether a final destination is reachable, traceroute reveals every single router (hop) the traffic passes through along the way - useful for pinpointing exactly where, along a path, a problem is actually occurring.

$ traceroute example.com

1  192.168.1.1       2 ms
2  10.20.30.1        8 ms
3  isp-router.net    15 ms
4  backbone-1.net    22 ms
5  93.184.216.34     30 ms   (destination reached)

The Clever Trick Behind How It Works

traceroute sends a series of packets with a gradually increasing TTL (Time To Live) value - starting at 1. Each router that receives a packet decrements its TTL, and if the TTL hits zero, that router sends back an error message rather than forwarding it further. By deliberately triggering that error one hop at a time, traceroute reveals each router along the path, one at a time.

Reading the Output for Clues

A sudden, large jump in delay between two consecutive hops often points to exactly where a bottleneck exists. A hop that simply times out repeatedly (often shown as asterisks) might indicate a router configured not to respond to this kind of probe at all - not necessarily an actual failure at that specific point.

Why This Matters for Real Troubleshooting

If a ping to a destination fails entirely, traceroute can reveal exactly how far the traffic actually got before failing - showing whether the problem is on your local network, somewhere in your ISP's infrastructure, or much further away, close to the destination itself.

A Caveat Worth Knowing

Just like with ping, some routers along a path may be configured to not respond to traceroute's probes at all, showing up as missing hops in the output - this doesn't necessarily mean that hop is broken, only that it's silent by deliberate configuration.