Troubleshooting EIGRP Neighbor Adjacencies: The Loud Failure and the Silent One

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 a finite list. A handful of causes account for nearly every case, and each one leaves a distinct fingerprint in the logs and the show commands.

This guide works through the real ones, broken deliberately on live CML labs so you can see the exact output each failure produces. The two headline cases, a K-value mismatch and a wrong autonomous system number, were captured on iol-xe routers running IOS XE 17.18.2, and they behave in opposite ways. One fills your log every few seconds. The other produces nothing at all, anywhere, ever. Knowing which is which is most of the diagnosis. For the protocol theory underneath the adjacency, how EIGRP builds and maintains its topology table is the hub.

The requirements list itself, meaning what has to match before two routers will peer at all, lives in the five things that must match before EIGRP will peer. This article is the other half: recognizing each failure from the router's point of view.

What This Was Captured On

Three routers, all iol-xe nodes in Cisco Modeling Labs running IOS XE 17.18.2. R1 is the observer, and it has two broken adjacencies at the same time, deliberately broken in two different ways:

• R1 Et0/0 10.0.12.1/30 to R2 Et0/0 10.0.12.2/30. Both run router eigrp 100, but R2 was given metric weights 0 1 1 1 0 0, which turns K2 on. K-value mismatch.
• R1 Et0/1 10.0.13.1/30 to R3 Et0/0 10.0.13.2/30. Layer 3 is fine and the subnet is shared, but R3 runs router eigrp 200 against R1's 100. AS mismatch.

Both links are up, both interfaces sit in the right /30, and there is no ACL and no authentication anywhere. The only thing wrong on each link is one parameter. Broken state, fix and recovery were captured on R1 with on-box EEM applets writing show output to syslog, so everything below is what the router actually printed.

The later sections (passive interface, authentication, timers) come from a companion CML lab built in EIGRP named mode, which is why their captures carry the longer VR(PINGLABZ) Address-Family header. Same protocol, different syntax.

The Checklist, In the Order That Finds Problems Fastest

Two routers 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). Start every investigation the same way, on both ends:

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.0.13.2               Et0/1                    13 00:00:50    1   100  0  3
0   10.0.12.2               Et0/0                    13 00:00:54    2   100  0  3

That is what healthy looks like (R1, after both faults were repaired). Hold counting down and resetting, uptime climbing, SRTT in single-digit milliseconds, 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. When EIGRP has an opinion about why a neighbor went away it says so in plain text, and each scenario below has different phrasing. When it has no opinion, that silence is itself diagnostic, and the next two sections are about the difference.

Failure 1: K-Value Mismatch (Loud)

K values weight the composite metric formula, and both routers must agree or the metrics they exchange would be incomparable. R1 to R2 fails this test, and R1 will not stop telling you about it:

R1# show logging | include DUAL
*Jul 20 22:50:30.411: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2
  (Ethernet0/0) is down: K-value mismatch
*Jul 20 22:50:43.855: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2
  (Ethernet0/0) is down: K-value mismatch

Read that message carefully, because the wording explains the mechanism. It says Neighbor is down, which means a neighbor object briefly existed. R2's hello arrives, R1 accepts it (the AS in the header matches, so the packet is for this process), parses the parameters, finds K2 set where its own K2 is zero, and tears the relationship down before it ever reaches the update phase. The next hello repeats the cycle, roughly every 13 seconds in our capture, which is why this failure is impossible to miss on a console.

Meanwhile the neighbor table is empty, and this part is worth sitting with:

R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
R1#

Nothing. Not R2, and not R3 either. R1 should have two neighbors and has zero, but the log names exactly one of them, 10.0.12.2 on Ethernet0/0. The other link is invisible.

The compare command is show ip protocols, which prints the AS number and all five K values on one screen. Run it on both ends and put them side by side:

R1# show ip protocols
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    <-- R1 defaults; R2 had K2=1
    Soft SIA disabled
    NSF-aware route hold timer is 240
    Router-ID: 10.0.13.1
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum metric variance 1
      Total Prefix Count: 2

K1=1, K3=1, everything else 0 is the default and the right answer for almost everyone. K2 (load) and K5 (reliability) pull live, fluctuating interface statistics into the metric, which is how you build a network whose routes recompute because somebody started a backup job. For the full derivation, what each EIGRP K value actually weights covers the formula properly.

The fix is to make them agree. On R2, restore the defaults with metric weights 0 1 0 1 0 0 (the leading 0 is TOS, always 0, then K1 through K5), or simply no metric weights. The adjacency returns on its own within a hello or two, with nothing to bounce.

Failure 2: AS Number Mismatch (Silent)

Now the opposite personality, and this is the contrast the whole article is built on. R3 sits on the same /30 as R1, with a working link, running router eigrp 200 against R1's router eigrp 100.

Here is what R1 logged about R3 during the entire broken window: nothing. Not one line, and that is the finding. The log excerpt above is the complete DUAL output from that capture, and every entry in it names 10.0.12.2. The 10.0.13.2 link, equally broken, generated no syslog at any severity.

The reason is structural. The AS number sits in the EIGRP packet header and is checked before anything else. A router running AS 100 does not treat an AS 200 hello as a badly configured peer, it treats it as a packet for a process it is not running, and drops it. No neighbor object is created, so there is nothing to declare down and nothing to log. They are separate routing domains that happen to share a wire.

So the evidence for a silent failure is entirely negative: a neighbor that should be in the table is not, with no explanation anywhere. That combination is the signal to stop grepping the log and start comparing configuration by inspection.

The fastest tell is the header line of show ip eigrp neighbors. Notice that R1's empty output above still prints EIGRP-IPv4 Neighbors for AS(100). Run the same command on the far end and read its header. If it says AS(200), you are finished, and it took four seconds. show ip protocols gives the same answer with more context (its process line reads Routing Protocol is "eigrp 200"), and show ip protocols summary gives one line per process if the box runs several. Easy to check, easy to overlook, and the number one cause of "EIGRP just will not come up" on a link somebody else built.

Loud Versus Silent, Side By Side

Both faults produce the identical top-level symptom, an empty neighbor table. Everything that distinguishes them is in what the router does or does not say:

The practical consequence: a quiet log does not clear EIGRP. It is exactly what a wrong AS number, a passive interface, or an ACL blocking protocol 88 looks like.

The Fix, and What Recovery Looks Like

Both repairs are applied on the far ends. R2 restores the default weights, R3 moves from AS 200 to AS 100:

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

R3(config)# no router eigrp 200
R3(config)# router eigrp 100
R3(config-router)# network 10.0.13.0 0.0.0.3

R1 was not touched. Within seconds it picked up both peers, and this time both events are logged, because "up" is always loud:

R1# show logging | include DUAL
*Jul 20 22:53:11.686: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2
  (Ethernet0/0) is up: new adjacency
*Jul 20 22:53:16.061: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.13.2
  (Ethernet0/1) is up: new adjacency

The neighbor table then reads exactly as the healthy example at the top of this article. Note that is up: new adjacency fires for the silent failure too: once the AS matches, the router that had nothing to say suddenly has plenty, and that line is your confirmation the fix landed. One warning before copying the R3 snippet into production: no router eigrp 200 throws away everything scoped to that process, interface authentication included.

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, and that asymmetry tells you which end to log into: 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, though the two most useful lines are debug-level, so they appear only if you are already looking:

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: 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 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, and on IOL and IOS XE inbound ACLs are evaluated before almost everything. A neighbor cycling through retransmissions with Q Cnt climbing, then retry limit exceeded, means hellos pass but unicast updates do not: MTU mismatch or a unidirectional link. 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 shorter than the loss and jitter on the path (an overloaded WAN circuit, a congested tunnel) means a couple of dropped hellos bounce the neighbor, 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 live under the af-interface (hello-interval, 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 for input errors, CRCs, and output drops. On virtual and lab gear, also check 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.

Flapping neighbors also carry a second-order cost. Every drop sends the routes learned through that peer active and DUAL floods queries, and if a query lands on a peer that cannot reply in time you get the stuck in active timeout that tears down an unrelated neighbor. If a ticket has both a flap and an SIA event, fix the flap first.

Common Mistakes and Gotchas

• Assuming a quiet log means EIGRP is healthy. Our AS 200 link was as dead as the K-value link and produced zero syslog on either side. Absence of a message is data, not reassurance.
• Forgetting that one log line may cover only one of several faults. R1 had two broken links and one message, naming 10.0.12.2, so the Ethernet0/1 side was diagnosed purely by elimination. Count the peers that are unaccounted for.
• Skimming past the neighbor table header. EIGRP-IPv4 Neighbors for AS(100) prints even when the table is empty, which makes it the cheapest AS comparison available. Named mode adds the virtual instance name, so the two ends may format the line differently.
• Touching K values at all. The only defensible reason to change metric weights is a documented design decision applied identically to every router in the AS.
• Recreating a routing process to "reset" it. no router eigrp <as> silently removes AS-scoped interface commands, including authentication, which turns a one-line fix into a second, subtler outage.
• Fixing timers to fix an adjacency. Hello and hold do not need to match. Time spent aligning them is time not spent on the AS number.

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. A named reason puts you one section above away from the fix. Nothing at all points at AS, passive-interface or a filter.
• Total silence? ping the neighbor's interface address, then show ip eigrp interfaces both sides (passive check), then show ip protocols both sides.
• 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.
• A K-value mismatch is loud. IOS XE logs %DUAL-5-NBRCHANGE ... is down: K-value mismatch on every hello, because the hello is accepted and then rejected on parameters.
• An AS mismatch is completely silent. The hello is dropped at the header, no neighbor object exists, nothing is logged on either router. Find it by comparing headers or show ip protocols, never by grepping the log.
• show ip protocols is the single best compare-both-ends command: AS number and all five K values on one screen.
• 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 if you want the wider context for why DUAL cares so much about metric agreement in the first place, start from the full EIGRP protocol reference.