Traceroute is a basic network investigation tool that every IT professional has used for simple network troubleshooting. It tracks the path of an IP network packet from source to destination by sending packets marked with a TTL value (or hop count) that increments for each transmission. It can give you a rough idea of the route from the user to the application. Used alone, though, it suffers from severe constraints in measuring modern networks.
Traceroute can be run with a protocol flag that dictates what is used to send probes—either UDP (by default), ICMP or TCP. In modern networking, it’s typical to run into obstacles like load balancing, protocol-based routing, multi-path networks and protocol blocking. Whether the perpetrator is the ISP, your SaaS vendor or your cloud platform, each can produce results that can be misinterpreted by traceroute.
In multi-path networks, there are often several routes that could be taken. Traffic is balanced across them, commonly using a high-order port randomly assigned to the flow to distribute the traffic. But traceroute is not a continuous test; rather, it’s a series of discrete tests. and it is likely that the hops returned in a multi-path network are not actually representative of the hops used by your application. This is not a reason to discard the traceroute, but it does require you understand it properly.
Why People Still Use Traceroute
Traceroute is by no means useless. Knowing the network source to destination route is clearly one of the first steps needed to identify the scope of a problem. If the source of the problem is obvious—like a device is down or severely degraded where that device is a single point of failure—traceroute will identify that. However, infrastructure today has so many inputs (e.g., remote employees and offices) and so many new targets like SaaS apps that it is impossible to manually run enough traceroutes to cover the shifting landscape. One tactic is to automate the execution of traceroutes via multiple protocols from every set of inputs and outputs. This results in an incredibly deep data set that can be referenced when an issue arises, via help desk ticket or word of mouth. IT needs big analytics to sort through the haystack.
Traceroute has no performance measurement value. One metric that a traceroute will deliver is the round-trip time (RTT) to that hop. Too often, those in IT read too much into high RTT values, because devices—especially Cisco devices—prioritize traffic, and ICMP traffic targeted at a device is the absolute lowest priority, resulting in an artificially high RTT number. When you see results like 40ms to the target but 200ms to a hop in the middle of the route, you should know that the RTT is much faster than 200ms to that hop. The remaining time is the device processing time for your ICMP response to come up to the top of the queue. So with proper understanding this information is valuable.
Doing a quick traceroute check may come in handy now and then for basic troubleshooting. But modern applications are largely web- and SaaS-based, which means they depend on a dynamic, asynchronous internet. Routing has become more important and more active over time. Knowing where traffic is going allows you to identify who is responsible when performance drops. The methodology of traceroute is to identify (through TTL manipulation) the hops involved in traversing a connection. AppNeta uses traceroute in the route determination stage of our monitoring by running it with TCP, UDP and ICMP. But to make that data actionable, we utilize packet train dispersion to measure key network performance metrics at every hop along the way (latency, jitter, round-trip time [RTT], etc.), while inferring others (total and used capacity) for the connection as a whole.
The combination of traceroute as a route determination method and packet train dispersion as an actual data gathering mechanism gets us closer to true analytics instead of simply raw data. That’s because metrics like detailed hop-by-hop latency and end-to-end connection capacity can be monitored more effectively than route changes. Add analytics on top of that to identify the top network issues, and you’ve got AppNeta.