Worldwide Locations
“Traceroute” is a utility that’s commonly used when troubleshooting IP networks, but many network managers at the CCNA level and beyond aren’t really sure how it works or what you can do with it. One reason for this might be that, unlike most things in the IP world, there are no standards documents describing how “Traceroute” functions. Thus the implementations are vendor-specific, and not even the utilities’ names are standardized. With Cisco IOS and Unix it’s called “traceroute”, in the Microsoft world, it’s “tracert”, and other operating systems have similar utilities, such as “tracepath” for Linux.
There is RFC 1393 Traceroute Using an IP Option, but as far as I know no vendor implements this, so we’ll talk about how “trace” programs work in the real world. Now suppose that we have two host computers in an IP internetwork that also contains several routers, as shown in Figure 1:
Let’s pretend that we don’t know the topology, and we’d like to determine it. Specifically, we’re interested in the path taken by a packet going from Host 1 (H1, with IP address 1.1.1.2), to Host 2 (H2, with IP address 4.4.4.4). We’ll use a “trace” program on H1 to determine this. When we do, what appears on H1’s screen looks something like this:
H1#trace ip 4.4.4.4 probe 1
Type escape sequence to abort.
Tracing the route to 4.4.4.4
At this point we invoked the trace program from H1, tracing towards the destination IP address 4.4.4.4 (H2) and told it to send one “probe” packet for each hop. The probe is a unicast IP packet in which H1 has set the IP source address to its own, the IP destination address to H2, and the IP TTL field to a value of one (an artificially low number that wouldn’t be used for normal data). H1 will then encapsulate the probe packet in a frame and send the frame to R1, its default gateway. When H1 sends the probe packet, it also starts a timer.
When the packet arrives at R1 several things occur, and RFC 1812 Requirements for IP Routers describes what those things are. Here’s a quote from section 5.3.1 of that RFC:
The Time-to-Live (TTL) field of the IP header is defined to be a timer limiting the lifetime of a datagram. It is an 8-bit field, and the units are seconds. Each router (or other module) that handles a packet MUST decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, the TTL is effectively a hop count limit on how far a datagram can propagate through the Internet.
You might remember that in the IP world a “datagram” is the same thing as a “packet”. So, according to the RFC, when a router forwards a packet, it must decrement the TTL. By “elapsed time” we mean the amount of time that the packet spent sitting in the router between its arrival and being forwarded towards the destination. Okay, let’s continue on with section 5.3.1 of the RFC:
When a router forwards a packet, it MUST reduce the TTL by at least one. If it holds a packet for more than one second, it MAY decrement the TTL by one for each second.
Sounds reasonable … the TTL (Time To Live) was originally envisioned as a seconds counter (not a hop counter), so if the packet stays in the router for more than a second, decrement the TTL by the number of seconds that the packet sits in the router, and if it stays for a second or less, decrement the TTL by one. Since modern routers generally process packets pretty quickly (think about the per-packet latency of a router that’s forwarding a million or more packets per second), we’ll assume that the TTL is generally decremented by one for each router hop. And now, back to section 5.3.1:
If the TTL is reduced to zero (or less), the packet MUST be discarded, and if the destination is not a multicast address the router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded in Transit) message (sic) to the source.
Okay, so if a router decrements a packet’s TTL to zero or less, it must discard the packet. By default it also sends a packet containing an ICMP “TTL Exceeded” message (TEM) back to the original packet’s source.
In closing, let us quote from the RFC one last time:
The IP TTL is used, somewhat schizophrenically, as both a hop count limit and a time limit.
Next time we’ll investigate how this RFC impacts the behavior of “trace” programs.