Accepted Solutions
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:
- Via B, total distance 20, B being the current successor, 20 being the current feasible distance
- Via C, total distance 25, C being the current feasible successor
- Via D, total distance 21, D not being a feasible successor because it does not pass the feasibility condition check, as the reported distance of 20 from D is not strictly less than the current feasible distance of 20. However, should router B fail, the D would still provide the next shortest route from A 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:
- Router A detects a distance increase to E because of router B going down (a network going down is represented by the metric becoming infinity).
- Router A checks its topology table to find out which neighbor provides the next shortest path to E
- Router A will find out that the shortest available path to E goes through D, but D is not a feasible successor
- Router A will send out queries indicating its current infinite distance to E
- Routers C and D will respond with their current distances unchanged, as they are not influenced by router A's lost route to E.
- After receiving replies from C and D, router A is permitted to reset its FD and set it to the new lowest available total distance to E, which is 21 via D.
- Now, with FD=21, D becomes a new successor and C remains a feasible successor.
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
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:
- Via B, total distance 20, B being the current successor, 20 being the current feasible distance
- Via C, total distance 25, C being the current feasible successor
- Via D, total distance 21, D not being a feasible successor because it does not pass the feasibility condition check, as the reported distance of 20 from D is not strictly less than the current feasible distance of 20. However, should router B fail, the D would still provide the next shortest route from A 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:
- Router A detects a distance increase to E because of router B going down (a network going down is represented by the metric becoming infinity).
- Router A checks its topology table to find out which neighbor provides the next shortest path to E
- Router A will find out that the shortest available path to E goes through D, but D is not a feasible successor
- Router A will send out queries indicating its current infinite distance to E
- Routers C and D will respond with their current distances unchanged, as they are not influenced by router A's lost route to E.
- After receiving replies from C and D, router A is permitted to reset its FD and set it to the new lowest available total distance to E, which is 21 via D.
- Now, with FD=21, D becomes a new successor and C remains a feasible successor.
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
