Traceroute is an IP utility that is used to list all the routers (or “routing hops”) that are between the source host that issues the command and the destination host that is passed as argument. For each router, the command returns its IP address, Fully Qualified Domain Name (FQDN) if available, and Round-Trip Time (RTT) to it. Advanced option could also include the Autonomous Systems traversed and Maximum Transmission Unit (MTU). Traceroute is one of the most important utilities that network engineers use every day to identify and troubleshoot network issues.
The most beneficial use of this command is that it can help to identify routing issues that could impact end-users and applications. Traceroute also has some limitations that should be pointed out to its users. This utility is available on most modern operating systems, such as Unix, Linux, Windows, and Mac OS X. Some operating systems may also name the executable as tracepath (e.g. Linux) and or tracert (e.g. Windows).
Time To Live (TTL)
Routing hops are discovered by exploiting the ICMP Time Exceeded message. IP packets have a field called Time To Live (TTL) that is used to limit their lifespan in a communications network. All routers inspect this field to avoid packets being routed indefinitely, such as in the case of routing loops or where the destination is not available or known. The TTL’s maximum value is 255, and typically, this field is set to 64. When an IP packet traverses a router, its value is decremented by one. When a router receives a packet with TTL equal to 1, it discards the packet and sends an ICMP error message Time Exceeded (Code 11) to the source.
Example of a Time Exceeded packet notification as captured with tcpdump:
IP my.meraki.net > 10.1.36.5: ICMP time exceeded in-transit, length 60
How Traceroute Works
Traceroute works by using the Time Exceeded mechanism to identify routers at each hop. For simplicity, we’ll call the packets sent by traceroute “probes”. By default, the utility sends three probes for each hop. As a result, probes could discover more than one path, in case of multipath routing, or return three RTT measurements for a specific hop.
At each iteration, traceroute sends three probes with an increased TTL value, starting from TTL equal to one. To discover the first hop, the TTL is set to one. For the second hop, the TTL is set to two, and so on. The command terminates when it either reaches the destination host, or it reaches the maximum number of hops set. By default, the maximum number of hops is set to 30. This value can be changed via the command line. Please consult your documentation for the appropriate flag.
Hop by hop, the command builds the list of routing hops to destination, assuming everything goes well (as I will explain further in the next section). Here’s the example of a traceroute to www.google.com with default options:
$ traceroute www.google.com
traceroute to www.google.com (220.127.116.11), 64 hops max, 52 byte packets
1 my.meraki.net (10.1.36.1) 10.140 ms 2.565 ms 3.272 ms
2 18.104.22.168 (22.214.171.124) 5.580 ms 4.006 ms 3.104 ms
3 126.96.36.199 (188.8.131.52) 4.069 ms 2.501 ms 5.308 ms
4 * * *
5 * * *
6 google-level3-60g.washingtondc.level3.net (184.108.40.206) 85.500 ms 9.336 ms 8.873 ms
7 220.127.116.11 (18.104.22.168) 10.156 ms 10.853 ms 13.887 ms
8 22.214.171.124 (126.96.36.199) 8.865 ms 9.400 ms 9.387 ms
9 iad30s08-in-f132.1e100.net (188.8.131.52) 9.145 ms 9.527 ms 12.434 ms
By default, probes are sent using ICMP on Windows and UDP on Linux and Mac OS X. Both operating systems also have the option to change the transport protocols, such as TCP and GRE (on Mac OS X).
Traceroute has known limits that, in some cases, impact its ability to draw an accurate picture of the network. Here’s a list of known limitations that a network engineer should be aware of:
- Firewalls between a source and the destination host may block the probe packets, causing traceroute to reach the maximum hops without returning any result; when no response is received from a router, it will display an asterisk instead of a router’s IP address or FQDN (see hops 4 and 5 in the example I reported in the previous paragraph). In such cases, it’s recommended to test different transport protocols, and perhaps change ports. Some firewalls may block all traffic, so there’s very little that you can do in this case.
- Routers that implement load balancing based on the packet’s header could use more than one path to route traffic towards a destination. In this case, traceroute may return an inaccurate path between source and destination. I will report a solution to this problem in the next paragraph.
There are two valid open source traceroute alternatives and they are:
- MTR – https://github.com/traviscross/mtr – MTR also reports the packet loss at each hop; the utility works by sending continuous packets against each hop to determine packet loss and identify performance issues caused by that.
- Paris-Traceroute – https://paris-traceroute.net/ – This alternative overcomes the load balancing limit of traceroute by revealing the real underlying network topology. This utility works by manipulating the header information of the probe packets in order to identify the multiple paths available.
Both commands are ‘open source’ so can be easily installed and run on a Linux host.
NetBeez and Traceroute
Currently, NetBeez agents are capable of running traceroute tests! They support TCP, UDP, and ICMP protocols to circumvent the firewall limitation I described earlier. The data reported from the traceroute tests include path RTT, IP, FQDN and MTU per hop (when using UDP or ICMP as transport protocol).
Here’s a quick screenshot of a this test in NetBeez:
If you are interested in running MTR or paris-traceroute, you should be able to install those via the command line. Feel free to reach out via chat or support if you are interested in enabling those utilities.
Traceroute is one of the most important utilities network engineers use every day to identify and troubleshoot network issues.