EIGRP Neighbor Requirements: The 5 Things That Must Match

Two EIGRP routers connected by a working link will not necessarily form a neighbor relationship. EIGRP has a specific list of things that must match before two routers become neighbors, and when an adjacency refuses to come up, the cause is almost always one item on that list. This post is the checklist: the five things that must match, the things that surprisingly do not have to match, and how to confirm each one on Cisco IOS XE.

For the cluster overview, see the EIGRP complete guide. For how this compares to the other major IGP, see the OSPF pillar.

The five requirements

For two routers to become EIGRP neighbors, all five of these must be true:

#	Requirement	Why
1	Connectivity on the same subnet	EIGRP Hellos are sent to a multicast address on the local link; neighbors must be L2-adjacent and in the same IP subnet.
2	Matching autonomous system number	The AS number is part of the EIGRP process identity. Different AS = different EIGRP process = no adjacency.
3	Matching K-values (metric weights)	If two routers weight the metric components differently, EIGRP refuses to peer rather than risk inconsistent path math.
4	Matching authentication	If authentication is configured, the mode and key must match. A mismatch silently drops the Hellos.
5	The interface is in the EIGRP process and not passive	The interface must be covered by a `network` statement (or named-mode config) and must not be a passive interface.

Requirement 1: same subnet and primary address

EIGRP forms neighbors with routers it hears Hellos from on a directly connected link. Those routers must be in the same IP subnet. A common subtle failure: the two interfaces are physically connected but addressed in different subnets (a typo in the mask, or addresses that simply do not overlap). The link is up, but EIGRP never sees a neighbor.

One more wrinkle: EIGRP sources Hellos from the interface's primary IP address and expects neighbors on that primary subnet. If you are using secondary addresses, the primary subnets must still align.

Requirement 2: matching AS number

EIGRP is configured per autonomous system. router eigrp 100 and router eigrp 200 are two completely separate EIGRP processes that will not talk to each other, even on the same wire.

! R1
router eigrp 100
 network 10.30.30.0 0.0.0.3
!
! R2 - will NOT peer with R1
router eigrp 200
 network 10.30.30.0 0.0.0.3

In named mode the AS number appears in the address-family line (address-family ipv4 unicast autonomous-system 100) - same rule, it must match.

Requirement 3: matching K-values

EIGRP's composite metric is built from up to five components, each weighted by a K-value: K1 (bandwidth), K2 (load), K3 (delay), K4 and K5 (reliability/MTU terms). The defaults are K1=1, K2=0, K3=1, K4=0, K5=0 - bandwidth and delay only.

If one router has the default K-values and someone changed them on the other, EIGRP will not form the adjacency. The two routers would compute metrics differently, which could create routing loops, so EIGRP refuses to peer at all rather than allow the inconsistency. A K-value mismatch produces a specific log message naming the mismatch.

The practical advice: do not change K-values. The defaults are correct for virtually every network, and the only thing changing them reliably achieves is breaking adjacencies with routers you forgot to also change.

Requirement 4: matching authentication

If EIGRP authentication is configured on an interface, the neighbor must present the matching authentication. Both the mode (MD5, or the newer named-mode SHA / HMAC-SHA-256) and the key must align.

The failure mode here is quiet. A router receiving Hellos that fail authentication simply discards them. There is no neighbor, and unless you are looking at debug output you do not see why - it looks identical to "no Hellos arriving at all." If an adjacency will not form and the link is clean, check whether one side has authentication configured and the other does not.

Requirement 5: interface in the process, not passive

The interface has to actually be running EIGRP. In classic mode that means a network statement covers the interface's IP. In named mode it means the interface falls under the address-family configuration.

And it must not be passive. passive-interface tells EIGRP to stop sending Hellos out that interface - which means no neighbor will ever form across it. Passive-interface is correct on interfaces facing hosts (you advertise the subnet but do not want neighbors there); it is a bug on an interface where you expect an adjacency.

What does NOT have to match

This is the part that trips people who assume EIGRP behaves like OSPF:

Does not need to match	Note
Hello and hold timers	Unlike OSPF, EIGRP neighbors form even with different Hello/hold timers. Each router tells the other its own hold time. (Mismatched timers can still cause instability - keep them aligned in practice - but they do not block the adjacency.)
Router IDs	Should be unique, but a duplicate RID does not stop the adjacency the way it would in OSPF.
Interface MTU	EIGRP does not require matching MTU to form a neighbor (OSPF does, and stalls in ExStart/Exchange on a mismatch).

The OSPF habit of blaming Hello-timer and MTU mismatches does not transfer to EIGRP. For EIGRP, focus on the five real requirements.

Verifying the adjacency

The first command:

R1# 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.30.30.2    Et0/0       13    01:42:08  8     100   0   24

A neighbor listed here with a climbing Uptime is healthy. If the table is empty, walk the five requirements.

To confirm the interface is actually participating:

R1# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
                Xmit Queue   PeerQ        Mean
Interface  Peers Un/Reliable Un/Reliable  SRTT
Et0/0        1   0/0         0/0          8

If the interface you expect is missing from this list, it is not in the EIGRP process (requirement 5) - or it is passive. And for the most direct answer when an adjacency is failing:

R1# debug eigrp packets

This shows incoming Hellos and will explicitly report a K-value mismatch or an authentication failure. Turn it off as soon as you have the answer.

Troubleshooting flow

Symptom	Check
Neighbor table empty, link is up	Same subnet? `show ip interface brief` both ends.
Log shows "K-value mismatch"	Someone changed K-values. Restore defaults on both.
Hellos sent but no neighbor, link clean	Authentication mismatch - one side configured, the other not.
Interface missing from `show ip eigrp interfaces`	Not covered by a network statement, or set passive.
Neighbor flaps - forms then drops repeatedly	Often duplex/MTU/physical issues, or unidirectional connectivity. Not a "requirement" failure but a link problem.

Key takeaways

Two EIGRP routers become neighbors only when five things line up: same subnet, same AS number, matching K-values, matching authentication, and the interface in the process and not passive. Unlike OSPF, EIGRP does not require matching Hello timers or MTU - so do not waste time chasing those. When an adjacency will not form, run show ip eigrp neighbors, then show ip eigrp interfaces, then walk the five-item list. A K-value mismatch and a one-sided authentication config are the two that fail most quietly.

For the EIGRP cluster, see the EIGRP pillar.