What Is DUAL? EIGRP’s Diffusing Update Algorithm

The Diffusing Update Algorithm (DUAL) is the algorithm EIGRP uses to guarantee loop-free routes and maintain backup paths throughout the routing domain, recalculating a route whenever a change could otherwise introduce a loop. This guide covers what DUAL actually does, corrects a common point of confusion about how EIGRP really prevents loops, and walks through a worked example of DUAL responding to a link failure, both with and without a feasible successor already available.

DUAL’s Core Terminology

Several terms recur throughout any discussion of DUAL:

• Successor — the current best route to a destination.
• Feasible Distance (FD) — this router’s total metric to the destination via the successor.
• Feasible Successor (FS) — a backup route already verified as loop-free, ready to be promoted immediately if the successor fails.
• Reported Distance (RD), also called Advertised Distance (AD) — the metric the next-hop neighbor reports for reaching that destination, from its own perspective.
• Feasibility Condition (FC) — the test a candidate route must pass (RD less than the successor’s FD) to qualify as a feasible successor.

These concepts are covered with worked examples in EIGRP Topology Table; this guide focuses specifically on DUAL as the engine that uses them.

What Actually Prevents Loops in EIGRP

This is worth being precise about, since it’s a common point of confusion: DUAL’s Feasibility Condition — not a hold-down timer — is EIGRP’s primary loop-prevention mechanism. Unlike RIP, which relies on hold-down timers (deliberately suppressing a route for a period after a failure to prevent flapping) as a core anti-loop tool, EIGRP doesn’t need that mechanism at all, because the Feasibility Condition mathematically guarantees a feasible successor can never loop back through the local router in the first place.

EIGRP does have something called a Hold Timer — but it’s a completely different concept, easily confused by name alone. The Hold Timer tracks whether a neighbor is still alive, based on the regular arrival of Hello packets; if it expires, EIGRP considers that neighbor down. This is a neighbor-liveness mechanism, not a loop-prevention one, and it has nothing to do with RIP-style hold-down behavior, despite the overlapping terminology making the two easy to conflate at a glance.

Split horizon does play a role in EIGRP too, but its primary purpose is efficiency rather than loop prevention: the basic rule (don’t advertise a route back out the interface it was learned on) mostly just avoids sending redundant information a neighbor already has. Per Cisco’s own documentation, split horizon does combine with a specific “advertise as unreachable” rule during initial topology exchange between two new neighbors to provide an additional layer of loop protection in that specific startup scenario — but even without split horizon at all, DUAL’s Feasibility Condition alone is sufficient to guarantee a loop-free topology under normal, ongoing operation.

Why DUAL Provides Faster Convergence

DUAL’s key advantage over how older distance-vector protocols like RIP handle failures comes down to two things:

Bounded recalculation. When a topology change occurs, DUAL only involves the routers actually affected by that specific change — routers elsewhere in the network, whose best paths aren’t touched by the failure, never participate in any recalculation at all. This is fundamentally different from protocols that recompute routes network-wide on every single change, regardless of where in the topology that change actually occurred.

Reuse of pre-verified backup routes. EIGRP avoids recalculation whenever possible, since recalculation (specifically, the Query/Reply process when no feasible successor exists) is comparatively processor- and time-intensive. DUAL maintains a list of backup routes it has already verified as loop-free — feasible successors — and if the primary route fails, the best available feasible successor is promoted directly into the routing table, with no need to consult neighbors or wait for a fresh computation.

Worked Example: DUAL Responding to a Link Failure

Consider a router, R1, with a successor route to a destination via R2, and a feasible successor via R3 that has already satisfied the Feasibility Condition.

1. R1’s link to R2 fails. R1’s Hold Timer for R2 expires (or the interface itself goes down), and DUAL is informed of the topology change.
2. DUAL checks the topology table for a feasible successor. Since R3’s route already passed the Feasibility Condition earlier, it’s immediately available — no Query packets are needed.
3. The feasible successor is promoted to successor. R1’s routing table updates to use R3 as the new next hop, and the route remains in the Passive state throughout — meaning it was never actively being recomputed, just switched to an already-qualified alternative.

Now consider the same scenario, but without a feasible successor available:

1. R1’s link to R2 fails, exactly as before.
2. DUAL checks the topology table and finds no feasible successor — no other candidate route satisfies the Feasibility Condition against R2’s former Feasible Distance.
3. The route transitions to Active state. R1 sends Query packets to its remaining neighbors, asking whether any of them have a usable path.
4. Once Reply packets return from every queried neighbor, DUAL selects a new successor from the responses (or concludes the destination is genuinely unreachable), and the route returns to Passive state.

The first scenario converges almost instantly; the second takes measurably longer, since it depends on round-trip communication with neighbors rather than information R1 already had on hand locally. This is exactly why network designs concerned with fast convergence pay close attention to ensuring feasible successors actually exist for critical destinations, rather than assuming DUAL’s speed advantage applies uniformly everywhere.

The DUAL Finite State Machine (FSM)

The DUAL FSM is EIGRP’s underlying route-computation engine — the formal logic that tracks and compares candidate routes using EIGRP’s metrics to select loop-free, least-cost paths for the routing table. A Finite State Machine, as a general concept, is an abstract model (not a physical device) that defines a limited set of possible states, the events that trigger transitions between those states, and the results of each transition. For EIGRP specifically, the two states that matter most in practice are Passive (stable, not currently being recomputed) and Active (currently undergoing recalculation because no feasible successor was available), covered in more depth with real command output in EIGRP Packet Types.

Deep FSM state-transition detail is generally considered beyond typical CCNA-level material, but the concept remains directly observable on a live router. The debug eigrp fsm command surfaces the FSM’s actual decision-making in real time, which is genuinely useful during hands-on troubleshooting even without needing to master the full formal state-transition model behind it.

Verifying DUAL Activity on a Live Router

A few commands surface DUAL’s behavior directly rather than only reasoning about it in the abstract:

Router# show ip eigrp topology active

Lists any routes currently in the Active state — a route appearing here means DUAL is actively querying neighbors for that destination right now, which is expected during a genuine topology change but worth investigating if a route stays listed for an unusually long time.

Router# debug eigrp fsm

Surfaces the FSM’s internal decision-making in real time, including feasibility checks and state transitions as they happen. This produces substantial output on a busy router, so it should be used deliberately and disabled with undebug all once the relevant information has been captured.

Router# show ip eigrp topology <network>

Shows the Feasible Distance and, where one exists, the Reported Distance of any feasible successor for a specific destination — the most direct way to confirm whether DUAL has a ready backup for a route you’re specifically interested in.

Common Mistakes

Assuming split horizon alone prevents EIGRP loops. As covered above, split horizon’s role is mostly about efficiency, not loop prevention — DUAL’s Feasibility Condition is what actually provides the loop-free guarantee. Disabling split horizon (rarely necessary, but sometimes done in specific NBMA hub-and-spoke designs) does not reintroduce loop risk, precisely because DUAL doesn’t depend on it for that purpose.

Confusing EIGRP’s Hold Timer with RIP-style hold-down. These are genuinely different mechanisms serving different purposes, despite the similar name. EIGRP’s Hold Timer detects a dead neighbor; it has no role in loop prevention, unlike RIP’s hold-down timer, which exists specifically to reduce loop risk by delaying acceptance of a route change.

Assuming every route has a feasible successor. Whether a feasible successor exists depends entirely on the actual topology and metrics involved — some destinations simply have no alternate path that satisfies the Feasibility Condition, meaning any failure on the primary path forces the slower Active/Query process regardless of how well-designed the rest of the network is. This is one more reason redundant physical links don’t automatically translate into fast failover — the metrics along those redundant links still have to actually satisfy the Feasibility Condition for DUAL to treat them as an instantly usable backup.

Treating a route in Active state as automatically a problem. A route briefly entering Active state after a genuine topology change is completely normal, expected EIGRP behavior. It only becomes a real concern if the Active state persists for an unusually long time, which points toward a Stuck-in-Active condition worth investigating specifically, covered in more depth in EIGRP Packet Types.

Frequently Asked Questions

Does EIGRP use hold-down timers to prevent routing loops?

No — this is a common point of confusion. EIGRP’s actual loop-prevention mechanism is DUAL’s Feasibility Condition, which mathematically guarantees a feasible successor can’t loop back through the local router. EIGRP does have a “Hold Timer,” but it’s an unrelated neighbor-liveness mechanism that detects a dead neighbor, not a loop-prevention tool in the RIP sense.

Why is DUAL considered faster than the way RIP handles convergence?

Two reasons: DUAL only recalculates routes for the specific destinations actually affected by a topology change, leaving unaffected routers and routes untouched, and it maintains pre-verified backup routes (feasible successors) that can be promoted instantly without any recalculation at all, when one is available.

What’s the difference between a route in Passive state and Active state?

Passive means the route is stable and not currently being recomputed — the normal, healthy state. Active means DUAL is actively recalculating that route, typically because the successor failed and no feasible successor was available, requiring Query packets to be sent to neighbors.

Is understanding the DUAL FSM required for the CCNA exam?

The deep formal state-transition logic is generally considered beyond CCNA scope, but the practical concepts it produces — Passive/Active states, successors, and feasible successors — are commonly tested and worth understanding regardless of how deeply the underlying FSM theory is covered.

Does split horizon actually prevent loops in EIGRP, or just improve efficiency?

Primarily efficiency — avoiding the redundant advertisement of a route back to the neighbor it was learned from. Per Cisco’s own documentation, split horizon does combine with an additional rule during the initial topology exchange between two new neighbors to add a layer of loop protection specific to that startup scenario, but DUAL’s Feasibility Condition alone is what guarantees a loop-free topology under normal, ongoing operation.

Conclusion

DUAL is the algorithm underneath EIGRP’s reputation for fast, loop-free convergence — and the Feasibility Condition, not a hold-down timer, is what actually makes the loop-free guarantee possible. Whether a specific route converges almost instantly or has to go through the slower Query/Reply process comes down to one thing: whether a feasible successor was already sitting in the topology table when the failure happened. Understanding that distinction, more than memorizing the formal FSM model behind it, is what makes DUAL’s behavior predictable when troubleshooting a real network under real conditions.