Back to EIGRP GuideEvidence before changes

EIGRP Troubleshooting: Find the First Broken Layer

Start with the visible symptom, preserve the evidence, and trace the route from interface and neighbor state through topology, routing, forwarding, and return traffic.

InterfacesNeighborsTopologyRoutesActive and SIAData Plane

Troubleshooting at a Glance

EIGRP troubleshooting becomes easier when you stop asking “Why is EIGRP broken?” and ask a smaller question: “What is the first table or state that does not match the design?”

Link proofInterface + ping

Control-plane proofNeighbor

Path knowledgeTopology

Installed pathRIB + CEF

Core rule: Fix the first failed layer. A routing command cannot repair a down interface, and clearing a neighbor cannot repair an incorrect prefix list.

1. Preserve Evidence and Define the Symptom

Before changing configuration, write one precise symptom. “EIGRP is down” is too broad. “R1 has no neighbor on Gi0/0,” “R2 knows 10.30.0.0/24 in topology but does not install it,” or “traffic leaves R3 but the reply never returns” gives you a testable starting point.

Capture a small baseline

show clock
show ip interface brief
show ip eigrp neighbors
show ip eigrp interfaces detail
show ip eigrp topology
show ip route eigrp
show logging | include EIGRP|DUAL

Record the test

Source:       10.10.10.1
Destination:  10.30.30.1
Expected path: R1 - R2 - R3
Observed result: timeout
First failed proof: R2 has no route

Do not clear first: Restarting EIGRP can temporarily restore service while deleting the neighbor uptime, queue, Active-route, and log evidence that explains the real fault.

2. Follow the Six-Layer Workflow

Move in order. Stop at the first failed proof and investigate there.

Interface

Is the link up, addressed, and error-free?

Neighbor

Do both routers form and keep adjacency?

Topology

Did EIGRP learn or originate the prefix?

Routing

Did the RIB install the EIGRP path?

Forwarding

Does CEF point to the correct interface and next hop?

Return path

Can the destination reply to the real source?

✓

Re-test

Use the same source, destination, and success criteria.

3. Verify Interfaces and Basic IP Reachability

EIGRP uses IP protocol 88, but it cannot exchange packets until the interface and local subnet work. Prove the link before comparing routing settings.

Check the interface

show ip interface brief
show interfaces GigabitEthernet0/0
show ip interface GigabitEthernet0/0
show arp GigabitEthernet0/0

Test the peer address

ping 192.168.12.2 source 192.168.12.1
show interfaces counters errors
show access-lists
show ip cef 192.168.12.2 detail

Evidence	Meaning	Next action
Administratively down	The interface is shut.	Confirm authorization, then use `no shutdown`.
Up/down	Layer 1 works but the line protocol does not.	Check encapsulation, keepalives, and the remote end.
Up/up but peer ping fails	Addressing, mask, VLAN, ACL, ARP, or one-way path issue.	Compare both interfaces before touching EIGRP.
Errors or drops increase	The link can disrupt Hellos and reliable packets.	Repair transport quality and re-test.

4. Diagnose a Missing Neighbor

If peer IP connectivity works but no neighbor appears, compare EIGRP participation and compatibility on both routers.

Prove local participation

show ip eigrp interfaces detail
show ip protocols
show running-config | section router eigrp
show running-config interface GigabitEthernet0/0

Check packets and policy

show access-lists
show key chain
show logging | include EIGRP|DUAL
show ip traffic | include EIGRP

Requirement	What must be true	Common failure
Interface selection	EIGRP is enabled on the link.	Network statement or address-family interface omission.
Autonomous system	Both peers use the same EIGRP AS.	AS 100 on one side and AS 200 on the other.
K-values	The metric K-values match.	One side has a custom metric weight.
Primary subnet	IPv4 primary addresses share the subnet.	Incorrect mask or address.
Passive status	The transit interface sends Hellos.	`passive-interface` applied accidentally.
Authentication	Method, usable key ID, secret, and lifetime agree.	Wrong key, algorithm, clock, or interface.
Packet delivery	IP protocol 88 and multicast/unicast traffic pass.	ACL, control-plane policy, or one-way link.

For a focused configuration comparison, use the EIGRP neighbors and authentication lesson.

5. Repair a Flapping or Unstable Neighbor

A neighbor that forms and repeatedly resets has a different problem from a neighbor that never forms. Record the reset reason, uptime, queue, and transport counters while the issue is present.

Inspect stability

show ip eigrp neighbors detail
show interfaces GigabitEthernet0/0
show logging | include EIGRP|holding|retry|peer
show processes cpu sorted

Read neighbor fields

Hold:    should count down then refresh
Uptime:  should grow without resetting
SRTT:    reliable-packet round-trip time
RTO:     retransmission timeout
Q count: normally returns to zero

Hold-time expiry: Look for missing Hellos, packet loss, control-plane delay, or one-way traffic.
Retry-limit exceeded: Reliable Updates, Queries, or Replies are not being acknowledged.
Authentication changes: Check key lifetime, clock synchronization, and whether both peers changed together.
Physical instability: Correlate adjacency resets with carrier changes, interface errors, and switch logs.

6. Find a Route Missing from the EIGRP Topology Table

A stable neighbor proves only that routers can exchange EIGRP packets. It does not prove that a particular prefix is originated, permitted, or advertised.

Check the source

Does the origin router have the route in its local RIB?

Check origination

Does network selection or redistribution place it in EIGRP?

Check advertisement

Do summary, stub, or outbound policy suppress it?

Trace one prefix at the source

show ip route 10.30.30.0
show ip eigrp topology 10.30.30.0/24
show ip protocols
show ip prefix-list
show route-map

Trace it downstream

show ip eigrp topology all-links | include 10.30.30.0
show ip route 10.30.30.0 255.255.255.0
show running-config | include distribute-list|summary|stub
show ip eigrp neighbors detail

First split: If the source router lacks the prefix, repair the source. If the source topology contains it but the neighbor does not, inspect advertisement policy between them.

7. Explain Why Topology Has the Route but the RIB Does Not

The EIGRP topology table records paths DUAL knows. The IP routing table installs only the winning usable route. A topology entry without an EIGRP RIB entry is therefore a selection or next-hop question, not an adjacency problem.

Reason	Evidence	Interpretation
Another protocol wins	`show ip route 10.30.30.0` shows a different source.	Compare administrative distance and prefix length.
Next hop is unresolved	Topology has the path but recursive lookup fails.	Repair reachability to the successor.
Route is not the successor	It appears only with `all-links`.	DUAL knows it but selected another path.
Route is Active	Topology shows an ongoing diffusing calculation.	Wait briefly or trace missing Replies.
Same prefix, different mask	The expected and installed routes have different lengths.	Search the exact prefix and mask.

Important: Administrative distance decides between route sources only after the router compares the same destination prefix length. A longer prefix always wins forwarding regardless of AD.

8. Explain an Unexpected EIGRP Best Path

When EIGRP chooses a path you did not expect, compare the metric inputs along the complete path. Do not judge the decision from interface bandwidth alone.

Compare metric evidence

show ip eigrp topology 10.30.30.0/24
show interfaces GigabitEthernet0/0
show interfaces GigabitEthernet0/1
show ip protocols | include K

Confirm installed forwarding

show ip route 10.30.30.0
show ip cef 10.30.30.0/24 detail
show ip eigrp topology all-links
traceroute 10.30.30.1 source Loopback0

Bandwidth: Classic metric uses the lowest bandwidth along the path.
Delay: Delay is accumulated across outgoing interfaces.
Manual values: A configured delay or interface metric can override expectations.
Load balancing: Variance still requires the alternate to satisfy feasibility.

Use the metrics and K-values lesson for calculation practice and the load-balancing lesson for variance and CEF validation.

9. Investigate Active and Stuck-in-Active Routes

An Active route is not automatically broken. It means the successor failed, no feasible successor was ready, and DUAL is waiting for Replies. The problem begins when the Reply chain takes too long or never completes.

Find the waiting route and peer

show ip eigrp topology active
show ip eigrp topology 10.30.30.0/24
show ip eigrp neighbors detail
show logging | include SIA|DUAL|EIGRP

Check the reply path

show interfaces counters errors
show processes cpu sorted
show ip route 10.30.30.0
show ip eigrp topology all-links

Name the prefix

Begin with the exact route marked Active.

Name the peer

Identify the neighbor whose Reply is outstanding.

Move one hop

Check that peer's route state and downstream dependency.

Large Query domains, packet loss, slow links, CPU pressure, or unstable routes can delay the chain. Stub routing and summaries can reduce unnecessary Query scope but do not replace transport repair.

Continue with the DUAL lesson or the focused SIA and Query Boundaries lesson.

10. Check Filtering, Stub, Summary, and Redistribution Policy

A healthy neighbor can remain up while policy removes one route. Treat route visibility and neighbor formation as separate problems.

Feature	Typical symptom	Evidence
Distribute list	Selected routes missing inbound or outbound.	Prefix-list and route-map matches plus direction.
Summary	Specifics disappear toward one neighbor.	Neighbor-facing interface and generated Null0 route.
EIGRP stub	Some local route sources are not advertised.	Configured stub options and neighbor detail.
Redistribution	No `D EX` route or too many external routes.	Source RIB, route map, seed metric, and tag.
Leak map	Expected exception is absent.	Prefix-list match and summary attachment.

Inspect policy objects

show ip prefix-list
show route-map
show access-lists
show running-config | include distribute-list|summary-address|stub|redistribute

Confirm route ownership

show ip route 172.20.10.0
show ip eigrp topology 172.20.10.0/24
show ip protocols
show ip route eigrp | include EX

For deeper policy examples, use EIGRP filtering and redistribution and summarization and default routing.

11. Verify Forwarding and the Return Path

A correct EIGRP route does not prove that traffic succeeds. CEF, ARP, ACLs, NAT, MTU, the destination host, and the return route still matter.

RIB

Confirm the exact prefix, next hop, and interface.

CEF

Confirm the forwarding adjacency is resolved.

Forward test

Ping and trace from the real source address.

Return route

Verify how the destination returns to that source.

Test the forward path

show ip route 10.30.30.0
show ip cef 10.30.30.0/24 detail
ping 10.30.30.1 source 10.10.10.1
traceroute 10.30.30.1 source 10.10.10.1

Test the return path

show ip route 10.10.10.1
show ip cef 10.10.10.1 detail
show access-lists
show ip nat translations

Source matters: A router ping may use a nearby interface address that follows a different return path. Specify the same source that the failed application uses.

12. Use Debugging, Clearing, and Changes Safely

Show commands are the first choice. Use focused debugging only when the current state cannot reveal which packet or transition is failing.

Focused lab debugging

debug eigrp packets hello
debug eigrp packets update
debug eigrp packets query
debug eigrp packets reply
undebug all

Save evidence before a reset

show tech-support | redirect bootflash:eigrp-before.txt
show logging | redirect bootflash:eigrp-log-before.txt
show ip eigrp topology active
show ip eigrp neighbors detail

Production caution: Debugging and process resets can increase CPU use or disrupt neighbors and routes. Filter the scope, watch the console destination, define a stop condition, and obtain change approval.

Action	Use when	Risk
Targeted show command	Always begin here.	Low.
Filtered debug	A packet or state transition remains unclear.	CPU and output volume.
Clear one neighbor	Evidence supports a controlled adjacency restart.	Temporary route withdrawal.
Clear the process	Approved recovery after evidence capture.	All EIGRP adjacencies and learned routes reset.

13. Choose the Right Command for the Question

Question	Best first command	What success looks like
Is the link usable?	`show ip interface brief`	Correct address and up/up state.
Is EIGRP active on it?	`show ip eigrp interfaces detail`	Interface listed with expected peers and timers.
Is the peer stable?	`show ip eigrp neighbors detail`	Growing uptime and Q count returning to zero.
Does DUAL know the route?	`show ip eigrp topology all-links`	Exact prefix with expected next-hop candidates.
Is DUAL waiting?	`show ip eigrp topology active`	No long-running Active entries.
Was the route installed?	`show ip route <prefix>`	Expected source, next hop, and metric.
Can the router forward it?	`show ip cef <prefix> detail`	Resolved adjacency and correct interface.
Does the real flow work?	`ping` and `traceroute` with source	Expected path and successful replies.

14. Guided Troubleshooting Fault Labs

Use an isolated three-router EIGRP AS 100 topology. For every fault, record the symptom before looking at configuration.

Task 1: Missing Neighbor

Change R3 to AS 200.
Prove the interface remains up/up.
Compare show ip protocols.
Repair the AS.
Confirm uptime starts again.

Expected result: You distinguish link success from EIGRP compatibility.

Task 2: Neighbor Up, Route Missing

Apply an outbound prefix filter.
Confirm the adjacency remains stable.
Trace the prefix from source RIB to receiver topology.
Inspect policy counters.
Correct only the permit rule.

Expected result: You repair route policy without resetting the neighbor.

Task 3: Unexpected Path

Change delay on one transit interface.
Predict the metric effect.
Compare topology, RIB, and CEF.
Restore the baseline.
Confirm the original path returns.

Expected result: You explain the path from metric evidence.

Task 4: Active Route

Use a route with no feasible successor.
Fail its current successor.
Identify the Active prefix and queried peers.
Follow the Reply chain.
Restore the link and confirm Passive.

Expected result: You diagnose DUAL state without clearing the process.

Task 5: Return-Path Failure

Remove the remote route to the ping source.
Confirm the forward destination route still exists.
Run a sourced ping and traceroute.
Inspect the remote return RIB.
Restore and retest the same flow.

Expected result: You prove that routing must work in both directions.

Task 6: Safe Change Closure

Save before-output.
Repair one confirmed cause.
Repeat the original test.
Verify unaffected prefixes.
Save after-output and rollback steps.

Expected result: The repair is measurable, limited, and documented.

15. Frequently Asked Questions

What should I check first when an EIGRP neighbor is missing?

Confirm the interface is up/up and that the peer's primary IP address is reachable. Then check EIGRP interface participation, AS number, K-values, passive status, authentication, and packet filtering.

Can neighbors stay up while routes are missing?

Yes. Distribute lists, summaries, stub options, redistribution policy, or missing source routes can affect prefixes without breaking adjacency.

Why is a route in EIGRP topology but not the routing table?

It may not be the successor, another route source may win, its next hop may be unresolved, or DUAL may still be Active. Compare the exact prefix in topology and the RIB.

Is an Active route always a problem?

No. Active means DUAL is searching after losing a successor without a feasible successor. It becomes concerning when the state lasts too long or a Reply never returns.

Why does a neighbor repeatedly reset?

Common causes include hold-time expiry, reliable-packet retry failure, packet loss, physical instability, CPU pressure, authentication changes, or one-way filtering.

Should I clear EIGRP when routes are wrong?

Not first. Capture evidence and identify the failed layer. Clear a neighbor or process only when the impact is understood and the reset addresses a confirmed need.

Why does ping fail when the route is present?

The next hop or CEF adjacency may be unresolved, an ACL or NAT rule may block traffic, the host may be down, MTU may matter, or the return path may be missing.

What proves that the repair worked?

Repeat the original source-to-destination test, verify the expected neighbor, topology, route, and CEF state, check the return path, and confirm unrelated prefixes remain healthy.