cancel
Showing results for
Did you mean:
cancel
10381
Views
80
14
Replies
Beginner

## EIGRP , successor and feasible successor

what happen in EIGRP if a successor fails and a Feasible successor is not present ?

i mean if ther'es  route in the topology table but the route for the destination is not a Feasible Successor.

does the router discard che packet or use the route without the feasibility condition ?

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Cisco Employee

Hi Joseph,

You are welcome!

`why when the link R1-R3 was active the link R2-R3 did not met the FC ?`

This question goes back to the definition of the Feasible Distance. The Feasible Distance is a record of the lowest distance towards a particular destination since the last time the destination went from Active to Passive state. The Feasible Distance is therefore not necessarily the current distance, rather, it is a historical minimum of the distance (with the history starting anew with the Active->Passive transition). The Feasible Distance can be reset and newly initialized in the moment of Active->Passive transition (meaning it can also increase during this transition) but otherwise, during a stable Passive state, the Feasible Distance can only decrease.

If we understand the Feasible Distance as the minimal historical distance to a destination then the Feasibility Condition that says: RD < FD can be put into words as follows:

Any neighbor who is closer to the destination than we have ever been is not on a routing loop.

Assuming that in your network, R2 was not considered a feasible successor to 192.168.1.0/24, this tells us that the R2 is not closer to the destination than we have ever been. Why would that be? Well, we can always construct a network in which the link metrics are chosen so that while R2 is not going to route packets back to R1, it won't pass the FC check, like here:

R1's FD to the destination LAN behind R3 is 16, following the shortest path R1-R3. R2's distance to the same LAN is 18. Notice that R2 is certainly not using the path via R1 - that path would be much longer (20+15+1=36). However, at this point, R2 does not meet the FC check from R1's viewpoint. R1's FD is 16, R2's reported distance is 18, so R1 can not be sure if R2 is or is not using R1 to reach the destination. This is the exact situation where the FC check is actually more strict than necessary but it is better to be too cautious against routing loops than to be too trusting.

So in this network, R1 does not consider R2 to be a feasible successor because it is not closer to the destination than R1 has ever been (the RD of R2, 18, is more than the FD of R1, 16).

When the link from R1 to R3 fails, R1 loses its successor, and because the next router, in this case R2, provides the next least cost path but does not meet the FC check, R1 will put the network into active state and start sending Queries. These Queries simply contain the current increased distance of R1 to the destination (in this case, infinity because the path has been totally lost). Basically, R1 is informing its neighbors that its own distance has increased, and expects the neighbors to reevaluate their own choices of successors (subject to their own FDs and FC checks). If R1's increased distance does not influence the neighbor's selection of successor, it simply sends a Reply with the current distance. If, however, R1 has been a successor for some neighbor up to the moment of the distance increase and now, because of the increased distance, R1 does not meet the FC check from that neighbor's viewpoint anymore, that neighbor has just lost a successor and must deal with it exactly in the way I've explained in my first reply. It is possible that this neighbor will also have to put the destination into Active state and start sending Queries itself. This is what is called a Diffusing Computation in EIGRP.

In this network, after the R1-R3 link is torn down, R1 will indeed send a Query to R2, indicating its current infinite distance to the LAN. However, R2 does not currently consider R1 a successor - it is using R3 as its successor. So, for R2, the increased distance of R1 to the destination is irrelevant as it does not influence its own choice of successor. Here, R2 merely sends back a Reply immediately, indicating its current distance to R1, saying that the distance stays at 18 despite R1's increase of distance. Because R2 is R1's only neighbor, this Reply is the last expected Reply, after which R1 can put the route back into Passive state and reset the FD to the newly found shortest path metric, in this case, the route through R2, with the metric being 20+17+1=38.

This is why the Active->Passive transition allows you to reset and reinitialize, even increase the FD - because as a result of sending Queries, you have forced your neighbors to reevaluate their own choice of successors. If a neighbor sends you a Reply, you can be sure that it has taken your new increased distance into account and has modified its routing table accordingly - in any case, in such a way there is no routing loop, subject to that neighbor's own FD and its own FC check. Therefore, now you simply choose the least cost path and set the FD to its cost.

Note that the situation will be different if we change the metrics like this:

The R1's FD to the LAN is still 16. However, R2's reported distance is 11, so here, it meets the FC check even though it is not considered to be a successor by R1 because the total path through it would be 31. It it still a feasible successor, though.

Here, if the link between R1 and R3 is torn down, R1 will find in its topology table that R2 provides the next least cost path and it is a feasible successor as well. So here, the route will never enter the Active state - it will remain Passive, just the successor will be changed to R2 and the current distance on R1 will increase to 31. Notice, however, that because we have not gone through the Active state (we did not need to), the FD at R1 will not change and will remain on the previous value of 16!

This example shows the true behavior of FD. It is a record of the minimum distance to the destination since the last time it entered the Passive state, and is used for FC checks only. It does not necessarily represent the current distance, contrary to the popular - and incorrect - belief.

Now let's modify this network a little more:

R1's shortest path to the destination LAN is via R3, with the FD being set to 16. R2's shortest path is via R3 and its distance is 11, therefore, R2 is a feasible successor. R4's shortest path is via R3 as well, and its distance is 18, but because 18 is more than R1's FD of 16, R4 is not considered a feasible successor.

Note, however, that while R2 is a feasible successor here, the route from R1 through R2 to the destination would have the metric of 31, while the route through R4 - even though R4 is not considered a feasible successor - would have the metric of 23. Quite a difference, isn't it? Now, if R1-R3 link fails, what should R1 do?

If it decides to go with R2 as the feasible successor, it will surely be using a loop free path but at the same time, that path won't be the shortest one that is available. The path through R4 at this point seems to be shorter but because R4 fails the FC check, R1 is not sure - is R4 actually using R1 as its next hop, or is it using a different router? That is why R1 has to make sure.

So in this network, if R1-R3 link fails, R1 will find out that the router providing the next least cost path is R4, not R2, and that the R4 does not meet the FC check. So R1 will again go Active and start sending out Queries, indicating its current (infinite) distance to the LAN network. Both R2 and R4 will receive this Query, and because neither of them is using R1 as its next hop, the increased distance on R1 is irrelevant to them, so they immediately send a Reply with their current metrics: R2 replies with 11 and R4 replies with 18. When R1 receives both Reply messages, it goes back to Passive state, resets the FD and chooses the neighbor that provides the least cost path - in this case, R4. The current metric will be set to 23 including the FD, as the FD has been reset. Note that R2 was and has remained a feasible successor all the time - it has never been promoted to successor role.

Quite a lengthy explanation, I admit - but these are not intuitive facts so it takes a little to digest them.

Best regards,
Peter

14 REPLIES 14
Hall of Fame Cisco Employee

Hello Joseph,

`what happen in EIGRP if a successor fails`

To set up a ground for our further discussion, note that a network may have several successors (i.e. routers that both pass the Feasibility Condition check and all provide the same least cost path) and several feasible successors (i.e. routers that pass the Feasibility Condition check but do not provide the least cost path). There may also be neighbors that advertise the destination network but which do not pass the Feasibility Condition check.

Now, what really happens in EIGRP if the successor fails? The router will first check its topology table to search for a neighbor that  provides the next least cost path towards the destination. At this point, we are not yet verifying the Feasibility Condition, we are just looking if we can find a known neighbor that also advertises this network. If there are more such neighbors, we choose the one through which the total distance is the lowest available.

If such neighbor X can not be found at all, EIGRP will put the network into the Active state and start sending out Queries, asking its neighbors to help it find a new path towards the destination. At this point, the routing table has not changed at all - it still points towards the failed successor. This will cause all packets going to the destination network to get lost, but it is better to lose packets than to create a routing loop by making hasty decisions. Buffering the packets is not an option - the flow may be so huge that any reasonably sized buffers would be filled in milliseconds. Only after all Replies have been received, the router may make a new decision about the newly found successor, and modify its routing table.

If such neighbor X is found, we now check whether it passes the Feasibility Condition check. If it passes it, all is good - it is indeed a feasible successor who provides the next shortest path towards the destination, so we simply promote it to the new successor and update our routing table. This change occurs very rapidly.

There is one possibility left - the neighbor X is found, i.e. we know about a neighbor who can provide the next least cost path to the destination - but it does not pass the Feasibility Condition check. In this case, we can not promote it to the new successor because we have no guarantee it won't pass the packets back to us. In this case, we act as if no neighbor was found - we put the route into the Active state, start sending Queries and expect Replies. The routing table won't be changed at this point. Only after receiving all Replies, we can choose the next successor and update the routing table.

Note that this sequence of steps is slightly different from what most textbooks say. Usually, textbooks say that if a successor fails, you locate a feasible successor and start using it. This is not always true. There may be a neighbor that provides a better total distance to the destination than the feasible successor but which does not pass the Feasibility Condition. Sticking with the feasible successor would cause us to use a worse path than what may be available. That is why we need to make sure whether there is no better path.

The sequence of steps can thus be abbreviated as:

1. After losing the current successor, freeze the entry in the routing table and disallow any modifications to it. It will still point towards the failed successor.
2. From all neighbors in the topology table that have advertised the destination network, select the one that provides the least total cost towards the destination.
3. If such neighbor does not exist, or if it exists but does not pass the Feasibility Condition check then:
1. Move the network to the Active state
2. Send out Queries asking all neighbors for assistance in locating a new shortest path to the destination
3. After receiving all Replies, choose the neighbor that provides the least cost path, promote it to the succesor and update the routing table. Put the network into Passive state and end here.
4. If such neighbor exists and passes the Feasibility Condition check, promote it to the successor and update the routing table.

EIGRP is never allowed to use a route without performing the Feasibility Condition check. This check make sure that the chosen next hop does not cause a routing loop. Because EIGRP tries to be loop-free at every instant, all its decisions are supplemented by the Feasibility Condition check.

Best regards,

Peter

Beginner

thanks this is a very complete complete explanation. i haven't thought that a ROUTER that is not a feasible succesor, can become the new successor when the old successor fails.

i mean the fact that the router is not a FS, does not mean that it can't become a new Successor.

i explain:

Router R1 is connected to Router R2 and Router R3, Rourter R2 is also connected to Router R3.

Router R1 need to forward a packet to the lan of the Router R3.

EIGRP detects that Router R3 is the Successor, but Router R2 is not listed ad the FS.

now the link Router R1- RouterR3 goes down.

dual send queries to the neighbors and discover that now Router R2 has the route for the lan of the Router R3, the FC is met and promote Router R2 as the new successor.   (when the link RouterR1-RouterR3 was active the link RouterR2- RouterR3 did't met the FC)

now Router R1 can send the packet to the lan fo the Router R3, with its new successor Router R2

the only thing that i'm not sure is that:

why when the link R1-R3 was active the link R2-R3 did not met the FC ?

does DUAL use in its calculations only one rererence bandwidth or compare more bandwidth ?

i mean R1-R3 has for example a certain Feasible distance

is it possible that R2-R3 has the reported distance higher then the feasible distance R1-R3  ??

so i have to think that dual uses different bandwidh value for the calculations, of S  and FS.

i thought that dual had used only one value for the bandwidht.

can you explain this  to me ? i mean when it has to calculate the Reported Distance in this case (R2-R3) and the Feasible Distance (R1-R3) does it use different bandwidth values ??

i hope this is clear....

Hall of Fame Cisco Employee

Hi Joseph,

You are welcome!

`why when the link R1-R3 was active the link R2-R3 did not met the FC ?`

This question goes back to the definition of the Feasible Distance. The Feasible Distance is a record of the lowest distance towards a particular destination since the last time the destination went from Active to Passive state. The Feasible Distance is therefore not necessarily the current distance, rather, it is a historical minimum of the distance (with the history starting anew with the Active->Passive transition). The Feasible Distance can be reset and newly initialized in the moment of Active->Passive transition (meaning it can also increase during this transition) but otherwise, during a stable Passive state, the Feasible Distance can only decrease.

If we understand the Feasible Distance as the minimal historical distance to a destination then the Feasibility Condition that says: RD < FD can be put into words as follows:

Any neighbor who is closer to the destination than we have ever been is not on a routing loop.

Assuming that in your network, R2 was not considered a feasible successor to 192.168.1.0/24, this tells us that the R2 is not closer to the destination than we have ever been. Why would that be? Well, we can always construct a network in which the link metrics are chosen so that while R2 is not going to route packets back to R1, it won't pass the FC check, like here:

R1's FD to the destination LAN behind R3 is 16, following the shortest path R1-R3. R2's distance to the same LAN is 18. Notice that R2 is certainly not using the path via R1 - that path would be much longer (20+15+1=36). However, at this point, R2 does not meet the FC check from R1's viewpoint. R1's FD is 16, R2's reported distance is 18, so R1 can not be sure if R2 is or is not using R1 to reach the destination. This is the exact situation where the FC check is actually more strict than necessary but it is better to be too cautious against routing loops than to be too trusting.

So in this network, R1 does not consider R2 to be a feasible successor because it is not closer to the destination than R1 has ever been (the RD of R2, 18, is more than the FD of R1, 16).

When the link from R1 to R3 fails, R1 loses its successor, and because the next router, in this case R2, provides the next least cost path but does not meet the FC check, R1 will put the network into active state and start sending Queries. These Queries simply contain the current increased distance of R1 to the destination (in this case, infinity because the path has been totally lost). Basically, R1 is informing its neighbors that its own distance has increased, and expects the neighbors to reevaluate their own choices of successors (subject to their own FDs and FC checks). If R1's increased distance does not influence the neighbor's selection of successor, it simply sends a Reply with the current distance. If, however, R1 has been a successor for some neighbor up to the moment of the distance increase and now, because of the increased distance, R1 does not meet the FC check from that neighbor's viewpoint anymore, that neighbor has just lost a successor and must deal with it exactly in the way I've explained in my first reply. It is possible that this neighbor will also have to put the destination into Active state and start sending Queries itself. This is what is called a Diffusing Computation in EIGRP.

In this network, after the R1-R3 link is torn down, R1 will indeed send a Query to R2, indicating its current infinite distance to the LAN. However, R2 does not currently consider R1 a successor - it is using R3 as its successor. So, for R2, the increased distance of R1 to the destination is irrelevant as it does not influence its own choice of successor. Here, R2 merely sends back a Reply immediately, indicating its current distance to R1, saying that the distance stays at 18 despite R1's increase of distance. Because R2 is R1's only neighbor, this Reply is the last expected Reply, after which R1 can put the route back into Passive state and reset the FD to the newly found shortest path metric, in this case, the route through R2, with the metric being 20+17+1=38.

This is why the Active->Passive transition allows you to reset and reinitialize, even increase the FD - because as a result of sending Queries, you have forced your neighbors to reevaluate their own choice of successors. If a neighbor sends you a Reply, you can be sure that it has taken your new increased distance into account and has modified its routing table accordingly - in any case, in such a way there is no routing loop, subject to that neighbor's own FD and its own FC check. Therefore, now you simply choose the least cost path and set the FD to its cost.

Note that the situation will be different if we change the metrics like this:

The R1's FD to the LAN is still 16. However, R2's reported distance is 11, so here, it meets the FC check even though it is not considered to be a successor by R1 because the total path through it would be 31. It it still a feasible successor, though.

Here, if the link between R1 and R3 is torn down, R1 will find in its topology table that R2 provides the next least cost path and it is a feasible successor as well. So here, the route will never enter the Active state - it will remain Passive, just the successor will be changed to R2 and the current distance on R1 will increase to 31. Notice, however, that because we have not gone through the Active state (we did not need to), the FD at R1 will not change and will remain on the previous value of 16!

This example shows the true behavior of FD. It is a record of the minimum distance to the destination since the last time it entered the Passive state, and is used for FC checks only. It does not necessarily represent the current distance, contrary to the popular - and incorrect - belief.

Now let's modify this network a little more:

R1's shortest path to the destination LAN is via R3, with the FD being set to 16. R2's shortest path is via R3 and its distance is 11, therefore, R2 is a feasible successor. R4's shortest path is via R3 as well, and its distance is 18, but because 18 is more than R1's FD of 16, R4 is not considered a feasible successor.

Note, however, that while R2 is a feasible successor here, the route from R1 through R2 to the destination would have the metric of 31, while the route through R4 - even though R4 is not considered a feasible successor - would have the metric of 23. Quite a difference, isn't it? Now, if R1-R3 link fails, what should R1 do?

If it decides to go with R2 as the feasible successor, it will surely be using a loop free path but at the same time, that path won't be the shortest one that is available. The path through R4 at this point seems to be shorter but because R4 fails the FC check, R1 is not sure - is R4 actually using R1 as its next hop, or is it using a different router? That is why R1 has to make sure.

So in this network, if R1-R3 link fails, R1 will find out that the router providing the next least cost path is R4, not R2, and that the R4 does not meet the FC check. So R1 will again go Active and start sending out Queries, indicating its current (infinite) distance to the LAN network. Both R2 and R4 will receive this Query, and because neither of them is using R1 as its next hop, the increased distance on R1 is irrelevant to them, so they immediately send a Reply with their current metrics: R2 replies with 11 and R4 replies with 18. When R1 receives both Reply messages, it goes back to Passive state, resets the FD and chooses the neighbor that provides the least cost path - in this case, R4. The current metric will be set to 23 including the FD, as the FD has been reset. Note that R2 was and has remained a feasible successor all the time - it has never been promoted to successor role.

Quite a lengthy explanation, I admit - but these are not intuitive facts so it takes a little to digest them.

Best regards,
Peter

Beginner

thanks

Beginner

Hi Peter,

but the 3rd pic in your 2nd reply i think R4's shortest path is via R1 (1+15+1=17) NOT via R3 (17+1=18).

am i right?

Thanks

Hall of Fame Cisco Employee

You are right! I have modified the cost of the R1-R4 link from 1 to 5 - that will correct the problem. Very good observation!

Best regards,
Peter

Beginner

Thank you so much Peter, for such a clear explanation! Your example just lays it out so nicely.

Hall of Fame Cisco Employee

Hi,

Thank you very much!

Best regards,
Peter

Contributor

2015 and this explanation is still as perfect as ever.

Beginner
Thank you very much for taking time to write an awesome explanation. I literally learned a lot. Thank you very much Peter. I respect you from bottom of my heart
Beginner
Thank you very very much for a flawless explanation. By the way, Peter I am very curious about how you have learned these invaluable information which cannot be found on the internet or books.
Beginner

Upvoted.

Hi Peter, thanks.

I know this is a little bit of an older post, but I have a question that might be able to help myself and others understand this concept a little more:

"If such neighbor does not exist, or if it exists but does not pass the Feasibility Condition check then:"

A) What feasible distance value is used in the feasibility condition check in this step? Would we compare the distance of the route through the feasible successor to the neighbor's AD / RD (for the one that has the lowest cost to the destination)?
B) What is the point of having a feasible successor for a route if we are going to send EIGRP query packets to our neighbors anyway?

Beginner

basically you query for a successor.

Beginner

Probably the best explanation i have come across on the internet on this topic. Peter, your broke it down really well. I am archiving this straight up. Thanks!

Create