Why does EIGRP's feasibility condition guarantee that a feasible successor's path is loop-free, and why does it still reject some loop-free paths?

## What has to be proved A **feasible successor** is a neighbour an EIGRP router may switch to instantly, without consulting anyone. That is only safe if the neighbour's path to the prefix does not lead back through the router itself: otherwise the two would forward to each other and the packets would loop until their TTL ran out. The router has no map of the network. It knows only each neighbour's **reported distance** (RD) and its own **feasible distance** (FD), the lowest distance it has had to the prefix since the route last became passive. The **feasibility condition** is `RD < FD`. ## The argument in outline RFC 7868 states the condition and the rules around it; the proof comes from the research it cites on loop-free routing. In outline, assuming every link cost is positive: 1. **While the route is passive, the FD only falls.** It is defined as a minimum, so every distance this router has held, and therefore every distance it has advertised, since the route went passive is at least the current FD. 2. **A path through this router costs more than this router's distance.** If neighbour N reaches the prefix via this router, directly or a few hops later, N's distance is built on a value this router advertised, plus at least one positive link cost. So N reports more than that value, which is at least the FD. 3. **So a reported distance below the FD rules the router out.** If N reports less than the FD, N's path cannot include this router. Using N cannot create a loop. RFC 7868 states the inequality as strict, so a neighbour reporting exactly the FD does not qualify. ## Keeping the guarantee while things change Step 1 depends on the FD never jumping upward while stale information is still around. That is what DUAL's active state protects: - When no feasible successor remains, the route goes **active**, and RFC 7868 forbids changing the successor, the FD or the reported distance until it is passive again. New information only updates computed distances. - The router queries its neighbours and waits for a reply from **every** one. A reply means that neighbour has processed the query and is no longer relying on this router's old, lower distance. - Only then does it reset the FD, to the best distance it now knows, and return to passive. If the router raised its FD early, a neighbour still holding the router's old, lower advertisement could report a distance that looks smaller than the new FD while actually pointing back through the router. Waiting for all replies closes that gap. ## Why loop-free paths can still fail RFC 7868 says the condition is **sufficient but not necessary**: every path meeting it is loop-free, but not every loop-free path meets it. The reason is the same blindness that made the proof necessary. A neighbour reports a high distance either because its path runs back through this router, or because its own independent path is simply long. From distances alone the router cannot tell these apart, so it rejects both. | Neighbour reports | Its real path | Feasibility condition | Outcome when the successor fails | |---|---|---|---| | 15, FD 20 | independent | passes | instant switch, route stays passive | | 25, FD 20 | through this router | fails | would loop; correctly rejected | | 25, FD 20 | independent but long | fails | loop-free, yet the route goes active and queries | The third row is the price. When the successor fails and only such neighbours remain, the router cannot switch locally. It goes active, queries, and typically ends up choosing that very neighbour once the replies arrive and the FD is reset. ## What this means in practice - **Fast failover depends on topology and metrics.** A backup path is only instant if the backup neighbour is genuinely closer to the destination than this router's best distance. In a ring or a square of routers, the far side of the ring often fails the test. - **The conservative test is the reason for queries.** Every rejection of a safe path turns a failure into a diffusing computation, and large ones are where stuck-in-active problems start. - **The condition is per prefix.** One link failure can leave some prefixes with feasible successors and send others active.