Network support: Traceroute overview

Traceroute is used by networking professionals to discover the path network traffic takes. The key to understanding traceroute is knowing the IP (Internet Protocol), specifically the TTL (Time to Live), source IP address, and destination IP address fields in the IP header and how they interact. The default behavior is to route traffic based on the destination IP address; this is analogous to writing your friend’s address on an envelope to send a letter to them. Typically, when you send a letter in the mail you also write down your address, analogous to a source IP address; this way your friend knows where to send their response letter. This also allows the postal service to send the letter back to you if something goes wrong along the way. To show an example of this, if you forgot to put a stamp on the letter the postal service would send the letter back to your (source) address.

The TTL field is needed to prevent the packet from traversing the network forever via a routing loop. The TTL field is eight bits which allows for a maximum value of 255 = (28-1). Any time a packet traverses a L3 device (router, L3 switch, etc.) the TTL is decremented by one before being sent to the next device. If a host sends a packet with a TTL of 255 at most the packet will transit 255 L3 devices. Once the TTL reaches 0 the packet is discarded at the device that notices the TTL reached 0. Traceroute takes advantage of this knowledge by sending out probes with the first set of probes starting with TTL 1 and each set of subsequent probes incrementing the TTL by 1. The first set of probes uses TTL 1, the second set uses TTL 2, the third set uses TTL 3 and so on until the last set of probes reach the destination.

As we’ll see throughout this document traceroute’ s main use is to discover the forward path that traffic takes, that is the path from the host originating the traceroute command to the destination specified in the traceroute command itself. Oftentimes tools like traceroute, PingPlotter, MTR are used not only to show the forward path but also to measure latency and loss to each hop. Trying to use these tools for anything other than path discovery will lead to a red herring in many cases, some of these reasons are discussed here, while some others are discussed in more detail later in this document. One of the reasons these tools create red herrings is CoPP (Control Plane Policing). Network admins will protect their network devices from being attacked with too much of a certain type of traffic (ICMP for example); this is done by policing ICMP traffic sent directly to the device, which is exactly what these tools do. These tools by themselves aren’t likely to exceed the policer rate of a CoPP but combined with ICMP traffic from other hosts and this greatly increases that likelihood. If the CoPP drops ICMP (traceroute) traffic this will give false reports of packet loss in a traceroute indicated by an asterisk (*). Another reason these tools create a red herring is QoS. Network Admins will ensure that more important traffic (routing protocol updates for example) are prioritized over less important traffic such as ICMP. It wouldn’t make sense to allow ICMP to utilize resources when these resources for BGP messages are needed to keep the network working and up-to-date. Due to this ICMP messages generally will be de-prioritized over other important protocol traffic, this can create loss and delay which will be falsely reported in a traceroute. Besides CoPP and QoS let’s look at what else can occur and explain a bit more about what a traceroute is showing us.