At this point, we know that DUAL finds the successor(s) for each destination and attempts to find feasible[DU1] successors as well. As with successors, a router can have more than one feasible successor for a particular destination. Refer to Figure 1 for an example:

In addition to calculating the successor (best next hop), DUAL will also attempt to find one or more “feasible successors” (loop-free backup next hops) for each destination.

Welcome back! Continuing on with our discussion of EIGRP, let’s delve further into the details of what makes this particular Interior Gateway Protocol (IGP) so successful.

Interior Gateway Routing Protocol (IGRP) was a Cisco-proprietary Distance-Vector (D-V) classful routing protocol — basically an improved version of RIPv1. Like other D-V protocols, each IGRP router periodically flooded its routing table, but it differed from RIP in two ways. First, RIP’s advertisement interval was thirty seconds but IGRP’s was ninety seconds, which allowed IGRP to scale to larger networks than RIP. Second, RIP used a simple hop count metric, but IGRP’s more sophisticated metric was based on minimum path bandwidth and total path delay, with options to include link reliability and interface loading.

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.