EIGRP is a routing protocol whose strategy to prevent routing loops is based upon what is known as the EIGRP Feasibility Condition. EIGRP also makes use of another concept called Split Horizon, which we will also briefly touch on later in this article.
To properly discuss the Feasibility Condition however, you must have an understanding of the following EIGRP terms: Successor, Feasible Successor, Reported Distance, and Feasible Distance. You will also want to understand the EIGRP Metric and how it is calculated. Luckily, each of these concepts were covered in other articles.
We will be using this topology to describe the Feasibility Condition and how it works:
In this topology, we have four EIGRP routers. Despite there being many IP networks, the one we will focus on is the 9.9.9.0/29 network connected to R4.
Each link in the topology also displays the EIGRP link cost. We will use these to calculate each Router’s Feasible Distance and Reported Distance. For example:
- R4’s Feasible Distance to 9.9.9.0/29 is 256
- R4’s Reported Distance is 0, since the network is directly connected
- R3’s Feasible Distance to 9.9.9.0/29 is 2816 (2560 + 256)
- R3’s Reported Distance is 256 from the route advertised from R4
If any of these points don’t make sense, review the EIGRP Terminology article which illustrates how Reported Distances and Feasible Distances work.
With that out of the way, let’s discuss one of EIGRP’s most confusing concepts, the Feasibility Condition.
Feasibility Condition
The Feasibility Condition states that a route will not be accepted if the Reported Distance is more than the best path’s Feasible Distance.
Or said another way and from the perspective of the router: a path to a network will not be accepted if my neighbor’s cost is more than my cost.
To illustrate this, we will look at the values for Feasible Distance (FD) and Reported Distance (RD) for R1, R2, and R3 as the advertisements for the 9.9.9.0/29 network propagate throughout the topology.
Denying a Path with a Loop
We will start by tracing the route advertisements for the 9.9.9.0/24 network that R4 generates to R3, and that R3 in turn advertises to R2, which in turn advertises it to R1, then finally back to R3.
Notice R3 will receive two* advertisements: one from R4, and another one from R1 as the route advertisements make their way around and through R2. * Sort of — we will explore this later.
We can plainly see that the advertisement that went from R4 to R3 does not create a loop, while the one that went from R4 to R3 to R2 to R1 then back to R3 does create a loop. EIGRP will also come to the same conclusion by testing the advertisement from R1 against the Feasibility Condition.
As said above, the Feasibility Condition states that a route will not be accepted if the Reported Distance is more than the best path’s Feasible Distance. R3’s best path to 9.9.9.0/29 is through R4, since it has the lowest Feasible Distance of 2816.
The route from R1 contained a Reported Distance of 5888. This value is higher than R3’s best Feasible Distance (2816), therefore, the advertisement from R1 violates the Feasibility Condition and would be ignored by R3.
This is an example of how the EIGRP avoids accepting a path with a loop by using the Feasibility Condition.
Accepting a Loop-Free Path
Next we will take a look at the advertisements received from the perspective of R2:
If we propagate the route advertisements for the 9.9.9.0/29 network throughout the network, R2 will receive two advertisements: one from R4 to R3 to R2, and the other from R4 to R3 to R1 to R2. The preferred path will be the one through R3, since it has a better (lower) Feasible Distance of 4864.
The route from R1 contained a Reported Distance of 4096. This value is lower than R2’s best Feasible Distance from R3 (4864), therefore, the advertisement from R1 will be accepted since it does not violate the Feasibility Condition.
This will allow R2 to keep track of two, perfectly good, loop-free paths to get to 9.9.9.0/29. The path with the lower Feasible Distance will be stored as the Successor route, and will populate the router’s Routing Table. The other path will be stored in the EIGRP Topology Table as a Feasible Successor, and will be ready to replace the Successor instantly should something happen to the link between R2 and R3.
Here we have shown an example of EIGRP accepting a loop-free path which passed the Feasibility Condition.
Feasibility Condition Is Not Perfect
It should be pointed out, however, that the EIGRP Feasibility Condition is not perfect:
- The Feasibility Condition can guarantee that any path with a loop will not be accepted
- The Feasibility Condition cannot guarantee that all loop-free paths will be accepted.
To illustrate this, we will look at same topology as above from the perspective of R1:
R1 receives two advertisements to get to 9.9.9.0/24. One from R4 to R3 to R1, and the other from R4 to R3 to R2 to R1. Neither of these paths contain a loop. And of the two advertisements received, the preferred one will be the one through R3, since it has a better (lower) Feasible Distance of 4096.
The route from R2 contained a Reported Distance of 4864. This value is higher than R1’s best Feasible Distance from R3 (4096), therefore, the advertisement from R2 violates the Feasibility Condition and would be ignored by R1 – despite the path from R1 > R2 > R3 > R4 being loop free.
Because of how varied the EIGRP metric can be, there is no perfect formula that would guarantee denying all looped-paths and accepting all loop-free paths. Between the choices of accidentally denying a loop-free path or accidentally accepting a looped-path, the latter is far more dangerous. As such, EIGRP (correctly) took the more conservative approach, and the Feasibility Condition’s main purpose is to guarantee that a looped-path will not be accepted.
Proving the Behavior of the Feasibility Condition
In order to prove all the results above, this exact topology was set up in a lab. Details on how the path costs were specifically manipulated to the values above will be listed below. But first we will prove the behavior above with show commands on each of the router’s you see above.
Show Output
Below you will find the output of three commands on each router. For brevity, the command outputs have been trimmed to reflect only the 9.9.9.0/29 network:
show ip eigrp topology— show only the paths which pass the Feasibility Conditionshow ip eigrp topology all-links— show all the paths, whether they pass the Feasibility Condition or notshow ip route— show the routes that were added to the router’s Routing Table
R1# show ip eigrp topology
P 9.9.9.0/29, 1 successors, FD is 4096
via 10.1.3.3 (4096/2816), FastEthernet2/0
R1# show ip eigrp topology all-links
P 9.9.9.0/29, 1 successors, FD is 4096, serno 13
via 10.1.3.3 (4096/2816), FastEthernet2/0
via 10.1.2.2 (5888/4864), FastEthernet1/0
R1# show ip route
9.0.0.0/29 is subnetted, 1 subnets
D 9.9.9.0 [90/4096] via 10.1.3.3, 01:53:18, FastEthernet2/0
R2# show ip eigrp topology
P 9.9.9.0/29, 1 successors, FD is 4864
via 10.2.3.3 (4864/2816), FastEthernet0/1
via 10.1.2.1 (5120/4096), FastEthernet1/0
R2# show ip eigrp topology all-links
P 9.9.9.0/29, 1 successors, FD is 4864, serno 15
via 10.2.3.3 (4864/2816), FastEthernet0/1
via 10.1.2.1 (5120/4096), FastEthernet1/0
R2# show ip route
9.0.0.0/29 is subnetted, 1 subnets
D 9.9.9.0 [90/4864] via 10.2.3.3, 01:53:49, FastEthernet0/1
R3# show ip eigrp topology
P 9.9.9.0/29, 1 successors, FD is 2816
via 10.3.4.4 (2816/256), FastEthernet0/0
R3# show ip eigrp topology all-links
P 9.9.9.0/29, 1 successors, FD is 2816, serno 7
via 10.3.4.4 (2816/256), FastEthernet0/0
R3# show ip route
9.0.0.0/29 is subnetted, 1 subnets
D 9.9.9.0 [90/2816] via 10.3.4.4, 01:55:34, FastEthernet0/0
R4# show ip eigrp topology
P 9.9.9.0/29, 1 successors, FD is 256
via Connected, Loopback99
R4# show ip eigrp topology all-links
P 9.9.9.0/29, 1 successors, FD is 256, serno 2
via Connected, Loopback99
R4# show ip route
9.0.0.0/29 is subnetted, 1 subnets
C 9.9.9.0 is directly connected, Loopback99
You can compare the values in the commands above to each iteration of the topology displayed above to find that EIGRP and the Feasibility Condition work exactly as described above. With one exception, that is…
Earlier, we stated R3 would receive two advertisements for the 9.9.9.0/29 network: one from R4, and one from R1. But if you examine the output of the command show ip eigrp topology 9.9.9.0/29 from R3, you’ll notice there is only one route which was learned.
For the purpose of showing how the Feasibility Condition would prevent a looped-path from being accepted, we claimed that R1 would advertise the 9.9.9.0/29 network back to R3. But in reality, R1 would not advertise this route due another loop prevention mechanism built into EIGRP. That loop prevention mechanism is known as Split Horizon.
Split Horizon
The Split Horizon rule states that a route will not be advertised out an interface that a better route to the same destination was received.
For example: R1 receives an advertisement from R2, but R1 also receives an advertisement from R3. Upon realizing R3’s path to get to 9.9.9.0/29 is better than the path R1 could provide, R1 stops advertising the path out the interface facing R3.
So in reality, the route from R1 will not be accepted by R3 due to Split Horizon, not due to the Feasibility Condition. Or to be more accurate, R1 will not advertise the path to R3 because R1 received a better path from R3 about the same network.
Manipulating Costs
To attain the simpler cost values, we modified the default EIGRP Metric formula to only include the interface Delay by setting each K-value to 0, except for K3:
This created a setup where the cost was simply an additive value from hop to hop, then multiplied by 256. Then the delay values were manually set for each interface:
R3# show cdp neighbors Device ID Local Intrfce Holdtme Capability Platform Port ID R4 Fas 0/0 178 R S I 3725 Fas 0/0 R2 Fas 0/1 141 R S I 3725 Fas 0/1 R1 Fas 2/0 171 R S I 3725 Fas 2/0
R3# show run | i ^interface|delay interface FastEthernet0/0 delay 10 interface FastEthernet0/1 delay 8 interface FastEthernet2/0 delay 5
These delay values are then simply multiplied by 256 to get each link’s delay to match the topology.
The purpose of showing you how the costs were manipulated to prove the functionality of the EIGRP Feasibility Condition is to arm you with the know-how so you rebuild the topology above and prove to yourself how it works. The goal is not for you to simply read and learn, but hopefully read, learn, and apply.
What other topologies can you design that show case your mastery of the Feasibility Condition? Upload a picture and add a link to the comments section below!
Line 15 “R4’s Reported Distance is 256 from the route advertised from R4” mistake R3’s not R4’s
Oops, good catch. Fixed it. Thanks, Shami.
Very good article. It helped me a lot. Thanks
One of the best article I have seen yet, that’s really going to help me pass the ICND2 and finally get the CCNA R&S!
Thank-you
You’re welcome!
Great article! Just came from some Cisco training and this seemed to explain this a bit more clearly.
Glad this helped, Cam =). All of my CCNA content is posted here: https://www.practicalnetworking.net/index/ccna/
it should be ” better than a path R2..” in the split horizon section