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 from a primary path to a backup happens without re-querying the network. The result is sub-second convergence on healthy networks, which is the headline EIGRP feature.
This article walks through DUAL's four key concepts (successor, feasible successor, feasible distance, reported distance), the feasibility condition that prevents loops, the active vs passive states, the query process when no feasible successor exists, and the worked examples that make it click. If you are studying for CCNP/CCIE or trying to figure out why show ip eigrp topology shows what it shows, this is the deep dive.
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 the route may receive an outdated advertisement from a neighbor (whose advertisement is based on the now-failed route via the first router) and install 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 but do not eliminate it. They also slow convergence dramatically.
DUAL eliminates loops mathematically. By validating every backup path with the feasibility condition before installing it, DUAL guarantees the backup cannot loop back through the failed router. No hold-down timers. No count-to-infinity. No loops.
The Four Key Concepts
| Term | Meaning | How calculated |
|---|---|---|
| Reported Distance (RD) | The metric a neighbor reports to us for a destination | Sent in EIGRP UPDATE; the neighbor's metric to the destination |
| Feasible Distance (FD) | The lowest metric we have ever recorded for this destination | Set when route first installed; updated only downward |
| Successor | The neighbor offering the best (lowest) total metric | The neighbor with the lowest (RD + cost-to-neighbor) |
| Feasible Successor (FS) | A backup neighbor whose Reported Distance is strictly less than current FD | Pre-computed for instant failover |
The math: for any destination, the total metric via a neighbor = (cost to that neighbor) + (Reported Distance from that neighbor). The successor is the neighbor that minimizes this sum.
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 this work? If a neighbor reports a metric (RD) that is less than our best-ever metric (FD), the neighbor must already have a shorter path to the destination than we do. Our route to the destination cannot transit through them and back to us, because that would mean their path back to us is longer than the one they are reporting. Mathematical loop-freedom.
The feasibility condition is conservative. Some loop-free paths fail it (because the neighbor's RD happens to be equal to or greater than FD even though no loop exists). DUAL trades off some optimality for guaranteed loop-freedom.
A Worked Example
Topology: R1 connects to R2, R3, R4. The destination 10.10.10.0/24 is somewhere beyond. The routers have the following metrics to it:
| Path | Cost from R1 to neighbor | Reported Distance (neighbor's metric) | Total via this neighbor |
|---|---|---|---|
| via R2 | 10 | 20 | 30 |
| via R3 | 15 | 10 | 25 |
| via R4 | 20 | 40 | 60 |
R3's path is shortest (total 25). R3 is the successor. R1's Feasible Distance becomes 25.
Now check feasibility for the others:
- R2: RD=20. FD=25. 20 < 25? Yes. R2 is a Feasible Successor.
- R4: RD=40. FD=25. 40 < 25? No. R4 is NOT a Feasible Successor.
R1 installs the route via R3 in the routing table, with R2 as the Feasible Successor in the topology table. If R3's path fails, R1 instantly switches to R2 - no queries, no recomputation, sub-second convergence. The total metric becomes 30 (via R2).
If R3 AND R2 fail, R1 has no Feasible Successor for this destination. The route enters Active state and R1 must query R4 (and any other neighbors) to find an alternative. Slower convergence; can take seconds.
Active vs Passive States
Every route in EIGRP's topology table has a state:
| State | Meaning | Operator action |
|---|---|---|
| Passive (P) | Route is stable. Successor and any feasible successors known. | None; healthy steady state |
| Active (A) | Route lost its successor with no feasible successor. Querying neighbors for alternatives. | Investigate; persistent active routes mean trouble |
| Update (U) | Update message in flight | Brief transient |
| Query (Q) | Query message in flight | Transient during DUAL active state |
| Reply (R) | Reply pending | Transient |
| Stuck-In-Active (SIA) | Active for too long; neighbor not responding | Neighbor declared dead; relationship reset |
You should see "Passive" in show ip eigrp topology for every healthy route. Active routes are normal during convergence (a few seconds) but persistent active state means a neighbor is failing to reply, often due to 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 neighbor relationship. Cascading SIAs across a large EIGRP network can cause network-wide instability. The classic mitigations are stub routing on spokes (so the hub does not query them) and increasing SIA timers (rarely the right answer).
Verifying DUAL State
R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.10.10.0/24, 1 successors, FD is 25
via 10.0.13.3 (25/10), GigabitEthernet0/0/1
via 10.0.12.2 (30/20), GigabitEthernet0/0/0
R1# show ip eigrp topology 10.10.10.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 10.10.10.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 25
Routing Descriptor Blocks:
10.0.13.3 (GigabitEthernet0/0/1), from 10.0.13.3, Send flag is 0x0
Composite metric is (25/10), route is Internal <-- successor
Vector metric:
...
10.0.12.2 (GigabitEthernet0/0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (30/20), route is Internal <-- feasible successorThe two numbers in parentheses are (FD/RD). For the successor, FD/RD = 25/10 means the total metric is 25 and R3 reported 10. For the feasible successor candidate, 30/20 means the total metric via R2 would be 30 and R2 reported 20. RD=20 < FD=25 confirms feasibility.
Multiple Successors and Variance
By default, EIGRP installs only one successor (the lowest-metric path) in the routing table even if multiple paths have similar metrics. To install multiple equal-cost paths (ECMP), they must have identical metrics. To install unequal-cost paths for load balancing, use the variance command.
router eigrp 100
variance 2 ! Install paths up to 2x the FD as additional successorsVariance lets paths whose metric is up to N times the FD enter the routing table as additional successors, provided they pass the feasibility condition. variance 2 with FD=25 admits any feasible path with metric <= 50.
Caveat: only feasible successors qualify for variance load balancing. Non-feasible paths do not enter the routing table even with high variance. This is the protection against loops.
Stub Routing's Impact on DUAL
EIGRP stub routing modifies DUAL's query behavior. By default, when a route enters Active state, the router queries all neighbors. With stub routing on spokes, the hub does not query stub neighbors during Active states.
The benefit: in hub-and-spoke topologies, the hub avoids fanning out queries to every spoke (each query consumes resources at the spoke and contributes to convergence latency). The trade-off: stubs cannot be transit routers - they do not advertise routes learned from other neighbors.
For most hub-and-spoke designs, this is exactly what you want. See EIGRP Stub Routing.
DUAL vs SPF: Why EIGRP Is Different from OSPF
| Aspect | DUAL (EIGRP) | SPF (OSPF) |
|---|---|---|
| Algorithm type | Distance-vector with diffusing computation | Link-state with Dijkstra |
| Each router knows | Routes from direct neighbors plus their RDs | Full topology of the area |
| Failover | Sub-second when FS exists; queries otherwise | SPF runs across the area |
| Topology visibility | Limited (per-prefix only) | Full (LSDB) |
| Convergence on healthy network | Fastest of the IGPs (cached FS) | Sub-second with tuning |
| Convergence in worst case | Slower (queries propagate across topology) | Bounded by SPF complexity |
The trade-off: DUAL's per-route caching lets it fail over instantly on cached alternates but requires querying when alternates do not exist. SPF always runs the same computation, so its convergence time is more predictable but its best case is slower than DUAL's best case.
For the full EIGRP vs OSPF comparison, see EIGRP vs OSPF: When to Use Each.
Summary
DUAL is EIGRP's superpower. The four concepts (successor, feasible successor, FD, RD) and the feasibility condition (RD < FD) together give EIGRP loop-free routing with sub-second failover on healthy networks. Cached feasible successors mean failover happens without querying neighbors; queries only happen when no feasible alternative exists.
Master the feasibility condition - it is the algorithmic guarantee underlying everything EIGRP does. Watch for active routes in show ip eigrp topology; they should be transient, not persistent. Bookmark this article alongside the EIGRP cluster pillar as your DUAL reference.