Last night I was going through some CCIE Routing and Switching VOD’s and found a statement I found interesting. Beyond the fact that I thought the content was far below the expert level (which is fine because a refresher or level-set is typically helpful), I believed it to be incorrect. The statement that was made is as follows:
“A neighbor meets the feasibility condition if the reported distance by the neighbor is the same as or smaller than the feasible distance of the router”
So what are my issues with this statement? First, I thought “feasible distance of the router” is ambiguous and could be assumed to be the advertised distance or the reported distance which is basically the feasible distance of the neighboring router. However, that was not my main problem with the statement. My main concern with this statement is that I have always learned that the feasibility condition is only met if the reported distance (RD) is strictly less than the feasible distance of the local route. So I set out to determine if I had a correct understanding or if the Feasibility Condition (FC) could really be met with a RD equal to the FD.
To test my theory, I built out a simple topology with a 126.96.36.199/24 network in two different places. The second instance of 188.8.131.52/24 is one more hop away and should work out perfectly to demonstrate this from the perspective of csr1000v-1. This should create an RD through csr1000v-2 that is equal to the local FD of csr1000v-1 for the network represented on the L1 interfaces. I also simplified the topology by removing the link between the two intermediary routers and only included transit links and the 184.108.40.206/24 in the EIGRP topology.
EIGRP Topology from csr1000v-1
//show ip eigrp topology //omits eigrp routes that //do not meet the fc csr1000v-1#show ip eigrp topology | begin 220.127.116.11 P 18.104.22.168/24, 1 successors, FD is 130816 via 10.0.0.10 (130816/128256), GigabitEthernet3 //all-links parameter shows //routes whether or not //the fc is met csr1000v-1#show ip eigrp topology all-links | begin 22.214.171.124 P 126.96.36.199/24, 1 successors, FD is 130816, serno 80 via 10.0.0.10 (130816/128256), GigabitEthernet3 via 10.0.0.6 (131072/130816), GigabitEthernet2 csr1000v-1#
Based on the output above, we can see that the FD to 188.8.131.52/24 is 130816. This is the EIGRP metric to access that network through 10.0.0.10. In the output of “show ip eigrp topology” we can see that the route through 10.0.0.6 is not shown. We could correctly presume that it is because the feasibility condition is not met. Contrasted with the output of the second show command, both routes are listed when “all-links” keyword is used. It is also apparent that the RD from 10.0.0.6 is 130816 (equal to the local FD).
So at this point the different outputs from the show commands would seem to indicate that the RD must be less than the FD in order for the Feasibility Condition to be met. There’s one more test that we can do. When a route is lost and no Feasible Successor (neighbor meeting the Feasibility Condition for the route) exists, an EIGRP Query should be issued. This can be easily tested.
//set a debug for query packets csr1000v-1#debug eigrp packet query //break the neighbor relationship ship to csr1000v-3 csr1000v-1(config)#access-list 101 deny eigrp any any csr1000v-1(config)#access-list 101 permit ip any any csr1000v-1(config)#interface Gigabit 3 csr1000v-1(config-if)#ip access-group 101 in
Now the output can be observed
*Jul 5 20:50:07.897: %SYS-5-CONFIG_I: Configured from console by console *Jul 5 20:50:14.636: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.0.10 (GigabitEthernet3) is down: holding time expired *Jul 5 20:50:14.647: EIGRP: Enqueueing QUERY on Gi2 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 82-82 *Jul 5 20:50:14.648: EIGRP: Sending QUERY on Gi2 - paklen 44 tid 0 *Jul 5 20:50:14.648: AS 1, Flags 0x0:(NULL), Seq 99/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 82-82
As seen above, a query is definitely sent to the EIGRP neighbor on Gi2. So this behavior is consistent with the remaining route through Gi2 not meeting the Feasibility Condition. Based on all of these behaviors, I now know that my original thought was correct and that the VOD was simply incorrect (I was right and they were wrong–nananana).
We can compare this behavior to that when a Feasible Successor exists. In order to do that, I will remove the access-list from the interface, adjust the delay values, and clear the neighbors (simply to make sure we get a local FD based on the current configuration).
csr1000v-1(config)#interface Gigabit 2 csr1000v-1(config-if)#delay 2 csr1000v-1(config-if)#interface Gigabit 3 csr1000v-1(config-if)#no ip access-group in csr1000v-1(config-if)#delay 2 csr1000v-1(config-if)#do clear ip eigrp neighbors
Now let’s execute the same show commands that were issued previously.
csr1000v-1#show ip eigrp topology | begin 184.108.40.206 P 220.127.116.11/24, 1 successors, FD is 131072 via 10.0.0.10 (131072/128256), GigabitEthernet3 via 10.0.0.6 (131328/130816), GigabitEthernet2 csr1000v-1#show ip eigrp topology all-links | begin 18.104.22.168 P 22.214.171.124/24, 1 successors, FD is 131072, serno 106 via 10.0.0.10 (131072/128256), GigabitEthernet3 via 10.0.0.6 (131328/130816), GigabitEthernet2
Now we can see that both routes show whether or not the “all-links” parameter is used. Since the route through 10.0.0.10 shows without “all-links”, it is feasible. To further the point, it is also possible to see if a query is sent when the best path (through Gi3) is broken.
csr1000v-1(config-if)#do debug eigrp packet query (QUERY) EIGRP Packet debugging is on csr1000v-1(config-if)#interface Gigabitethernet 3 csr1000v-1(config-if)#ip access-group 101 in csr1000v-1(config-if)# *Jul 5 21:30:01.430: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.0.10 (GigabitEthernet3) is down: holding time expired csr1000v-1(config-if)#
As seen here, no query is issued. However, the successor (next hop) is now the neighbor at 10.0.0.6 and the new route is installed in the route table.
csr1000v-1(config-if)#do show ip eigrp topology | begin 126.96.36.199 P 188.8.131.52/24, 1 successors, FD is 131072 via 10.0.0.6 (131328/130816), GigabitEthernet2 csr1000v-1(config-if)#do show ip route 184.108.40.206 Routing entry for 220.127.116.11/24 Known via "eigrp 1", distance 90, metric 131328, type internal Redistributing via eigrp 1 Last update from 10.0.0.6 on GigabitEthernet2, 00:01:52 ago Routing Descriptor Blocks: * 10.0.0.6, from 10.0.0.6, 00:01:52 ago, via GigabitEthernet2 Route metric is 131328, traffic share count is 1 Total delay is 5030 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2
Part of the learning process is questioning your training material. This stuff should be error free, but that isn’t always the case. Although it is important that you don’t find yourself learning the wrong thing, it is also important to solidify the topics by testing yourself in the lab. My recommendation is to spend as much time as possible in the equipment. It is much more valuable than memorization (which you will forget the day after taking the test anyway).
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.