Skip to content
Log in Sign up My account

1.9.b EIGRP Neighbor Relationships and Authentication

Blueprint 1.9.b: Troubleshoot EIGRP (classic and named mode): neighbor relationship and authentication

  • How neighbors are discovered and how reliable delivery (RTP) works
  • The parameters that must match, and the ones that do not have to
  • Reading show ip eigrp neighbors and the neighbor-change log messages
  • MD5 authentication with key chains (classic and named mode)
  • HMAC-SHA-256 authentication (named mode)
  • Common failure modes: passive interfaces, ACLs, static neighbors, timers, duplicate router IDs

When an EIGRP ticket starts with "a route is missing", the first question is always whether the neighbor that should advertise it is up. Most adjacency faults leave a clear trace in show ip eigrp neighbors, the %DUAL-5-NBRCHANGE log message, or a short debug eigrp packets session. This page teaches you to read those three sources.

How an adjacency forms

EIGRP runs directly over IP as protocol 88. Hellos go to 224.0.0.10 (IPv4) or FF02::A (IPv6) every 5 seconds on most links. When a router hears a hello that passes all the checks below, it adds the sender to its neighbor table and immediately sends it a full set of routes in unicast update packets. After that, only changes are sent.

Packet Opcode Delivery Purpose
Update 1 Reliable, unicast during startup, multicast for later changes Carry routes
Query 3 Reliable Ask neighbors for an alternate path when a route goes active
Reply 4 Reliable, unicast Answer a query
Hello 5 Unreliable, multicast Discover and keep neighbors
Ack 5 (hello with no data) Unreliable, unicast Acknowledge a reliable packet
SIA-Query, SIA-Reply 10, 11 Reliable Check on a neighbor during a long active period

The Reliable Transport Protocol (RTP) tracks every reliable packet. If a neighbor does not acknowledge, the packet is retransmitted as unicast, waiting the RTO shown in the neighbor table between attempts. After 16 retries the neighbor is reset with the reason "retry limit exceeded". That message almost always means hellos (multicast) get through but unicast does not.

graph TB
  S["Neighbor missing"] --> L{"Interface up/up and<br/>addressed?"}
  L -- No --> L1["Fix Layer 1, 2 or 3 first"]
  L -- Yes --> E{"Interface in<br/>show ip eigrp interfaces?"}
  E -- No --> E1["network statement, passive,<br/>af-interface shutdown (IPv6)"]
  E -- Yes --> H{"Hellos received?<br/>debug eigrp packets hello"}
  H -- No --> H1["ACL, filter, static neighbor<br/>on one side only, Layer 2 issue"]
  H -- Yes --> M{"Log or debug<br/>gives a reason?"}
  M -- "K-value mismatch" --> M1["metric weights"]
  M -- "auth message" --> M2["key ID, key string,<br/>mode, password"]
  M -- "not on common subnet" --> M3["primary IP addresses"]
  M -- "retry limit exceeded" --> M4["unicast blocked:<br/>ACL, MTU path, one-way link"]

What must match

Parameter Must match? Symptom when wrong
AS number Yes No neighbor and no log message. Hellos from another AS are silently ignored.
K values Yes Log: Neighbor 10.1.2.2 (GigabitEthernet0/1) is down: K-value mismatch
Primary IPv4 subnet Yes (IPv4 only) Log or debug reports the neighbor is "not on common subnet"
Authentication Yes No neighbor. debug eigrp packets shows ignored packets with an authentication reason
Hello and hold timers No Can cause flapping, see below
Router ID Does not have to differ for adjacency Duplicate IDs make each router drop the other's external routes
MTU Not checked Adjacency forms; large updates may fail if the path cannot carry them
Named vs classic mode No They interoperate if the checks above pass

Timers: why mismatched values still matter

Each router advertises its own hold time in its hellos. The neighbor uses that value to decide how long to wait. If R2 is changed to hello-interval 20 but its hold time stays at 15, R1 waits only 15 seconds for a hello that arrives every 20 seconds, so R1 drops R2 with "holding time expired", re-forms the adjacency, and drops it again. R2 sees nothing wrong with R1. Fix it on R2 by setting the hold time to at least three times the hello interval. When reading show ip eigrp neighbors, the Hold column counts down from the neighbor's advertised hold time. A value that counts down well past 10 before resetting shows a slow hello.

Router ID

The EIGRP router ID is used for loop prevention on external routes. If two routers share a router ID, each one ignores external routes that claim to originate from "itself". Internal routes and the adjacency are unaffected, so the symptom is very specific: redistributed prefixes from one router never appear on the other. show ip eigrp topology <prefix> on the originating router shows the "Originating router" field, and show ip protocols shows each router's ID.

Exam trap

EIGRP does not require hello and hold timers to match, unlike OSPF's hello and dead timers. An exhibit with different timers on two neighbors is only a fault if the hold time is shorter than the hello interval on the sending side. Do not pick "timer mismatch" as the cause of a missing adjacency.

Other adjacency killers

  • Passive interface. No hellos are sent or processed, so no neighbor forms, but the interface's subnet is still advertised. In named mode: af-interface Gi0/1 then passive-interface.
  • Static neighbors. neighbor 10.1.2.2 GigabitEthernet0/1 makes EIGRP send unicast hellos on that interface and stop processing multicast hellos there. If only one side has the neighbor command, the other side's multicast hellos are ignored and the adjacency fails. Every router on that segment that needs to peer must be configured with static neighbors.
  • ACLs. An inbound ACL must permit eigrp from the neighbor's address and to 224.0.0.10. An ACL that permits only the multicast destination lets hellos through but drops unicast updates and acks, which produces "retry limit exceeded" and a neighbor that flaps every couple of minutes.
  • Secondary addresses. Hellos are sourced from the primary address. If R1's primary is 10.1.2.1/30 and R2's primary is 192.168.12.2/24, they are not neighbors even if they share a secondary subnet.

Reading the neighbor table

R1# show ip eigrp neighbors
EIGRP-IPv4 VR(CORP) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
2   10.1.5.5                Gi0/3                    13 00:42:10    4   100  0  31
1   10.1.3.3                Gi0/2                    11 00:00:47 1180  5000  2  44
0   10.1.2.2                Gi0/1                    12 00:42:16    2   100  0  52
Column Meaning What a fault looks like
H Order in which neighbors came up
Hold Seconds left before the neighbor is declared down Counting below 10 regularly means hellos are being lost
Uptime Time since the adjacency formed A short uptime on one neighbor among long ones means it is flapping
SRTT Smoothed round-trip time for reliable packets A large value means slow acks
RTO Retransmission timeout Grows toward 5000 ms when acks go missing
Q Cnt Reliable packets waiting to be sent or acknowledged Should be 0. A value that stays above 0 means unicast is not getting through
Seq Num Last sequence number received from the neighbor

In the output, 10.1.3.3 has an uptime under a minute, an SRTT over a second, RTO at its 5000 ms ceiling and two packets queued. That is the signature of a neighbor whose hellos arrive but whose acks do not, and it will reset with "retry limit exceeded".

The log messages give you the reason directly. The most useful reasons are:

Reason in %DUAL-5-NBRCHANGE Meaning
holding time expired No hello within the hold time: link loss, filter, or a slow hello from the neighbor
retry limit exceeded Reliable packets not acknowledged after 16 retries
K-value mismatch Metric weights differ
Interface PEER-TERMINATION received The neighbor shut its process or interface down, or its configuration changed
peer restarted The neighbor process restarted
stuck in active The neighbor did not answer a query in time (see DUAL)
route configuration changed Local configuration change (for example, authentication or a network statement)

Authentication

EIGRP authentication protects against forged neighbors and route injection. Every EIGRP packet carries the authentication data, so a mismatch stops the adjacency entirely. It never partially works.

MD5 HMAC-SHA-256
Classic mode Yes, with a key chain No
Named mode Yes, with a key chain Yes, with a password under af-interface
Key rotation with lifetimes Yes (key chain send-lifetime and accept-lifetime) Not with the inline password form
Must match Key ID and key string Password

MD5 with a key chain

The sender puts the key ID in the packet along with the MD5 digest. The receiver looks up the same key ID in its own key chain and checks the digest. So both the key number and the key string must match. The key-chain name is local and does not have to match.

When a key chain holds several keys, the router sends with the first valid key, meaning the lowest key ID whose send-lifetime covers the current time, and accepts any key whose accept-lifetime is valid. Lifetimes depend on the clock, so key rollover without NTP is a classic cause of a whole region losing adjacencies at midnight.

key chain BRANCH-KEYS
 key 1
  key-string Br4nchKey1
!
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  af-interface GigabitEthernet0/3
   authentication mode md5
   authentication key-chain BRANCH-KEYS
  exit-af-interface

key chain BRANCH-KEYS
 key 1
  key-string Br4nchKey1
!
interface GigabitEthernet0/3
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 BRANCH-KEYS

interface GigabitEthernet0/3
 ipv6 authentication mode eigrp 100 md5
 ipv6 authentication key-chain eigrp 100 BRANCH-KEYS

Both commands are needed in every form. A mode with no key chain, or a key chain with no mode, does not authenticate.

HMAC-SHA-256 (named mode only)

router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  af-interface default
   authentication mode hmac-sha-256 0 C0reS3cret
  exit-af-interface
  af-interface GigabitEthernet0/3
   authentication mode md5                   ! the specific interface overrides default
   authentication key-chain BRANCH-KEYS
  exit-af-interface

af-interface default applies to every interface in the address family. A specific af-interface block overrides it for that interface. The 0 means the password that follows is in clear text. With service password-encryption it is displayed encrypted.

Exam trap

If an exhibit shows ip authentication mode eigrp 100 hmac-sha-256 on an interface, that command does not exist in classic mode. HMAC-SHA-256 needs named mode. Equally, authentication mode under an af-interface of the IPv4 address family does nothing for the IPv6 address family. Each AF is authenticated separately.

Verifying authentication

R1# show ip eigrp interfaces detail GigabitEthernet0/3
EIGRP-IPv4 VR(CORP) Address-Family Interfaces for AS(100)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Gi0/3                    1        0/0       0/0           4       0/0           50           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 3/0
  Hello's sent/expedited: 512/2
  Un/reliable mcasts: 0/3  Un/reliable ucasts: 4/3
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 0  Out-of-sequence rcvd: 0
  Topology-ids on interface - 0
  Authentication mode is md5,  key-chain is "BRANCH-KEYS"

R1# show key chain
Key-chain BRANCH-KEYS:
    key 1 -- text "Br4nchKey1"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]

When authentication fails, debug eigrp packets (filter it with debug eigrp packets hello on a busy router) prints one line per rejected packet, for example:

EIGRP: Gi0/3: ignored packet from 10.1.5.5, opcode = 5 (invalid authentication)

"Invalid authentication" means both sides authenticate but the key ID, key string or password differs. When only one side is configured, the reason reads "missing authentication" or "authentication off or key-chain missing", depending on which side you are on and the release. A key chain name that is referenced but does not exist produces the key-chain-missing message on the local router.

Exam trap

show running-config shows a key-string exactly as typed, including a trailing space if one was entered. Two key strings that look identical in an exhibit can differ by a trailing space. If everything else matches and the debug still says "invalid authentication", re-enter the key string on both sides.

Lab: three neighbor tickets

Use the module baseline from the address-family lab. Reload flash:baseline.cfg before each ticket. Prove each fix with show ip eigrp neighbors and the route the ticket names.

graph LR
  R5["R5 branch"] -- "Gi0/1 MD5 key 1" --- R1["R1"]
  R1 -- "Gi0/1 HMAC-SHA-256" --- R2["R2"]
  R1 -- "Gi0/2 HMAC-SHA-256" --- R3["R3"]
  R2 -- "HMAC" --- R4["R4"]
  R3 -- "HMAC" --- R4

Ticket 3: "The branch dropped off the network after a security change on R1."

Inject on R1:

router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  af-interface GigabitEthernet0/3
   authentication key-chain BRANCH-KEY
  1. show ip eigrp neighbors on R1: 10.1.5.5 is missing. The IPv6 neighbor FE80::5 is still up, so the link works.
  2. show ip eigrp interfaces detail Gi0/3 on R1 reports key-chain is "BRANCH-KEY".
  3. show key chain lists only BRANCH-KEYS. The referenced chain does not exist, so R1 cannot build or check digests.
  4. Fix: authentication key-chain BRANCH-KEYS, then confirm 10.5.50.0/24 is back in R1's routing table.

Ticket 4: "Since the core password change, R1 has no backup path to the data centre."

Inject on R3:

router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  af-interface GigabitEthernet0/1
   authentication mode hmac-sha-256 0 C0reS3cret2026
  1. On R1, show ip route 10.4.40.0 lists only the path through 10.1.2.2. show ip eigrp neighbors has no 10.1.3.3.
  2. On R3, show ip eigrp neighbors still shows R4, so R3's EIGRP process is healthy.
  3. debug eigrp packets hello on R1 shows ignored packet from 10.1.3.3, opcode = 5 (invalid authentication).
  4. show running-config | section router eigrp on R3 shows the specific af-interface GigabitEthernet0/1 block overriding the default password. Remove it with no af-interface GigabitEthernet0/1 or set the password back, and confirm both paths to 10.4.40.0/24 return on R1.

Ticket 5: "The R1 to R2 adjacency keeps bouncing every few minutes."

Inject on R2:

ip access-list extended WAN-IN
 permit eigrp any host 224.0.0.10
 permit icmp any any
 deny   ip any any log
!
interface GigabitEthernet0/1
 ip access-group WAN-IN in
  1. On R1, show ip eigrp neighbors shows 10.1.2.2 with a short uptime, RTO near 5000 and a Q Cnt above zero.
  2. The log on both routers cycles through is up: new adjacency and is down: retry limit exceeded.
  3. R2's ACL counters (show ip access-lists WAN-IN) increase on the deny ip any any log line, and the log entries show protocol 88 packets from 10.1.2.1 to 10.1.2.2.
  4. Fix by permitting EIGRP from the link subnet to any destination, for example permit eigrp 10.1.2.0 0.0.0.3 any above the deny. Watch Q Cnt return to 0 and uptime keep climbing.

Quick check

R1 uses key chain A with key 1 and string cisco. R2 uses key chain B with key 1 and string cisco. Do they authenticate?

Yes. Key-chain names are local. The key ID and the key string match, so the digests match.

An adjacency shows an uptime that never exceeds about 80 seconds, Q Cnt of 1 and RTO 5000. What category of fault is this?

Hellos are getting through but reliable unicast packets are not acknowledged, so the neighbor is reset with "retry limit exceeded". Look for an ACL that permits only multicast EIGRP, a one-way link, or a path that cannot carry full-size update packets.

Two routers redistribute static routes into EIGRP. Each one sees the other's internal routes but not its external routes. Everything else is normal. What do you check?

The router IDs. A router discards external routes whose originating router ID equals its own, so a duplicate EIGRP router ID hides external routes only.

References