How It's Supposed to Work
Let's start with the basics. Traceroute is a clever diagnostic tool that maps the journey of your data packets. It sends out a probe with a Time-to-Live (TTL) value of 1. The first router it hits decrements the TTL to 0, discards the packet, and sends back
an ICMP "Time Exceeded" message, revealing its identity. Traceroute then sends a new probe with a TTL of 2, which makes it past the first router to the second one, and so on. This process repeats, incrementing the TTL each time to discover every 'hop' along the path until the final destination is reached. In a perfect, simple network, this gives you a clean, line-by-line list of routers between you and the target.
The Great Wall of Firewall
The first and most common mystery is the dreaded line of asterisks: ` *`. This usually means a timeout occurred. The probe sent out didn't get a response. While this could indicate a down router or network congestion, it's frequently caused by a firewall. Many corporate and provider networks configure their firewalls to block or deprioritize the ICMP packets that traceroute relies on for its reports. The router may have successfully forwarded your data packet, but it was configured not to send back the "Time Exceeded" notification. So, a line of asterisks doesn't always mean your packet hit a dead end; often, it just means you've encountered a router that's been told not to talk back.
The Load Balancer Shell Game
Modern networks are built for high availability, which means using load balancers to distribute traffic across multiple paths. This plays havoc with traditional traceroute. Classic traceroute often changes a detail (like the UDP port number) in each probe it sends. A load balancer sees these probes as parts of different 'flows' and might send them down entirely different routes. The result is a traceroute output that seems to zigzag illogically between different devices. You aren't seeing one consistent path; you're seeing a jumbled composite of several different paths stitched together, which can be highly misleading. Some load balancers don't decrement TTL at all, making them completely invisible to traceroute.
Into the MPLS Void
Large internet service providers and enterprises often use a technology called Multi-Protocol Label Switching (MPLS) to manage their traffic. Inside an MPLS network, the routers (Label-Switched Routers or LSRs) don't make decisions based on the final destination IP address. Instead, they just look at a special MPLS label attached to the packet. This means the core routers within the MPLS cloud often have no idea how to route a packet back to your source IP. When a TTL expires inside this cloud, the ICMP error message has to travel all the way to the end of the MPLS path before it can be routed back to you. This can make it look like one hop has an impossibly high latency or that several intermediate hops are missing entirely.
The Problem of Two Paths
A very common but often misunderstood phenomenon is asymmetric routing. This is when the path your packet takes to a destination is different from the path the reply takes to get back to you. This is normal in most modern networks due to complex routing policies, multiple internet providers, and load balancing. However, it can make traceroute results confusing. The round-trip times (RTT) you see are for a packet going out one way and coming back another. A high latency on a specific hop might not be due to that outbound router at all, but rather an issue on the completely separate return path. Without running a trace in the reverse direction, it's nearly impossible to diagnose this from a single traceroute command.
