Troubleshooting EIGRP Neighbor Adjacencies

Every EIGRP problem starts with the same question: are the neighbors up? No adjacency means no routes, and a flapping adjacency means a flapping network. The good news is that adjacency failures are finite: a handful of causes account for nearly every case, and each one leaves a distinct fingerprint in the logs and show commands. This guide works through the real ones, broken deliberately on a live CML lab so you can see the exact output each failure produces. It pairs with the requirements list in the EIGRP complete guide.

The Checklist, In the Order That Finds Problems Fastest

For two routers to become EIGRP neighbors they need: layer 3 connectivity on a shared primary subnet, the same autonomous system number, matching K values, matching authentication, and hellos actually flowing (no passive-interface, no ACL eating protocol 88, multicast 224.0.0.10 working). The deep version of the list is in EIGRP neighbor requirements: the 5 things that must match; this article is about recognizing each failure from the router's point of view.

Start every investigation the same way:

R1# show ip eigrp neighbors
EIGRP-IPv4 VR(PINGLABZ) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.0.13.2               Et0/2                    11 00:00:42    1   100  0  8
0   10.0.12.2               Et0/1                    12 00:00:46    1   100  0  11

Healthy neighbors: hold counting down from the hold time and resetting, uptime climbing, Q count at 0. A neighbor missing entirely, or cycling up and down, sends you into the failure catalog below. Second stop, always: show logging | include DUAL. EIGRP tells you the down reason in plain text, and each scenario below has a different one.

Failure 1: K-Value Mismatch (Loud)

K values weight the metric formula (their meaning is covered in the K values guide), and both routers must agree or the metrics they exchange would be incomparable. We broke R5 on purpose:

R5(config)# router eigrp 100
R5(config-router)# metric weights 0 1 1 1 1 0

R4's reaction is immediate and unambiguous, repeating every few seconds as each new hello arrives:

R4# show logging | include DUAL
*Jul 11 05:31:10.439: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.45.2
  (Ethernet0/2) is down: K-value mismatch

R4# show ip eigrp neighbors
EIGRP-IPv4 VR(PINGLABZ) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
0   10.0.24.1               Et0/1                    12 00:14:33    1   100  0  91

This is the easiest failure in the catalog because the router names it. Compare show ip protocols | include Metric weight on both sides, make them match (K1=1, K3=1, everything else 0 is the default and the right answer for almost everyone), and the adjacency returns on its own. Fix: no metric weights.

Failure 2: AS Number Mismatch (Silent)

Now the opposite personality. We moved R3 from AS 100 to AS 10:

R3(config)# no router eigrp 100
R3(config)# router eigrp 10
R3(config-router)# network 10.0.0.0

R1 logs nothing ongoing. A router running AS 100 simply ignores hellos stamped AS 10; they are different routing domains by definition. There is no mismatch error because, from each router's perspective, there is no peer, just silence:

R1# show ip eigrp neighbors
EIGRP-IPv4 VR(PINGLABZ) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
0   10.0.12.2               Et0/1                    13 00:10:09    1   100  0  106

R3# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(10)

The tell is in that second capture: R3's own header says AS(10). When a neighbor is missing with no error anywhere, read the header line of show ip eigrp neighbors on both routers and compare AS numbers. show ip protocols summary gives the same answer in one line per process. Seconds to check, embarrassingly easy to overlook.

Failure 3: Passive Interface (Half Silent)

Passive interface tells EIGRP to advertise a network without speaking the protocol on it. Correct on user-facing LANs (it is standard hardening); an outage when it lands on a transit link. In named mode:

R1(config)# router eigrp PINGLABZ
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# af-interface Ethernet0/1
R1(config-router-af-interface)# passive-interface

Two views of the damage. R1's interface list simply loses Et0/1 (passive interfaces are not EIGRP interfaces anymore):

R1# show ip eigrp interfaces
EIGRP-IPv4 VR(PINGLABZ) Address-Family Interfaces for AS(100)
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo0                      0        0/0       0/0           0       0/0            0           0
Et0/2                    1        0/0       0/0           1       0/2           50           0
Et0/0                    0        0/0       0/0           0       0/0            0           0

And the far side, R2, sees a normal-looking teardown with a reason that points at the peer:

R2# show logging | include DUAL
*Jul 11 05:32:43.564: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.1
  (Ethernet0/1) is down: Interface PEER-TERMINATION received

So the diagnostic pattern is asymmetric: one side has the interface missing from show ip eigrp interfaces, the other side got a peer termination. Check passive configuration with show ip protocols (classic mode lists passive interfaces explicitly) or show run | section eigrp in named mode.

Failure 4: Authentication Mismatch (Loud If You Look)

With authentication enabled on one side only, or with mismatched keys, hellos are received and rejected. The receiver logs it precisely:

R3# show logging | include authentication|DUAL
*Jul 11 05:23:19.445: EIGRP: pkt key id = 1, authentication mismatch
*Jul 11 05:23:19.445: EIGRP: Dropping peer, invalid authentication
*Jul 11 05:23:19.447: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.35.1
  (Ethernet0/2) is down: Auth failure

Check both sides with show ip eigrp interfaces detail | include Authentication: mode and key chain must match. One trap deserves special mention because we hit it live in this lab: removing a classic EIGRP process (no router eigrp 100) also deletes the AS-scoped ip authentication commands from every interface. Recreate the process and auth is simply gone on one side, failing silently against a peer that still requires it. Full configuration coverage, including key rotation, is in the EIGRP authentication guide.

Failure 5: The Plumbing (Subnet, ACLs, MTU, Unidirectional Links)

If none of the above match your symptoms, drop a layer. Mismatched primary subnets log not on common subnet warnings. An inbound ACL that forgot to permit EIGRP (IP protocol 88) or multicast 224.0.0.10 blocks hellos entirely; on IOL and IOS XE, remember inbound ACLs are evaluated before almost everything. A neighbor stuck cycling through retransmissions with Q Cnt climbing and then retry limit exceeded usually means hellos pass but unicast updates do not: think MTU mismatch or a unidirectional link. And on hub-and-spoke or tunnel topologies, confirm multicast actually works across the transport (GRE handles it; the details live in routing protocols over GRE).

The Mismatch That Is Not a Failure: Hello and Hold Timers

Here is the one that trips up engineers coming from OSPF: EIGRP hello and hold timers do not need to match between neighbors. Each router announces its own hold time inside its hellos, and the neighbor simply honors it. Two routers with completely different timer sets will form and keep a perfectly stable adjacency. So if you have been staring at a timers difference as your root cause, stop; it is not the problem, and "fixing" it will not bring the neighbor up.

What timers can do is destabilize an adjacency that already works. A hold time set shorter than the loss and jitter on the path (an overloaded WAN circuit, a congested tunnel) means a couple of dropped hellos exceed the hold time and the neighbor bounces, over and over. The signature is periodic holding time expired teardowns with immediate re-establishment:

%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.1 (Ethernet0/1)
  is down: holding time expired

Defaults are hello 5 and hold 15 seconds on most interfaces (60/180 on low-speed multipoint). If a link drops hellos routinely, raising timers is a bandage; the real fix is the congestion. In named mode, both are set under the af-interface (hello-interval and hold-time), and af-interface default applies them fleet-wide.

Flapping Adjacencies: When It Forms and Will Not Stay

A neighbor that cycles is a different diagnosis tree from one that never appears. Work it in this order:

• Read the down reason for the flap, not the first event. holding time expired points at packet loss or one-way traffic; retry limit exceeded means hellos survive but reliable unicast (updates, replies) dies, which is classic MTU mismatch or unidirectional link territory.
• Check the interface counters both sides: show interface looking at input errors, CRCs, and output drops. On virtual and lab gear, also confirm neither side is oversubscribed on CPU; a router at 100% control-plane CPU misses hello deadlines it technically received.
• Watch SRTT and Q Cnt in the neighbor table. A healthy neighbor shows single-digit SRTT and Q Cnt 0. SRTT in the hundreds of milliseconds with Q Cnt stuck above zero means the reliable transport is struggling, and the adjacency is next.
• Suspect the path, not the protocol. EIGRP survives on remarkably bad links when timers and MTU agree. Chronic flapping is almost always layer 1 or layer 2 weather: duplex mismatches, a dirty optic, a saturated policer on the carrier side.

The Two-Minute Method

• show ip eigrp neighbors on both sides. Note who is missing, and read the AS number in the header line while you are there.
• show logging | include DUAL. If there is a named reason, you are one section above away from the fix.
• Total silence? ping the neighbor's interface address, then show ip eigrp interfaces both sides (passive check), then show ip protocols (AS, K values, filters in one screen).
• Auth suspected: show ip eigrp interfaces detail | include Authentication both sides.
• Adjacency forms but flaps: watch Q Cnt and SRTT in the neighbor table, and go hunting below layer 3.

Note that adjacency troubleshooting in OSPF is a different game with more states to inspect (the OSPF guide covers its state machine); EIGRP is binary, a neighbor exists or it does not, which is why the logs and the process of elimination above carry most of the weight.

Key Takeaways

• Adjacency failures are a short list: AS, K values, authentication, passive-interface, and layer 3 plumbing. Learn the fingerprint of each.
• K-value and auth failures announce themselves in the logs. AS mismatch and passive-interface fail silently, so they are checked by inspection, not by waiting for errors.
• show ip eigrp neighbors, show logging | include DUAL, and show ip protocols resolve the majority of cases without a single debug.
• Removing a classic EIGRP process silently deletes AS-scoped interface auth commands. Audit interfaces after process surgery.
• A neighbor that forms and then flaps with rising Q counts is a transport problem (MTU, unidirectional link), not a protocol problem.

Once the adjacency is solid but routes still are not where they should be, the sequel is troubleshooting EIGRP route advertisement and missing routes. And for the protocol theory underneath all of it, the EIGRP complete guide is the hub.