EIGRP , successor and feasible successor

Question

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 ?

Answer 1

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.
Please feel welcome to ask further!
Best regards,
Peter