EIGRP
What It Is
Enhanced Interior Gateway Routing Protocol is a Cisco-originated interior routing protocol based on distance vector behavior with DUAL loop-free path selection. It is mostly a brownfield enterprise topic now. You still need to understand it when operating older Cisco networks, mergers, campus cores, WAN edge designs, and certification labs.
EIGRP can converge quickly and is straightforward in all-Cisco environments, but it is rarely the first choice for new multi-vendor designs. For new networks, compare it honestly against OSPF, IS-IS, and BGP.
Core Attributes
| Attribute | Value |
|---|---|
| Algorithm | DUAL |
| Cisco administrative distance | Internal 90, external 170, summary 5 |
| Transport | IP protocol 88 |
| IPv4 multicast | 224.0.0.10 |
| IPv6 multicast | ff02::a |
| Default K values | K1 = 1, K3 = 1, others 0 |
| Classic metric inputs | Minimum bandwidth and cumulative delay by default |
| Modern metric note | Named mode supports wide metrics |
Modern note: RFC 7868 documents EIGRP as informational, not an Internet Standards Track protocol. Treat multi-vendor EIGRP as a risk unless it is explicitly tested.
Packet Types
| Type | Packet | Purpose |
|---|---|---|
| 1 | Update | Advertises route changes |
| 3 | Query | Asks neighbors for alternate paths |
| 4 | Reply | Answers a query |
| 5 | Hello | Discovers and maintains neighbors |
| 8 | Acknowledgment | Confirms reliable packet delivery |
DUAL Terms
| Term | Meaning |
|---|---|
| Successor | Best next hop installed in the routing table |
| Feasible successor | Backup path that satisfies loop-free feasibility |
| Feasible distance | Local best metric to reach a prefix |
| Reported distance | Neighbor's advertised distance to the prefix |
| Feasibility condition | Neighbor reported distance is lower than local feasible distance |
| Passive route | Stable route, not actively recomputing |
| Active route | Route is querying for a new loop-free path |
| Stuck in active | Query process did not complete before timeout |
Watch out: "Passive" is good in the topology table. It means stable. A passive interface is a separate configuration concept.
Design Choices
| Choice | Recommendation |
|---|---|
| Classic vs named mode | Prefer named mode for modern IOS/IOS-XE work |
| Summarization | Summarize at boundaries to limit query scope |
| Stub routing | Use on spokes and access routers that should not be transit |
| Passive interfaces | Use passive by default, enable only routing adjacencies |
| K values | Do not change unless every router matches and the reason is documented |
| Unequal-cost load sharing | Use variance carefully and verify traffic split |
| Authentication | Use supported authentication for trusted adjacencies |
| Redistribution | Tag and filter redistributed routes |
Design note: EIGRP scales better when queries are contained. Stub routing, summarization, and clean topology matter more than clever metrics.
Cisco IOS/IOS-XE Examples
Named mode IPv4:
router eigrp CAMPUS
address-family ipv4 unicast autonomous-system 100
eigrp router-id 10.255.0.10
af-interface default
passive-interface
exit-af-interface
af-interface GigabitEthernet1/0/1
no passive-interface
authentication mode md5
authentication key-chain EIGRP-KEYS
exit-af-interface
network 10.0.0.0 0.255.255.255
topology base
variance 1
Stub spoke:
router eigrp BRANCH
address-family ipv4 unicast autonomous-system 100
eigrp stub connected summary
network 10.50.0.0 0.0.255.255
Manual summary:
interface GigabitEthernet1/0/1
ip summary-address eigrp 100 10.50.0.0 255.255.0.0
Notes:
- Syntax differs between classic and named mode. Do not mix examples without checking the platform.
- Named mode is the better default for new IOS-XE EIGRP configurations.
- Keep autonomous system numbers, K values, authentication, and address families consistent across neighbors.
Troubleshooting
| Symptom | Check | Likely Cause |
|---|---|---|
| No neighbor | AS number, subnet, passive interface, ACL, multicast | Hellos not exchanged |
| Neighbor flaps | Hold timer, loss, interface errors, CPU | Missed hellos |
| Route missing | Topology table, stub, summary, filter | Query boundary or policy |
| Route stuck active | Query scope, unreachable neighbor, summarization | Unbounded query domain |
| Bad path chosen | Bandwidth, delay, wide metric, offset list | Metric mismatch |
| External route surprise | Redistribution tags and route maps | Route leaked or reintroduced |
| Unequal load not working | Variance and feasibility condition | Candidate is not feasible |
Commands
show ip eigrp neighbors
show ip eigrp interfaces
show ip eigrp topology
show ip eigrp topology all-links
show ip eigrp traffic
show ip protocols
show ip route eigrp
clear ip eigrp neighbors
Expected clues:
- Neighbor uptime is stable.
- Topology table has a successor for expected prefixes.
- Feasible successors exist where backup paths are expected.
- Stubs and summaries limit query propagation.
- EIGRP traffic counters move during adjacency and route changes.
Watch Out
- Do not change K values casually.
- Do not run EIGRP on user-facing interfaces.
- Do not redistribute between EIGRP and another protocol without tags and filters.
- Do not ignore SIA events. They are topology and query-scope problems, not just log noise.
- Do not assume RFC publication means practical multi-vendor interoperability.