11-20-2011 11:06 AM - edited 03-04-2019 02:20 PM
Let me know if I have this right.
In EIGRP, let's say on Router A, we have a network that has just gone done, EIGRP will look in the topology table for a
Feasible Successor, and if it finds one it will update it's routing table, and' send out an update. If it doesn't have a Feasible
Successor, it will send out a Query to it's directly connected network, asking if they have a alternate route to the network
that just went down, If these routers have a route, they will send a Reply back, which will update Router A's routing
table. If no Feasible Successor is found on any of the neighbors, they will query therre neighbors and so forth. I know that
it will not query a stub router, and if all the router don't have a Feasible Successor the route will be removed from all routing
tables on the network.
In OSPF, I would assume, that Router A, would send out an LSA, informing the other routers in the area of the network change,
which will then allow those routers to update their LSDB and run the Dijstka algorithm to recalculate their routes.
Solved! Go to Solution.
11-20-2011 03:17 PM
Hi John,
EIGRP will look in the topology table for aFeasible Successor, and if it finds one it will update it's routing table, and' send out an update
This is how the EIGRP process is usually taught, and according to the popular books, this would be completely correct. In reality, it isn't
What really happens is that after a router finds out that a network has gone down, it will go over the EIGRP topology table and try to find any neighbor which provides the next best distance to the network. If such neighbor is found, EIGRP will verify whether that neighbor is a Feasible Successor (i.e. whether it passes the feasibility condition check). If it is, it will choose it as the new successor, and send an update. If the neighbor does not pass the feasibility condition check, or if no such neighbor is found at all, the router will send queries, trying to actively find a new route to the lost network.
The difference is subtle but important: we do not immediately jump to using the feasible successor, even if we know about it. Instead, we first check whether the feasible successor provides the next best distance to the destination. If it does not, we are not going to use it even though it is a feasible successor. The reason is clear: there may be a neighbor providing a better total distance to the destination but not currently passing the feasibility condition check. If we remained happy with the feasible successor, we would potentially miss the opportunity to use a shorter route that is available. See the following exhibit (respectfully taken from Cisco Networking Academy CCNP:ROUTE slide deck with minor modifications made by myself):
Router A has three paths to E:
Now if router B fails, the natural (and naive) next choice would be to choose the router C, currently the feasible successor, as the new successor. However, choosing C would make router A use a longer route than is objectively available. The path through D is also loop-free, however, it does not currently pass the feasibility condition check because the current FD=20 is not strictly lower than router D's RD=20. The sequence of steps taken by router A would therefore be:
Note how the router D "suddenly" becomes a successor, not even being a feasible successor before the topology change.
I know thatit will not query a stub router
It should not, but even if it did, a stub router would immediately respond with an unreachable metric, regardless of which network it is queried about. A stub router never propagates a query, even if it receives any. This can happen if old EIGRP speakers are used as hub routers and do not recognize the stub TLV indicated by stub routers in their Hello packets.
if all the router don't have a Feasible Successor the route will be removed from all routing tables on the network.
I would personally not focus too much on Feasible Successors in this case, because as shown in my explanation above, a router that does not even look like a Feasible Successor may promptly become a Successor. Correctly, we should say that if there really isn't any other route to the destination that just disappeared, the route will be removed from all routing and topology tables in the network.
In OSPF, I would assume, that Router A, would send out an LSA, informing the other routers in the area of the network change, which will then allow those routers to update their LSDB and run the Dijstka algorithm to recalculate their routes.
Basically, yes. Routers that notice the topology change (an interface going down, a neighbor going down - note that all these changes can be directly detected only by routers being directly attached to the object going down) will generate new LSAs and flood it throughout the network (area or domain, depending on the LSA type). Other routers will replace the older LSAs with these newer LSAs and run the Dijkstra algorithm on the new version of the LSDB, producing an updated routing table.
Please feel welcome to ask further!
Best regards,
Peter
11-20-2011 03:17 PM
Hi John,
EIGRP will look in the topology table for aFeasible Successor, and if it finds one it will update it's routing table, and' send out an update
This is how the EIGRP process is usually taught, and according to the popular books, this would be completely correct. In reality, it isn't
What really happens is that after a router finds out that a network has gone down, it will go over the EIGRP topology table and try to find any neighbor which provides the next best distance to the network. If such neighbor is found, EIGRP will verify whether that neighbor is a Feasible Successor (i.e. whether it passes the feasibility condition check). If it is, it will choose it as the new successor, and send an update. If the neighbor does not pass the feasibility condition check, or if no such neighbor is found at all, the router will send queries, trying to actively find a new route to the lost network.
The difference is subtle but important: we do not immediately jump to using the feasible successor, even if we know about it. Instead, we first check whether the feasible successor provides the next best distance to the destination. If it does not, we are not going to use it even though it is a feasible successor. The reason is clear: there may be a neighbor providing a better total distance to the destination but not currently passing the feasibility condition check. If we remained happy with the feasible successor, we would potentially miss the opportunity to use a shorter route that is available. See the following exhibit (respectfully taken from Cisco Networking Academy CCNP:ROUTE slide deck with minor modifications made by myself):
Router A has three paths to E:
Now if router B fails, the natural (and naive) next choice would be to choose the router C, currently the feasible successor, as the new successor. However, choosing C would make router A use a longer route than is objectively available. The path through D is also loop-free, however, it does not currently pass the feasibility condition check because the current FD=20 is not strictly lower than router D's RD=20. The sequence of steps taken by router A would therefore be:
Note how the router D "suddenly" becomes a successor, not even being a feasible successor before the topology change.
I know thatit will not query a stub router
It should not, but even if it did, a stub router would immediately respond with an unreachable metric, regardless of which network it is queried about. A stub router never propagates a query, even if it receives any. This can happen if old EIGRP speakers are used as hub routers and do not recognize the stub TLV indicated by stub routers in their Hello packets.
if all the router don't have a Feasible Successor the route will be removed from all routing tables on the network.
I would personally not focus too much on Feasible Successors in this case, because as shown in my explanation above, a router that does not even look like a Feasible Successor may promptly become a Successor. Correctly, we should say that if there really isn't any other route to the destination that just disappeared, the route will be removed from all routing and topology tables in the network.
In OSPF, I would assume, that Router A, would send out an LSA, informing the other routers in the area of the network change, which will then allow those routers to update their LSDB and run the Dijstka algorithm to recalculate their routes.
Basically, yes. Routers that notice the topology change (an interface going down, a neighbor going down - note that all these changes can be directly detected only by routers being directly attached to the object going down) will generate new LSAs and flood it throughout the network (area or domain, depending on the LSA type). Other routers will replace the older LSAs with these newer LSAs and run the Dijkstra algorithm on the new version of the LSDB, producing an updated routing table.
Please feel welcome to ask further!
Best regards,
Peter
11-21-2011 05:38 AM
Thanks for clearing up the EIGRP Part. It seems Cisco books have a misnotion about how EIGRP automatically will choose the next best Feasible Successor. It turns out, it looks for the next best distance to the network, and if it's not a Feasible Successor, will query the other neighbors of the router, which will receive a reply, indicating that it should be the new successor basically.. It dosn't necessarily choose the next best Feasible Successor, since there could be another path with a better distance just not a Feasible Successor at that time.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: