It’s a reflex for any network engineer: when connectivity gets weird, you type `traceroute`. For decades, it's been the go-to tool for mapping a packet's journey. But its simple output hides a world of complexity that regularly fools even the pros.
The Myth of the Straight Line
The
first and most common mistake is assuming the path traceroute shows you is the same one traffic takes on its way back. This is often false. The internet is built for resilience, not symmetry, and 'asymmetric routing' is the norm. This means packets going from Server A to Server B may follow a completely different set of routers than packets returning from B to A. Since traceroute only shows the forward path, you're only seeing half the picture. A problem that seems to be on the path to a destination could actually be on the entirely separate, invisible return path. To get a fuller picture, you'd need to run a second traceroute from the destination back to the source and compare the results.
That Latency Spike Might Be a Lie
You run a trace and see a huge latency jump at hop 5, from 20ms to 150ms. Your instinct is to blame the router at hop 5. But then, every hop after it is also around 150ms. This doesn't mean hop 5 is the problem; it likely means the latency was introduced before that hop. A more confusing scenario is when hop 5 shows 150ms, but hop 6 drops back down to 30ms. This is almost never a real network problem. Routers are designed to forward traffic at high speed; generating ICMP 'Time Exceeded' messages for a traceroute is a low-priority task for their control plane. That 150ms spike is likely just the router telling you, 'I'm too busy forwarding actual data to answer your diagnostic packet quickly'. If subsequent hops are fine, the spike can usually be ignored.
The Black Hole of Asterisks
A line of three asterisks (` *`) looks alarming. When a whole trace ends in them, it often means the destination is unreachable. But when they appear at an intermediate hop, followed by successful hops, it typically means nothing is wrong. This usually just signifies that a router or firewall is configured not to send back ICMP error messages, often for security reasons. Many corporate and cloud networks intentionally block or rate-limit these packets to prevent their infrastructure from being mapped or used in denial-of-service attacks. A few asterisks in the middle of a trace is just a router refusing to talk to you, not a sign that your actual traffic is being dropped.
Not All Traceroutes Are Created Equal
Another subtle trap is that the `traceroute` command on Linux and macOS works differently than `tracert` on Windows by default. Windows uses ICMP packets (the same kind 'ping' uses), while Unix-like systems typically use UDP packets sent to high-numbered ports. This matters because firewalls often apply different rules to different protocols. A firewall might block the UDP packets used by a Linux traceroute, resulting in timeouts, while allowing the ICMP packets from a Windows machine to the same destination. This can lead two engineers to get conflicting results and waste time arguing about whose trace is 'correct'. More advanced traceroute versions can use TCP packets, often to port 443 (for HTTPS), which are even more likely to get through since blocking them would break most web browsing.
Load Balancers and Other Modern Illusions
Modern networks are full of technologies that can make a traceroute's output deceptive. For example, some networks use Equal-Cost Multi-Path (ECMP) routing, where multiple paths exist to the same destination. A load balancer might send each of your traceroute probes down a different path, stitching together a 'Frankenstein' route in the output that no single packet ever actually travels. Similarly, MPLS networks, common in ISP backbones, can 'hide' hops from a traceroute. The trace might appear to jump directly from one city to another with a large latency increase, obscuring the actual path through the provider's core. This is why context is everything; traceroute isn't showing an absolute truth, but rather clues that need expert interpretation.
