> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # EIGRP DUAL Algorithm Deep Dive: Feasible Successors and the Real FD/RD Math - URL: https://www.pinglabz.com/eigrp-dual-algorithm/ - Published: 2026-04-26T07:41:56.000Z - Updated: 2026-08-01T18:36:25.000Z - Description: Everyone memorises RD < FD; nobody shows the arithmetic on a real router. Here it is on captured show ip eigrp topology output: one prefix with a feasible successor (409600 < 640000), one without (537600 > 512000), and a live failover where the route never left Passive. - Author: Jaime - Tags: EIGRP, #Import 2026-08-01 19:54 DUAL (Diffusing Update Algorithm) is what makes EIGRP fundamentally different from RIP, IGRP, and even OSPF. It is a distributed loop-prevention algorithm that pre-computes loop-free alternates, so failover to a backup happens without re-querying the network. The result is sub-second convergence on healthy networks, the headline EIGRP feature. This article walks DUAL's four key concepts (successor, feasible successor, feasible distance, reported distance), the feasibility condition, the active vs passive states, and what happens when no feasible successor exists. Every number past the theory comes off a three-router CML lab on IOS XE 17.18.2 (`iol-xe`), so you get real six-digit composite metrics, not textbook tens. If you are studying for CCNP/CCIE, or working out why `show ip eigrp topology` shows what it shows, this is the deep dive under the rest of the [guide to how EIGRP builds and maintains its topology table](https://www.pinglabz.com/eigrp/). ## The Problem DUAL Solves Distance-vector protocols (RIP, IGRP) have a famous failure mode: routing loops during convergence. When a route fails, the router that lost it may install a stale advertisement from a neighbor whose own path ran back through it. Traffic loops between the two until the count-to-infinity timer expires. The classic mitigations (split horizon, route poisoning, hold-down timers) reduce loop frequency without eliminating it, and they slow convergence badly. DUAL eliminates loops mathematically instead: every backup is validated by the feasibility condition before installation, guaranteeing it cannot loop back through the failed router. No hold-down timers, no count-to-infinity. ## The Four Key Concepts Reported Distance (RD) Meaning The metric a neighbor reports to us for a destination How calculated Sent in EIGRP UPDATE; the neighbor's metric to the destination Feasible Distance (FD) Meaning The lowest metric we have ever recorded for this destination How calculated Set when route first installed; updated only downward Successor Meaning The neighbor offering the best (lowest) total metric How calculated The neighbor with the lowest (RD + cost-to-neighbor) Feasible Successor (FS) Meaning A backup neighbor whose Reported Distance is strictly less than current FD How calculated Pre-computed for instant failover The math: total metric via a neighbor = (cost to that neighbor) + (its Reported Distance). The successor is the neighbor that minimizes this sum. One naming trap. RD is also called Advertised Distance, abbreviated AD in older material, colliding with administrative distance. They are unrelated: the 90 in square brackets in the RIB is [the number that decides whether EIGRP or another protocol wins a prefix](https://www.pinglabz.com/eigrp-administrative-distance/), the six-digit number after a slash is RD. ## The Feasibility Condition The single most important rule in DUAL: a path is loop-free if and only if the neighbor's Reported Distance is strictly less than the current Feasible Distance. ``` RD < FD => Loop-free, eligible to be a Feasible Successor RD >= FD => May loop; not a Feasible Successor ``` Why does it work? If a neighbor reports a metric lower than our best-ever metric, it must already have a shorter path than we do, so it cannot be reaching the destination through us, so traffic handed to it cannot loop back. Loop-freedom by arithmetic, no timers. The condition is deliberately conservative: some genuinely loop-free paths fail it because the neighbor's RD lands at or above FD. You will see exactly that below on a real prefix. ## The Lab This Was Captured On Three `iol-xe` routers on CML running IOS XE 17.18.2, EIGRP AS 100, wired as a triangle so R1 has two paths to one target prefix (3.3.3.0/24 on R3's Loopback0). - **R1 Et0/1 to R3 Et0/0** \- 10.0.13.0/30, `delay 1000`. The short direct path. - **R1 Et0/0 to R2 Et0/0** \- 10.0.12.0/30, `delay 5000`. Slow, so via-R2 loses. - **R2 Et0/1 to R3 Et0/1** \- 10.0.23.0/30, `delay 100`. Fast, so R2's own distance is low. Delay is in tens of microseconds, set on both ends. That third link is the trick: making R2 to R3 fast gives R2 a small reported distance without making the end-to-end path competitive. Low RD plus high total metric is the shape of a feasible successor, and what you engineer for when you want a pre-computed backup. Delay is the right lever: it is additive along the path while bandwidth is a minimum across it (the [K-value weighting that turns bandwidth and delay into a composite metric](https://www.pinglabz.com/eigrp-metric-k-values/) has the formula). All output below came from on-box EEM applets. ## A Worked Example: The Real Numbers Here is 3.3.3.0/24 on R1 with both paths healthy, from the most useful command in EIGRP troubleshooting: it prints FD and RD for every candidate, side by side. ``` R1# show ip eigrp topology 3.3.3.0/24 EIGRP-IPv4 Topology Entry for AS(100)/ID(10.0.13.1) for 3.3.3.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 640000 Descriptor Blocks: 10.0.13.2 (Ethernet0/1), from 10.0.13.2, Send flag is 0x0 <-- SUCCESSOR Composite metric is (640000/128256), route is Internal Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 15000 microseconds 10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0 <-- FEASIBLE SUCCESSOR Composite metric is (1689600/409600), route is Internal Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 56000 microseconds ``` Read the parentheses as **(total metric via this path / RD reported by that neighbor)**. Left is what the path costs R1, right is what the neighbor claims it costs them, and the header FD (640000) is the lowest left-hand number R1 has ever recorded here. Now the arithmetic the abstract explanations skip. The classic composite metric is `256 * (10^7 / minimum-bandwidth-in-Kbit + total-delay-in-usec / 10)`. Both paths cross 10 Mbit Ethernet, so the bandwidth term is 1000 for both and only delay separates them. Successor: via 10.0.13.2 Delay15000 usec Metric(1000 + 1500) x 256 Result = FD640000 R3 reports128256 Backup: via 10.0.12.2 Delay56000 usec Metric(1000 + 5600) x 256 Result1689600 R2 reports (RD)409600 Run the condition on those figures. R2's RD is **409600**, R1's FD is **640000**, and 409600 is strictly less than 640000, so the via-R2 path is a feasible successor: DUAL parks it in the topology table as a pre-validated backup. Notice what the test did **not** look at: 1689600, the backup's total cost, 2.6x the successor metric and completely irrelevant. Feasibility asks about the neighbor's distance, not yours. R2's 409600 sitting under R1's 640000 proves R2 is not reaching 3.3.3.0/24 through R1, so traffic sent that way cannot loop. ## A Prefix With No Feasible Successor The same lab, the same instant, contains prefixes that fail the test. Use `all-links` to see them: the default view hides non-feasible paths and leaves you believing a prefix has no alternate. ``` R1# show ip eigrp topology all-links EIGRP-IPv4 Topology Table for AS(100)/ID(10.0.13.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.0.13.0/30, 1 successors, FD is 512000, serno 2 via Connected, Ethernet0/1 via 10.0.12.2 (1817600/537600), Ethernet0/0 P 3.3.3.0/24, 1 successors, FD is 640000, serno 4 via 10.0.13.2 (640000/128256), Ethernet0/1 via 10.0.12.2 (1689600/409600), Ethernet0/0 P 10.0.23.0/30, 1 successors, FD is 537600, serno 5 via 10.0.13.2 (537600/281600), Ethernet0/1 via 10.0.12.2 (1561600/281600), Ethernet0/0 P 10.0.12.0/30, 1 successors, FD is 1536000, serno 1 via Connected, Ethernet0/0 via 10.0.13.2 (1817600/1561600), Ethernet0/1 ``` Four prefixes, four sums, two verdicts each way. 3.3.3.0/24 - FD 640000, alt RD 409600409600 < 640000 - feasible 10.0.23.0/30 - FD 537600, alt RD 281600281600 < 537600 - feasible 10.0.13.0/30 - FD 512000, alt RD 537600537600 > 512000 - NOT feasible 10.0.12.0/30 - FD 1536000, alt RD 15616001561600 > 1536000 - NOT feasible 10.0.13.0/30 is the instructive one. R1 is directly connected out Et0/1, so its FD is the connected metric, 512000\. R2 reports 537600, having learned the subnet from R3 rather than from R1, so that path is provably loop-free. It fails the feasibility condition anyway, by 25600. That is the conservatism made concrete. Connected prefixes are the classic victims: your FD is as low as it can get, so almost nothing a neighbor reports beats it and the alternate sits there unusable. Feasibility is a gate, not a preference. So when 10.0.13.0/30 loses its successor, DUAL cannot promote anything locally. The prefix goes Active, R1 queries R2, and nothing is installed until the reply lands. That is [where a prefix that goes Active and never comes back gets stuck](https://www.pinglabz.com/eigrp-query-process-stuck-in-active/): if a router in the query chain fails to reply in time, the adjacency is torn down. Every SIA incident starts as a prefix with no feasible successor. ## Proving It: Kill the Successor Link Theory is cheap. Here is the RIB before anything was touched: ``` R1# show ip route eigrp 3.0.0.0/24 is subnetted, 1 subnets D 3.3.3.0 [90/640000] via 10.0.13.2, 00:01:27, Ethernet0/1 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks D 10.0.23.0/30 [90/537600] via 10.0.13.2, 00:01:27, Ethernet0/1 ``` An EEM applet then shuts Et0/1, the successor path, and the adjacency drops: ``` %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.13.2 (Ethernet0/1) is down: interface down ``` Here is the same topology entry afterwards. Read the state field carefully: ``` R1# show ip eigrp topology 3.3.3.0/24 EIGRP-IPv4 Topology Entry for AS(100)/ID(10.0.13.1) for 3.3.3.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 640000 Descriptor Blocks: 10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0 <-- former FS, now SUCCESSOR Composite metric is (1689600/409600), route is Internal ``` **State is Passive.** The successor link is down, the prefix changed next hop and interface, and DUAL never ran a diffusing computation. No Active state, no query, no reply to wait on, no SIA exposure. R1 already knew this path was loop-free, so promotion was a local table operation. The RIB agrees: ``` R1# show ip route eigrp 3.0.0.0/24 is subnetted, 1 subnets D 3.3.3.0 [90/1689600] via 10.0.12.2, 00:01:00, Ethernet0/0 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks D 10.0.13.0/30 [90/1817600] via 10.0.12.2, 00:01:00, Ethernet0/0 D 10.0.23.0/30 [90/1561600] via 10.0.12.2, 00:01:00, Ethernet0/0 ``` The metric rose to 1689600 because the path really is longer, but reachability never dropped. Note the FD still reads 640000: FD only ratchets downward while a route is Passive, holding the historic best until the route next goes Active. That catches people out when they recompute feasibility after a failover using the metric in the RIB. Contrast the second RIB line. 10.0.13.0/30 also recovered via R2, but with no feasible successor it could only get there by going Active and querying. Same outcome, different journey: one a table lookup, one a conversation with a neighbor. How fast DUAL notices a failure is a separate problem from how fast it recovers. Here the interface went physically down, so detection was instant. On a link that stays up while the far end is dead you wait on hold timers, which is why [sub-second failure detection with BFD](https://www.pinglabz.com/bfd-bidirectional-forwarding-detection/) pairs well with EIGRP. ## Active vs Passive States Every route in the topology table has a state: Passive (P) Meaning Route is stable. Successor and any feasible successors known. Operator action None; healthy steady state Active (A) Meaning Route lost its successor with no feasible successor. Querying neighbors for alternatives. Operator action Investigate; persistent active routes mean trouble Update (U) Meaning Update message in flight Operator actionBrief transient Query (Q) Meaning Query message in flight Operator action Transient during DUAL active state Reply (R) MeaningReply pending Operator actionTransient Stuck-In-Active (SIA) Meaning Active for too long; neighbor not responding Operator action Neighbor declared dead; relationship reset Every healthy route shows Passive, like every prefix in the `all-links` capture above. Active routes are normal during convergence, but persistent active state means a neighbor is failing to reply, usually from overload or path issues. The dreaded SIA: a neighbor receives a query, fails to reply within the SIA timer (default 3 minutes), and EIGRP tears down the relationship. Cascading SIAs destabilise large networks. The classic mitigations are stub routing on spokes and raising SIA timers (rarely the right answer). The real fix sits upstream of both: engineer feasible successors so the prefixes that matter never go Active. ## Verifying DUAL State `show ip eigrp topology`Table view, P or A. Hides non-feasible paths. `show ip eigrp topology `FD, state, descriptor blocks, vector metrics. `show ip eigrp topology all-links`Every candidate, feasible or not. `show ip route eigrp`What got installed, with AD and metric. To answer "does this prefix have a backup?", run `all-links` and compare the header FD against the right-hand number in every other path. To build this triangle yourself, the [step-by-step lab that engineers a feasible successor with interface delay](https://www.pinglabz.com/ccna-lab-ipc-11-eigrp-feasible-successor-dual/) has the configs. ## Multiple Successors and Variance By default EIGRP installs one successor. Equal-cost paths need identical metrics to be installed together; unequal-cost paths need `variance`. ``` router eigrp 100 variance 2 ! Install paths up to 2x the FD as additional successors ``` Variance admits paths up to N times the FD, provided they already pass feasibility. On the lab numbers, with FD 640000, `variance 2` admits up to 1280000, so the via-R2 path at 1689600 stays out of the RIB until `variance 3`. The alternate for 10.0.13.0/30 would never be installed at any variance value, because variance cannot override feasibility. Feasibility decides whether a path is allowed, variance decides whether an allowed path is used. Full mechanics are in [how to load balance EIGRP over unequal-cost paths](https://www.pinglabz.com/eigrp-variance-unequal-cost-load-balancing/). ## Stub Routing's Impact on DUAL EIGRP stub routing modifies DUAL's query behavior. By default a router entering Active state queries all neighbors; with stub routing on spokes, the hub does not query stub neighbors. The benefit: the hub avoids fanning queries out to every spoke (each consumes spoke resources and adds convergence latency). The trade-off: stubs cannot be transit routers, because they do not advertise routes learned from other neighbors. For most hub-and-spoke designs that is what you want. See [EIGRP Stub Routing](https://www.pinglabz.com/eigrp-stub-routing/). ## DUAL vs SPF: Why EIGRP Is Different from OSPF Algorithm type DUAL (EIGRP) Distance-vector with diffusing computation SPF (OSPF) Link-state with Dijkstra Each router knows DUAL (EIGRP) Routes from direct neighbors plus their RDs SPF (OSPF) Full topology of the area Failover DUAL (EIGRP) Sub-second when FS exists; queries otherwise SPF (OSPF) SPF runs across the area Topology visibility DUAL (EIGRP) Limited (per-prefix only) SPF (OSPF)Full (LSDB) Convergence on healthy network DUAL (EIGRP) Fastest of the IGPs (cached FS) SPF (OSPF)Sub-second with tuning Convergence in worst case DUAL (EIGRP) Slower (queries propagate across topology) SPF (OSPF) Bounded by SPF complexity The trade-off: DUAL fails over instantly on cached alternates but forces a query when none exist, while SPF runs the same computation every time, so it is more predictable but slower at its best. The lab above is DUAL's best case rendered literally: an interface went down and the topology entry never changed state. See [EIGRP vs OSPF: When to Use Each](https://www.pinglabz.com/eigrp-vs-ospf/). ## Common Mistakes and Gotchas - **Reading (X/Y) backwards.** Left is your total metric via that path, right is the neighbor's RD. Compare the right number against the header FD, never against the left. - **Concluding there is no backup from plain `show ip eigrp topology`.** The default view suppresses non-feasible paths. Confirm with `all-links`. - **Assuming a cheap path is automatically feasible.** Here a backup costing 2.6x the successor passed, while a path 5 percent above FD failed. - **Expecting connected prefixes to have feasible successors.** Your FD there is as low as it gets, so a neighbor's RD rarely beats it. Those go Active on you. - **Recomputing feasibility against the post-failover metric.** FD does not rise while a route is Passive: after failover the installed metric was 1689600 but FD still read 640000. - **Reaching for the SIA timer.** The answer is more feasible successors or fewer query targets, not a longer timer that extends the outage before it is declared. ## Key Takeaways - The feasibility condition is `RD < FD`, strictly less than. Proven here with 409600 < 640000. - Composite metrics print as (FD-via-this-path / RD-from-neighbor). The header line's "FD is N" is what you compare against. - Total path cost is irrelevant to feasibility: 1689600 qualified, 537600 did not. - With a feasible successor present the successor link can drop and the route **never leaves Passive**. Captured live. - With no feasible successor the same failure forces a query and a wait, which is where every stuck-in-active story begins. Run `all-links` before declaring a prefix has no backup. ## Summary DUAL is EIGRP's superpower. The four concepts and the feasibility condition (RD < FD) give loop-free routing with sub-second failover, because a cached feasible successor lets failover happen without querying anyone. Master the condition, and get comfortable running the arithmetic on real six-digit metrics. Bookmark this alongside the rest of the [EIGRP configuration and troubleshooting guides](https://www.pinglabz.com/eigrp/). New labs and guides, in your inbox Every new PingLabz lab and deep-dive, built and verified on real Cisco IOS XE - free, straight to your inbox. [Join free](https://www.pinglabz.com/signup/)