DUAL Algorithm & Path Selection

Deep dive into EIGRP's computational core — Diffusing Update Algorithm (DUAL), Successor and Feasible Successor selection, the Feasibility Condition, topology table metrics (FD/CD/RD), query and reply propagation, and the mechanics behind Stuck-In-Active (SIA) failure states.

Author: Hrishi Pradhan

Level: Basic to Advanced

Sections: 4 Theory

Diagrams: 4 Mermaid

Recommended: Complete Module A first

1. DUAL Algorithm Architecture & Loop Prevention

The computational engine that guarantees loop-free paths

Section 1

What, Where, How & Why

DUAL is EIGRP's path-calculation engine. It computes the best loop-free route (Successor) and keeps qualified backups (Feasible Successors). Use it to achieve instant convergence without query storms. It solves the problem of slow, loop-prone convergence found in classic distance-vector protocols like RIP.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% flowchart TD Start["Route Received from Neighbor"] --> Calc["Calculate CD
(Cumulative Distance)"] Calc --> Check{"Is CD lowest
seen so far?"} Check -->|Yes| Succ["SUCCESSOR
Install in Routing Table
CD becomes FD"] Check -->|No| FeasCheck{"Does RD < FD?"} FeasCheck -->|Yes| FS["FEASIBLE SUCCESSOR
Keep as loop-free backup"] FeasCheck -->|No| Alt["ALTERNATE
Not eligible for FS"] Succ --> End1["Done"] FS --> End1 Alt --> End1 style Succ fill:#10B981,color:#FFF style FS fill:#0EA5E9,color:#FFF style Alt fill:#F59E0B,color:#FFF style Calc fill:#7C3AED,color:#FFF

Successor: The primary path with the lowest Cumulative Distance. Its metric becomes the Feasible Distance (FD).
Feasible Successor: A loop-free backup path whose Reported Distance (RD) is less than the successor's FD.
Alternate: A path that fails the Feasibility Condition. Not eligible as a backup.
Loop-free guarantee: The Feasibility Condition mathematically prevents loops.

2. Topology Metrics & the Feasibility Condition

FD, CD, RD — and the inequality that prevents loops

Section 2

What, Where, How & Why

DUAL uses three distance metrics stored in the topology table. The Feasibility Condition is the mathematical rule that makes EIGRP loop-free. Understanding FD, CD, and RD is essential for every advanced EIGRP troubleshooting scenario.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% flowchart LR R1["R1"] -->|"CD = 100"| R2["R2 (Successor)"] R1 -->|"CD = 120"| R3["R3 (Candidate)"] R2 -->|"RD = 80"| Dest["Destination"] R3 -->|"RD = 90"| Dest style R1 fill:#7C3AED,color:#FFF style R2 fill:#10B981,color:#FFF style R3 fill:#0EA5E9,color:#FFF style Dest fill:#F59E0B,color:#FFF

Feasible Distance (FD): The best (lowest) cumulative metric seen to the destination. In the example, FD = 100.
Cumulative Distance (CD): The total metric to reach the destination through a specific neighbor. R1 via R2 = 100, via R3 = 120.
Reported Distance (RD): The metric a neighbor reports to reach the destination. R2 reports 80, R3 reports 90.
Feasibility Condition: RD < FD. R3's RD (90) is less than R1's FD (100) → R3 qualifies as Feasible Successor.

How the Feasibility Condition Prevents Loops

If R3's RD were 120 (equal to or higher than FD = 100), R3 would be routed back through R1 to reach the destination — creating a loop. The Feasibility Condition mathematically excludes such paths.

Candidate Path	RD	FD	RD < FD?	Result
Via R2 (primary)	80	100	Yes	Successor
Via R3 (case A)	90	100	Yes	Feasible Successor
Via R3 (case B)	105	100	No	Alternate only

3. Query, Reply & Stuck-In-Active (SIA) Mechanics

What happens when a route loses its successor and no feasible successor exists

Section 3

What, Where, How & Why

When the primary path fails and no Feasible Successor exists, DUAL puts the route into Active state and sends queries to all neighbors. Use this knowledge to diagnose convergence delays and SIA events. It solves the problem of a router not knowing whether a backup path is truly loop-free without asking neighbors.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% sequenceDiagram participant R1 as R1 participant R2 as R2 participant R3 as R3 Note over R1: Successor fails
No Feasible Successor R1->>R1: Route enters ACTIVE state R1->>R2: Query (multicast 224.0.0.10) R1->>R3: Query (multicast 224.0.0.10) R2-->>R1: Reply (Positive) R3-->>R1: Reply (Negative) Note over R1: Best Reply wins
Route becomes PASSIVE

Active State: The route is being queried because no Feasible Successor exists.
Query: Sent via multicast 224.0.0.10 to all neighbors, asking "Do you have a path to X?"
Reply: Sent via unicast back to the querying router with the neighbor's answer.
Positive Reply: The neighbor has a valid path — becomes the new successor.
Negative Reply: The neighbor has no path — sends delay infinity.

The SIA Problem

If a neighbor does not reply to the query within the Active Timer (default 3 minutes), the querying router declares that neighbor Stuck-In-Active (SIA). The neighbor relationship is torn down, causing cascading route failures.

Timer	Default	Purpose
Active Timer	3 minutes	How long to wait for query replies before declaring SIA
SIA Query Timer	1.5 minutes	Half of active timer — sends SIA-Query to confirm neighbor is alive
SIA Reply Timer	1.5 minutes	Time for neighbor to respond to SIA-Query

Why This Matters

SIA events usually indicate a design problem — a router is too deep in the query domain, or a link is too slow to reply in time. Real production outages often trace back to a single SIA that cascaded across the network. Knowing how to diagnose and prevent SIA is a CCIE-level skill.

4. Query Scope Confinement — Stub Routing & Summarization

The production techniques that prevent SIA events

Section 4

What, Where, How & Why

Stub routing and summarization are the two design patterns that stop query propagation from turning into network-wide chaos. Use them on edge routers and at boundary points to confine EIGRP queries to small domains. They solve the problem of SIA events cascading across large networks.

%%{init: { 'theme': 'base', 'themeVariables': { 'fontSize': '12px' }}}%% flowchart TD Core["Core Network
(Full EIGRP)"] -->|Query| Border1["Border Router
(Summarization Point)"] Border1 -.Query Stopped.-x Branch1["Branch Stub Router"] Border1 -.Query Stopped.-x Branch2["Branch Stub Router"] style Core fill:#7C3AED,color:#FFF style Border1 fill:#F59E0B,color:#FFF style Branch1 fill:#10B981,color:#FFF style Branch2 fill:#10B981,color:#FFF

Stub Routing: A stub router advertises limited routes (connected, summary, static, redistributed) and does not forward queries to other stubs.
Summarization: A boundary router advertises a summary route instead of individual subnets. Queries about the specific subnets stop at the boundary.
Result: The query domain stays small. Large networks with many branch routers no longer experience cascading SIA events.

Stub Configuration Options

Keyword	What It Does
`connected`	Advertise directly connected networks
`static`	Advertise static routes
`summary`	Advertise summary routes
`redistributed`	Advertise redistributed routes (rare on stubs)
`receive-only`	Advertise nothing — receive-only mode

Production Example

router eigrp 1234
 eigrp stub connected summary
 ! Advertises only connected + summary routes
 ! Never forwards queries to other stub routers

interface GigabitEthernet0/0
 ip summary-address eigrp 1234 10.16.0.0 255.255.240.0
 ! Boundary summarization -- queries for specific /24s stop here

The Golden Rule of EIGRP Design

Every EIGRP network should be designed so that the query domain is small. Stub routers at the edge and summarization at boundaries turn a potentially fragile 500-router network into a resilient 20-router core with hundreds of isolated edge stubs. This is what separates amateur EIGRP designs from production-grade ones.