EIGRP may be configured to discover neighboring routers dynamically (default) or via manual administrator configuration.  Both methods, as well as other EIGRP neighbor-related topics will be described in the following sections.

Dynamic Neighbor Discovery

Dynamic neighbor discovery is performed by sending EIGRP Hello packets to the destination Multicast group address 224.0.0.10. This is performed as soon as the network command is used when configuring EIGRP on the router. Also, as stated earlier in this guide, EIGRP packets are sent directly over IP using protocol number 88.  Figure 2-2 illustrates the basic EIGRP neighbor discovery and route exchange process:

Fig. 2-2. EIGRP Neighbor Discovery and Route Exchange

Referencing Figure 2-1, upon initialization, the EIGRP neighbors send Hello packets to discover other neighbors. The neighbors then exchange their full routing tables via full Updates. These Updates contain information about all known routes. Because Update packets are sent reliably, they must be explicitly acknowledged by the recipient.

After the neighbors have exchanged their routing information, they continue to exchange Hello packets to maintain the neighbor relationship. Additionally, the EIGRP neighbor routers will send only incremental updates to advise neighbors of status or routing changes. They will no longer send full Updates to neighbor routers.

It is important to understand that simply enabling EIGRP between two or more routers does not guarantee that a neighbor relationship will be established. Instead, there are some parameters that must match for the routers to become neighbors. The EIGRP neighbor relationship may not establish due to any of the following:

• Mismatched EIGRP Authentication Parameters (if configured)
• Mismatched EIGRP K Values
• Mismatched EIGRP Autonomous System (AS) Number
• Using secondary addresses for EIGRP neighbor relationships
• The neighbors are not on a common subnet

While the show ip eigrp neighbors command does not differentiate between dynamically and statically configured neighbors, the show ip eigrp interfaces detail <name> command can be used to verify that the router interface is sending out Multicast packets to discover and maintain neighbor relationships. The output of this command on a router enabled for dynamic neighbor discovery is illustrated below:

NOTE: The show ip eigrp neighbors command is described in detail later in this section. When looking at the output of the show ip eigrp interfaces detail <name> command, keep in mind that because EIGRP uses both Multicast and Unicast packets, the command counters will include values for both types of packets as shown in the output above.

Static Neighbor Discovery

Unlike the dynamic EIGRP neighbor discovery process, static EIGRP neighbor relationships require manual neighbor configuration on the router. When static EIGRP neighbors are configured, the local router uses the Unicast neighbor address to send packets to these routers.

Static neighbor relationships are seldom used in EIGRP networks. The primary reason is that the manual configuration of neighbors does not scale well in large networks. However, it is important to understand why this option is available in Cisco IOS software, and the situations in which this feature can be utilized. A prime example of when static neighbor configuration could be used would be in a situation where EIGRP is being deployed across media that does not natively support Broadcast or Multicast packets, such as Frame Relay.

A second example would be to prevent sending unnecessary EIGRP packets on multi-access networks, such as Ethernet, when only a few EIGRP-enabled routers exist. In addition to basic EIGRP configuration, the neighbor command must be configured on the local router for all static EIGRP neighbors. EIGRP-enabled routers will not establish an adjacency if one router is configured to use Unicast (static) while another uses Multicast (dynamic).

In Cisco IOS software, static EIGRP neighbors are configured using the neighbor <address> <interface> router configuration command. Keep in mind that this is simply in addition to the basic EIGRP configuration. The simple network topology that is illustrated in Figure 2-4 will be used to both demonstrate and verify the configuration of static EIGRP neighbors:

Fig. 2-4. Configuring Static EIGRP Neighbors

Referencing the topology illustrated in Figure 2-2, router R2 is configured as follows:

The configuration implemented on router R3 is as follows:

The show ip eigrp interfaces detail <name> command can be used to determine whether or not the router interface is sending Multicast (dynamic) or Unicast (static) packets for neighbor discovery and maintenance. This is illustrated in the following output:

In addition to this, the show ip eigrp neighbors [detail] command can also be used to determine the type of EIGRP neighbor. This command is described in detail later in this chapter.

EIGRP Hello and Hold Timers

EIGRP uses different Hello and Hold timers for different types of media. Hello timers are used to determine the interval rate EIGRP Hello packets are sent. The Hold timer is used to determine the time that will elapse before a router considers an EIGRP neighbor as down. By default, the Hold time is three (3) times the Hello interval.

EIGRP sends Hello packets every 5 seconds on Broadcast, point-to-point serial, point-to-point subinterfaces, and multipoint circuits greater than T1. The default Hold Time is 15 seconds. EIGRP sends Hello packets every 60 seconds on other link types. These include low-bandwidth WAN links less than T1 speed. The default Hold time for neighbor relationships across these links is also three times the Hello interval and therefore defaults to 180 seconds.

EIGRP timer values do not have to be the same on neighboring routers in order for a neighbor relationship to be established. In addition to this, there is no mandatory requirement that the Hold time be three times the Hello interval. This is only a recommended guideline which can be manually adjusted in Cisco IOS software. The EIGRP Hello time can be adjusted using the ip hello-interval eigrp <ASN> <secs> interface configuration command, while the EIGRP Hold time can be adjusted using the ip hold-time eigrp <ASN> <secs> interface configuration command.

It is important to understand the use of both the Hello timer and Hold timers as they pertain to EIGRP. The Hold time value is advertised in the EIGRP Hello packet. The Hello time value tells the local router how often to send its neighbor(s) Hello packets. The Hold time, on the other hand, tells the neighbor router(s) of the local router how long to wait before declaring the local router ‘dead’. The EIGRP Hello packet and the Hold Time field is illustrated in Figure 2-5:

Fig. 2-5. EIGRP Hold Time in the EIGRP Hello Packet

Referencing Figure 2-5, the EIGRP Hello packet (OPCode 5) contains, amongst other things, the configured Hold time value. The value of 7 illustrated in Figure 2-5 is a non default configured value implemented using the ip hold-time eigrp <ASN> <secs> interface configuration command. It is important to remember that the actual Hello time interval is not included. However, the configured Hello time can be viewed using the show ip eigrp interfaces detail <name> command. The information printed by this command is illustrated below:

The most common reason for adjusting the default EIGRP timer values is to speed up routing protocol convergence. For example, on a low-speed WAN link, a Hold time of 180 seconds might be a long time to wait before EIGRP declares a neighbor router down. Inversely, in some situations, it may be necessary to increase the EIGRP timer values on high speed links in order to ensure a stable routing topology. This is common when implementing a solution for Stuck-In-Active (SIA) routes. SIA will be described in detail later in this chapter.

EIGRP Neighbor Table

The EIGRP Neighbor Table is used by routers running EIGRP to maintain state information about EIGRP neighbors. When newly discovered neighbors are learned, the address and interface of the neighbor is recorded. This is applicable to both dynamically discovered neighbors and statically defined neighbors. There is a single EIGRP Neighbor Table for each Protocol Dependent Module (PDM).

When an EIGRP neighbor sends a Hello packet, it advertises a Hold Time, which is the amount of time a router treats a neighbor as reachable and operational. After a router receives a Hello packet, the Hold time value begins to decrement and count down to zero. When another Hello packet is received, the Hold time value restarts from the beginning and the process is continually repeated. If a Hello packet isn’t received within the Hold time, then the Hold time expires (goes to 0). When the Hold time expires, DUAL is informed of the topology change and the neighbor is declared down by EIGRP. A message similar to the following is then printed and logged by the router:

The EIGRP Neighbor Table entry also includes information required by the Reliable Transport Protocol (RTP). Reliable Transport Protocol is the protocol that is used by EIGRP to ensure that Update, Query and Reply packets are sent reliably. In addition, sequence numbers are also used to match acknowledgments with data packets. The last sequence number received from the neighbor is recorded so out of order packets are detected. This ensures reliable packet delivery.

NOTE: Reliable Transport Protocol (RTP) is described in detail later in this chapter.

The Neighbor Table includes a transmission list that is used to queue packets for possible retransmission on a per neighbor basis. Additionally, round trip timers are kept in the neighbor data structure to estimate an optimal retransmission interval. This information is all printed in the output of the show ip eigrp neighbors command as illustrated below:

It is important to understand the information printed by this command, both as a basis for demonstrating competency on a core EIGRP component, as well as for troubleshooting EIGRP issues. Table 2-2 lists and describes the fields contained in the output of this command:

Tab. 2-2. EIGRP Neighbor Table Fields

While the show ip eigrp neighbors command prints out information on known EIGRP neighbors, it does not differentiate between dynamically discovered and manually configured neighbors. For example, the output of theshow ip eigrp neighbors command on R2 indicates that the router has two EIGRP neighbor relationships. Based on the configuration, one is a statically configured neighbor, while the other is dynamically discovered. As we can see, it is not possible to determine which is which based on the output below:

In environments where the router has both dynamically discovered and manually configured neighbor relationships, the show ip eigrp neighbors detail command can be used to determine which neighbor is statically configured and which is dynamically discovered:

Referencing the output above, neighbor 192.168.1.3 is a manually configured neighbor and the neighbor 150.2.2.2 is a dynamically discovered neighbor. The static neighbors can also be viewed using the show ip eigrp neighbors static <interface> command as below:

Reliable Transport Protocol

EIGRP needs its own transport protocol to ensure the reliable delivery of packets. Reliable Transport Protocol is the protocol that is used by EIGRP to ensure that Update, Query and Reply packets are sent reliably. The use of sequence numbers also ensures that the EIGRP packets are received in the correct order.

When reliable EIGRP packets are sent to a neighbor, the sending router expects an ACK from the receiving routers stating that the packet has been received. Using RTP, EIGRP maintains a transport window of one unacknowledged packet, which means that every single reliable packet that is sent out must be acknowledged before the next reliable packet can be sent. The sending router will retransmit the unacknowledged reliable packet until it receives an ACK.

It is important to note, however, that the unacknowledged packet will only be retransmitted up to 16 times. If there is still no acknowledgment after 16 retransmissions, EIGRP will reset the neighbor relationship. RTP uses both Multicast and Unicast packets. On Broadcast multi-access networks such as Ethernet, EIGRP uses Multicast instead of sending an individual packet to each router on the segment. However, packets may also be sent using Unicast if a response is not received from one or more of the neighbors on the multi-access segment. This is described referencing the diagram in Figure 2-6:

Fig. 2-6. EIGRP RTP Operation

In Figure 2-6, routers R1, R2, and R3 reside on a common subnet on the multi-access segment. Given the media, EIGRP will use Multicast to send reliable packets between the routers. Assume, for example, that R1 sends out a packet that requires acknowledgment to routers R2 and R3. R1 then waits for acknowledgement from R2 and R3 confirming receipt of this packet. Assume that R3 responds, but R2 is unable to respond to this packet.

Given that EIGRP maintains a transport window of one unacknowledged packet, which means that every individual reliable packet that is sent out must be explicitly acknowledged by the neighbor router(s) before the next reliable packet can be sent, this presents a possible issue on the multi-access segment because R1 will not be able to send out packets until it has received the acknowledgment from R2. R3 is therefore indirectly affected by the issues on R2.

To avoid this potential pitfall, R1 will wait for the Multicast Flow Timer (MFT) on the Ethernet interface connected to the multi-access segment to expire. The MFT, or simply the Flow Timer, is the maximum amount of time that the sending router will wait for an ACK packet from a group member. When the timer expires, R1 will Multicast a special EIGRP packet called a Sequence TLV. This packet lists R2 (the offender) and indicates an out-of-sequence Multicast packet. Because R3 is not listed in this packet, it enter Conditional Receive (CR) mode and continue listening to Multicast packets. R1 uses Unicast to retransmit the packet to R2. The RTO indicates the time that the router waits for an acknowledgement of that Unicast. If after 16 total attempts there is still no response from R2, EIGRP will reset the neighbor.

NOTE: You are not required to go into any further detail on MFT or RTO in the ROUTE exam.