Clearing the Topology Table and Querying Neighbors in EIGRP Networks
Once EIGRP has built a topology table and decided which paths are not looped, it needs some way to adjust to changes in that topology table. Because EIGRP uses nonperiodic updates, it does not time routes out of its table; the route must either be removed by new information from a neighbor, or through tearing down a neighbor relationship.
When a router loses its connection to a destination, it will examine its topology table first to determine if it has a feasible successor for that destination. If a feasible successor exists, the router will do the following:
Remove the old route.
Replace the old successor with the new one.
Re-compute the topology table for that destination. (Changing the feasible distance may produce a new set of feasible successors.)
Update any neighbors on the change in its path.
If, however, a router loses its route to a destination, and it has no other loop free routes to that destination, the router will query each of its neighbors to see if any of them has another path. At first glance, this may seem unnecessary, but it serves three purposes:
To re-evaluate paths that may have been rejected as looped.
To learn of paths that may not have been originally advertised due to split-horizon rules.
To inform all neighbors that this router no longer has a path to this network; if they are relying on this path to reach this destination, they need to find a new path because this one is no longer available.
In Figure C-6, if Router D's interface on 10.1.1.0/24 goes down (later, you discover the cable dangling out of the router, of course), Router D would immediately mark this destination as unreachable and query each of its neighbors—Routers B and C in this case—for a new path to this destination (arrow 1 in Figure C-6).
Routers B and C are both using Router D as their successor to this network and, therefore, mark the destination as unreachable and query each of their neighbors (arrows 2 and 3). Because the link between Routers A and C is faster than the link between Routers A and B, Router A uses Router C as its successor to this network, and the query from Router C arrives first (in theory anyway—there are many other sequences in which these events could occur, but the end result will be the same).
Figure C-6. Query Path through a Network
When Router A receives the query from Router C, it examines its topology table, notes that it has a feasible successor for this destination through Router B, and queues a response for Router C. Assume the query from Router B arrives before that response is sent; Router A notes that it has no other feasible successors and marks the route as unreachable. Then, Router A adjusts its response to Router C to make the replied metric unreachable and also sends a packet to Router B, notifying it that this path is unreachable (arrows 4 & 5).
When these replies arrive at Routers B and C, these routers remove the destination from their topology tables and send responses back to Router D that this path is unreachable (arrow 6). Once Router D receives all the answers, or replies, to its queries, it sends updates to Routers B and C to notify them that 10.1.1.0/24 is no longer reachable. Routers B and C, in turn, propagate this information to Router A.