So, what can go wrong while doing a trace, and what would we see if it did? Sometimes you’ll see an asterisk (*) appear in the display. This happens when the host doing the trace does not receive a reply to a probe packet in a timely fashion (typically two seconds, but you can generally specify the timeout).

Let’s talk about trace utilities and directionality. First, be aware that in general, tracing from H1 to H2 gives you no reliable information whatsoever about what you see if you trace from H2 to H1. In fact, since the router’s per-hop forwarding behavior is controlled by its routing table, even the paths taken by a particular trace probe packet and its corresponding ICMP TTL Exceeded Message (TEM) may not be the same (but this shouldn’t have an adverse impact on the hop-by-hop results of the trace).

Most implementations of “trace” will send several probe packets at each TTL, and display the round-trip time for each. For example, Cisco IOS and MS Windows do three probes per hop by default. The display then resembles a table with a row for each hop, and the columns are hop number, the round-trip times, and the router address at that hop. If DNS or host table info is available, the trace program can also supply the hostname of the device at each hop.

When we left off, we were two hops into a trace from H1 to H2. Now H1 sends a probe packet towards H2 with the IP TTL set to three, and starts the timer. When the probe packet arrives at R1, it will decrement the TTL to two and forward the packet towards H2. The probe packet will then reach R2 with a TTL of two. When the probe packet arrives at R2, it will decrement the TTL to one and forward the packet towards R3. The probe packet will then reach R3 with a TTL of one.

When the probe packet arrives at R1, per RFC 1812 (section 5.3.1), that router will decrement the packet’s IP TTL. Since the TTL in the probe packet was one, after being decremented the TTL will be zero, and R1 will discard the probe packet. The RFC also specifies that the router should send a packet containing an ICMP “TTL Exceeded” message (TEM) back to the originating host. This is a key part of the operation of the trace utility, so let’s take a closer look at this. When R1 sends the TEM packet back to H1, it sets the destination address of the TEM packet to H1’s IP address (the source address of the probe packet), but to what does it set the TEM packet’s source address?

“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.

As we previously discussed, the Internet Control Message Protocol (ICMP), which is documented in RFC 792, is a required protocol that is tightly integrated with IP. ICMP messages, delivered in IP packets, are used for out-of-band messages related to network operation. ICMP is sometimes called an umbrella protocol, because it contains many sub-protocols, and provides […]