CCNA: EIGRP Fundamentals
Enhanced Interior Gateway Routing Protocol (EIGRP) sits in a unique position among routing protocols. It was developed by Cisco in the late 1980s as a proprietary replacement for IGRP, remained closed for decades, and was finally published as an informational RFC (RFC 7868) in 2016. It is classless, supports variable-length subnet masking, converges faster than almost any other IGP in common use, and is the only protocol in the CCNA exam scope that supports unequal-cost load balancing. For engineers preparing for CCNA, EIGRP is also the protocol most likely to generate confusion around its core convergence algorithm, the Diffusing Update Algorithm (DUAL), and specifically around the feasibility condition that separates a feasible successor from a route that merely looks attractive. This post covers all of it — from first principles through complete lab configurations with annotated IOS output.
1. What EIGRP Is
EIGRP is commonly called a hybrid or advanced distance-vector protocol, though Cisco itself describes it as an advanced distance-vector protocol. The “hybrid” label comes from the fact that it borrows certain characteristics from link-state protocols — most notably, it maintains a topology database that stores more than just the best route to each destination — but its underlying convergence algorithm is rooted in distance-vector mathematics. Neighbors do not flood link-state advertisements to the entire autonomous system; instead, they exchange routing information directly with adjacent neighbors, and the metric reported by a neighbor is trusted as an opaque number, not computed independently from a map of the network. This is the fundamental distinction from OSPF.
Key Characteristics
Autonomous system number. EIGRP requires all neighbors to share the same autonomous system (AS) number. The AS number is a locally significant integer configured on the router; it does not carry the same weight as a BGP AS number, but it must match on both sides of an adjacency or the adjacency will not form. A router running router eigrp 100 will only peer with a neighbor also running router eigrp 100.
Classless with VLSM support. EIGRP carries subnet mask information in its routing updates, so it correctly handles discontiguous networks and any prefix length. Unlike RIPv1 or IGRP, it does not assume a classful boundary.
Partial and bounded updates. EIGRP does not send periodic full routing table broadcasts. After the initial full update exchange when a neighbor relationship forms, EIGRP sends only incremental changes (partial updates), and only to the neighbors affected by the change (bounded updates). This dramatically reduces bandwidth consumption compared to RIP, which sends its full routing table every 30 seconds to the broadcast address.
Rapid convergence via DUAL. When a route’s best path fails and a pre-computed backup path exists, EIGRP can failover in milliseconds without sending any queries to the network. When no backup exists, it uses a controlled query-reply process. The algorithm that governs this is DUAL, covered in depth in sections 5 and 6.
Reliable Transport Protocol (RTP). EIGRP has its own transport layer mechanism called RTP that provides guaranteed, ordered delivery for certain packet types without relying on TCP. It uses sequence numbers and selective acknowledgments. Hello packets are sent unreliably (no ACK required); Update, Query, Reply, and ACK packets are sent reliably.
Multicast address 224.0.0.10. EIGRP uses the reserved multicast address 224.0.0.10 (all EIGRP routers) for Hello and Update packets sent to neighbors on a segment, with unicast used for retransmissions.
Protocol support. EIGRP originally supported IP, IPX, and AppleTalk. IPX and AppleTalk support is long deprecated. EIGRP for IPv6 is configured separately using the ipv6 router eigrp command or within a named-mode address family.
Router ID. Like OSPF, EIGRP uses a 32-bit router ID expressed in dotted-decimal notation. It is selected by the highest loopback IP address, then highest active interface IP address, and can be manually configured (recommended for stability).
2. EIGRP vs OSPF vs RIP
The table below covers the dimensions most likely to appear on CCNA exams and in practical deployment decisions.
| Characteristic | RIPv2 | EIGRP | OSPFv2 |
|---|---|---|---|
| Algorithm | Bellman-Ford | DUAL (distance-vector basis) | Dijkstra SPF (link-state) |
| Update type | Full table, periodic (30s) | Partial, bounded, event-driven | Partial LSA floods, event-driven |
| Metric | Hop count (max 15) | Composite (BW + delay by default) | Cost (reference BW / link BW) |
| Convergence speed | Slow (minutes) | Very fast (sub-second with FS) | Fast (seconds to minutes) |
| Resource usage (CPU) | Low | Low-moderate | Higher (SPF recalculation) |
| Resource usage (memory) | Low | Moderate (topology table) | Higher (LSDB) |
| Open standard | Yes (RFC 2453) | Informational RFC 7868 (2016) | Yes (RFC 2328) |
| Scalability | Poor (15-hop limit) | Good (bounded queries) | Very good (area hierarchy) |
| VLSM / classless | Yes | Yes | Yes |
| Unequal-cost LB | No | Yes (variance command) | No (equal-cost only) |
| Authentication | MD5, plain text | MD5, SHA-256 (named mode) | MD5, SHA-256 (OSPFv3) |
| Administrative distance | 120 | 90 (internal), 170 (external) | 110 |
| Multicast address | 224.0.0.9 | 224.0.0.10 | 224.0.0.5 / 224.0.0.6 |
| Hello interval (default) | 30s (LAN) | 5s (LAN), 60s (WAN) | 10s (LAN), 30s (WAN) |
| Hold time (default) | 180s | 15s (LAN), 180s (WAN) | 40s (LAN), 120s (WAN) |
The administrative distance values are critical for CCNA: EIGRP internal routes (originating within the EIGRP AS) carry AD 90, redistributed routes carry AD 170. OSPF is 110, RIP is 120. When multiple routing protocols learn the same prefix, the route with the lowest AD wins.
3. EIGRP Packet Types
EIGRP defines five packet types. Understanding them is important both for exam questions and for troubleshooting with debug eigrp packets.
Hello
Hello packets serve two purposes: neighbor discovery and keepalive. A router sends Hellos periodically to 224.0.0.10. When a router receives a Hello from a neighbor it has not yet seen, and the parameters in that Hello (AS number, K-values, authentication) match, it initiates the neighbor relationship by sending a full Update. Hello packets are sent unreliably — there is no ACK — because a missing Hello is simply noticed when the hold timer expires.
Default Hello intervals: 5 seconds on Ethernet and other high-bandwidth interfaces, 60 seconds on low-bandwidth WAN interfaces (T1 and below, multipoint). The hold time defaults to three times the Hello interval (15 seconds on LAN, 180 seconds on WAN). These can be tuned per-interface:
R1(config-if)# ip hello-interval eigrp 100 2
R1(config-if)# ip hold-time eigrp 100 6
Important: The hold time is communicated to the neighbor in the Hello packet so that the neighbor knows how long to wait before declaring the router dead. The two sides of an adjacency do not need to have matching Hello or hold times. This differs from OSPF, where mismatched Hello or Dead timers prevent adjacency formation.
Update
Update packets carry routing information. After initial neighbor formation, full Updates are exchanged once. Thereafter, only changes trigger partial Updates. Updates use RTP (reliable delivery with ACK). They are sent as multicast when multiple neighbors on a segment need the same information, or unicast when retransmitting to a single neighbor that did not acknowledge.
Query
When a router loses its best path to a destination and has no feasible successor (no backup in the topology table that satisfies the feasibility condition), it transitions the route to the ACTIVE state and sends Queries to all neighbors. The Query asks: “Do you have an alternate path to this destination?” Queries propagate through the network, bounded by the scope of the EIGRP domain. This is the mechanism that can cause the “stuck in active” (SIA) problem discussed in the troubleshooting section.
Reply
A Reply is sent in response to a Query. Every router that receives a Query must send a Reply, either with its own metric to the destination or with an indication that it has no route. The originating router waits for Replies from all queried neighbors before exiting the ACTIVE state and selecting a new successor.
ACK
An ACK is a Hello packet with no data — just the acknowledgment sequence number. It is used to acknowledge reliable packets (Update, Query, Reply). ACKs are always unicast.
4. EIGRP Neighbor Requirements
An EIGRP adjacency will form when all of the following conditions are met:
| Requirement | Notes |
|---|---|
| Same AS number | Must match exactly. router eigrp 100 on R1 will not peer with router eigrp 200 on R2. |
| Same K-values | The five metric weights (K1 through K5) must be identical. Mismatched K-values cause “K-values mismatch” log messages and no adjacency. Default K1=1, K2=0, K3=1, K4=0, K5=0. |
| Reachability | The router must be able to receive a Hello from the neighbor — they must share a common subnet on the connecting interface. |
| Authentication | If configured, type (MD5 or SHA-256) and key string must match. |
| Interface not passive | A passive interface sends no Hellos and forms no adjacencies, but its connected network is still advertised. |
Subnet mask matching: Unlike OSPF, EIGRP does NOT require matching subnet masks to form an adjacency. Two routers with /24 and /30 addresses on the same physical wire can still form an EIGRP neighbor relationship. However, mismatched masks can cause route advertisement problems and is considered a misconfiguration. For CCNA, remember: OSPF requires mask matching, EIGRP does not.
Network type matching: EIGRP also does not require matching interface network types. OSPF’s notorious NBMA/point-to-point mismatch problem does not apply to EIGRP.
5. The Three EIGRP Tables
EIGRP maintains three separate tables in memory. Each serves a distinct purpose, and understanding the relationship between them is fundamental to understanding DUAL.
5a. Neighbor Table
The neighbor table records all directly adjacent EIGRP routers from which a valid Hello has been received and with which a full adjacency has been established. Each entry includes:
| Field | Meaning |
|---|---|
| H | Handle: an internal index number assigned in order of neighbor discovery, starting at 0. |
| Address | The neighbor’s IP address on the connecting interface. |
| Interface | The local interface through which the neighbor is reachable. |
| Hold | Remaining hold time in seconds. Counts down; reset when a Hello is received. When it reaches 0, the neighbor is declared dead and the adjacency is torn down. |
| Uptime | How long the adjacency has been established. |
| SRTT | Smooth Round-Trip Time in milliseconds. A weighted average of round-trip times for reliable packets. Used to calculate the RTO. |
| RTO | Retransmission Timeout in milliseconds. Calculated as 6 x SRTT (with a floor of 200ms and ceiling of 5000ms). If an ACK is not received within this window, the reliable packet is retransmitted unicast. |
| Q Cnt | Queue count: the number of packets waiting to be sent to this neighbor reliably. A persistently non-zero Q Cnt indicates a problem. |
| Seq Num | The sequence number of the last reliable packet received from this neighbor. |
R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.2.2 Gi0/1 13 01:23:47 4 200 0 47
0 10.1.3.3 Gi0/2 11 01:23:52 3 200 0 39
In this output, R1 has two neighbors: 10.1.2.2 reachable via GigabitEthernet0/1, and 10.1.3.3 via GigabitEthernet0/2. Both have very low SRTT values (3-4ms), indicating fast local links. RTO is floored at 200ms. Q Cnt is 0, meaning no packets are pending. The H=1 for 10.1.2.2 means it was the second neighbor discovered (0-indexed).
5b. Topology Table
The topology table is the heart of EIGRP. It stores every route learned from every neighbor, not just the best route. For each destination network, the topology table tracks:
- The current state: P (Passive, meaning stable and converged) or A (Active, meaning the router is querying neighbors for a replacement path)
- The Feasible Distance (FD): the best total metric from this router to the destination — the metric of the route currently installed via the successor
- For each neighbor that advertises the route: the neighbor’s Advertised Distance (AD), also called Reported Distance (RD), and the full metric via that neighbor
The successor and any feasible successors are both stored here.
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.4.0.0/24, 2 successors, FD is 3072
via 10.1.2.2 (3072/2816), GigabitEthernet0/1
via 10.1.3.3 (3328/2816), GigabitEthernet0/2
Reading this entry: the destination is 10.4.0.0/24. The state is P (Passive, converged). The FD is 3072. The first path (via 10.1.2.2) has a total metric of 3072 and the neighbor’s AD is 2816. The second path (via 10.1.3.3) has a total metric of 3328 and the neighbor’s AD is 2816.
The format is always (total_metric/AD). The total metric is what would be installed in the routing table. The AD is what the neighbor reported.
5c. Routing Table
The routing table contains only the successor route(s) — the best path(s) — for each destination. In the routing table, EIGRP internal routes are marked with the code D (for DUAL/EIGRP) and show the administrative distance and metric in brackets.
R1# show ip route eigrp
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.4.0.0/24 [90/3072] via 10.1.2.2, 01:23:47, GigabitEthernet0/1
D EX 172.16.0.0/16 [170/5120] via 10.1.2.2, 00:15:22, GigabitEthernet0/1
The D code is EIGRP internal. D EX is EIGRP external (redistributed from another protocol). [90/3072] means administrative distance 90 and EIGRP metric 3072.
6. DUAL – Diffusing Update Algorithm
DUAL was developed by J.J. Garcia-Luna-Aceves and is the mechanism that gives EIGRP its convergence speed and loop-free guarantee. Every concept in this section must be understood precisely, because the CCNA exam tests it at the definition level, not just conceptually.
Core Definitions
Feasible Distance (FD)
The FD is the lowest-cost metric from the local router to the destination that has been recorded. Critically: the FD is the metric of the current best path (the successor route). It represents the router’s own best-known total distance to the destination. The FD is stored in the topology table and is updated when a better path is found.
Advertised Distance (AD) / Reported Distance (RD)
The AD (these terms are used interchangeably; Cisco documentation uses both) is the metric that a neighbor reports for reaching a destination. It represents the neighbor’s own cost to the destination. When a neighbor sends an Update or Reply for a prefix, the metric it includes is its AD. The local router adds the cost of the link to that neighbor to compute the total metric for the route.
Total metric via neighbor = AD + link_cost_to_neighbor
This total metric is what appears as the left number in the (total_metric/AD) pair in the topology table.
Successor
The successor is the neighbor providing the best (lowest total metric) path to a destination. The successor’s route is installed in the routing table. If multiple neighbors provide equal-cost paths, multiple successors exist (up to the maximum-paths limit).
Feasible Successor (FS)
A feasible successor is a neighbor that provides a backup path to a destination and that satisfies the feasibility condition. A feasible successor is stored in the topology table but not in the routing table. If the successor fails, EIGRP can immediately promote the feasible successor to successor and update the routing table without any query process.
Feasibility Condition (FC)
The feasibility condition is: a neighbor’s Advertised Distance must be strictly less than the current Feasible Distance.
AD_neighbor < FD_current --> feasible successor (loop-free backup)
AD_neighbor >= FD_current --> NOT a feasible successor (could cause a loop)
This condition is a loop prevention guarantee. If a neighbor’s AD is less than the local router’s FD, then that neighbor has a shorter path to the destination than the best path this router has ever seen. It cannot be routing through this router to reach the destination — it has a shorter path independently. Therefore, using that neighbor as a backup cannot create a routing loop.
If the condition is not met, the route might still exist in the topology table, but it will NOT be marked as a feasible successor and will NOT be used for instant failover. It will only be considered after a full query-reply cycle determines it is safe.
ACTIVE vs PASSIVE State
A route in PASSIVE (P) state is stable. A route enters ACTIVE (A) state when the successor is lost and no feasible successor exists. In ACTIVE state, the router sends Queries to all EIGRP neighbors. It waits for a Reply from every neighbor queried. Once all Replies are received, the router selects a new successor from the responses, transitions back to PASSIVE, and updates the routing table.
A router that receives a Query first checks its own topology table. If it has an alternate path (a successor for that prefix), it Replies immediately with its metric. If it does not, it must Query its own neighbors – the Query diffuses outward through the network (hence “Diffusing Update Algorithm”). The boundary of this diffusion is the query boundary – routers with alternate paths or stub routers absorb the query and reply without propagating it further.
7. DUAL Worked Example
This section traces DUAL completely through a four-router topology. Work through every number manually – this is the only way to internalize the feasibility condition.
Topology
10.1.2.0/30 (GigE) 10.2.4.0/30 (GigE)
R1 -------------------- R2 ----------------------+
| |
| 10.1.3.0/30 (FastE) 10.3.4.0/30 (GigE) R4 --- 10.4.0.0/24
+-------------------- R3 ----------------------+
Interface parameters:
R1 <-> R2 : GigabitEthernet, bandwidth 1,000,000 Kbps, delay 10 usec
R1 <-> R3 : FastEthernet, bandwidth 100,000 Kbps, delay 100 usec
R2 <-> R4 : GigabitEthernet, bandwidth 1,000,000 Kbps, delay 10 usec
R3 <-> R4 : GigabitEthernet, bandwidth 1,000,000 Kbps, delay 10 usec
R4 -> 10.4.0.0/24 : GigabitEthernet, bandwidth 1,000,000 Kbps, delay 10 usec
Step 1 – Compute R4’s Metric for 10.4.0.0/24
10.4.0.0/24 is directly connected to R4 on a GigabitEthernet interface. R4’s metric to this network (using the simplified formula Metric = 256 * (10^7/min_bw + sum_delay_in_10us)):
Delay in tens-of-microseconds = 10 usec / 10 = 1
Metric = 256 * (10,000,000/1,000,000 + 1)
= 256 * (10 + 1)
= 256 * 11
= 2816
R4 advertises AD = 2816 to both R2 and R3.
Step 2 – Compute R2’s and R3’s Metrics
R2’s metric to 10.4.0.0/24 (via GigE R2-R4):
R2 adds its own interface delay to what R4 reported:
Min bandwidth along R2->R4->10.4.0.0: 1,000,000 Kbps (all GigE)
Cumulative delay: R2-R4 (1) + R4-10.4 (1) = 2 ... but EIGRP accumulates
all delays end-to-end from R2's perspective.
Delay at R2->R4 interface = 10 usec = 1 unit
Delay at R4->10.4 interface = 10 usec = 1 unit
Sum = 2
Metric = 256 * (10 + 2) = 256 * 12 = 3072
R2’s FD = 3072. R2 advertises AD = 3072 to R1.
R3’s metric to 10.4.0.0/24 (via GigE R3-R4):
Min bandwidth: 1,000,000 Kbps (GigE R3-R4 is not the bottleneck)
Cumulative delay: R3-R4 (1) + R4-10.4 (1) = 2
Metric = 256 * (10 + 2) = 3072
R3’s FD = 3072. R3 advertises AD = 3072 to R1.
Both R2 and R3 report the same AD (3072) to R1.
Step 3 – Compute R1’s Total Metrics
R1 via R2 (GigE R1-R2, then R2->R4->10.4.0.0):
Min bandwidth along entire path R1->R2->R4->10.4.0.0: 1,000,000 Kbps
Cumulative delay: R1-R2 (1) + R2-R4 (1) + R4-10.4 (1) = 3
Metric = 256 * (10 + 3) = 256 * 13 = 3328
R2's AD = 3072
R1 via R3 (FastEthernet R1-R3, then R3->R4->10.4.0.0):
Min bandwidth along entire path: 100,000 Kbps (FastEthernet bottleneck on R1-R3)
Cumulative delay: R1-R3 (10) + R3-R4 (1) + R4-10.4 (1) = 12
Note: FastEthernet delay = 100 usec = 10 units of 10us
Metric = 256 * (10,000,000/100,000 + 12) = 256 * (100 + 12) = 256 * 112 = 28,672
R3's AD = 3072
Step 4 – DUAL Evaluation at R1
| Via | Total Metric | AD | Is AD < FD? | Result |
|---|---|---|---|---|
| R2 | 3328 | 3072 | (FD not yet set) | Lowest metric – becomes SUCCESSOR; FD = 3328 |
| R3 | 28672 | 3072 | 3072 < 3328? YES | FEASIBLE SUCCESSOR |
R1’s topology table:
R1# show ip eigrp topology
P 10.4.0.0/24, 1 successors, FD is 3328
via 10.1.2.2 (3328/3072), GigabitEthernet0/1 <-- SUCCESSOR
via 10.1.3.3 (28672/3072), FastEthernet0/2 <-- FEASIBLE SUCCESSOR
R2 is the successor (lowest total metric = 3328, which becomes the FD). R3 is a feasible successor because R3’s AD (3072) is strictly less than FD (3328). Both paths are stored. Only the successor’s route enters the routing table.
Step 5 – Successor Fails (with FS available)
R1-R2 link goes down. EIGRP detects this immediately (link-down event or hold timer expiry).
DUAL checks topology table:
- Is there a feasible successor for 10.4.0.0/24? YES -- R3 at metric 28672
Action:
- Promote R3 to SUCCESSOR
- Install via 10.1.3.3 / FastEthernet0/2 in routing table
- Update FD to 28672
- Remain in PASSIVE state
- NO Query sent to any neighbor
Convergence: sub-second (milliseconds). The routing table update happens in the same interrupt that processes the topology change.
R1# show ip eigrp topology
P 10.4.0.0/24, 1 successors, FD is 28672
via 10.1.3.3 (28672/3072), FastEthernet0/2 <-- now SUCCESSOR
Step 6 – The Feasibility Condition Failure Case
Now change the topology: imagine a fifth router R5 connected to R1 with a moderate-speed link. R5 reaches 10.4.0.0/24 through a long chain that eventually loops back through R1’s best path. R5 reports AD = 4000 to R1 for 10.4.0.0/24.
With FD = 3328 (from the R2 successor path):
R5's AD = 4000
FD = 3328
Is 4000 < 3328? NO -- feasibility condition FAILS.
R5 is NOT a feasible successor.
Why must we exclude R5? Because R5’s AD (4000) is greater than R1’s FD (3328). R5’s path to 10.4.0.0/24 is worse than the best path R1 has ever seen. There is a real possibility that R5 is routing to 10.4.0.0/24 by sending traffic to R1, then relying on R1’s R2 path. If R1 then failed over to R5, R1 would send traffic to R5, R5 would send it back to R1, and a routing loop would form. DUAL’s feasibility condition prevents this by construction.
R5’s route appears in show ip eigrp topology all-links but not in the standard output. It will not be used for instant failover. If R2 and the FS (R3) were both unavailable, EIGRP would go ACTIVE, send Queries to all neighbors including R5, and wait for Replies before selecting a new path.
DUAL State Machine
Route in PASSIVE (P) state
|
| Successor link fails or metric worsens
v
+------------------------+
| Check topology table |
| for feasible successor |
+------------------------+
/ \
FS exists No FS exists
/ \
v v
Promote FS to SUCCESSOR. Route goes ACTIVE (A).
Install in routing table. Send Query to ALL neighbors.
Update FD. Wait for Reply from each.
Stay PASSIVE. |
(sub-second convergence) | All Replies received
v
Evaluate all Reply metrics.
Select new SUCCESSOR (lowest metric
that satisfies FC against new FD).
Install in routing table.
Transition to PASSIVE.
(seconds; depends on query scope)
8. EIGRP Composite Metric
EIGRP’s composite metric is one of its most powerful and misunderstood features. It allows administrators to express path quality as a function of multiple variables – primarily bandwidth and delay – rather than a simple hop count.
The Formula
The complete composite metric formula is:
Metric = 256 * [(K1 * Bw) + ((K2 * Bw) / (256 - Load)) + (K3 * Delay)]
* [K5 / (Reliability + K4)]
Where:
Bw = 10^7 / (minimum interface bandwidth in Kbps along the entire path)
Delay = sum of all interface delays (in tens of microseconds) along the path
Load = composite interface load, 1-255 (255 = 100%)
Reliability = composite interface reliability, 1-255 (255 = 100%)
K1..K5 = configurable metric weights
Default K-values: K1=1, K2=0, K3=1, K4=0, K5=0.
With defaults, the formula simplifies to:
Metric = 256 * (Bw + Delay)
= 256 * (10^7 / min_bw_kbps + sum_delay_in_tens_of_microseconds)
The K5=0 case deserves explanation: when K5=0, the entire second multiplier [K5/(Reliability+K4)] is treated as 1 by the IOS implementation (not 0), so reliability does not affect the metric. K2=0 eliminates load from the formula. The result: by default, EIGRP metric depends only on bandwidth and delay.
This is deliberate. If load or reliability were in the metric by default, routes would flap constantly as traffic load changes. Stable routing requires stable metrics.
Bandwidth Component
Bw = 10^7 / interface_bandwidth_kbps
The bandwidth term uses the minimum bandwidth along the entire path from the computing router to the destination. It is the bottleneck bandwidth. Adding more hops on fast links does not increase the Bw term – only the slowest link matters.
The bandwidth value is taken from the bandwidth interface command (default = physical link speed in Kbps).
| Interface Type | Default Bandwidth (Kbps) | Bw Term (10^7 / BW) |
|---|---|---|
| GigabitEthernet | 1,000,000 | 10 |
| FastEthernet | 100,000 | 100 |
| Serial T1 | 1,544 | 6,476 |
| Serial 512K | 512 | 19,531 |
| Loopback | 8,000,000 | 1 |
Delay Component
Delay = sum of (interface_delay / 10) for all interfaces along path
The delay term uses the sum of all interface delays. Unlike bandwidth, delay is cumulative – every hop adds its own delay to the total. This means longer paths through slow links accumulate delay rapidly.
The delay shown by show interfaces is in microseconds. The EIGRP formula uses tens of microseconds, so divide by 10.
| Interface Type | show interfaces Delay | Formula Units (delay/10) |
|---|---|---|
| GigabitEthernet | 10 usec | 1 |
| FastEthernet | 100 usec | 10 |
| Serial T1 | 20,000 usec | 2,000 |
| Serial 512K | 20,000 usec | 2,000 |
Worked Metric Calculation
Path: R1 -> R2 (GigE) -> R4 (GigE) -> 10.4.0.0/24 (GigE)
Min bandwidth: 1,000,000 Kbps (all GigE)
Cumulative delay:
R1-R2 interface: 1 (10 usec / 10)
R2-R4 interface: 1
R4-10.4.0.0 interface: 1
Total: 3
Metric = 256 * (10,000,000/1,000,000 + 3)
= 256 * (10 + 3)
= 256 * 13
= 3,328
Path: R1 -> R3 (FastE) -> R4 (GigE) -> 10.4.0.0/24 (GigE)
Min bandwidth: 100,000 Kbps (FastEthernet is the bottleneck)
Cumulative delay:
R1-R3 interface (FastE): 10 (100 usec / 10)
R3-R4 interface (GigE): 1
R4-10.4.0.0 (GigE): 1
Total: 12
Metric = 256 * (10,000,000/100,000 + 12)
= 256 * (100 + 12)
= 256 * 112
= 28,672
The GigE path (3,328) is strongly preferred over the FastEthernet path (28,672). The metric difference is large enough that even variance 8 would not include the FastEthernet path (28,672 > 8 * 3,328 = 26,624).
Tuning Metrics with Interface Commands
R1(config)# interface Serial0/0/0
R1(config-if)# bandwidth 512
R1(config-if)# delay 2000
The bandwidth command sets the bandwidth in Kbps used for EIGRP metric calculation (and for IOS bandwidth reservation features). It does NOT change the actual interface clock rate. The delay command sets the delay in tens of microseconds used in the metric. Neither command affects actual data transfer speed.
Changing these values affects EIGRP metrics, which can trigger DUAL recalculation and change routing decisions. It can also affect whether routes satisfy the feasibility condition, potentially enabling or disabling feasible successors. Always consider the full impact before tuning.
Wide Metrics (Named Mode)
The classic 32-bit metric was designed when GigabitEthernet was the fastest interface type. As 10GbE, 40GbE, and 100GbE became common, the Bw term collapsed:
10GbE: 10^7 / 10,000,000 = 1
40GbE: 10^7 / 40,000,000 = 0.25 -> rounds to 0
100GbE: 10^7 / 100,000,000 = 0.1 -> rounds to 0
A Bw term of 0 means EIGRP cannot differentiate between a 10GbE and a 100GbE path. EIGRP named mode uses a 64-bit wide metric with a scaled formula:
Wide Bw = 10^13 / min_bw_kbps
Wide Delay = sum of delay in picoseconds
Wide Metric = (Wide Bw + Wide Delay) * RIB_scale
Wide metrics are backward-compatible: classic-mode and named-mode routers can peer, but the wide metric is only meaningful end-to-end when all routers are in named mode.
9. Unequal-Cost Load Balancing
This is EIGRP’s most distinctive feature and one of its most powerful in real deployments. OSPF supports only equal-cost load balancing; EIGRP can simultaneously use paths with different metrics and distribute traffic proportionally.
The variance Command
R1(config-router)# variance 2
variance N tells EIGRP: install any feasible successor path whose total metric is no greater than N times the FD (the successor’s metric).
Path qualifies for routing table if:
path_metric <= variance * FD
AND
path is a feasible successor (AD < FD)
Both conditions must be true. Variance alone is not sufficient – the path must also be a feasible successor. This is non-negotiable from DUAL’s perspective: a path that fails the feasibility condition could cause a loop and is never used for load balancing regardless of the variance value.
Default variance is 1, which means only equal-cost paths (metric = FD) are installed.
Traffic Distribution
When multiple paths are installed with different metrics, EIGRP distributes traffic in inverse proportion to their metrics. A lower-metric path carries proportionally more traffic.
Example calculation with two paths:
Path A (successor): metric = 3,328 (via GigE)
Path B (FS): metric = 4,500 (via slightly slower GigE)
variance = 2
Is 4500 <= 2 * 3328 = 6656? YES. Path B qualifies.
Traffic shares (inverse of metric):
Path A weight = 1/3328
Path B weight = 1/4500
Total weight = 1/3328 + 1/4500
= 4500/(3328*4500) + 3328/(3328*4500)
= (4500 + 3328) / (3328 * 4500)
= 7828 / 14,976,000
Path A share = (4500/14,976,000) / (7828/14,976,000) = 4500/7828 = 57.5%
Path B share = (3328/14,976,000) / (7828/14,976,000) = 3328/7828 = 42.5%
IOS implements this as integer traffic share counts in the routing table:
R1# show ip route 10.4.0.0
Routing entry for 10.4.0.0/24
Known via "eigrp 100", distance 90, metric 3328
Routing Descriptor Blocks:
* 10.1.2.2, from 10.1.2.2, via GigabitEthernet0/1
Route metric is 3328, traffic share count is 45
10.1.2.6, from 10.1.2.6, via GigabitEthernet0/3
Route metric is 4500, traffic share count is 33
The traffic share counts (45 and 33) represent the relative proportion of packets forwarded on each path. Their ratio approximates the inverse-metric ratio.
maximum-paths Command
R1(config-router)# maximum-paths 8
Controls how many paths EIGRP installs in the routing table simultaneously. Default is 4. Maximum is 32. This applies to both equal-cost and (with variance) unequal-cost paths.
Summary: Path Selection Logic
Step 1: Find the path with lowest total metric -> SUCCESSOR (FD = this metric)
Step 2: For each remaining path:
- Compute: is AD < FD?
YES -> mark as FEASIBLE SUCCESSOR (stored in topology table)
NO -> mark as non-feasible (stored only in topology all-links)
Step 3: With variance N, for each feasible successor:
- Is path_metric <= N * FD?
YES -> install in routing table alongside successor
NO -> stays in topology table only (not in routing table)
Step 4: Stop adding paths when maximum-paths limit is reached.
10. EIGRP Configuration
Classic Mode
Classic mode uses a flat router eigrp configuration block. This is the style covered by most CCNA study materials and present on all IOS versions that support EIGRP.
R1(config)# router eigrp 100
R1(config-router)# eigrp router-id 1.1.1.1
R1(config-router)# network 10.1.2.0 0.0.0.3
R1(config-router)# network 10.1.3.0 0.0.0.3
R1(config-router)# network 192.168.1.0 0.0.0.255
R1(config-router)# no auto-summary
R1(config-router)# passive-interface GigabitEthernet0/3
R1(config-router)# variance 2
R1(config-router)# maximum-paths 4
The network command specifies which interfaces participate in EIGRP. An interface is included if its IP address falls within the range defined by the network address and wildcard mask. The wildcard mask is optional in classic mode – without it, IOS uses the classful mask for the given address class. network 10.0.0.0 (no wildcard) matches all 10.x.x.x interfaces. network 10.1.2.0 0.0.0.3 matches only addresses in 10.1.2.0 through 10.1.2.3.
no auto-summary disables automatic classful summarization. In older IOS, EIGRP automatically summarized routes to their classful boundary when advertising across classful boundaries. This causes incorrect routing for discontiguous networks (two 10.x.x.x subnets separated by a 192.168.x.x network, for example). Always configure no auto-summary in classic mode unless you have a specific reason to keep classful summarization. In IOS 15.x and later, no auto-summary is the default.
passive-interface prevents EIGRP from sending or receiving Hellos on the specified interface, so no adjacency can form there. However, the interface’s connected network is still advertised into EIGRP by the local router. Use this on any interface facing end users, DMZs, or any segment where you don’t want an EIGRP neighbor to form.
passive-interface default with selective exceptions:
R1(config-router)# passive-interface default
R1(config-router)# no passive-interface GigabitEthernet0/0
R1(config-router)# no passive-interface GigabitEthernet0/1
This pattern is more secure: start with all interfaces passive, then explicitly enable EIGRP only on interfaces that need to form adjacencies.
Named Mode (Modern, Recommended)
Named mode (IOS 15.0(1)M+) provides a hierarchical configuration structure, enables wide metrics by default, supports multiple address families in one process, and supports SHA-256 authentication.
R1(config)# router eigrp MYORG
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# eigrp router-id 1.1.1.1
R1(config-router-af)# network 10.1.2.0 0.0.0.3
R1(config-router-af)# network 10.1.3.0 0.0.0.3
R1(config-router-af)# network 192.168.1.0 0.0.0.255
R1(config-router-af)# variance 2
R1(config-router-af)# maximum-paths 4
!
R1(config-router-af)# af-interface GigabitEthernet0/3
R1(config-router-af-interface)# passive-interface
R1(config-router-af-interface)# exit-af-interface
!
R1(config-router-af)# af-interface default
R1(config-router-af-interface)# authentication mode hmac-sha-256
R1(config-router-af-interface)# authentication key-chain EIGRP_KEYS
R1(config-router-af-interface)# exit-af-interface
!
R1(config-router-af)# exit-address-family
The process name (MYORG) is locally significant and does not need to match between routers. The AS number inside the address family (100) must match. Named mode does not require no auto-summary because classful summarization does not apply to the named-mode framework.
For IPv6 in the same process:
R1(config)# router eigrp MYORG
R1(config-router)# address-family ipv6 unicast autonomous-system 100
R1(config-router-af)# eigrp router-id 1.1.1.1
R1(config-router-af)# network ::/0
11. Manual Summarization
Manual summarization reduces routing table size, stabilizes the network during topology changes, and – critically for DUAL – limits the scope of Queries.
Configuration
Summarization is configured on the outbound interface – the interface facing the direction you want to advertise the summary:
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip summary-address eigrp 100 192.168.0.0 255.255.252.0
This causes R1 to advertise 192.168.0.0/22 out GigabitEthernet0/0 instead of the four component /24 routes (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24). The component routes are suppressed from advertisement out that interface.
The Null0 Summary Route
When a summary is configured, IOS automatically installs a route to the summary prefix pointing to Null0 with administrative distance 5:
R1# show ip route 192.168.0.0 255.255.252.0
Routing entry for 192.168.0.0/22
Known via "eigrp 100", distance 5, metric 0
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
This Null0 route prevents routing loops. Suppose R1 has advertised 192.168.0.0/22 to its upstream neighbor, but the specific 192.168.1.0/24 component route is temporarily down. If an upstream router sends a packet destined for 192.168.1.100, R1 receives it. Without the Null0 route, R1 would have no match for 192.168.1.0/24 and might fall back to a default route or send the packet back upstream – creating a loop. With the Null0 route, 192.168.1.100 matches 192.168.0.0/22 and is dropped cleanly, preventing the loop. The AD of 5 ensures the Null0 summary is always preferred over any other protocol’s route to the same prefix.
Summarization and Query Scope
When a query for a component route (192.168.1.0/24) reaches R1, R1 checks its topology table. It finds that the 192.168.0.0/22 summary is still valid (other component routes exist). R1 replies to the query immediately rather than propagating it further. The query does not cross the summarization boundary. This is why summarization is a best practice in large EIGRP deployments: it creates natural query boundaries and prevents SIA conditions from propagating across the network.
12. EIGRP Stub
The stub feature is designed for hub-and-spoke topologies. A spoke router is a “stub” if all its EIGRP neighbors are on the hub side and it has no alternate paths to offer. Declaring it a stub prevents the hub from sending Queries to it, dramatically reducing the query domain.
Configuration
R3(config)# router eigrp 100
R3(config-router)# eigrp stub connected summary
Stub options:
| Option | What the stub router advertises |
|---|---|
| connected | Directly connected networks (most common) |
| summary | Manually configured summary routes |
| static | Redistributed static routes |
| redistributed | All redistributed routes |
| receive-only | Nothing – the router only receives routes, cannot transit |
eigrp stub connected summary is the standard configuration for a branch router: it can receive routes from the hub and advertise its local networks, but it will not be asked to help the hub find alternate paths.
How Stub Reduces Query Scope
Without stub in a hub-and-spoke network:
Hub (R1) loses route to 10.100.0.0/24.
R1 has no FS. Goes ACTIVE.
R1 sends Query to ALL neighbors: R2 (spoke), R3 (spoke), R4 (spoke).
R2, R3, R4 have no path to 10.100.0.0/24.
They must Query THEIR neighbors, which may only be R1.
R1 receives Queries from spokes asking about a route R1 just queried them about.
Delays and potential SIA if any spoke is slow to respond.
With stub configured on R2, R3, R4:
Hub (R1) loses route to 10.100.0.0/24.
R1 has no FS. Goes ACTIVE.
R1 checks neighbor flags: R2, R3, R4 are all stub.
R1 does NOT send Queries to stub neighbors.
R1 has no non-stub neighbors that might have an alternate path.
R1 transitions to PASSIVE with no feasible route (or finds route via another mechanism).
Convergence is immediate -- no Query propagation at all.
The stub flag is communicated in the Hello packet. The hub stores this flag per neighbor and uses it to determine who to query.
Stub Does Not Mean Isolated
A stub router:
- Maintains full EIGRP adjacency with the hub
- Receives all routes from the hub and installs them in its routing table
- Advertises its connected and summary routes to the hub
- Is simply excluded from the Query process – it will not be asked to help find alternate paths
A stub router is NOT the same as a passive interface. A passive interface prevents adjacency formation. A stub router has a complete adjacency but with limited query participation.
13. Complete Verification Commands with Annotated Output
show ip eigrp neighbors
R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.2.2 Gi0/1 13 02:14:33 3 200 0 52
0 10.1.3.2 Gi0/2 11 02:14:41 4 200 0 44
H=1 means 10.1.2.2 was the second neighbor discovered.
H=0 means 10.1.3.2 was the first.
Hold=13: 13 seconds remain before R1 declares 10.1.2.2 dead.
The hold timer for neighbor 10.1.2.2 was set to 15s (as advertised in
R2's Hello packet). It is currently at 13 and counting down.
Each Hello received from 10.1.2.2 resets it to 15.
Uptime: This adjacency has been stable for over 2 hours.
SRTT=3ms: Very low round-trip time. These are LAN links.
RTO=200ms: Floor value. 6 * 3 = 18ms would be too aggressive;
IOS enforces a minimum 200ms RTO.
Q Cnt=0: No reliable packets waiting for ACK. Healthy.
Seq=52: The last reliable packet from 10.1.2.2 had sequence number 52.
Used for reordering detection and acknowledgment.
show ip eigrp topology
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.4.0.0/24, 1 successors, FD is 3328
via 10.1.2.2 (3328/3072), GigabitEthernet0/1
via 10.1.3.2 (28672/3072), GigabitEthernet0/2
P 10.24.0.0/30, 1 successors, FD is 3072
via 10.1.2.2 (3072/2816), GigabitEthernet0/1
P 192.168.3.0/24, 1 successors, FD is 3072
via 10.1.3.2 (3072/2816), GigabitEthernet0/2
Line: P 10.4.0.0/24, 1 successors, FD is 3328
P = PASSIVE state. The route is stable.
If this showed "A", DUAL is actively querying.
1 successors = one primary next-hop installed in routing table.
FD is 3328 = the lowest metric this router has recorded
for 10.4.0.0/24. Established by the successor route.
Line: via 10.1.2.2 (3328/3072), GigabitEthernet0/1
10.1.2.2 = the next-hop neighbor
3328 = R1's TOTAL metric to 10.4.0.0/24 via R2
(this equals FD, so this IS the successor)
3072 = R2's AD -- what R2 reports as its own metric
to 10.4.0.0/24
GigabitEthernet0/1 = local interface to reach R2
Line: via 10.1.3.2 (28672/3072), GigabitEthernet0/2
10.1.3.2 = next-hop neighbor R3
28672 = R1's total metric via R3 (much higher: FastEthernet path)
3072 = R3's AD
Is 3072 < FD (3328)? YES.
R3 satisfies the feasibility condition.
R3 IS a feasible successor.
This route is a backup, ready for instant failover.
The topology table always shows the successor first (equal to FD), then any feasible successors. Non-feasible routes are hidden by default.
show ip eigrp topology all-links
R1# show ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
...
P 10.4.0.0/24, 1 successors, FD is 3328, serno 12
via 10.1.2.2 (3328/3072), GigabitEthernet0/1
via 10.1.3.2 (28672/3072), GigabitEthernet0/2
via 10.1.5.5 (4000/3500), Serial0/0/0
-- 3500 is NOT < 3328. Fails feasibility condition.
-- Not a feasible successor. Only visible with all-links.
all-links reveals the routes that fail the feasibility condition. The entry via 10.1.5.5 shows AD=3500, but FD=3328. Since 3500 >= 3328, this path could theoretically cause a loop and DUAL refuses to use it as a backup. This command is invaluable for troubleshooting “why won’t EIGRP use this path as a backup?”
show ip eigrp interfaces
R1# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/1 1 0/0 0/0 3 0/0 50 0
Gi0/2 1 0/0 0/0 4 0/0 50 0
Each row is an EIGRP-active interface (one matching the network statement and not passive). Peers shows the count of EIGRP neighbors on that interface. Xmit Queue shows outstanding unreliable/reliable packets. A non-zero reliable queue count indicates a stalled neighbor. Flow Timer is the multicast pacing timer.
show ip eigrp interfaces detail
R1# show ip eigrp interfaces detail GigabitEthernet0/1
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/1 1 0/0 0/0 3 0/0 50 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial <none>
Packetized sent/expedited: 24/2
Hello's sent/expedited: 2100/2
Un/reliable mcasts: 0/3 Un/reliable ucasts: 3/24
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 2
Retransmissions sent: 0 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is not set
Bandwidth percent is 50
Key detail fields:
- Hello-interval / Hold-time: per-interface Hello and hold timer values
- Split-horizon: enabled by default; suppresses advertisements back out the receiving interface (can cause hub-and-spoke problems; disable with
no ip split-horizon eigrp 100) - Authentication mode: shows whether MD5 or HMAC-SHA-256 is active, or not set
- Bandwidth percent: EIGRP’s self-throttle – it will use at most 50% of configured interface bandwidth for its own traffic by default on WAN links
show ip route eigrp
R1# show ip route eigrp
Codes: D - EIGRP, EX - EIGRP external
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/2816] via 10.1.2.2, 02:14:33, GigabitEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/2816] via 10.1.3.2, 02:14:41, GigabitEthernet0/2
4.0.0.0/32 is subnetted, 1 subnets
D 4.4.4.4 [90/3072] via 10.1.2.2, 02:14:33, GigabitEthernet0/1
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.4.0.0/24 [90/3328] via 10.1.2.2, 02:14:33, GigabitEthernet0/1
D 10.24.0.0/30 [90/3072] via 10.1.2.2, 02:14:33, GigabitEthernet0/1
192.168.3.0/24
D 192.168.3.0 [90/3072] via 10.1.3.2, 02:14:41, GigabitEthernet0/2
D 10.4.0.0/24 [90/3328] via 10.1.2.2, 02:14:33, GigabitEthernet0/1
^ ^ ^
D = EIGRP internal | Metric = 3328 (the FD from the topology table)
AD = 90 (EIGRP internal always shows 90 here)
The "via" shows the SUCCESSOR's IP address and the local exit interface.
Only successor routes appear here. Feasible successors are topology-table only.
show ip protocols
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
EIGRP-IPv4 Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240
Router-ID: 1.1.1.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 2
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
1.1.1.1/32
10.1.2.0/30
10.1.3.0/30
Passive Interface(s):
(none)
Routing Information Sources:
Gateway Distance Last Update
10.1.2.2 90 02:14:33
10.1.3.2 90 02:14:41
Distance: internal 90 external 170
This is the most comprehensive single-command summary of EIGRP state. Read it top to bottom:
- K-values confirm the metric formula in use
- Router-ID confirms the EIGRP router ID
- Active Timer: 3 minutes is the SIA timeout
- Distance: internal 90 external 170
- Maximum metric variance 2 confirms the variance setting
- Automatic Summarization disabled confirms
no auto-summary - Routing for Networks shows exactly which network statements are configured
- Passive Interface(s) lists passive interfaces
- Routing Information Sources shows active neighbors and their last update times
14. Complete Lab – Hub-and-Spoke with Stub and Variance
Lab Topology
10.1.2.0/30
(GigabitEthernet)
+----------+----------+
| |
[R1] [R2]----10.24.0.0/30----[R4]
(hub)| (spoke) (GigabitEthernet) |
| 10.4.0.0/24
+----------+----------+
10.1.3.0/30
(GigabitEthernet)
|
[R3]
(stub spoke)
192.168.3.0/24 (LAN, passive)
IP Addressing
| Router | Interface | IP Address | Description |
|---|---|---|---|
| R1 | Lo0 | 1.1.1.1/32 | Router-ID |
| R1 | Gi0/1 | 10.1.2.1/30 | Link to R2 |
| R1 | Gi0/2 | 10.1.3.1/30 | Link to R3 |
| R2 | Lo0 | 2.2.2.2/32 | Router-ID |
| R2 | Gi0/0 | 10.1.2.2/30 | Link to R1 |
| R2 | Gi0/1 | 10.24.0.1/30 | Link to R4 |
| R3 | Lo0 | 3.3.3.3/32 | Router-ID |
| R3 | Gi0/0 | 10.1.3.2/30 | Link to R1 |
| R3 | Gi0/1 | 192.168.3.1/24 | Stub LAN (passive) |
| R4 | Lo0 | 4.4.4.4/32 | Router-ID |
| R4 | Gi0/0 | 10.24.0.2/30 | Link to R2 |
| R4 | Gi0/1 | 10.4.0.1/24 | Destination LAN (passive) |
R1 Configuration
hostname R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/1
description To-R2-Spoke
ip address 10.1.2.1 255.255.255.252
no shutdown
!
interface GigabitEthernet0/2
description To-R3-Stub-Spoke
ip address 10.1.3.1 255.255.255.252
no shutdown
!
router eigrp 100
eigrp router-id 1.1.1.1
network 1.1.1.1 0.0.0.0
network 10.1.2.0 0.0.0.3
network 10.1.3.0 0.0.0.3
no auto-summary
maximum-paths 4
variance 2
R2 Configuration
hostname R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet0/0
description To-R1-Hub
ip address 10.1.2.2 255.255.255.252
no shutdown
!
interface GigabitEthernet0/1
description To-R4
ip address 10.24.0.1 255.255.255.252
no shutdown
!
router eigrp 100
eigrp router-id 2.2.2.2
network 2.2.2.2 0.0.0.0
network 10.1.2.0 0.0.0.3
network 10.24.0.0 0.0.0.3
no auto-summary
R3 Configuration (Stub Spoke)
hostname R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet0/0
description To-R1-Hub
ip address 10.1.3.2 255.255.255.252
no shutdown
!
interface GigabitEthernet0/1
description Stub-LAN
ip address 192.168.3.1 255.255.255.0
no shutdown
!
router eigrp 100
eigrp router-id 3.3.3.3
network 3.3.3.3 0.0.0.0
network 10.1.3.0 0.0.0.3
network 192.168.3.0 0.0.0.255
no auto-summary
passive-interface GigabitEthernet0/1
eigrp stub connected summary
R4 Configuration
hostname R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/0
description To-R2
ip address 10.24.0.2 255.255.255.252
no shutdown
!
interface GigabitEthernet0/1
description Destination-LAN
ip address 10.4.0.1 255.255.255.0
no shutdown
!
router eigrp 100
eigrp router-id 4.4.4.4
network 4.4.4.4 0.0.0.0
network 10.24.0.0 0.0.0.3
network 10.4.0.0 0.0.0.255
no auto-summary
passive-interface GigabitEthernet0/1
Verifying Neighbor Tables
R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.2.2 Gi0/1 14 00:08:12 2 200 0 8
0 10.1.3.2 Gi0/2 12 00:08:17 3 200 0 6
R1 has two neighbors. Both are healthy: hold timers counting down normally, Q Cnt = 0, low SRTT. R1 does not know yet that R3 is a stub – that information is in the Hello flags.
R3# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.3.1 Gi0/0 14 00:08:17 3 200 0 9
R3 has only one neighbor: R1. This is correct for a stub spoke – it has no path to R4 except through R1.
Verifying Topology Tables
R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
P 10.4.0.0/24, 1 successors, FD is 3328
via 10.1.2.2 (3328/3072), GigabitEthernet0/1
-- R3 has no path to R4 (no entry via 10.1.3.2)
-- R3 is stub; only advertises connected and summary routes
P 10.24.0.0/30, 1 successors, FD is 3072
via 10.1.2.2 (3072/2816), GigabitEthernet0/1
P 192.168.3.0/24, 1 successors, FD is 3072
via 10.1.3.2 (3072/2816), GigabitEthernet0/2
P 4.4.4.4/32, 1 successors, FD is 3072
via 10.1.2.2 (3072/2816), GigabitEthernet0/1
P 3.3.3.3/32, 1 successors, FD is 3072
via 10.1.3.2 (3072/2816), GigabitEthernet0/2
P 2.2.2.2/32, 1 successors, FD is 2816
via 10.1.2.2 (2816/128), GigabitEthernet0/1
P 1.1.1.1/32, 1 successors, FD is 128
via Connected, GigabitEthernet0/1
Notice that 10.4.0.0/24 has only one successor and no feasible successor at R1. R3, being a stub, does not advertise a path to 10.4.0.0/24 (it has none, and even if it did, it would not transit for the hub). If R1-R2 fails, R1 would go ACTIVE for 10.4.0.0/24. Because R3 is stub, R1 would not query R3. With no other non-stub neighbors, R1 would have no route to 10.4.0.0/24 until R2 recovers.
R1# show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/2816] via 10.1.2.2, 00:08:12, GigabitEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/3072] via 10.1.3.2, 00:08:17, GigabitEthernet0/2
4.0.0.0/32 is subnetted, 1 subnets
D 4.4.4.4 [90/3072] via 10.1.2.2, 00:08:12, GigabitEthernet0/1
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D 10.4.0.0/24 [90/3328] via 10.1.2.2, 00:08:12, GigabitEthernet0/1
D 10.24.0.0/30 [90/3072] via 10.1.2.2, 00:08:12, GigabitEthernet0/1
192.168.3.0/24
D 192.168.3.0 [90/3072] via 10.1.3.2, 00:08:17, GigabitEthernet0/2
Confirming Stub on R3
R3# show ip protocols
Routing Protocol is "eigrp 100"
...
EIGRP Stub, connected, summary
...
Routing for Networks:
3.3.3.3/32
10.1.3.0/30
192.168.3.0/24
Passive Interface(s):
GigabitEthernet0/1
The EIGRP Stub, connected, summary line confirms the stub configuration. R3 will advertise its connected routes and any summaries but will not be queried by R1.
Demonstrating variance
To demonstrate unequal-cost load balancing, suppose R1 has a second path to R4’s 10.4.0.0/24 through a slightly slower link. We can simulate this by adjusting the delay on an alternate path. For this lab, assume R2 has two physical connections to R4: one GigE (current) and one FastEthernet (slower backup). R2’s FastEthernet to R4 has delay 100 usec.
R2 would compute two paths and install the GigE path. However, for the purpose of variance demonstration at R1, imagine R1 itself has two upstream providers: R2 via GigE (metric 3328) and R2 via an alternate GigE with slightly higher delay (metric 3584 due to an extra hop).
R1# show ip eigrp topology 10.4.0.0 255.255.255.0
EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1) for 10.4.0.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3328
Descriptor Blocks:
10.1.2.2 (GigabitEthernet0/1), from 10.1.2.2, Send flag is 0x0
Composite metric is (3328/3072), route is Successor
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 30 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 4.4.4.4
10.1.2.6 (GigabitEthernet0/3), from 10.1.2.6, Send flag is 0x0
Composite metric is (3584/3072), route is Feasible Successor
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 40 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 4.4.4.4
FD = 3328 (via Gi0/1)
Alternate via Gi0/3: metric 3584, AD 3072.
Is 3072 < 3328? YES -- this IS a feasible successor.
Is 3584 <= variance(2) * 3328 = 6656? YES -- qualifies for routing table.
With variance 2 configured:
R1# show ip route 10.4.0.0
Routing entry for 10.4.0.0/24
Known via "eigrp 100", distance 90, metric 3328
Routing Descriptor Blocks:
* 10.1.2.2, from 10.1.2.2, via GigabitEthernet0/1
Route metric is 3328, traffic share count is 8
10.1.2.6, from 10.1.2.6, via GigabitEthernet0/3
Route metric is 3584, traffic share count is 7
Traffic shares: 8 and 7. The GigE primary path carries slightly more traffic. The ratio approximates 3584/3328 = 1.077, so approximately 52% / 48% distribution.
15. Troubleshooting EIGRP
Neighbors Not Forming
The most common EIGRP issue. Always start here:
R1# show ip eigrp neighbors
If the expected neighbor is absent, work through the following:
AS number mismatch:
R1# debug eigrp packets hello
...
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.2.2 (GigabitEthernet0/1)
is down: AS mismatch
Fix: verify router eigrp <AS> on both routers. The AS number must match exactly.
K-value mismatch:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.2.2 (GigabitEthernet0/1)
is down: K-value mismatch
Verify:
R1# show ip protocols | include K
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
R2# show ip protocols | include K
Metric weight K1=1, K2=1, K3=1, K4=0, K5=0 <-- K2=1 differs from R1
Fix: make K-values identical on both routers. Never change K-values from default unless you have a specific design reason.
Passive interface:
R1# show ip protocols | section Passive
Passive Interface(s):
GigabitEthernet0/1 <-- This should be an active peer interface
Fix: no passive-interface GigabitEthernet0/1 under router eigrp 100.
Authentication failure:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.2.2 (GigabitEthernet0/1)
is down: Auth failure
Check key chain configuration on both sides. Verify key string matches exactly (case-sensitive). Check key ID numbers and time validity windows.
Network statement missing:
If the interface IP does not match any network statement, EIGRP will not send Hellos on that interface. Verify with show ip protocols | section Networks.
Split horizon on hub interface:
On hub-and-spoke topologies where multiple spokes are behind the same hub interface, split horizon can prevent R1 from advertising R2’s routes to R3 and vice versa (because R1 learned those routes from the same interface it would use to advertise them). Check with show ip eigrp interfaces detail and disable if needed:
R1(config)# interface GigabitEthernet0/1
R1(config-if)# no ip split-horizon eigrp 100
Stuck in Active (SIA)
The Active state timer is 3 minutes by default. If a router in ACTIVE state does not receive Replies from all queried neighbors within 3 minutes, it declares those neighbors SIA and resets those adjacencies:
%DUAL-3-SIA: Route 10.4.0.0/24 stuck-in-active state in IP-EIGRP(0) 100.
Cleaning up
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.2.2 (GigabitEthernet0/1)
is down: stuck in active
Resetting the adjacency is destructive – all routes learned from that neighbor are flushed and must be relearned. This can cause a cascade of route withdrawals and re-advertisements across the network.
IOS 12.3+ SIA-Query mechanism: At the halfway point of the active timer (90 seconds by default), the querying router sends an SIA-Query to neighbors that haven’t replied. If the neighbor sends an SIA-Reply (“I’m alive, still processing”), the active timer resets. This prevents false SIA declarations when a neighbor is genuinely working on a long query chain.
Root causes of SIA:
-
Large query domain – a route loss propagates queries deep into the network before hitting a boundary that can absorb them. Fix: configure stub routers and manual summarization to create query boundaries.
-
Overloaded router – a router is too busy (high CPU or memory pressure) to process and reply to Queries promptly. Fix: hardware upgrade, reduce routing table size, optimize process scheduling.
-
Network partition – a link failure creates an island where queries propagate but replies cannot return. Fix: design for redundant paths.
-
Flapping links – a link going up and down rapidly causes repeated Active states. Fix: address the physical layer problem; consider
ip dampeningfor WAN interfaces.
Preventing SIA:
! Configure stub on all branch/leaf routers
R3(config-router)# eigrp stub connected summary
! Configure summarization at aggregation points
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip summary-address eigrp 100 10.0.0.0 255.0.0.0
! Tune active timer if needed (shorter = fail faster, less disruption)
R1(config-router)# timers active-time 1 ! 1 minute instead of 3
! Verify query domain with:
R1# show ip eigrp topology active ! Shows all currently active routes
Route Present in Topology but Not Routing Table
If show ip eigrp topology shows a route but show ip route does not:
-
Another protocol may have a lower-AD route:
show ip route <prefix>to see which protocol installed the route. EIGRP internal (90) loses to OSPF (110) — wait, EIGRP 90 beats OSPF 110. But if OSPF is 110 and EIGRP is 90, EIGRP should win. Check for any static routes (AD 1) or connected routes that might match. -
The route may be ACTIVE and not yet resolved. Verify with
show ip eigrp topology | include A. -
A distribute-list or route-map may be filtering the route from being installed. Check
show ip protocolsfor filter lists.
Route Missing from Topology Table
If a route does not appear in show ip eigrp topology at all:
-
The neighbor is not advertising it. Use
debug ip eigrp neighbor <neighbor-ip>to watch for Update packets containing the prefix. -
A distribute-list on the neighbor is filtering the advertisement outbound.
-
Split horizon on the hub interface is suppressing re-advertisement.
-
The neighbor has a passive interface toward the affected network.
debug Commands Reference
| Command | Purpose |
|---|---|
debug eigrp packets hello |
Show Hello exchanges; diagnose adjacency formation |
debug eigrp packets update |
Show Update packets; trace route advertisement |
debug eigrp packets query |
Show Query packets; trace DUAL Active state propagation |
debug eigrp packets reply |
Show Reply packets; trace query resolution |
debug eigrp packets ack |
Show ACK packets; diagnose reliable delivery problems |
debug ip eigrp neighbor <addr> |
Filter all EIGRP debug to a specific neighbor |
debug ip eigrp summary |
High-level EIGRP events without full packet decode |
debug ip routing |
Route installation/removal events in the routing table |
debug eigrp fsm |
DUAL finite state machine transitions |
Always stop debugging immediately after collecting data:
R1# undebug all
On a production router handling hundreds of routes, debug eigrp packets during a convergence event can generate thousands of lines per second and severely impact CPU.
Troubleshooting Decision Tree
Symptom: Neighbor not in "show ip eigrp neighbors"
|
+-- Is the link physically up? (show interfaces: line/protocol up/up)
| No --> Fix physical or Layer 2 issue
|
+-- Is the interface passive? (show ip protocols)
| Yes --> no passive-interface <interface>
|
+-- Does a network statement cover the interface address?
| No --> Fix network statement and wildcard mask
|
+-- Are AS numbers identical on both sides?
| No --> Fix router eigrp <AS> to match
|
+-- Are K-values identical? (show ip protocols | include K)
| No --> Fix metric weights (rarely needed)
|
+-- Is authentication configured and do keys match?
| No --> Fix key-chain, key string, key timing
|
+-- Is multicast 224.0.0.10 blocked by ACL or firewall?
Yes --> Remove or modify the ACL
---
Symptom: Route missing from routing table
|
+-- Is it in the topology table? (show ip eigrp topology <prefix>)
| No --> Route not being received from any neighbor
| (check split-horizon, neighbor filtering, passive-if)
|
+-- Is the route in ACTIVE state?
| Yes --> DUAL is querying; wait for resolution or investigate SIA
|
+-- Is a lower-AD route from another protocol winning?
| Yes --> show ip route <prefix> to identify winning protocol
| Redistribute or tune AD if this is unintentional
|
+-- Is a distribute-list filtering installation?
Yes --> show ip protocols for filter list; remove or fix
Summary Reference
| Topic | Key Fact |
|---|---|
| Protocol type | Advanced distance-vector; DUAL algorithm; classless |
| RFC | RFC 7868 (2016, informational) |
| Multicast address | 224.0.0.10 |
| Administrative distance | 90 internal, 170 external |
| Routing table code | D (internal), D EX (external) |
| AS number requirement | Must match between neighbors |
| K-values requirement | Must match; default K1=1, K2=0, K3=1, K4=0, K5=0 |
| Hello interval (LAN) | 5 seconds; hold time 15 seconds |
| Hello interval (WAN) | 60 seconds; hold time 180 seconds |
| Feasibility Condition | Neighbor’s AD strictly less than current FD |
| Successor | Best next-hop; installed in routing table; metric = FD |
| Feasible Successor | Backup next-hop; topology table only; satisfies FC; enables instant failover |
| FD (Feasible Distance) | This router’s best metric to destination (successor route metric) |
| AD / RD | Advertised (Reported) Distance: neighbor’s own metric to destination |
| PASSIVE state | Route stable; successor valid |
| ACTIVE state | Successor lost; no FS; sending Queries; waiting for Replies |
| SIA | Stuck-in-Active: neighbor did not reply within 3 minutes; adjacency reset |
| Metric formula | 256 * (10^7/min_bw_kbps + sum_delay_in_10us) with default K-values |
| Bandwidth in metric | Uses MINIMUM bandwidth along path (bottleneck) |
| Delay in metric | Uses SUM of delays along path (cumulative) |
| Unequal-cost LB | variance command; paths must be feasible successors |
| variance 1 | Default; equal-cost paths only |
| maximum-paths | Default 4; up to 32 |
| no auto-summary | Required on older IOS; disables classful summarization |
| passive-interface | Suppresses Hellos; still advertises connected network |
| eigrp stub | Tells hub to skip querying this router; limits query domain |
| Manual summary (interface) | ip summary-address eigrp; creates Null0 discard at AD 5 |
| Named mode | Hierarchical; wide metrics; SHA-256 auth; preferred for new deployments |
| Split horizon | Enabled by default; may need disabling on hub interface in hub-and-spoke |
| show ip eigrp neighbors | Neighbor table: H, Address, Interface, Hold, Uptime, SRTT, RTO, Q Cnt, Seq |
| show ip eigrp topology | Topology table: P/A state, FD, (total/AD), successor and FS entries |
| show ip eigrp topology all-links | All routes including those failing feasibility condition |
| show ip eigrp interfaces | Per-interface: peer count, queue depth, SRTT, Hello/hold timers |
| show ip protocols | AS, K-values, networks, variance, max-paths, passive interfaces, AD values |
EIGRP rewards careful study. The feasibility condition is the concept that trips up the most candidates – not because it is complex, but because it is easy to memorize the definition without internalizing why it works as a loop prevention mechanism. Work through the DUAL example in section 7 on paper, with different numbers, until you can look at any (total_metric/AD) pair in a topology table and immediately determine whether the route is a successor, a feasible successor, or neither, and state precisely why. That fluency carries through both the CCNA exam and any real-world EIGRP deployment you encounter.
Comments