Every toolbox has a tool that is used on problems even though it's well past retirement age. Perhaps it's an old rusty screwdriver that has a comfortable handle. Or a hammer with a broken claw that has driven hundreds of nails. We all have tools that we fall back on even when better options are available. In the world of building and repairing physical things that means the project will take more time. But in the networking world old tools can cause more problems than they solve.

Traceroute is a venerable protocol used for collecting information about network paths. Van Jacobsen created it in 1987 to help measure paths that packets take in the network and the delays that those paths cause. It uses UDP packets with a Time To Live (TTL) of 1 to force a remote system to send a special ICMP message back to the source. These ICMP messages help the originating system build a table of the hops in the path as well as the latency to that hop.

Traceroute has served the networking world well for a number of years. It has helped many of us diagnose issues in service provider networks and figure out routing loops. It's like the trusty screwdriver or hammer in the bottom of the toolbox that's always there waiting for us to use them to solve a problem. But Traceroute is starting to show its age when it comes to troubleshooting.

  • Traceroute requires ICMP messages to be enabled on the return path to work correctly. The ICMP Time Exceeded message is the way that Traceroute works magic. If a firewall in the path blocks that message from returning, everything on the other side of that device is a black hole as far as Traceroute is concerned. Even though networking professionals have been telling security pros for years to keep ICMP enabled on firewalls, there are still a surprising number of folks that turn it off to stay "safe".
  • Traceroute doesn't work well with multiple paths. Traceroute was written in the day when one path was assumed to exist between two hosts. That works well when you have a single high speed path. But today's systems can take advantage of multiple paths to different devices across carrier networks. The devices in the middle can find the most optimum path for traffic and steer it in that direction. Traceroute is oblivious to path changes.
  • Traceroute can only provide two pieces of information. As long as all you really want to know about a network is a hop-by-hop analysis of a path and the delay on that path, Traceroute is your tool. But if you need to know other information about that path, like charting the latency over time or knowing when the best time to pick a specific multi path through the network would be then Traceroute's utility becomes significantly limited.

In a modern network, we need more information that we can get from a simple tool like Traceroute. We need to collect all kinds of data that we can't get from a thirty year old program written to solve a specific kind of issue. What we need is a better solution built into something that can collect the data we need from multiple points in the network and give us instant analysis about paths and how our packets should be getting from Point A to Point B as quickly as possible.

That would be something, wouldn't it?