When an EIGRP router loses its successor and has no feasible successor, how does DUAL's query-and-reply diffusing computation find a new path?
answer
- the route stops being usable
- ask everyone, wait for everyone
- unaffected neighbours answer at once
- the computation grows, then shrinks
basics
~20 sThe EIGRP route goes active and unusable; the router queries its neighbours, unaffected ones reply at once, affected ones go active and query onward, and once every reply is in it resets its feasible distance and picks the best answer.
solid answer
~50 sWith no feasible successor left, the route goes **active**, which RFC 7868 treats as unusable. The router sends a `QUERY` for the prefix to its neighbours and marks a reply outstanding from each. A neighbour whose own successor is unaffected, or that has a feasible successor, answers immediately with a `REPLY` carrying its distance and stays passive; a neighbour with no route replies with an infinite metric. A neighbour that was routing through the querying router has no safe answer, so it goes active itself and queries its own neighbours, replying only when its replies are in. That is the **diffusing computation**: it grows through affected routers and shrinks as replies return. While active, the router must not change its successor, feasible distance or reported distance. When the last reply arrives, it resets the feasible distance, picks the least-cost answer as the new successor, returns to **passive** and sends an `UPDATE`.
go deeper
Recall that without a feasible successor the route goes active and the router asks its neighbours before choosing a new path.
Describe how each kind of neighbour answers a query, and why an affected neighbour must query onward before replying.
Trace a failure through a small topology, showing who goes active, who replies at once, and why the originator must wait for every reply.
Relate the reach of a diffusing computation to topology and prefix design, since the slowest reply in the affected region sets convergence time.
## When the query process starts An EIGRP route is **passive** while at least one neighbour giving the least-cost path meets the **feasibility condition** (its reported distance is strictly below this router's feasible distance). After a topology change (a link to the successor fails, or the successor reports a higher distance) DUAL checks again. If no neighbour passes, the route becomes **active**. RFC 7868 is explicit that an active route is unusable and that the router "must coordinate with its neighbors" to find a new loop-free path. ## The steps of a diffusing computation 1. **Freeze.** The router keeps its successor, feasible distance and reported distance unchanged until the route is passive again; new information updates only computed distances. 2. **Query.** It sends a `QUERY` for the prefix to its neighbours and sets a reply-outstanding flag for each. When the change came from the successor, the query is not sent back out of the interface toward that successor (split horizon). 3. **Neighbours answer according to their own state:** - unaffected, or holding a feasible successor: reply at once with their distance and stay passive; - no entry for the prefix: reply at once with an infinite metric; - the querying router was their successor and they have no feasible successor: go active and query their own neighbours, replying only when their own computation is done. 4. **Collect.** Each `REPLY` clears one flag. A link failure to a queried neighbour counts as its reply. 5. **Finish.** When every flag is clear, the router resets its feasible distance, takes the least computed distance from the replies, installs that neighbour as successor, returns to passive and sends an `UPDATE`. If every reply was infinite, the prefix is unreachable and is removed. Queries and replies travel on EIGRP's reliable transport, and each prefix runs this process independently, so one link failure can send several prefixes active at once. ## Example 1: one hop of querying Four routers in a square; costs are 1 per link for illustration. `10.40.0.0/24` is attached to A. | Router | Distance | Successor | |---|---|---| | A | 1 | connected | | B | 2 | A | | D | 2 | A | | C | 3 | B | The link A–D fails. D's only other neighbour is C, which reports 3. D's feasible distance is 2, and 3 is not below 2, so C fails the test even though C's path through B is loop-free. D goes active and queries C. C's successor is B, untouched by the failure, so C stays passive and replies with 3. That is D's only outstanding reply. D resets its feasible distance, takes C at 3 + 1 = 4 as the new successor, goes passive and sends an update. A and B never took part. This is RFC 7868's own illustration of the process. ## Example 2: the computation spreads Now take the same routers without the C–D link, and fail A–B instead. B loses its successor; its only remaining neighbour is C, whose path ran through B. B goes active and queries C. The query came from C's successor, and C has no feasible successor, so C goes active too and queries onward. C has no other neighbour, so its computation finishes at once with nothing found: it removes the prefix, returns to passive and replies to B. That was B's last outstanding reply, so B removes the prefix as well. A and D, whose successors were never affected, were not involved. In a larger network the same pattern can travel many hops: each affected router waits on the routers behind it, and the router that started the computation waits for all of them. ## Why every reply is required - A reply proves that neighbour has processed the query and is no longer relying on the old, lower distance. Choosing earlier risks picking a neighbour that still routes through this router. - Waiting for all replies is also how the originator knows the computation has ended; RFC 7868 describes a diffusing computation as one where the starting node detects completion while avoiding false terminations. - The cost is time: the slowest reply in the whole affected region sets the convergence time for that prefix. ## What bounds the cost The process is self-limiting where neighbours are unaffected, because they reply immediately. It is expensive where many routers depend on the failed path or hold the specific prefix. Hiding the prefix with summarisation or filtering makes distant routers reply at once with an infinite metric, and stub routing, an implementation feature, keeps queries away from routers that never offer transit. When a reply takes too long, the router's active timer and the SIA-QUERY exchange take over.
- What does an EIGRP router do with a query for a prefix it has no route to?It replies at once with an infinite metric, which EIGRP encodes by setting the delay part of the metric to its maximum, and does not go active or query further. RFC 7868 notes a router informed of a change for a destination it has no reachability for need not join the computation. That is exactly why hiding specific prefixes behind summaries limits how far queries travel.
- Why does the querying router wait for every reply instead of taking the first good one?A reply shows that neighbour has seen the query and no longer depends on the router's old distance. Until all are in, some neighbour may still be routing through the router on stale information, so choosing early could create a loop. Waiting for every reply is also how the router knows the computation has truly finished.
- Does a neighbour that is itself active answer a query from a router other than its successor?Yes. RFC 7868 says a router that receives a query from a non-successor while active sends a reply and does not propagate the query further. The reply carries its current distance, so the querying router is not left waiting on a computation the neighbour started for its own reasons.
saying these in an interview costs you the question
- While the route is active, the router keeps forwarding on whichever neighbour answers first
- Every router in the autonomous system takes part in each active computation
- The router installs the first reply that offers a path and ignores the rest
- A neighbour with no route to the prefix simply ignores the query
- Queries are flooded like link-state advertisements and need no replies