Once of EIGRP’s claims to fame is its fast convergence in the event of a link failure. However, one thing that might slow down this convergence is timer configuration. That's the focus of this blog post, which is the third in a series of posts on Understanding EIGRP. If you missed the first couple of posts, you can get them here:
Let's beging our discussion of EIGRP timers by considering a situation where two EIGRP neighbors are directly connected to one another. If the physical link between them fails, each router’s connected interface goes down, and EIGRP can fail over to a backup path (that is, a feasible successor route). Such a situation is shown in the following figure:
Routers R1 and R2, shown in the above figure, are directly attached to one another. Therefore, if the cable between them physically breaks, each of the router interfaces connecting to that link go down, and EIGRP realizes that it just lost a neighbor and starts to reconverge. However, a communications breakdown between a couple of EIGRP neighbors isn’t always as evident. For example, consider a variation of the previous topology, as show below:
Notice a switch (named SW4) has been inserted between routers R1 and R2 in the figure above. If a link failure occurs between switch SW4 and router R1, router R2 is not immediately aware of this, because it’s Gig 0/1 is still in the up/up state. As a result, router R2 might continue to believe router R1 is the best path to get to a network such as 192.0.2.0 /24. Fortunately, EIGRP uses timers to help EIGRP-speaking routers determine when they’ve lost connectivity with a neighbor over a particular interface.
The timers used by EIGRP are the Hello and Hold timers. Let’s take a moment to define their operation, because the Hold timer doesn’t behave in an intuitive manner. First, consider the Hello timer. As you might guess, this determines how frequently a router interface sends Hello messages to its neighbor. However, an interface’s Hold timer is not how long that interface waits to receive a Hello message from its neighbor before considering that neighbor unavailable. Instead, the Hold timer is a value that we send to a neighboring router, telling that neighboring router how long to wait for us, before considering us unavailable. This concept is illustrated in the figure below, where router R2 is configured with a Hello timer of 5 seconds and a Hold timer of 15 seconds.
Two big takeaways from this figure are:
Since the Hold timer we send is actually an instruction telling a neighboring router how long to wait for us and not how long we wait for the neighbor’s Hellos to arrive, each neighbor could have a different set of timers. However, having matching timers between neighbors is considered as best practice for EIGRP (and is a requirement for OSPF).
To illustrate the configuration and verification of EIGPR timers, imagine we wanted router R1 to have a Hello time of 1 second and a Hold time of 3 seconds on its Gig 0/1 interface (connecting to R2). Then, we wanted router R2 to have a Hello time of 5 seconds and a Hold time of 15 seconds on its Gig 0/1 interface (connecting to router R1). Such a configuration reinforces the point that EIGRP neighbors do not require matching timers (although it’s a best practice to have matching timers). The following example shows this timer configuration for routers R1 and R2.
The ip hello-interval eigrp asn hello_interval command is issued on each router to set the Hello timers. The asn parameter specifies the configured EIGRP autonomous system of 1, and the Hello time for router R1 is configured to be 1 second, while the Hello time for router R2 is configured to be 5 seconds. Similarly, the ip hold-time eigrp asn hold_time command is issued on each router to set the Hold timers. Again, both commands specify an autonomous system of 1. Router R1’s Hold time is configured to be 3 seconds, while router R2’s Hold time is configured to be 15 seconds. In both instances, the EIGRP Hold timer was configured to be three times the Hello timer. While this approach is a common practice, it’s not a requirement. Also, you should be cautious not to set the Hold timer on a router to a value less than the Hello timer. Such a misconfiguration could cause neighborships to continually drop and be reestablished. Interestingly, Cisco IOS does accept such a misconfiguration without giving you an error or a warning.
EIGRP uses a default Hello timer of 5 seconds and a default Hold timer of 15 on LAN interfaces. However, in some situations on interfaces configured for Frame Relay, the default timers will be greater.
Next, let’s see how we can verify EIGRP timer settings. The show ip eigrp neighbors command, as seen in the example below, shows the remaining Hold time for each EIGRP neighbor.
Notice in above example that the value under the Hold column is 2 seconds for router R1 (that is, 10.1.1.1) and 13 seconds for router R3 (that is 10.1.1.10). These numbers are not telling us the configured Hold timers. Rather, they’re telling us how much time remains before router R2 considers these neighborships down, in the absence of a Hello message from these neighbors. Router R2 restarts its Hold timer countdown for router R3 to 15 seconds (router R3’s Hold time) every time it receives a Hello message from R3 (which R3 sends every 5 seconds based on its Hello timer). Therefore, if you repeatedly issue the show ip eigrp neighbors command on router R2, you’re likely to see the remaining Hold time for router R3 somewhere in the range of 10 - 14 seconds. However, since router R1 is configured with a Hold timer of 3 seconds and a Hello timer of 1 second, the remaining Hold time seen on router R2 for its neighborship with router R1 should usually be 2 seconds.
We can see the configured Hello and Hold timer values for a router interface by issuing the show ip eigrp interfaces detail interface_id command, as shown in the example below. You can see from the output that interface Gig 0/1 on router R2 has a Hello timer of 5 seconds and a Hold timer of 15 seconds.
By the way, you can watch me teach EIGRP as part of the curriculum in the following video courses:
Click HERE to learn more about the CCNA R/S 200-125 Complete Video Course.
Click HERE to learn more about the ROUTE 300-101 Complete Video Course.
Well, that's it for this installment of Understanding EIGRP. In the next post of this series, we'll dig into EIGRP Passive Interfaces.
See you then!
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945