Chapter 9: EIGRP

Cisco Press

1 2 3 4 Page 2
Page 2 of 4

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:

  1. Initially, full updates are sent, including all routes except those omitted due to split horizon.

  2. Once all routes have been exchanged, the updates cease.

  3. Future partial updates occur when one or more routes change.

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

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:

  1. 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.)

  2. R1 sends the multicast EIGRP Update.

  3. R1 notes from which neighbors it receives an EIGRP ACK for the Update.

  4. RTO expired before router R2 sent its EIGRP ACK.

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

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:

  1. R1 advertises a route, with bandwidth = 10,000 and delay = 100.

  2. R2 calculates the RD for this route per the received K values.

  3. 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).

  4. 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 PointEIGRP Convergence FunctionDescription
 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 conditionWhen multiple routes to reach one subnet exist, the case in which one route's RD is lower than the FD
 Successor routeThe 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 eventAny occurrence that could change a router's EIGRP topology table
 Local computationAn 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

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

Related:
1 2 3 4 Page 2
Page 2 of 4
SD-WAN buyers guide: Key questions to ask vendors (and yourself)