You are here

Busting 5 Myths of EIGRP

In this post, I’m going to explain some core EIGRP topics that are poorly or even incorrectly documented in many resources including Cisco’s documents, forums and books.

This post will be loosely based on the topology in this Article. The focus will be on R4 and how it’s seeing 192.168.10.0/24.

For all routers, I configured EIGRP with (metric weights 0 0 0 1 0 0) to remove Bandwidth from the metric calculation to simplify this post.

R4#sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 7680
         via 10.1.42.2 (7680/5120), Ethernet0/2
         via 10.1.41.1 (10240/5120), Ethernet0/1 
R4#sh ip eigrp top all
P 192.168.10.0/24, 1 successors, FD is 7680, serno 33
        via 10.1.42.2 (7680/5120), Ethernet0/2
        via 10.1.41.1 (10240/5120), Ethernet0/1
        via 10.1.43.3 (14080/8960), Ethernet0/3

Myth No. 1: Feasible Distance

This is probably one of the most wrongly/poorly documented topics in EIGRP. From Cisco Press/books, CCIE blogs to Cisco’s website(s) – very few resources and authors really got this right.

So. let’s start by getting the correct EIGRP terms here:

Feasible Distance (FD): This is a historical copy of the best metric (CD) for any given destination since the last time that destination went from active to passive. This is a local value to the router and is NEVER advertised to neighbors. There is always ONE and ONLY ONE FD per destination/route. Many resources confuse this with the Computed Distance (CD) which will be explained next. You can see the FD in the above show command in bold here:

P 192.168.10.0/24, 1 successors, FD is 7680

This value might be equal or less than the CD (and strictly higher than RD) as we will see later on. This is probably what caused the confusion between FD and RD in the first place.

Reported Distance (RD): This is the metric that a neighbor is reporting as its own best metric to reach a specific destination. Basically it’s saying “if you decide to reach the destination through me, this is how much the metric is from my perspective, but you have to compute your own total metric to reach me (plus my metric to get the total metric, CD). This value is advertised to neighbors and is shown in the EIGRP topology table per neighbor as shown here:

P 192.168.10.0/24, 1 successors, FD is 7680, serno 33
via 10.1.42.2 (7680/5120), Ethernet0/2
via 10.1.41.1 (10240/5120), Ethernet0/1
via 10.1.43.3 (14080/8960), Ethernet0/3

Computed Distance (CD): This is the total composite metric that EIGRP has calculated on a router to reach a specific destination. This distance is NOT the feasible distance as many resources/authors claim even though it might be equal to the FD (or higher) as we will see. This value is shown in both EIGRP topology and routing tables

P 192.168.10.0/24, 1 successors, FD is 7680, serno 33
via 10.1.42.2 (7680/5120), Ethernet0/2
via 10.1.41.1 (10240/5120), Ethernet0/1
via 10.1.43.3 (14080/8960), Ethernet0/3

D 192.168.10.0/24 [90/7680] via 10.1.42.2, 04:00:55, Ethernet0/2

From R4’s point of view, it’s seeing that to reach 192.168.10.0/24 through R2/Eth0/2, the metric from R2 to the destination is 5120, the total metric from R4 to the destination is 7680. Same applies for the other two neighbors.

Does that mean that the RD showing in R4, say for R2 (5120), is R2’s CD for the same destination? Yes, it is! Let’s confirm that:

R2#sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 5120
        via 10.1.25.5 (5120/2560), Ethernet0/0


R2#sh ip rou eigrp | be Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D        10.1.15.0/24 [90/28160] via 10.1.25.5, 04:17:39, Ethernet0/0
D        10.1.35.0/24 [90/28160] via 10.1.25.5, 04:12:12, Ethernet0/0
D        10.1.41.0/24 [90/30720] via 10.1.42.4, 04:17:39, Ethernet0/2
D        10.1.43.0/24 [90/30720] via 10.1.42.4, 04:12:12, Ethernet0/2
D     192.168.10.0/24 [90/5120] via 10.1.25.5, 04:18:38, Ethernet0/0

Feasible Condition (FC): The RD through a neighbor must be less than the FD of a specific destination in order for the router to consider this route and install it in the routing table as it’s guaranteed to be loop-free route.

Note1: By default, if there is an EIGRP route installed in the routing table, it must have satisfied the FC AND has the best/least metric. If there are more than one (with equal best metric and also passed the FC), they will be installed (up to 4, can be changed using ‘maximum-paths’ command). This can be shown in the routing table.
Note2: EIGRP topology table should show the route that is currently installed in the routing table. This route is called the Successor. It’s also possible that there is one or more other routes with higher metric than the Successor. If these routes passed the FC, they are called the Feasible Successor(s) and will show when using ‘show ip eigrp topology’ command. It is VERY important to keep in mind that all these routes have met the FC. Any other routes that have NOT met the FC, can be shown using this command ‘show ip eigrp topology all-links’. Both commands have been used in the beginning of this post.

Now, let’s go back and analyze R4 EIGRP topology table. It has two routes that have met the FC, one through R2 which has a lower metric than the other one through R1. So the first one gets installed in the routing table. Additionally, there is a third route through R3 that has not met the FC.

Myth No. 2: EIGRP backup route

Well, sorta a myth. Allow me to explain!

There are many resources claim that upon losing the successor, EIGRP will immediately promote the feasible successor (if there is one) to a successor and install it in the routing table without querying it’s neighbors. In reality, this will happen under one single scenario and not always as these resources claim. Let’s go over all these cases:

  • First Case: The Feasible Successor (already met the FC, as discussed above) has the best metric (next to the now lost Successor) among all other routes in the EIGRP topology.

looking at R4 topology table, assume that we lost via R2 (which is currently the successor/best route. The second best route is via R1. The router should not need to send Queries and mark the destination active while waiting for Replies from the other routers. Let’s see this in action, I’m going to use ‘debug eigrp fsm’ then shut down Ethernet 0/2:

*Mar 14 01:00:33.279: DUAL: Destination 192.168.10.0/24 for tid 0
*Mar 14 01:00:33.279: EIGRP-IPv4(100): Find FS for dest 192.168.10.0/24. FD is 7680, RD is 7680 on tid 0
*Mar 14 01:00:33.279: EIGRP-IPv4(100):  10.1.42.2 metric 72057594037927935/72057594037927935
*Mar 14 01:00:33.279: EIGRP-IPv4(100):  10.1.41.1 metric 10240/5120
*Mar 14 01:00:33.279: EIGRP-IPv4(100):  10.1.43.3 metric 14080/8960 found Dmin is 10240
*Mar 14 01:00:33.280: DUAL: AS(100) Removing dest 192.168.10.0/24, nexthop 10.1.42.2
*Mar 14 01:00:33.280: DUAL: AS(100) RT installed 192.168.10.0/24 via 10.1.41.1
*Mar 14 01:00:33.280: DUAL: AS(100) Send update about 192.168.10.0/24. Reason: metric chg on tid 0
*Mar 14 01:00:33.280: DUAL: AS(100) Send update about 192.168.10.0/24. Reason: new if on tid 0

R4#sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 7680
        via 10.1.41.1 (10240/5120), Ethernet0/1

R4#sh ip rou eigrp | b Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D        10.1.15.0/24 [90/7680] via 10.1.41.1, 10:24:26, Ethernet0/1
D        10.1.25.0/24 [90/33280] via 10.1.41.1, 00:04:42, Ethernet0/1
D        10.1.35.0/24 [90/11520] via 10.1.43.3, 10:24:26, Ethernet0/3
D        10.1.42.0/24 [90/58880] via 10.1.41.1, 00:04:41, Ethernet0/1
D     192.168.10.0/24 [90/10240] via 10.1.41.1, 00:04:42, Ethernet0/1

As you can see from the above debug, the router started by setting up the metric via R2 to infinity and started to look for a Feasible Successor and it did find one via R1, sent an EIGRP update for the new route and installed it in the routing table. Its very important to note that the FD is still unchanged at 7680.

  • Second Case: The Feasible Successor (already met the FC, as discussed above) DOES NOT have the best metric among all other routes in the EIGRP topology.

I’m going to bring Eth0/2 back up and reduce the Delay on Eth0/3 to 2 (from 20):

R4(config-if)#do sh ip route eigrp  | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
D        10.1.15.0/24 [90/7680] via 10.1.41.1, 00:03:55, Ethernet0/1
D        10.1.25.0/24 [90/5120] via 10.1.42.2, 00:04:21, Ethernet0/2
D        10.1.35.0/24 [90/6656] via 10.1.43.3, 00:03:55, Ethernet0/3
D     192.168.10.0/24 [90/7680] via 10.1.42.2, 00:03:55, Ethernet0/2

R4(config-if)#do sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 7680
        via 10.1.42.2 (7680/5120), Ethernet0/2
        via 10.1.41.1 (10240/5120), Ethernet0/1

R4(config-if)#do sh ip eigrp top all
P 192.168.10.0/24, 1 successors, FD is 7680, serno 48
        via 10.1.42.2 (7680/5120), Ethernet0/2
        via 10.1.41.1 (10240/5120), Ethernet0/1
        via 10.1.43.3 (9216/8960), Ethernet0/3

As shown above, there was no change on the routing table. However, if you look closely at the topology table, you see FD is still at 7680, Successor is still via R2, Feasible Successor is via R1. So what changed? check the route via R3, now it has a better metric (9216) than the feasible successor’s metric (10240) but it has not met the FC since its RD is 8960 which is higher than the FD.

Again almost all resources will say that the feasible successor will be immediately to the successor. So if I shut down Eth0/2, the route via R1 should be installed in the routing table. But is this true? Routing Protocol’s main task is to find the best route with least metric which is in this case is via R3, but at the same time it does not meet the FC, so EIGRP cannot guarantee that it is loop-free. The route via R1 is guaranteed to be loop-free, but its technically not the best route. So what would EIGRP do in this case? lets find out, I’m going to use the same debug and shut Eth 0/2:

*Mar 14 01:29:41.400: DUAL: Destination 192.168.10.0/24 for tid 0
*Mar 14 01:29:41.400: EIGRP-IPv4(100): Find FS for dest 192.168.10.0/24. FD is 7680, RD is 7680 on tid 0
*Mar 14 01:29:41.400: EIGRP-IPv4(100):  10.1.42.2 metric 72057594037927935/72057594037927935
*Mar 14 01:29:41.401: EIGRP-IPv4(100):  10.1.41.1 metric 10240/5120
*Mar 14 01:29:41.401: EIGRP-IPv4(100):  10.1.43.3 metric 9216/8960 not found Dmin is 9216
*Mar 14 01:29:41.401: DUAL: AS(100) Dest 192.168.10.0/24 entering active state for tid 0.
*Mar 14 01:29:41.401: EIGRP-IPv4(100): Set reply-status table. Count is 2.
*Mar 14 01:29:41.402: EIGRP-IPv4(100): Set reply-status table. Count is 2.
*Mar 14 01:29:41.402: DUAL: AS(100) Clearing handle 1, count now 2
*Mar 14 01:29:41.402: DUAL: linkdown: finish
*Mar 14 01:29:41.457: EIGRP-IPv4(100): rcvreply: 192.168.10.0/24 via 10.1.41.1 metric 10240/5120 for tid 0
*Mar 14 01:29:41.457: EIGRP-IPv4(100): reply count is 2
*Mar 14 01:29:41.457: DUAL: AS(100) Clearing handle 0, count now 1
*Mar 14 01:29:41.458: EIGRP-IPv4(100): reply count is 2
*Mar 14 01:29:41.458: DUAL: AS(100) Clearing handle 0, count now 1
*Mar 14 01:29:41.466: EIGRP-IPv4(100): rcvreply: 192.168.10.0/24 via 10.1.43.3 metric 9216/8960 for tid 0
*Mar 14 01:29:41.466: EIGRP-IPv4(100): reply count is 1
*Mar 14 01:29:41.466: DUAL: AS(100) Clearing handle 2, count now 0
*Mar 14 01:29:41.466: DUAL: AS(100) Freeing reply status table
*Mar 14 01:29:41.466: EIGRP-IPv4(100): Find FS for dest 192.168.10.0/24. FD is 72057594037927935, RD is 72057594037927935 on tid 0found
*Mar 14 01:29:41.466: DUAL: AS(100) Removing dest 192.168.10.0/24, nexthop 10.1.42.2
*Mar 14 01:29:41.466: DUAL: AS(100) RT installed 192.168.10.0/24 via 10.1.41.1
*Mar 14 01:29:41.467: DUAL: AS(100) RT installed 192.168.10.0/24 via 10.1.43.3
*Mar 14 01:29:41.467: DUAL: AS(100) Send update about 192.168.10.0/24. Reason: metric chg on tid 0
*Mar 14 01:29:41.467: DUAL: AS(100) Send update about 192.168.10.0/24. Reason: new if on tid 0

R4(config-if)#do sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 9216
        via 10.1.43.3 (9216/8960), Ethernet0/3
        via 10.1.41.1 (10240/5120), Ethernet0/1

R4(config-if)#do sh ip route eigrp  | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D        10.1.15.0/24 [90/7680] via 10.1.41.1, 00:12:40, Ethernet0/1
D        10.1.25.0/24 [90/32256] via 10.1.43.3, 00:00:30, Ethernet0/3
D        10.1.35.0/24 [90/6656] via 10.1.43.3, 00:12:40, Ethernet0/3
D        10.1.42.0/24 [90/57856] via 10.1.43.3, 00:00:30, Ethernet0/3
D     192.168.10.0/24 [90/9216] via 10.1.43.3, 00:00:30, Ethernet0/3

The most interesting fact from the above output is that the feasible successor not only wasn’t promoted immediately but was not considered at all! reading through the debug output, you notice that it started by looking for a FS, but found none since the lowest distance belonged to a route that is not an FS, the router had to put this destination into active mode and send queries to its neighbor. Once received all queries, it looked at their RDs, calculated its own CDs, put the destination back to passive, updated the FD (now 9216), chose the best route, installed it in the routing table and sent EIGRP update for the new route.

To summarize:

  1. The router installs the best route that meets the FC in the routing table.
  2. If this route is lost, The router will look in the topology table for the next best route. If it meets the FC, it will use it right away.
  3. If it does not meet the FC, this destination will be put in active state.

Myth No. 3: CD and FD are the same

While their values could match, they are simply not the same by definition. You probably noticed that in all of the above show commands, there was at least one entry where the CD matched the FD. Is it always the case? No. It simply means that when this destination transitioned from active to passive and this route via this neighbor was chosen at the end of the DUAL, the router updated the FD to match the CD.

Now, I’m going to increase the delay on Eth 0/2 to 1.1:

R4(config-if)#do sh ip eigrp top all
P 192.168.10.0/24, 1 successors, FD is 7680, serno 78
        via 10.1.42.2 (7936/5120), Ethernet0/2
        via 10.1.41.1 (10240/5120), Ethernet0/1
        via 10.1.43.3 (14080/8960), Ethernet0/3

As shown above, you clearly have three different values for FD, RD and CD. FD did not change simply because this route is still the best route with lowest metric so DUAL was not needed and the destination did not go active, so the FD remained the same.

Some resources wrongly state that a router will advertise its FD to be the RD for a neighbor, in this case that is 7680. This is a gross mistake! the correct statement is that routers advertise their CD for a destination, this value will be considered as RD for a neighbor. Let’s demonstrate this in the lab.

R3 should have two routes to Netx, one directly through R5 and one through R4, lets look at the RD of the route that is going via R4:

R3#sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 8960
        via 10.1.35.5 (8960/2560), Ethernet0/0
        via 10.1.43.4 (33536/7936), Ethernet0/3

As demonstrated clearly above, the RD is 7936 which is the CD of R4 for the destination and NOT the FD (7680) – Another myth busted!

Myth No. 4: Variance is a multiplier of FD

This is another example of the confusion stemming from mixing FD and CD. Many resources incorrectly state that when you use variance command, EIGRP use that value to multiply it by the FD to install additional routes in the routing table to perform unequal cost load balancing.

I’m honestly not quite sure what they mean by that exactly since the purpose of FD is help the router compare it to an RD to confirm if this path is loop free or not. If we are talking about using variance to override the FC, then this is truly against the design of EIGRP and we are basically forcing EIGRP to install a route that is not loop-free guarantee.

We can clear this confusion simply in our topology. I reset all Delay values back to its original values per the diagram. Then, I updated the Delay on R4 as follows: Eth0/1 has delay of 300, Eth0/2 has delay of 200, Eth0/3 has delay of 300.

R4#sh ip route eigrp | be Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
D        10.1.15.0/24 [90/79360] via 10.1.42.2, 00:15:37, Ethernet0/2
                      [90/79360] via 10.1.41.1, 00:15:37, Ethernet0/1
D        10.1.25.0/24 [90/53760] via 10.1.42.2, 00:15:37, Ethernet0/2
D        10.1.35.0/24 [90/79360] via 10.1.42.2, 00:15:37, Ethernet0/2
D     192.168.10.0/24 [90/56320] via 10.1.42.2, 00:15:37, Ethernet0/2

R4#sh ip eigrp top
P 192.168.10.0/24, 1 successors, FD is 7680
        via 10.1.42.2 (56320/5120), Ethernet0/2
        via 10.1.41.1 (81920/5120), Ethernet0/1

R4#sh ip eigrp top all
P 192.168.10.0/24, 1 successors, FD is 7680, serno 172
        via 10.1.42.2 (56320/5120), Ethernet0/2
        via 10.1.41.1 (81920/5120), Ethernet0/1
        via 10.1.43.3 (85760/8960), Ethernet0/3

As shown above, there is one (best) route being installed, that is via R2. The goal here is to install a second route that is via R1. Keep in mind EIGRP will never install a route that does not satisfy FC. So the route via R3 will NEVER be considered no matter what the value of variance is, we can also test that.

So, lets start with the wrong statement that if we need to install the second route, we need to use FD. Basic math (81920/7680=7.3) so this means if we configure a variance of 8, the second route will be installed. Per the math, anything less won’t work.

Now. let’s do the actual correct math here which is CD of the second route divided by the CD of the current installed route (81920/6320=1.45) which means a variance of 2 should do which clearly contradicts the other statement but if it did work, then we confirm that the variance is a multiplier of the CD and NOT FD. Let’s configure the lab now

R4#sh run | sec router eigrp
router eigrp 100
 metric weights 0 0 0 1 0 0
 variance 2
 network 0.0.0.0

R4(config-router)#do sh ip rou eigrp
Gateway of last resort is not set
D     192.168.10.0/24 [90/85760] via 10.1.43.3, 00:00:35, Ethernet0/3
                      [90/56320] via 10.1.42.2, 00:00:35, Ethernet0/2
                      [90/81920] via 10.1.41.1, 00:00:35, Ethernet0/1

As shown above, variance 2 was enough to install the second route.
NOTE: I know you are probably wondering how the route via R3 that did not (and still does not) meet the FC made it to the routing table. I’ve seen this behavior as well when I was doing one of INE labs – I have posted this on Cisco Network Community and as of this writing – there is a long debate on that thread with no final answer. I will update this post once this issue is explained.

UPDATE (3/18/2019): Ok, I finally got what is going on in the above example. It’s most likely a bug, I ran the exact same scenario with a different code and it worked just fine and it helped me to understand what happened above. All routers in this post are running IOS version 15.4(2)T. Let’s have a look:

R4(config-if)#int eth 0/2
R4(config-if)#del 200


*Mar 18 15:03:38.802: EIGRP-IPv4(100): rcvupdate: 192.168.10.0/24 via 1.1.13.3 metric 56320/5120 on tid 0
*Mar 18 15:03:38.802: EIGRP-IPv4(100): Find FS for dest 192.168.10.0/24. FD is 7680, RD is 7680 on tid 0
*Mar 18 15:03:38.802: EIGRP-IPv4(100): 1.1.13.3 metric 56320/5120
*Mar 18 15:03:38.802: EIGRP-IPv4(100): 1.1.13.2 metric 81920/5120
*Mar 18 15:03:38.802: EIGRP-IPv4(100): 1.1.14.4 metric 84736/7936 found Dmin is 56320

P 192.168.10.0/24, 1 successors, FD is 7680, serno 198
via 1.1.13.3 (56320/5120), Ethernet0/2
via 1.1.12.2 (81920/5120), Ethernet0/1
via 1.1.14.4 (85760/8960), Ethernet0/3

R1#sh ip rou eigrp
D     192.168.10.0/24 [90/85760] via 1.1.14.4, 01:21:42, Ethernet0/3
                      [90/56320] via 1.1.13.3, 01:21:42, Ethernet0/2
                      [90/81920] via 1.1.12.2, 01:21:42, Ethernet0/1

Now, using version 15.2(4)S4

R4(config-if)#del 200
R4(config-if)#
*Mar 18 12:40:40.399: EIGRP-IPv4(100): rcvupdate: 192.168.10.0/24 via 10.1.42.2 metric 56320/5120 on tid 0
*Mar 18 12:40:40.399: EIGRP-IPv4(100): Find FS for dest 192.168.10.0/24. FD is 7680, RD is 7680 on tid 0
*Mar 18 12:40:40.399: EIGRP-IPv4(100): 10.1.42.2 metric 56320/5120
*Mar 18 12:40:40.399: EIGRP-IPv4(100): 10.1.41.1 metric 81920/5120
*Mar 18 12:40:40.399: EIGRP-IPv4(100): 10.1.43.3 metric 85760/8960 found Dmin is 56320
*Mar 18 12:40:40.399: DUAL: AS(100) RT installed 192.168.10.0/24 via 10.1.42.2
*Mar 18 12:40:40.399: DUAL: AS(100) Send update about 192.168.10.0/24. Reason: metric chg on tid 0

P 192.168.10.0/24, 1 successors, FD is 56320
via 10.1.42.2 (56320/5120), FastEthernet1/0
via 10.1.41.1 (81920/5120), FastEthernet0/0
via 10.1.43.3 (85760/8960), FastEthernet1/1

D     192.168.10.0/24 [90/85760] via 10.1.43.3, 00:00:08, FastEthernet1/1
                      [90/56320] via 10.1.42.2, 00:00:08, FastEthernet1/0
                      [90/81920] via 10.1.41.1, 00:00:08, FastEthernet0/0

Ignore the different IP addresses of the neighbors in both topologies, everything else is the same. As you can see both debug outputs are identical, they both say the FD was 7680, and the new one should be 56320 given the new metric calculation. The main difference (and here the main issue) is that the first one did not actually update the FD to the new one, but still shows the old one. The second one did. So that explains why variance of 2 caused both routes to be installed because in reality, both second and third route do indeed satisfy the DC 5120 and 8960 are both less than 56320 and NOT 7680.

Myth No. 5: EIGRP Stub vs Queries

This one is actually not much of a myth, but very poorly documented and has very few examples to explain what exactly going on. As you might know, queries can be multicast or unicast. Also documentations state that EIGRP Stub routers don’t get query messages.
So if its a mulitcast, how is a router going to make sure that its query does not reach a Stub router? as it turn out, a router will simply not send queries out the interface that has a Stub router connected on the other end. Makes sense…now what if this is a multi-access medium, like Ethernet? This is where unicast vs multicast comes into play. I will slightly modify the topology so we can better understand this in the lab:

The focus is again on R4. Each router has 192.168.1X.0/24 where X is the Router number.

R4#sh ip rou eigrp | beg Gateway
Gateway of last resort is not set
D     192.168.10.0/24 [90/409600] via 10.1.1.1, 00:24:30, Ethernet0/0
D     192.168.20.0/24 [90/409600] via 10.1.1.2, 00:24:38, Ethernet0/0
D     192.168.30.0/24 [90/409600] via 10.1.1.3, 00:25:11, Ethernet0/0

I have enabled ‘debug eigrp packets reply detail’ and debug eigrp packets query detail’ on all 4 routers, and I’m going to shut down R4’s Loopback that represents 192.168.40.0/24. All 4 routers are on the same Ethernet segment on VLAN10 on the switch.

R4(config-if)#sh
R4(config-if)#
*Mar 14 20:30:52.013: EIGRP: Enqueueing QUERY on Et0/0 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 45-45
*Mar 14 20:30:52.023: EIGRP: Sending QUERY on Et0/0 - paklen 44 tid 0
*Mar 14 20:30:52.023:   AS 100, Flags 0x0:(NULL), Seq 62/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 45-45
*Mar 14 20:30:52.023:   {type = 602, length = 44}
*Mar 14 20:30:52.023:   {vector = {afi = 1, tid = 0}
*Mar 14 20:30:52.023:             {routerid = 10.1.1.4
*Mar 14 20:30:52.023:             {offset = 0, priority = 0, reliability = 204, load = 0,
*Mar 14 20:30:52.023:              mtu = {0:[00, 00, 00]), hopcount = 255,
*Mar 14 20:30:52.023:              delay = 281474976710655, bw = 4294967295,
R4(config-if)#
*Mar 14 20:30:52.023:              reserved = 00, opaque_flags = 04}
*Mar 14 20:30:52.023:             {nh:00000000}
*Mar 14 20:30:52.023:             {18C0A828}
*Mar 14 20:30:52.023:   } route: 192.168.40.0/24 route: 192.168.40.0/24 route: 192.168.40.0/24
R4(config-if)#
*Mar 14 20:30:53.999: %LINK-5-CHANGED: Interface Loopback40, changed state to administratively down
*Mar 14 20:30:55.008: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback40, changed state to down
R4(config-if)#

R1> route: 192.168.40.0/24
*Mar 14 20:30:52.034: EIGRP: Enqueueing REPLY on Et0/1 - paklen 0 nbr 10.1.1.4 tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 37-37
*Mar 14 20:30:52.053: EIGRP: Sending REPLY on Et0/1 - paklen 44 nbr 10.1.1.4 tid 0
*Mar 14 20:30:52.053:   AS 100, Flags 0x0:(NULL), Seq 61/62 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 37-37
*Mar 14 20:30:52.053:   {type = 602, length = 44}
*Mar 14 20:30:52.053:   {vector = {afi = 1, tid = 0}
*Mar 14 20:30:52.053:             {routerid = 10.1.1.4
*Mar 14 20:30:52.053:             {offset = 0, priority = 0, reliability = 255, load = 1,
R1>
*Mar 14 20:30:52.053:              mtu = {1500:[00, 05, DC]), hopcount = 1,
*Mar 14 20:30:52.053:              delay = 281474976710655, bw = 10000,
*Mar 14 20:30:52.053:              reserved = 00, opaque_flags = 00}
*Mar 14 20:30:52.053:             {nh:00000000}
*Mar 14 20:30:52.053:             {18C0A828}
*Mar 14 20:30:52.053:   }

R2> route: 192.168.40.0/24
*Mar 14 20:30:52.034: EIGRP: Enqueueing REPLY on Et0/2 - paklen 0 nbr 10.1.1.4 tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 40-40
*Mar 14 20:30:52.052: EIGRP: Sending REPLY on Et0/2 - paklen 44 nbr 10.1.1.4 tid 0
*Mar 14 20:30:52.052:   AS 100, Flags 0x0:(NULL), Seq 63/62 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 40-40
*Mar 14 20:30:52.052:   {type = 602, length = 44}
*Mar 14 20:30:52.052:   {vector = {afi = 1, tid = 0}
*Mar 14 20:30:52.052:             {routerid = 10.1.1.4
*Mar 14 20:30:52.052:             {offset = 0, priority = 0, reliability = 255, load = 1,
R2>
*Mar 14 20:30:52.052:              mtu = {1500:[00, 05, DC]), hopcount = 1,
*Mar 14 20:30:52.052:              delay = 281474976710655, bw = 10000,
*Mar 14 20:30:52.052:              reserved = 00, opaque_flags = 00}
*Mar 14 20:30:52.052:             {nh:00000000}
*Mar 14 20:30:52.052:             {18C0A828}
*Mar 14 20:30:52.052:   }

R3> route: 192.168.40.0/24
*Mar 14 20:30:52.034: EIGRP: Enqueueing REPLY on Et0/3 - paklen 0 nbr 10.1.1.4 tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 34-34
*Mar 14 20:30:52.054: EIGRP: Sending REPLY on Et0/3 - paklen 44 nbr 10.1.1.4 tid 0
*Mar 14 20:30:52.054:   AS 100, Flags 0x0:(NULL), Seq 58/62 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 34-34
*Mar 14 20:30:52.054:   {type = 602, length = 44}
*Mar 14 20:30:52.054:   {vector = {afi = 1, tid = 0}
*Mar 14 20:30:52.054:             {routerid = 10.1.1.4
*Mar 14 20:30:52.054:             {offset = 0, priority = 0, reliability = 255, load = 1,
R3>
*Mar 14 20:30:52.054:              mtu = {1500:[00, 05, DC]), hopcount = 1,
*Mar 14 20:30:52.054:              delay = 281474976710655, bw = 10000,
*Mar 14 20:30:52.054:              reserved = 00, opaque_flags = 00}
*Mar 14 20:30:52.054:             {nh:00000000}
*Mar 14 20:30:52.054:             {18C0A828}
*Mar 14 20:30:52.054:   }

As shown, R4 queried all of its 3 neighbors.

Next, I’m going to configure R1-3 as Stub routers and repeat the same step above:

R4(config-if)#
*Mar 14 20:36:33.084: %LINK-5-CHANGED: Interface Loopback40, changed state to administratively down
*Mar 14 20:36:34.093: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback40, changed state to down

R1#
R1# route: 192.168.40.0/24

R2#
R2# route: 192.168.40.0/24

R3#
R3# route: 192.168.40.0/24

R4 did not need to query its neighbors for 192.168.40.0 since it knows that they are stub routers. How can we show that R4 knows which router is a stub?

R4#sh ip eigrp neigh det
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
2   10.1.1.1                Et0/0                    13 00:02:57    1   100  0  80
   Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED SUMMARY ) Routes
   Suppressing queries
0   10.1.1.2                Et0/0                    12 00:03:09    6   100  0  77
   Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED SUMMARY ) Routes
   Suppressing queries
1   10.1.1.3                Et0/0                    12 00:03:19    1   100  0  70
   Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED SUMMARY ) Routes
   Suppressing queries
Max Nbrs: 0, Current Nbrs: 0

Notice “Stub Peer Advertising (CONNECTED SUMMARY ) Routes”, but how does it know that? Let’s capture the traffic on R4’s Eth0/0

It’s obvious that each a stub router, will advertise itself as a stub in its Hello packets. Since we have the capture running, lets repeat remote all stub routers config and see how R4 will query for 192.168.40.0/24

Since R4 knows that all neighbors on its shared segment are non-stub routes, it’s efficient to send the query as multicast to 224.0.0.10 so all neighbors can hear that. But what happens if we configure, say R1 as a stub? in this case R4 should not query R4, which means it cannot multicast the query. Let’s configure R1 as a stub, and again shut down the same loopback on R4 while running Wireshark:

R4(config-if)#do sh ip eigrp nei det
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
2   10.1.1.1                Et0/0                    13 00:00:06    8   100  0  13
   Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED SUMMARY ) Routes
   Suppressing queries
1   10.1.1.2                Et0/0                    13 00:09:12    4   100  0  24
   Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
0   10.1.1.3                Et0/0                    13 00:09:12    4   100  0  32
   Version 15.0/2.0, Retrans: 0, Retries: 0, Prefixes: 1
   Topology-ids from peer - 0
Max Nbrs: 0, Current Nbrs: 0

R4 switched to unicast to query both R3 and R2 directly rather than sending a mutlicast query since R1 is a stub router that should not be queried.

Leave a Reply

Top