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.
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
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, 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 SuccessorWhy 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 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 microsecondsRead 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.
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/1Four prefixes, four sums, two verdicts each way.
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: 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/1An 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 downHere 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 InternalState 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/0The 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 pairs well with EIGRP.
Active vs Passive States
Every route in the topology table has a state:
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 topologyTable view, P or A. Hides non-feasible paths.show ip eigrp topology <prefix>FD, state, descriptor blocks, vector metrics.show ip eigrp topology all-linksEvery candidate, feasible or not.show ip route eigrpWhat 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 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 successorsVariance 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.
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.
DUAL vs SPF: Why EIGRP Is Different from OSPF
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.
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 withall-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-linksbefore 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.