Cisco Press
Excerpt from CCIE Routing and Switching Official Exam Certification Guide, 2nd Edition.
Please note that the 2nd Edition of this book is no longer available. The most current edition is the 3rd edition.
Read Wendell Odom’s blog for Cisco Subnet.
More chapters from new and classic Cisco Press books
Rate your favorite Cisco Press books
Blueprint topics covered in this chapter:
This chapter covers the following topics from the Cisco CCIE Routing and Switching written exam blueprint:
IP Routing
EIGRP
The use of show and debug commands
This chapter covers most of the features, concepts, and commands related to EIGRP. Chapter 11, “IGP Route Redistribution, Route Summarization, and Default Routing,” covers a few other details of EIGRP—in particular, route redistribution, route filtering when redistributing, and route summarization.
“Do I Know This Already?” Quiz
Table 9-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions.
Table 9-1: “Do I Know This Already” Foundation Topics Section-to-Question Mapping
| Foundation Topics Section | Questions Covered in This Section | Score |
|---|---|---|
| EIGRP Basics and Steady-State Operation | 1–4 | |
| EIGRP Convergence | 5–7 | |
| EIGRP Configuration | 8–9 | |
| Total Score |
In order to best use this pre-chapter assessment, remember to score yourself strictly. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
Which of the following items are true of EIGRP?
Authentication can be done using MD5 or clear text.
Uses UDP port 88.
Sends full or partial updates as needed.
Multicasts updates to 224.0.0.10.
Four routers (R1, R2, R3, and R4) are attached to the same VLAN. R1 has been configured for an EIGRP Hello timer of 3. R2 has been configured with a metric weights 0 0 0 1 0 0 command. R3 has been configured with a hold time of 11 seconds. Their IP addresses are 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4, with /24 prefixes, except R4, which has a /23 prefix configured. All other related parameters are set to their default. Select the routers that are able to collectively form neighbor relationships.
R1
R2
R3
R4
None of them can form a neighbor relationship.
In the following command output, what do the numbers in the column labeled “H” represent?
R1# show ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 172.31.11.2 Fa0/0 4 00:03:10 1 4500 0 233 1 172.31.11.202 Fa0/0 11 00:04:43 1 4500 0 81 0 172.31.11.201 Fa0/0 14 00:05:11 1927 5000 0 84The current Hold Time countdown
The number of seconds before a Hello is expected
The order in which the neighbors came up
None of the other answers are correct
Which of the following is not true regarding the EIGRP Update message?
Updates require an acknowledgement with an Ack message.
Updates can be sent to multicast address 224.0.0.10.
Updates are sent as unicasts when they are retransmitted.
Updates always include all routes known by a router, with partial routing information distributed as part of the EIGRP Reply message.
The output of a show ip eigrp topology command lists information about subnet 10.1.1.0/24, with two successors, and three routes listed on lines beginning with “via.” How many feasible successor routes exist for 10.1.1.0/24?
0
1
2
3
Cannot determine from the information given
The following command output shows R11’s topology information for subnet 10.1.1.0/24. Then R11 and R12 (IP address 10.1.11.2) are connected to the same LAN segment. Then R11’s EIGRP Hold Time expires for neighbor R12. Which of the following is true about R11’s first reaction to the loss of its neighbor R12?
R11# show ip eigrp topology ! lines omitted for brevity P 10.1.1.0/24, 1 successors, FD is 1456 via 10.1.11.2 (1456/1024), FastEthernet0/0 via 10.1.14.2 (1756/1424), Serial0/0.4
R11 sends Updates to all neighbors poisoning its route to 10.1.1.0/24.
R11 replaces the old route through 10.1.11.2 with the feasible successor route through 10.1.14.2.
R11 sends Query messages to all other neighbors to ensure that the alternate route through 10.1.14.2 is loop free, before using the route.
R11 first Queries only neighbors on interface fa0/0 for alternative routes before Querying the rest of its neighbors.
EIGRP router R11 has just changed its route to subnet 10.1.2.0/24 to the active state, and has sent a Query to five neighbors. Which of the following is true about the next step taken by R11?
R11 adds a new route to 10.1.2.0/24 to the routing table as soon as it receives an EIGRP Reply that describes a new route to 10.1.2.0/24.
R11 can add a new route to 10.1.2.0/24 after receiving Reply messages from all 5 neighbors.
R11 can add a new route for 10.1.2.0/24 to the routing table, even without 5 Reply messages, once the Hold timer expires.
R11 can add a new route for 10.1.2.0/24 to the routing table, even without 5 Reply messages, once the Dead timer expires.
EIGRP router R11 has five interfaces, with IP address 10.1.1.11/24 (interface fa0/0), 10.1.2.11/24, 10.1.3.11/24, 10.1.4.11/24, and 10.1.5.11/24. Its EIGRP configuration is shown below. Which of the following answers is true regarding this router?
router eigrp 1 network 10.1.0.0 0.0.3.255 passive-interface fa0/0
R11 will send EIGRP Updates out fa0/0, but not process received EIGRP Updates.
R11 will advertise connected subnets 10.1.3.0/24 and 10.1.4.0/24.
R11 will advertise subnets 10.1.1.0/24 and 10.1.2.0/24, as well as attempt to send Hellos and Updates on the related interfaces.
The network command does not match any interfaces, so EIGRP will essentially do nothing.
EIGRP router Br1 is a branch router with two Frame Relay subinterfaces (s0/0.1 and s0/0.2) connecting it to distribution routers. It also has one LAN interface, fa0/0. No other routers connect to the Br1 LAN. Which of the following scenarios prevent router Br1 from sending EIGRP Hellos out its fa0/0 interface?
The inclusion of the passive-interface fa0/0 command on Br1
The inclusion of the eigrp stub command on Br1
The inclusion of the eigrp stub receive-only command on Br1
The lack of a network command that matches the IP address of Br1’s fa0/0 interface
Foundation Topics
EIGRP Basics and Steady-State Operation
Many CCIE candidates have known, at least at some point, many of the details of EIGRP operation and configuration. EIGRP is widely deployed and is thoroughly covered on the CCNP BSCI exam. With that in mind, this chapter strives to review the key terms and concepts briefly, and get right to specific examples that detail EIGRP operation on a Cisco router. To that end, the chapter begins with Table 9-2, which lists some of the key features related to EIGRP.
Table 9-2: EIGRP Feature Summary
| Key Point | Feature | Description |
|---|---|---|
| Transport | IP, protocol type 88 (does not use UDP or TCP). | |
| Metric | Based on constrained bandwidth and cumulative delay by default, and optionally load, reliability, and MTU. | |
| Hello interval | Interval at which a router sends EIGRP Hello messages on an interface. | |
| Hold timer | Timer used to determine when a neighboring router has failed, based on a router not receiving any EIGRP messages, including Hellos, in this timer period. | |
| Update destination address | Normally sent to 224.0.0.9, with retransmissions being sent to each neighbor’s unicast IP address. | |
| Full or partial updates | Full updates are used when new neighbors are discovered; otherwise, partial updates are used. | |
| Authentication | Supports MD5 authentication only. | |
| VLSM/classless | EIGRP includes the mask with each route, also allowing it to support discontiguous networks and VLSM. | |
| Route Tags | Allows EIGRP to tag routes as they are redistributed into EIGRP. | |
| Next-hop field | Supports the advertisement of routes with a different next-hop router than the advertising router. | |
| Manual route summarization | Allows route summarization at any point in the EIGRP network. | |
| Multiprotocol | Supports the advertisement of IPX and AppleTalk routes. |
Hellos, Neighbors, and Adjacencies
After a router has been configured for EIGRP, and its interfaces come up, it attempts to find neighbors by sending EIGRP Hellos (destination 224.0.0.10). Once a pair of routers have heard each other say Hello, they become adjacent—assuming several key conditions are met. Once neighbors pass the checks in the following list, they are considered to be adjacent. At that point, they can exchange routes and are listed in the output of the show ip eigrp neighbor command.
Must pass the authentication process
Must use the same configured AS number
Must believe that the source IP address of a received Hello is in that router’s primary connected subnet on that interface
K values must match
The wording of the third item in the list bears a little further scrutiny. The primary subnet of an interface is the subnet as implied by the ip address command that does not have the secondary keyword. An EIGRP router looks at the source IP address of a Hello; if the source IP address is a part of that router’s primary subnet of the incoming interface, the Hello passes the IP address check.
This logic leaves open some interesting possibilities. For example, if the routers are misconfigured with different subnet masks, the check may still pass. If one router has configured 10.1.2.1/24, and the other has configured 10.1.2.2/23, they could become adjacent, assuming all the other checks pass. While EIGRP supports secondary IP addresses and subnets, EIGRP sources its messages from the address in the primary subnet, and the IP addresses of neighbors must be in the subnet of the primary subnets.
The last item in the list mentions K values; K values are constants that define the multipliers used by EIGRP when calculating metrics. The settings can be changed with a router eigrp subcommand metric weights tos k1 k2 k3 k4 k5. The command defaults to a setting of 0 1 0 1 0 0, meaning that only bandwidth and delay are used to calculate the metric. (The examples in this chapter habitually change the settings to 0 0 0 1 0 0, which removes bandwidth from the calculation and makes the metrics in the examples a little more obvious.)
Besides simply checking to see if the right parameters agree, the Hello messages also serve as an EIGRP keepalive. Adjacent routers continue to multicast Hellos based on each interface’s EIGRP hello interval. If a router fails to hear from a neighbor for a number of seconds, defined by the EIGRP Hold Time for that neighbor, all routes through the neighbor are considered to have failed.
Example 9-1 shows how a router displays some of the basic information regarding EIGRP operations based on Figure 9-1. The example begins with four routers (R1, R2, S1, and S2) that have only their common LAN interfaces up, just to show the Hello process. By the end of the example, the R2-to-R5 PVC will come up, but the EIGRP adjacency will fail due to a K-value mismatch.
Figure 9-1
Sample Internetwork Used for EIGRP Examples
Example 9-1: Forming EIGRP Adjacencies
! First, a debug is initiated on R1.
R1# debug eigrp packet hello
EIGRP Packets debugging is on
(HELLO)
Jan 11 13:27:19.714: EIGRP: Received HELLO on FastEthernet0/0 nbr 172.31.11.201
Jan 11 13:27:19.714: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ
un/rely 0/0
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! S2's LAN interface brought up, not shown
! Below, a pair of log messages appear, announcing the new neighbor; this message
! appears due to the default router eigrp subcommand eigrp log-neighbor-changes.
Jan 11 13:27:19.995: EIGRP: New peer 172.31.11.202
Jan 11 13:27:19.995: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.11.202 (FastEthernet0/0) is up: new adjacency
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Next, only neighbors who become adjacent—those that pass all the required
! checks for the parameters—are listed. The Hold timer is shown; it starts at
! its maximum, and decrements towards 0, being reset upon the receipt of any EIGRP
! packet from that neighbor. The "H" column on the left states the order in
! which the neighbors became adjacent.
R1# show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.31.11.2 Fa0/0 4 00:03:10 1 4500 0 233
1 172.31.11.202 Fa0/0 11 00:04:43 1 4500 0 81
0 172.31.11.201 Fa0/0 14 00:05:11 1927 5000 0 84
! Below, the PVC between R2 and R5 came up, but R5's K values do not match R2's.
! Both messages below are log messages, with no debugs enabled on either router.
! Next message on R5 !!!!!!!!!!
03:55:51: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.25.2 (Serial0) is down: K-value mismatch
! Next message on R2 !!!!!!!!!!
Jan 11 13:21:45.643: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.25.5 (Serial0/0.5) is down: Interface Goodbye received
Note that when the PVC between R2 and R5 comes up, the message on R5 is pretty obvious, but the message at R2 says nothing about K values. Some later releases of Cisco IOS mistake invalid EIGRP K-value settings as a newer EIGRP message called a Goodbye message. Goodbye messages allow routers to tell each other that they are shutting down in a graceful fashion; be aware that this message may simply be the result of a K-value mismatch.
Interestingly, the Hello and Hold time parameters do not need to match for EIGRP neighbor relationships to form. In fact, a router does not use its own timers when monitoring a neighbor
EIGRP Updates
Once routers are adjacent, they can exchange routes using EIGRP Update messages. The process follows this general sequence:
Initially, full updates are sent, including all routes except those omitted due to split horizon.
Once all routes have been exchanged, the updates cease.
Future partial updates occur when one or more routes change.
If neighbors fail and recover, or new neighbor adjacencies are formed, full updates are sent.
EIGRP uses the Reliable Transport Protocol (RTP) to send the multicast EIGRP updates. EIGRP sends updates, waiting on a unicast EIGRP ACK message from each recipient. Figure 9-2 shows the general idea over a LAN.
Figure 9-2
EIGRP Use of RTP on a LAN
RTP allows the Updates to be sent as multicasts. If any neighbors fail to acknowledge receipt of the multicasted update, RTP resends Updates as unicasts just to those neighbors. The steps run as follows, using Figure 9-2 as an example:
The EIGRP sender (R1 in Figure 9-2) starts a Retransmission Timeout (RTO) timer for each neighbor when sending a reliable message like an Update. (Cisco IOS actually calculates a Smoothed Round-Trip Time, or SRTT, to each neighbor, and derives RTO from the SRTT; both values are shown in the show ip eigrp neighbor output. These values vary over time.)
R1 sends the multicast EIGRP Update.
R1 notes from which neighbors it receives an EIGRP ACK for the Update.
RTO expired before router R2 sent its EIGRP ACK.
R1 resends the Update, this time as a unicast, and only to the neighbor(s) that did not reply within the RTO time (R2 in this case).
This process allows efficient multicasting of updates under normal circumstances, and efficient retransmission when ACKs do not arrive in time.
EIGRP and RTP use a simple acknowledgement process with a window size of one message. Each Update packet has a sequence number, with the returned ACK message confirming receipt of the message by listing that same sequence number. Example 9-2 shows the location of the sequence number information in both show and debug commands. (In the example, R1 does a no shut on a loopback interface [IP address 172.31.151.1/24], with R1 sending an update advertising the newly-available route.)
Example 9-2: Sequence Numbers in EIGRP Updates and ACKs
! First, note the show ip eigrp neighbor output on router R2. The last column
! lists the sequence number last used by that neighbor to send a "reliable"
! packet. So, R2 expects R1's next reliable EIGRP message to have sequence number
! 225. Also, the RTO calculations are listed for each neighbor. Note
! that the SRTT value is 0 until some reliable packets are exchanged, as SRTT
! is calculated based on actual round-trip time measurements.
R2# sh ip eigrp neighbor
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.31.11.1 Fa0/0 5 01:14:03 1 200 0 224
1 172.31.11.202 Fa0/0 13 01:15:36 1 200 0 92
0 172.31.11.201 Fa0/0 13 01:16:04 257 1542 0 96
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! R1 – R1 – R1 – R1
! Next, the debug command on R1 enables debug for Update and Ack packets.
R1# debug eigrp packet update ack
EIGRP Packets debugging is on
(UPDATE, ACK)
! Not Shown: R1's loop0 is "no shutdown," interface address 172.31.151.1/24.
! Below, the debug messages show R1's update, and each of the other three routers'
! Acks. Note R1's update has "sequence" 225, and the Acks list that same sequence
! number after the slash.
Jan 11 14:43:35.844: EIGRP: Enqueueing UPDATE on FastEthernet0/0 iidbQ un/rely 0/1 serno 207-207
Jan 11 14:43:35.848: EIGRP: Sending UPDATE on FastEthernet0/0
Jan 11 14:43:35.848: AS 1, Flags 0x0, Seq 225/0 idbQ 0/0 iidbQ un/rely 0/0 serno 207-207
Jan 11 14:43:35.848: EIGRP: Received ACK on FastEthernet0/0 nbr 172.31.11.202
Jan 11 14:43:35.852: AS 1, Flags 0x0, Seq 0/225 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Jan 11 14:43:35.852: EIGRP: Received ACK on FastEthernet0/0 nbr 172.31.11.2
Jan 11 14:43:35.852: AS 1, Flags 0x0, Seq 0/225 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
The EIGRP Topology Table
EIGRP uses three tables: the neighbor table, the topology table, and the IP routing table. The neighbor table keeps state information regarding neighbors, and is displayed using the show ip eigrp neighbors command. EIGRP Update messages fill the routers’ EIGRP topology tables. Based on the contents of the topology table, each router chooses its best routes and installs these routes in its respective IP routing table.
An EIGRP router calculates the metric for each route based on the components of the metric. When a neighboring router advertises a route, the Update includes the metric component values for each route. The router then considers the received metric values, as well its own interfaces settings, to calculate its own metric for each route. The default metric components are cumulative delay, in tens of microseconds, and the constraining bandwidth for the entire route, in bits per second. By setting the correct K values in the metric weights command, EIGRP can also consider link load, reliability, and MTU. Cisco recommends not using those values, in large part due to the fluctuation created by the rapidly changing calculated metrics and repeated routing reconvergence.
Figure 9-3 depicts the general logic relating to the metric components in a routing update, showing the units on the bandwidth and delay commands versus the contents of the updates.
A router considers its interface delay settings, as defined with the delay interface subcommand, when calculating EIGRP metrics. The delay command’s units are tens of microseconds, so a delay 1 command sets the interface delay as 10 microseconds.
Figure 9-3
EIGRP Update and Computing the Metric
Because the received update includes the neighbor’s metric components, a router can calculate the advertising neighbor’s metric for a route—called the reported distance (RD). A router can, of course, also calculate its own metric for a particular route, after adding its own interface delay and considering whether it should adjust the value for the constraining bandwidth. For example, consider the four steps outlined in Figure 9-3:
R1 advertises a route, with bandwidth = 10,000 and delay = 100.
R2 calculates the RD for this route per the received K values.
R2 updates its topology table, adding delay 1000 because the interface on which R2 received the update has a delay setting of 1000. It also uses a new bandwidth setting, because the received Update’s bandwidth (10,000) was greater than R2’s incoming interface’s bandwidth (1544).
R2’s update to another neighbor includes the new (cumulative) delay and the new (constraining) bandwidth.
Assuming default K-value settings, the EIGRP formula for the metric calculation is
Metric = 256 (107/bandwidth) 256 (delay)
The show ip eigrp topology command lists the RD and the locally computed metric for the entries in the EIGRP topology table. Example 9-3 shows a few details of where the RD and local metric can be seen in show command output. The example is based on Figure 9-1, with all routers and interfaces now working properly. Also, to keep things simple, the delay command has been used to set all links to delay 1 (LANs), delay 2 (WANs), or delay 3 (loopbacks). Also, the metric weights 0 0 0 1 0 0 command was used on each router, taking bandwidth out of the calculation, making the calculated metrics a little more meaningful in the command output.
Example 9-3: EIGRP Topology Table
! First, the numbers in parentheses show this router's (R1's) calculated metric,
! then a "/", then the RD. For example, S1 advertised the route to 211.0/24, with
! R1 calculating S1's metric (the RD) as 768. Delay 3 was set on S1's loopback
! (where 211.0/24 resides), so its metric was 3*256=768. R1's metric adds delay 1,
! for a metric of 4*256=1024.
R1# show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.31.16.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 172.31.151.0/24, 1 successors, FD is 768
via Connected, Loopback1
P 172.31.211.0/24, 1 successors, FD is 1024
via 172.31.11.201 (1024/768), FastEthernet0/0
P 172.31.24.0/30, 1 successors, FD is 768
via 172.31.11.2 (768/512), FastEthernet0/0
via 172.31.14.2 (1024/512), Serial0/0.4
! Lines omitted for brevity
! Below, the metric in the IP routing table entries match the first number in
! the parentheses, as well as the number listed as "FD is..." in the output above.
R1# show ip route
! omitted legend for brevity
172.31.0.0/16 is variably subnetted, 9 subnets, 2 masks
D 172.31.211.0/24 [90/1024] via 172.31.11.201, 00:29:42, FastEthernet0/0
D 172.31.24.0/30 [90/768] via 172.31.11.2, 00:29:44, FastEthernet0/0
! Lines omitted for brevity
The show ip eigrp topology command lists a few additional very important concepts and terms related to how EIGRP chooses between multiple possible routes to the same prefix. First, the term feasible distance (FD) refers to this router’s best calculated metric among all possible routes to reach a particular prefix. The FD is listed as “FD is x” in the command output. The route that has this best FD is called the successor route, and is installed in the routing table. The successor route’s metric is by definition called the feasible distance, so that metric is what shows up in the routes shown with the show ip route command. These additional terms all relate to how EIGRP processes convergence events, which is explained next.
EIGRP Convergence
Once all the EIGRP routers have learned all the routes in the network, and placed the best routes (the successor routes) in their IP routing tables, their EIGRP processes simply continue to send Hellos, expect to receive Hellos, and look for any changes to the network. When those changes do occur, EIGRP must converge to use the best available routes. This section covers the three major components of EIGRP convergence: input events, local computation (which includes looking for feasible successors), and using active querying to find alternative routes.
Table 9-3 lists several of the key EIGRP terms related to convergence. Following the table, the text jumps right into what EIGRP does when a topology or metric change occurs.
Table 9-3: EIGRP Features Related to Convergence
| Key Point | EIGRP Convergence Function | Description |
|---|---|---|
| Reported distance (RD) | The metric (distance) of a route as reported by a neighboring router | |
| Feasible distance (FD) | The metric value for the lowest-metric path to reach a particular subnet | |
| Feasibility condition | When multiple routes to reach one subnet exist, the case in which one route’s RD is lower than the FD | |
| Successor route | The route to each destination prefix for which the metric is the lowest metric | |
| Feasible successor (FS) | A route that is not a successor route but meets the feasibility condition; can be used when the successor route fails, without causing loops | |
| Input event | Any occurrence that could change a router’s EIGRP topology table | |
| Local computation | An EIGRP router’s reaction to an input event, leading to the use of a feasible successor or going active on a route |
Input Events and Local Computation
An EIGRP router needs to react when an input event occurs. The obvious input events are when a router learns of new prefixes via newly received routing updates, when an interface fails, or when a neighbor fails. Because EIGRP sends updates only as a result of changed or new topology information, a router must consider the update and decide if any of its routes have changed.
When an input event implies that a route has failed, the router performs local computation, a fancy term for a process that can be boiled down to relatively simple logic. In short, the result of local computation is that the router either is able to choose a replacement route locally, without having to ask any neighbors, or is required to ask neighbors for help. Simply put, for a failed route, local computation does the following:
If FS routes exist, install the lowest-metric FS route into the routing table, and send Updates to neighbors to notify them of the new route.
If no FS route exists, actively query neighbors for a new route.
To be an FS route, a route must meet the feasibility condition, defined as follows:
The RD must be lower than this router’s current FD for the route.
The local computation is best understood by looking at an example. Figure 9-4 shows the same network as in Figure 9-1, but with delay values shown. Example 9-4 begins with R4 using a successor route to 172.31.211.0/24, through R1. R4 also has an FS route to 172.31.211.0/24 through R2. The example shows what happens when the PVC from R1 to R4 fails, and R4’s neighbor relationship with R1 fails, causing R4 to perform local computation and start using its FS route through R2.
Figure 9-4
Network Used for EIGRP Convergence Examples
Note – The routers have disabled the use of bandwidth in the EIGRP metric calculation, so all metrics in Example 9-4 are multiples of 256.
Example 9-4: Local Computation: R1-R4 Link Fails; R4 Finds an FS to 172.31.211.0/24 Through R2
! First, the current successor route on R4 points out S0/0.1, to R1, metric 2048.
R4# show ip route
! lines omitted for brevity
172.31.0.0/16 is variably subnetted, 9 subnets, 2 masks
D 172.31.211.0/24 [90/2048] via 172.31.14.1, 00:01:46, Serial0/0.1
! Below, the FD is listed as 2048 as well. The topology entry for the successor
! has the same 2048 metric listed as the first number in parentheses; the second
! number is the RD on R1 (1280). The second topology entry for this route lists
! metric 2560, RD 1280; with RD in the second route being less than the FD, this
! second route meets the feasibility condition, making it an FS route.
R4# show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.31.104.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
! lines omitted for brevity
P 172.31.211.0/24, 1 successors, FD is 2048
via 172.31.14.1 (2048/1280), Serial0/0.1
via 172.31.24.2 (2560/1792), Serial0/0.2
! Next, R4 loses Neighbor R1, with EIGRP Finite State Machine (FSM) debug on.
R4# debug eigrp fsm
EIGRP FSM Events/Actions debugging is on
Jan 12 07:17:42.391: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.14.1 (Serial0/0.1) is down: holding time expired
! Below, debug messages have been edited to only show messages relating to
! the route to 172.31.211.0/24. R4 looks for an FS, finds it, replaces the old
! successor with the FS, and sends updates telling neighbors about the new route.
Jan 12 07:17:42.399: DUAL: Destination 172.31.211.0/24
Jan 12 07:17:42.399: DUAL: Find FS for dest 172.31.211.0/24. FD is 2048, RD is 2048
Jan 12 07:17:42.399: DUAL: 172.31.14.1 metric 4294967295/4294967295
Jan 12 07:17:42.399: DUAL: 172.31.24.2 metric 2560/1792 found Dmin is 2560
Jan 12 07:17:42.399: DUAL: Removing dest 172.31.211.0/24, nexthop 172.31.14.1
Jan 12 07:17:42.403: DUAL: RT installed 172.31.211.0/24 via 172.31.24.2
Jan 12 07:17:42.403: DUAL: Send update about 172.31.211.0/24. Reason: metric chg
Jan 12 07:17:42.403: DUAL: Send update about 172.31.211.0/24. Reason: new if
! Finally, note that the FD is unchanged; the FD is never raised until the route
! has been actively queried. The new route info has been put in the routing table.
R4# show ip eigrp topology
! lines omitted for brevity
P 172.31.211.0/24, 1 successors, FD is 2048
via 172.31.24.2 (2560/1792), Serial0/0.2
R4# show ip route
! Lines omitted for brevity
D 172.31.211.0/24 [90/2560] via 172.31.24.2, 00:00:25, Serial0/0.2
Going Active on a Route
The second branch in the local computation logic causes the EIGRP router to ask its neighbors about their current best route to a subnet, hoping to find an available, loop-free alternative route to that subnet. When no FS route is found, the EIGRP router goes active for the route. Going active is jargon for the process of changing a route’s status to active. Once the router is active, EIGRP multicasts Query messages to its neighbors, asking the neighbors if they have a valid route to the subnet. The neighbors should unicast EIGRP Reply packets back to the original router, stating whether or not they have a current loop-free route with which to reach that prefix.
Once a router receives Reply messages from all the neighbors to which it sent Queries, the router updates its topology table with all the new information learned in the Reply messages, recomputes metrics for any known routes, and chooses a new successor. Of course, if no routes to that subnet are found, this router simply does not add a route to the routing table.
Note – The EIGRP term “active” refers to a route for which a router is currently using the Query process to find a loop-free alternative route. Conversely, a route is in passive state when it is not in an active state.
The neighboring routers view any received Query messages as an input event. Each neighbor router’s behavior when receiving a Query can be summarized as follows:
If the router does not have an entry in its topology table for that subnet, it sends an EIGRP Reply packet stating that it has no route.
If the router’s successor for that subnet is unchanged, or an FS is found, the neighbor sends back an EIGRP Reply message with the details of the route.
If the conditions in step 1 or 2 do not exist, the router itself goes active, and withholds its EIGRP response to the original Query, until all of its neighbors respond.
Note that the logic in the third step can result in a route for which the Active Querying process never completes. Routes that stay in active state too long are considered to be stuck-in-active routes. The related concepts are covered in the next section.
Example 9-5 shows an example of the Query process. The example is again based on Figure 9-4, with R4 again losing its neighbor relationship with R1. In this case, R4’s local computation will not find an FS for its failed route to 172.31.151.0/24, so it must go active.
Example 9-5: R1-R4 Link Fails; R4 Actively Queries for 172.31.151.0/24
! First, the show ip eigrp topology command only lists the successor route, and no
! FS routes. This command does not list non-FS routes.
R4# show ip eigrp topo
! Lines omitted for brevity
P 172.31.151.0/24, 1 successors, FD is 1536
via 172.31.14.1 (1536/768), Serial0/0.1
! Below, the show ip eigrp topology all-links command includes non-FS routes,
! in this case including the non-FS route to 151.0/24 through R2. Note that this
! alternate non-FS route's RD is 1792, which is more than the FD of 1536.
R4# show ip eigrp topology all-links
! Lines omitted for brevity
P 172.31.151.0/24, 1 successors, FD is 1536, serno 175
via 172.31.14.1 (1536/768), Serial0/0.1
via 172.31.24.2 (2560/1792), Serial0/0.2
! Next, the FSM debug is again enabled, and R4 loses neighbor R1.
R4# debug eigrp fsm
Jan 12 07:16:04.099: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.14.1 (Serial0/0.1) is down: holding time expired
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Below, R4 looks for an FS for route 172.31.151.0/24, and does not find one—
! so it enters active state. R4 sends a query to its one remaining neighbor (R2),
! and keeps track of the number of outstanding Queries (1). Upon receiving the
! Reply from R2, it can update its topology table, and repeat local computation,
! and use the now-best route through R2.
Jan 12 07:17:42.391: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.14.1 (Serial0/0.1) is down: holding time expired
Jan 12 07:17:42.391: DUAL: linkdown: start - 172.31.14.1 via Serial0/0.1
Jan 12 07:17:42.391: DUAL: Destination 172.31.151.0/24
Jan 12 07:17:42.391: DUAL: Find FS for dest 172.31.151.0/24. FD is 1536, RD is 1536
Jan 12 07:17:42.395: DUAL: 172.31.14.1 metric 4294967295/4294967295
Jan 12 07:17:42.395: DUAL: 172.31.24.2 metric 2560/1792 not found Dmin is 2560
Jan 12 07:17:42.395: DUAL: Dest 172.31.151.0/24 entering active state.
Jan 12 07:17:42.395: DUAL: Set reply-status table. Count is 1.
Jan 12 07:17:42.395: DUAL: Not doing split horizon
Jan 12 07:17:42.459: DUAL: rcvreply: 172.31.151.0/24 via 172.31.24.2 metric 2560/1792
Jan 12 07:17:42.459: DUAL: reply count is 1
Jan 12 07:17:42.459: DUAL: Clearing handle 0, count now 0
Jan 12 07:17:42.463: DUAL: Freeing reply status table
Jan 12 07:17:42.463: DUAL: Find FS for dest 172.31.151.0/24. FD is 4294967295, RD is 4294967295 found
Jan 12 07:17:42.463: DUAL: Removing dest 172.31.151.0/24, nexthop 172.31.14.1
Jan 12 07:17:42.463: DUAL: RT installed 172.31.151.0/24 via 172.31.24.2
Jan 12 07:17:42.467: DUAL: Send update about 172.31.151.0/24. Reason: metric chg
Jan 12 07:17:42.467: DUAL: Send update about 172.31.151.0/24. Reason: new if
! Next, note that because R4 actively queried for the route, the FD could change.
R4# show ip eigrp topo
IP-EIGRP Topology Table for AS(1)/ID(172.31.104.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 172.31.151.0/24, 1 successors, FD is 2560
via 172.31.24.2 (2560/1792), Serial0/0.2
Of particular note in this example, look for the debug message starting with “Dual: rcvreply:” (highlighted). This message means that the router received an EIGRP Reply message, in this case from R2. The message includes R2’s valid routing information for 172.31.151.0/24. Also note that the FD was recomputed, whereas it was not in Example 9-4 when an FS route was found.
Note – Query messages use reliable transmission via RTP and are multicasts; Reply messages are reliable and are unicasts. Both are acknowledged using Ack messages.
Note – The EIGRP term Diffusing Update Algorithm (DUAL) refers to the totality of the logic used by EIGRP to calculate new routes. The term is based on the logic used as Query messages go outward from a router, with the outward movement stopped when routers Reply.
Stuck-in-Active
Any router in active state for a route must wait for a Reply to each of its Query messages. It is possible for a router to wait several minutes for all the replies, because neighboring routers might also need to go active, and then their neighbors might need to go active, and so on—each withholding its Reply message until it in turn receives all of its Reply messages. In normal operation, the process should complete; to handle exception cases, EIGRP includes a timer called the Active timer, which limits the amount of time in which a route can stay active. If the Active timer expires before a router receives all of its Reply messages, the router places the route in a stuck-in-active state. The router also brings down any neighbors from which no corresponding Reply was received, thinking that any neighbors that did not send a Reply are having problems.
In some conditions—large, redundant networks, flapping interfaces, or networks with lots of packet loss, to name a few—neighbors might be working fine, but their Reply messages may not complete within the Active timer. To avoid the downside of having the route become stuck-in-active, and losing all routes through a possibly still-working neighbor, you can disable the Active timer by using the timers active-time disabled subcommand under router eigrp.
Limiting Query Scope
Although disabling the Active timer can prevent stuck-in-active routes, a better solution to the prolonged wait for Reply messages is to limit the scope of Query messages. By reducing the number of neighbors that receive the messages, and by limiting the number of hops away the queries flow, you can greatly reduce the time required to receive all Reply messages.
Two methods can be used to limit query scope. The first is route summarization. When a Query reaches a router that has a summarized route, but not the specific route in the query, the router immediately replies that it does not have that route. For instance, a router with the route 172.31.0.0/16 in its topology table, upon receiving a query for 172.31.151.0/24, immediately sends a Reply, stating it does not have a route to 172.31.151.0/24. With well-designed route summarization, EIGRP queries can be limited to a few hops. (Chapter 11, “IGP Redistribution, Route Summarization, and Default Routing,” covers route summarization details.)
The use of EIGRP stub routers also limits the query scope. Stub routers, by definition, should not be used as transit routers for traffic. In Figure 9-4, R5 would be a classic candidate to be a stub router. Also, if R4 should not be used to forward traffic from R1 over to R2, or vice versa, R4 could be a stub as well. In either case, non-stub routers do not send Query messages to the stub routers, knowing that the stub routers should not be transit routers. (Stub router configuration is covered in the next section.)
EIGRP Configuration
This section explains the majority of the options for EIGRP configuration. The “Foundation Summary” section includes the full syntax of the commands, along with some comments, in Table 9-6.
EIGRP Configuration Example
Example 9-6 lists the configuration for R1, R2, R4, and R5 from Figure 9-4. The routers were configured based on the following design goals:
Enable EIGRP on all interfaces.
Configure K values to ignore bandwidth.
Configure R5 as an EIGRP stub router.
Ensure that R2’s LAN interface uses a Hello and Hold time of 2 and 6, respectively.
Configure R4 to allow 75 percent of interface bandwidth for EIGRP updates.
Advertise R4’s LAN subnet, but do not attempt to send or receive EIGRP updates on the LAN.
Example 9-6: Basic EIGRP Configuration on R1, R2, R4, and R5
! Below, R1 EIGRP-related configuration ! The default metric weights are "0 1 0 1 0 0". router eigrp 1 network 172.31.0.0 metric weights 0 0 0 1 0 0 ! R2 EIGRP-related configuration ! Note the commands used to change the Hello and Hold Time values per interface. ! R2's Hellos advertise the timer values, and other routers on the LAN use these ! values on their neighbor relationship with R2. Also below, note the use of the ! inverse mask to match a subset of interfaces on a single network command. interface FastEthernet0/0 ip hello-interval eigrp 1 2 ip hold-time eigrp 1 6 ! router eigrp 1 network 10.0.0.0 network 172.31.11.2 0.0.0.0 network 172.31.24.0 0.0.1.255 metric weights 0 0 0 1 0 0 ! R4 EIGRP-related configuration ! Below, the percentage of the interface bandwidth used for EIGRP is changed. The ! value can go over 100% to allow for cases in which the bandwidth has ! been artificially lowered to impact the EIGRP metric. Also note that R4 makes ! its e0/0 interface passive, meaning no routes learned or advertised on E0/0. interface Serial0/0.1 point-to-point bandwidth 64 ip bandwidth-percent eigrp 1 150 ! router eigrp 1 passive-interface Ethernet0/0 network 172.31.0.0 metric weights 0 0 0 1 0 0 ! R5 EIGRP-related configuration ! Below, note R5's configuration as a stub area. router eigrp 1 network 172.31.0.0 metric weights 0 0 0 1 0 0 eigrp stub connected summary
EIGRP allows for better control of the three functions enabled on an interface by the EIGRP network command. (The three functions are advertising the connected subnet, sending routing updates, and receiving routing updates.) Unlike RIP, but like OSPF, the EIGRP network command supports configuration of an optional wildcard mask (as seen on R4 in Example 9-6), allowing each interface to be matched individually—and making it simple to enable EIGRP on a subset of interfaces. Also, a LAN subnet might have a single router attached to it, so there is no need to attempt to send or receive updates on those interfaces. By enabling EIGRP on the interface with a network command, and then configuring the passive-interface command, you can stop the router from sending Hellos. If a router does not send Hellos, it forms no neighbor adjacencies, and it then neither sends nor receives updates on that LAN.
Example 9-6 also shows R5 configured as an EIGRP stub router. R5 announces itself as a stub router via its EIGRP Hellos. As a result, R2 will not send Query messages to R5, limiting the scope of Query messages.
The eigrp stub command has several options, with the default options (connected and summary) shown on the last line of Example 9-6. (Note that the eigrp stub command was typed, and IOS added the connected and summary options in the configuration.) Table 9-4 lists the eigrp stub command options, and explains some of the logic behind using them.
Table 9-4: EIGRP Features Related to Convergence
| Key Point | Option | This Router Is Allowed To… |
|---|---|---|
| connected | Advertise connected routes, but only for interfaces matched with a network command. | |
| summary | Advertise auto-summarized or statically configured summary routes. | |
| static | Advertise static routes, assuming the redistribute static command is configured. | |
| redistributed | Advertise redistributed routes, assuming redistribution is configured. | |
| receive-only | Not advertise any routes. This option cannot be used with any other option. |
Note that the stub option still requires the stub router to form neighbor relationships, even in receive-only mode. The stub router simply performs less work and reduces the query scope.
Example 9-6 also shows the EIGRP hello interval and hold time being set. These parameters can be set per interface using the interface subcommands ip hello-interval eigrp asn seconds and ip hold-time eigrp asn seconds, respectively. The default EIGRP hello interval defaults to 5 seconds on most interfaces, with NBMA interfaces whose bandwidth is T1 or slower using a hello interval of 60 seconds. The hold time defaults to 15 and 180 seconds, respectively—three times the default hello interval. However, if you change the hello interval, the hold time default does not automatically change to three times the new hello interval; instead, it remains at 15 or 180 seconds.
EIGRP Load Balancing
EIGRP allows for up to six equal-metric routes to be installed into the IP routing table at the same time. However, because of the complex EIGRP metric calculation, metrics may often be close to each other, but not exactly equal. To allow for metrics that are somewhat close in value to be considered equal, and added to the IP routing table, you can use the variance multiplier command. The multiplier defines a value that is multiplied by the lowest metric (in other words, the FD, which is the metric of the successor route). If any other routes have a better metric than that product of variance * FD, those other routes are considered equal, and added to the routing table.
Note – EIGRP allows only FS routes to be considered for addition as a result of using the variance command. Otherwise, routing loops could occur.
Once the multiple routes for the same destination are in the routing table, EIGRP allows several options for balancing traffic across the routes. Table 9-5 summarizes the commands that impact how load balancing is done with EIGRP, plus the other commands related to installing multiple EIGRP routes into the same subnet. Note that these commands are all subcommands under router eigrp.
Table 9-5: EIGRP Route Load-Balancing Commands
| Router EIGRP Subcommand | Meaning |
|---|---|
| variance | Any FS route whose metric is less than the variance value multiplied by the FD is added to the routing table (within the restrictions of the maximum-paths command). |
| maximum-paths {1..6} | The maximum number of routes to the same destination allowed in the routing table. Defaults to 4. |
| traffic-share balanced | The router balances across the routes, giving more packets to lower-metric routes. |
| traffic-share min | Although multiple routes are installed, sends traffic using only the lowest-metric route. |
| traffic-share balanced across-interfaces | If more routes exist than are allowed with the maximum-paths setting, the router chooses routes with different outgoing interfaces, for better balancing. |
| No traffic-share command configured | Balances evenly across routes, ignoring EIGRP metrics. |
EIGRP Configuration Options That Are Similar to RIP
Although EIGRP and RIPv2 differ quite a bit in their underlying operation, several of their features are configured almost identically. This section details these features. You can refer to Chapter 8, “RIP Version 2,” for more information on the configuration syntax for these features.
Authentication—EIGRP configures authentication almost exactly like RIP. EIGRP authentication commands use a keyword of eigrp asn instead of rip, using the ASN configured by the router eigrp command. For example, the interface subcommand ip eigrp 1 authentication key-chain carkeys enables EIGRP MD5 authentication on the interface, pointing to a key chain called “carkeys.” Also, EIGRP does not support simple-text authentication, instead defaulting to MD5. Therefore, it does not use an equivalent of the ip rip authentication mode {text | md5} command.
Route filtering—Configured with the distribute-list command, EIGRP route filtering is configured identically to RIP route filtering—with one important difference in the underlying operation. With RIP, incoming filters prevent the information from getting into the IP routing table; with EIGRP, an incoming filter prevents topology information from getting into the topology table.
Offset lists—EIGRP uses the same syntax for the offset-list command as RIP, but with an interesting underlying bit of logic. EIGRP does not advertise an integer metric, but rather advertises the components of the metric, including constraining bandwidth and cumulative delay. An EIGRP offset list increments only the delay value in the EIGRP metric. For instance, an inbound offset list adding an offset of 1 results in a net increase in the metric of 256, because it increases delay by 1, and EIGRP multiplies the delay setting by 256.
Autosummarization—EIGRP, like RIP, defaults to use auto-summarization; like RIPv2, autosummarization can be disabled with the no auto-summary command under router eigrp.
Split horizon—EIGRP bounds its updates using split horizon logic, like RIP. Split horizon can be disabled per interface by using the no ip split-horizon eigrp asn interface subcommand. Note that, like RIP, most interfaces default to split horizon, with the notable exception of a physical serial interface configured for Frame Relay.
Clearing IP routing tables—The clear ip route * command clears the IP routing table. However, because EIGRP keeps all possible routes in its topology table, a clear ip route * does not cause EIGRP to send any messages or learn any new topology information; the router simply refills the IP routing table with the best routes from the existing topology table. The clear ip eigrp neighbor command clears all neighbor relationships, which clears the entire topology table on the router. The neighbors then come back up, send new updates, and repopulate the topology and routing tables. The clear command also allows for clearing all neighbors that are reachable out an interface, or based on the neighbor’s IP address. (The generic syntax is clear ip eigrp neighbors [ip-address | interface-type interface-number].)
Foundation Summary
This section lists additional details and facts to round out coverage of the topics in this chapter. Unlike most of the Cisco Press Exam Certification Guides, this book does not repeat information presented in the “Foundation Topics” section of the chapter. Please take the time to read and study the details in this section of the chapter, as well as review the items in the “Foundation Topics” section noted with a Key Point icon.
Table 9-6 lists some of the most popular Cisco IOS commands related to the topics in this chapter. Also refer to Table 9-4 for a few additional commands related to load balancing.
Table 9-6: Command Reference for Chapter 9
| Command | Command Mode and Description |
|---|---|
| router eigrp as-number | Global config; puts user in EIGRP configuration mode for that AS |
| network ip-address [wildcard-mask] | EIGRP config mode; defines matching parameters, compared to interface IP addresses, to pick interfaces on which to enable EIGRP |
| distribute-list [access-list-number | name] {in | out} [interface-type | interface-number] | EIGRP config mode; defines ACL or prefix list to use for filtering EIGRP updates |
| ip split-horizon eigrp asn | Interface subcommand; enables or disables split horizon |
| passive-interface [default] {interface-type interface-number} | EIGRP config mode; causes EIGRP to stop sending Hellos on the specified interface, and thereby to also stop receiving and/or sending updates |
| ip hello-interval eigrp asn seconds | Interface subcommand; sets the interval for periodic Hellos sent by this interface |
| ip hold-time eigrp asn seconds | Interface subcommand; sets the countdown timer to be used by a router’s neighbor when monitoring for incoming EIGRP messages from this interface |
| auto-summary | EIGRP config mode; enables automatic summarization at classful network boundaries |
| metric weights tos k1 k2 k3 k4 k5 | EIGRP config mode; defines the per-ToS K values to be used in EIGRP metric calculations |
| ip bandwidth-percent eigrp asn percent | Interface subcommand; defines the maximum percentage of interface bandwidth to be used for EIGRP messages |
| timers active-time [time-limit | disabled] | EIGRP config mode; sets the time limit for how long a route is in active state before becoming stuck-in-active |
| show ip route eigrp asn | User mode; displays all EIGRP routes in the IP routing table |
| show ip eigrp topology [as-number | [[ip-address] mask]] [active | all-links | pending | summary | zero-successors] | User mode; lists different parts of the EIGRP topology table, depending on the options used |
| show ip eigrp interfaces [interface-type interface-number] [as-number] | User mode; lists EIGRP protocol timers and statistics per interface |
| show ip eigrp traffic [as-number] | User mode; displays EIGRP traffic statistics |
| show ip protocols | User mode; lists EIGRP timer settings, current protocol status, automatic summarization actions, and update sources |
| show ip eigrp asn neighbors | User mode; lists EIGRP neighbors |
| clear ip eigrp neighbors [ip-address | interface-type interface-number] | Enable mode; disables current neighbor relationships, removing topology table entries associated with each neighbor |
| clear ip route {network [mask] | *} | Enable mode; clears the routing table entries, which are then refilled based on the current topology table |
| show ip interface [type number] | User mode; lists many interface settings, including split horizon |
| eigrp log-neighbor-changes | EIGRP subcommand; displays log messages when neighbor status changes; enabled by default |
Table 9-7 summarizes the types of EIGRP packets and their purposes.
Table 9-7: EIGRP Message Summary
| Key Point | EIGRP Packet | Purpose |
|---|---|---|
| Hello | Identifies neighbors, exchanges parameters, and is sent periodically as a keepalive function | |
| Update | Informs neighbors about routing information | |
| Ack | Acknowledges Update, Query, and Response packets | |
| Query | Asks neighboring routers to verify their route to a particular subnet | |
| Reply | Sent by neighbors to reply to a Query | |
| Goodbye | Used by a router to notify its neighbors when the router is gracefully shutting down |
Memory Builders
The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers a fairly broad set of topics. This section provides some basic tools to help you exercise your memory about some of the broader topics covered in this chapter.
Fill in Key Tables from Memory
First, take the time to print Appendix F, “Key Tables for CCIE Study,” which contains empty sets of some of the key summary tables from the “Foundation Topics” section of this chapter. Then, simply fill in the tables from memory, checking your answers when you review the “Foundation Topics” section tables that have a Key Point icon beside them. The PDFs can be found on the CD in the back of the book, or at https://www.ciscopress.com/title/1587201410.
Definitions
Next, take a few moments to write down the definitions for the following terms:
hello interval, full update, partial update, Route Tag field, Next Hop field, MD5, DUAL, Hold timer, K value, neighbor, adjacency, RTP, SRTT, RTO, Update, Ack, query, Reply, Hello, Goodbye, RD, FD, feasibility condition, successor route, feasible successor, input event, local computation, active, passive, going active, stuck-in-active, query scope, EIGRP stub router, limiting query scope, variance
Refer to the CD-based glossary to check your answers.
Further Reading
Jeff Doyle’s Routing TCP/IP, Volume I, Second Edition, (Cisco Press) has several excellent examples of configuration, as well as several examples of the DUAL algorithm and the Active Query process.
EIGRP Network Design Solutions, by Ivan Pepelnjak, contains wonderfully complete coverage of EIGRP, at least as it existed at the latest publication date. It also has great, detailed examples of the Query process.
Copyright © 2007 Pearson Education. All rights reserved.
