Testing the EIGRP Feasibility Condition (FC)

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 network in two different places. The second instance of 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 in the EIGRP topology.

Screen Shot 2016-07-04 at 9.45.49 PM

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
P, 1 successors, FD is 130816
        via (130816/128256), GigabitEthernet3 

//all-links parameter shows
//routes whether or not 
//the fc is met

csr1000v-1#show ip eigrp topology all-links | begin
P, 1 successors, FD is 130816, serno 80
        via (130816/128256), GigabitEthernet3
        via (131072/130816), GigabitEthernet2


Based on the output above, we can see that the FD to is 130816. This is the EIGRP metric to access that network through In the output of “show ip eigrp topology” we can see that the route through 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 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 (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
P, 1 successors, FD is 131072
        via (131072/128256), GigabitEthernet3
        via (131328/130816), GigabitEthernet2

csr1000v-1#show ip eigrp topology all-links | begin
P, 1 successors, FD is 131072, serno 106
        via (131072/128256), GigabitEthernet3
        via (131328/130816), GigabitEthernet2

Now we can see that both routes show whether or not the “all-links” parameter is used. Since the route through 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
EIGRP Packet debugging is on
csr1000v-1(config-if)#interface Gigabitethernet 3
csr1000v-1(config-if)#ip access-group 101 in
*Jul  5 21:30:01.430: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor (GigabitEthernet3) is down: holding time expired

As seen here, no query is issued. However, the successor (next hop) is now the neighbor at and the new route is installed in the route table.

csr1000v-1(config-if)#do show ip eigrp topology | begin
P, 1 successors, FD is 131072
        via (131328/130816), GigabitEthernet2

csr1000v-1(config-if)#do show ip route
Routing entry for
  Known via "eigrp 1", distance 90, metric 131328, type internal
  Redistributing via eigrp 1
  Last update from on GigabitEthernet2, 00:01:52 ago
  Routing Descriptor Blocks:
  *, from, 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.


No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.