EIGRP Feasible Successor Routes
By stretch | Monday, August 9, 2010 at 2:48 a.m. UTC
EIGRP routers know only of routes advertised by directly adjacent neighbors because EIGRP is a distance vector routing protocol. When a destination network is removed from the EIGRP topology, a router initiates a route querying process in an attempt to locate a different route to that destination. As it is preferable to avoid this querying process, EIGRP routers will opportunistically store backup routes, known as feasible successors, when certain requirements are met.
To understand the concept of a feasible successor route, we must first understand what a successor is. The term successor can be defined as "one thing that succeeds another." In IP routing, this simply refers to the next-hop of the best route. A feasible successor, therefore, is not our current best route, but one which could be used in the event our successor route disappears.
An EIGRP router advertises each destination it can reach as a route with an attached metric. This metric is called the route's reported distance (the term advertised distance has also been used in older documentation). A successor route for any given destination is chosen as having the lowest computed feasible distance; that is, the lowest sum of reported distance plus the cost to get to the advertising router.
By default, an EIGRP router will store only the route with the best (lowest) feasible distance in the routing table (or, multiple routes with equivalent feasible distances). However, under certain conditions, EIGRP will also maintain less-than-optimal routes in its topology table. These feasible successor routes are not used in the forwarding of traffic, but can be injected into the routing table immediately in place of a failed successor route, to avoid the querying process mentioned earlier.
A route is entered into the EIGRP topology table as a feasible successor only if it meets the feasibility condition, which asserts that the reported distance of a route must be lower than the feasible distance of the current successor route. To better illustrate this concept, consider the following scenario.
A simplified metric for each link is shown in red. R5 advertises a route for 192.168.5.0/24 to R3 and to R4 with a reported distance of 512. R4's feasible distance to 192.168.5.0/24 is calculated as 1792: R5's reported distance of 512, plus R4's cost of 1280 to get to R5.
R4# show ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(126.96.36.199) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.0.12.0/24, 1 successors, FD is 6400 via 10.0.34.3 (6400/3840), Serial1/0 P 10.0.13.0/24, 1 successors, FD is 5120 via 10.0.34.3 (5120/2560), Serial1/0 P 10.0.23.0/24, 1 successors, FD is 5120 via 10.0.34.3 (5120/2560), Serial1/0 P 10.0.45.0/24, 1 successors, FD is 1280 via Connected, Serial1/1 P 10.0.34.0/24, 1 successors, FD is 2560 via Connected, Serial1/0 P 10.0.35.0/24, 1 successors, FD is 3840 via 10.0.45.5 (3840/2560), Serial1/1 via 10.0.34.3 (5120/2560), Serial1/0 P 192.168.5.0/24, 1 successors, FD is 1792 via 10.0.45.5 (1792/512), Serial1/1
If we inspect the EIGRP topology table on R3, we see that it has two paths to reach 192.168.5.0/24:
R3# show ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(188.8.131.52) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.0.12.0/24, 2 successors, FD is 3840 via 10.0.13.1 (3840/1280), Serial1/0 via 10.0.23.2 (3840/1280), Serial1/1 P 10.0.13.0/24, 1 successors, FD is 2560 via Connected, Serial1/0 P 10.0.23.0/24, 1 successors, FD is 2560 via Connected, Serial1/1 P 10.0.45.0/24, 2 successors, FD is 3840 via 10.0.34.4 (3840/1280), Serial1/2 via 10.0.35.5 (3840/1280), Serial1/3 P 10.0.34.0/24, 1 successors, FD is 2560 via Connected, Serial1/2 P 10.0.35.0/24, 1 successors, FD is 2560 via Connected, Serial1/3 P 192.168.5.0/24, 1 successors, FD is 3072 via 10.0.35.5 (3072/512), Serial1/3 via 10.0.34.4 (4352/1792), Serial1/2
We can tell from this output that there is only one successor route, through R5 (with a feasible distance of 3072), but the secondary route through R4 is being held as a feasible successor. The route through R5 meets the feasibility requirement because its reported distance of 1792 is lower than the successor route's feasible distance of 3072.
As noted earlier, feasible successor routes are not used to forward traffic. Only successor routes are placed into the routing table:
R3# show ip route 192.168.5.0 Routing entry for 192.168.5.0/24 Known via "eigrp 1", distance 90, metric 3072, type internal Redistributing via eigrp 1 Last update from 10.0.35.5 on Serial1/3, 00:28:32 ago Routing Descriptor Blocks: * 10.0.35.5, from 10.0.35.5, 00:28:32 ago, via Serial1/3 Route metric is 3072, traffic share count is 1 Total delay is 120 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
To illustrate how the feasibility condition protects against routing loops, suppose the following topology wherein R4 has been removed for simplicity. R5 advertises 192.168.5.0/24 to R3, which in turn advertises it to R1, which finally relays the route to R2. Some instability in the network has temporarily disrupted the adjacency between R2 and R3, so R2 only learns of this route from R1. Once the adjacency is restored, R2 advertises the route for 192.168.5.0/24 to R3 until the network fully converges.
If R3 accepted this advertisement and installed the route for 192.168.5.0/24 through R2 as a feasible successor, a routing loop would occur if the successor route became invalid. The feasibility requirement prevents the route from becoming a feasible successor: the route's reported distance of 6912 is higher than R3's feasible distance of 3072.
Finally, the command
show ip eigrp topology all-links can be used to show the entire topology table including successor, feasible successor, and non-successor routes. The output below was taken from R4 in the original example topology. Non-successor routes have been highlighted.
R4# show ip eigrp topology all-links IP-EIGRP Topology Table for AS(1)/ID(184.108.40.206) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.0.12.0/24, 1 successors, FD is 6400, serno 95 via 10.0.34.3 (6400/3840), Serial1/0 via 10.0.45.5 (7680/6400), Serial1/1 P 10.0.13.0/24, 1 successors, FD is 5120, serno 91 via 10.0.34.3 (5120/2560), Serial1/0 via 10.0.45.5 (6400/5120), Serial1/1 P 10.0.23.0/24, 1 successors, FD is 5120, serno 94 via 10.0.34.3 (5120/2560), Serial1/0 via 10.0.45.5 (6400/5120), Serial1/1 P 10.0.45.0/24, 1 successors, FD is 1280, serno 90 via Connected, Serial1/1 P 10.0.34.0/24, 1 successors, FD is 2560, serno 89 via Connected, Serial1/0 P 10.0.35.0/24, 1 successors, FD is 3840, serno 96 via 10.0.45.5 (3840/2560), Serial1/1 via 10.0.34.3 (5120/2560), Serial1/0 P 192.168.5.0/24, 1 successors, FD is 1792, serno 97 via 10.0.45.5 (1792/512), Serial1/1 via 10.0.34.3 (5632/3072), Serial1/0
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Routing
August 9, 2010 at 8:59 a.m. UTC
isn't it a little misspeling here "We can tell from this output that there is only one successor route, through R5 (with a feasible distance of 3072), but the secondary route through R5 is being held as a feasible successor."
i think it should be "We can tell from this output that there is only one successor route, through R5 (with a feasible distance of 3072), but the secondary route through R4 is being held as a feasible successor."
Correct me if I'm wrong.
August 9, 2010 at 2:00 p.m. UTC
Really good article Stretch...:)
August 9, 2010 at 2:36 p.m. UTC
@wredniak: Yep, fixed the typo. Thanks!
August 9, 2010 at 6:22 p.m. UTC
the term "Reported Distance" is addition to my knowledge and author did a great job in here to explain this topic.
August 9, 2010 at 8:44 p.m. UTC
Great article. I think I've spotted a little typo in the second sentence of the third last paragraph. "which finally relays the route to R1." should read "which finally relays the route to R2."
August 10, 2010 at 3:37 p.m. UTC
Thanks, stretch - great article. I finally inderstand the way it chooses some feasible routes and not others... Helped a lot...
August 12, 2010 at 1:13 p.m. UTC
Thanks for your article strech. I am currently preparing for the CCNP ROUTE and your articles help me to grasp the material even more.
September 6, 2010 at 6:04 p.m. UTC
Wat a article! Thanks author for keeping it so simple and easy to understand...
any thing on OSPF?
January 6, 2011 at 9:44 a.m. UTC
Its realy nice explanation, thanks
April 15, 2011 at 10:13 p.m. UTC
May 29, 2011 at 12:19 p.m. UTC
July 7, 2011 at 4:18 p.m. UTC
It's very nice and clear.
October 5, 2011 at 2:46 p.m. UTC
It would be great of you can answer to my question,
As you said Feasible Distance (FD) is Reported Distance(RD) value received from neighbor + cost to get to the advertising router. Which cost are you talking about, is it the end to end cost or just cost to get to the advertising neighbor?
How cost to advertising neighbor is calculated?
Also if a topology looks like three routers R1,R2,R3 connected to each other via serial links. On R3 and Fast Ethernet interface with an ip address 192.168.2.0/24 is advertised through EIGRP network command.
In my calculation for FD on Router 2: i.e FD = RD received from R3 + Cost to R3
From below sample o/p my Que is:
If the RD received from R3 is 28160 how Feasible Distance (FD) is being calculated as on R2.
On R2 = [(10,000,000 / Bandwidth) + ((sum of delays) /10)] * 256
On R2 = ((10,000,000/ 1544) + ((20000 + 100) /10)) *256
On R2 = ((6476 + 2010) * 256)
On R2 = (8486 * 256)
On R2 = 2172416
According to your statement and my calculation WHY I AM NOT ADDING THE RD VALUE TO GET THE FD.
The following is the O/P on the following routers:
R2#show ip eigrp topology 192.168.2.0 EIGRP-IPv4 Topology Entry for AS(1)/ID(172.17.0.1) for 192.168.2.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2172416 Descriptor Blocks: 220.127.116.11 (Serial1/1), from 18.104.22.168, Send flag is 0x0 Composite metric is (2172416/28160), route is Internal Vector metric: Minimum bandwidth is 1544 Kbit Total delay is 20100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 Originating router is 172.18.0.1 ----------------------------------------------------------------- R1#show ip eigrp topology 192.168.2.0 EIGRP-IPv4 Topology Entry for AS(1)/ID(172.16.0.1) for 192.168.2.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2684416 Descriptor Blocks: 10.0.0.2 (Serial1/0), from 10.0.0.2, Send flag is 0x0 Composite metric is (2684416/2172416), route is Internal Vector metric: Minimum bandwidth is 1544 Kbit Total delay is 40100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 Originating router is 172.18.0.1
October 26, 2011 at 8:03 a.m. UTC
great explanation! it helped a lot.
February 26, 2012 at 6:18 p.m. UTC
I have a question!!!
is there any command in GNS in which I could see feasible successor ?! I already tried " show ip eigrp topology " & " show ip eigrp topology detail-links ". but they only show FD.
I will be thankful if you answer me!
May 10, 2012 at 1:37 p.m. UTC
After reading few sites, I really couldn't understand how this works, but your explanation was spot on. Good work
August 4, 2012 at 7:48 a.m. UTC
'show ip eigrp topology' is the right command to see whether you have Feasible Successor for a particular route. You may want to refer to this post that has example scenario in addition to other materials: http://www.netxplane.com/2012/07/the-strength-of-eigrp-part-i.html
October 16, 2012 at 7:45 a.m. UTC
Great work. Studying EIGRP and this was stopping me in my tracks as I couldn't get my head around the feasible distance vs reported distance until now that is.
Saved for future ref.
November 8, 2012 at 3:14 a.m. UTC
Thanks for your posting. your explanation is very simple and understandable.
January 8, 2013 at 4:44 a.m. UTC
Great article. It was easy and fun learning from this site. For sure I will come back for more.
March 7, 2013 at 5:50 a.m. UTC
There is an another typo.
The feasible successor route is through R4 not R5.
The below sentence needs R5 changed to R4
"The route through R5 meets the feasibility requirement because its reported distance of 1792 is lower than the successor route's feasible distance of 3072."
March 15, 2013 at 10:10 a.m. UTC
Mistake in the para ..
where it says "The route through R5 meets the feasibility requirement because its reported distance of 1792 is lower than the successor route's feasible distance of 3072" .. it should be R4 not R5 .
March 23, 2013 at 5:12 p.m. UTC
Great article, Stretch. I'm currently in the CCNA course and was having some confusion on this topic. My professor sent out a link to this article to help clear some things up, which it did very well.
March 29, 2013 at 5:17 a.m. UTC
very well illustrated!! Ur blog is very useful.
April 24, 2013 at 12:38 p.m. UTC
Excellent example and very well done, i did spent time a lot on internet but by far this is the best example and explanation i found so far. keep up the good work
July 1, 2013 at 10:15 p.m. UTC
Great article to explain the nuances - thanks.
I'd like to put something out here about the different outputs.
sh ip eigrp top = Topology output of all prefixes, where they are successors or feasible successors.
sh ip eigrp top 192.168.0.0/16 = Topology output of this prefix of successors, feasible successors AND non-feasible successors. (similar to sh ip eigrp top all-links/detail-links but only for the specific prefix entered).
With the command above, I have always assumed only showed you a specific output of the top. table for the prefix that were successor or feasible successors, but I now believe it also shows non-FS's. Also the output of the above command does not show you these paths in any order... apart from the successor route being first. I have an example with there is 1 S, 1 FS and about 4 non-FS (these did not meet the feasibility condition). However the 1 FS in the sh ip eigrp top output was the last to be listed - below the S and the 4 non-FS...
Has anyone else found this?
September 2, 2013 at 12:55 p.m. UTC
This is very helpful !! Excellent post with easy example.. Thanks a ton !
January 12, 2014 at 10:41 p.m. UTC
Thank you, it really helped A LOT.
May 21, 2014 at 9:19 p.m. UTC
May 30, 2014 at 1:29 a.m. UTC
Thanks. Very thorough
June 6, 2014 at 11:10 a.m. UTC
I hate Jeremy Stretch as his post shows that he has too much more knowledge than me. :-)
August 16, 2014 at 7:15 p.m. UTC
great tuto man. i like the first diagram that explains AD vs FD very well.
October 17, 2014 at 5:06 a.m. UTC
Thanks a lot Jeremy, wish for you all the best
January 8, 2015 at 11:09 p.m. UTC
Very cool and really useful explanation. Lots of kudos.
March 3, 2015 at 5:55 p.m. UTC
Thanks for this. First really good explanation I've found of how the feasibility condition in EIGRP actually prevents routing loops. Much of the material out there simply states "eigrp uses the feasibility condition to prevent routing loops" and leaves it at that.
June 30, 2015 at 10:08 a.m. UTC
thanks , it helps me a lot .
July 11, 2015 at 10:43 p.m. UTC
IoI you are a crack, best article, great explanation
October 24, 2015 at 8:07 a.m. UTC
Really nice, thank you
October 29, 2015 at 1:41 a.m. UTC
The way you put it is really good. I have read it many times and I couldn't see that the main reason of this obvious rule is avoiding routing loops. If you read it without considering that it seems trivial.
November 3, 2015 at 9:22 p.m. UTC
Very clearly explained. Well done.
March 16, 2016 at 3:45 a.m. UTC
May 12, 2016 at 11:54 p.m. UTC
Great post! This article along with the one linked below one helped me completely understand EIGRP's metric and loop prevention mechanisms. Thanks Stretch!
May 19, 2016 at 4:40 p.m. UTC
Very well written description of EIGRP successor and feasible successor. Thank you
June 17, 2016 at 9:56 p.m. UTC
I have a strange issue where i am redistributing a BGP route into EIGRP(with a prefix list). EIGRP is designating the FS as the same router that originally received the redistrubuted BGP route. This BGP route goes up and down all the time as it's a mobile (transit) device, so when the BGP route is removed, the FS kicks in and creates a loop around to itself as the source of the route. It isn't affecting any traffic because when the device is on the BGP route is preferred and when the device is off, nothing needs to route to it. Just curious if you have seen this before.