EIGRP Authentication: MD5 and SHA in Classic and Named Mode

An unauthenticated EIGRP interface will happily form an adjacency with anything that speaks the protocol. That means anyone who can plug into that segment can inject routes, blackhole traffic, or quietly become a man in the middle. Authentication closes that door, and EIGRP gives you two flavors: MD5 with key chains (classic and named mode) and HMAC-SHA-256 (named mode only). This article configures both on a live CML lab, then deliberately breaks a key to show you exactly what failure looks like. It builds on the adjacency fundamentals in the EIGRP complete guide.

Why Authenticate an IGP

Routing protocol authentication is not about encrypting your routes; updates still cross the wire in cleartext. It is about trust: each packet carries a hash computed over the packet plus a shared secret, and a receiver that cannot reproduce the hash discards the packet. No valid hash, no adjacency, no route injection. Authentication is one of the five things that must match for an adjacency (the full list is in EIGRP neighbor requirements), and it is standard hardening in any environment where access switches or WAN circuits are not fully trusted. OSPF and BGP have their own equivalents; the same logic applies across your whole routing edge, including BGP peers.

MD5 vs HMAC-SHA-256

The named-mode-only restriction on SHA-256 is a genuinely common exam trap and a real-world migration argument: if you want stronger hashes, you migrate to named mode (the conversion path is in the EIGRP configuration guide).

The Lab

Same five-router CML topology as the rest of this cluster: R1/R2/R4 in named mode (router eigrp PINGLABZ, AS 100), R3/R5 classic (router eigrp 100). We will secure the R1-R2 link with SHA-256 and the R3-R5 link with MD5, then sabotage the MD5 key on R5.

HMAC-SHA-256 in Named Mode

One command under the af-interface, no key chain required in its simplest form:

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)# authentication mode hmac-sha-256 PingLabz!Secure123

Apply the mirror config on R2. The moment the first side goes live, the adjacency drops, because one side now demands authentication the other cannot provide. IOS XE logs it explicitly, and the recovery is automatic once both sides match:

R1# show logging | include DUAL
*Jul 11 05:21:33.266: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2
  (Ethernet0/1) is down: authentication HMAC-SHA-256 configured
*Jul 11 05:21:46.334: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2
  (Ethernet0/1) is up: new adjacency

That 13-second gap is your maintenance window reality: configure the second side promptly. Verification:

R1# show ip eigrp interfaces detail Ethernet0/1 | include Authentication
  Authentication mode is HMAC-SHA-256, key-chain is not set

MD5 with Key Chains in Classic Mode

Classic mode MD5 is a two-part job: build a key chain, then bind it to the interface with two commands (mode and key chain, and forgetting one of them is a classic ticket generator):

R3(config)# key chain EIGRP-KEYS
R3(config-keychain)# key 1
R3(config-keychain-key)# key-string PingLabzMD5key
R3(config)# interface Ethernet0/2
R3(config-if)# ip authentication mode eigrp 100 md5
R3(config-if)# ip authentication key-chain eigrp 100 EIGRP-KEYS

Modern IOS XE will lecture you about the plaintext key while you type it, which is fair:

SECURITY WARNING - Module: KEY_CHAIN, Command: key-string *,
Reason: Configuration employs an Insecure method for password storage,
Description: key-string in key-chain configured with weak encryption
(type 0, 7, or plaintext) instead of secure type 6 encryption

Repeat on R5, then verify both the interface binding and the chain itself:

R3# show ip eigrp interfaces detail Ethernet0/2 | include Authentication
  Authentication mode is md5,  key-chain is "EIGRP-KEYS"

R3# show key chain
Key-chain EIGRP-KEYS:
    key 1 -- text "PingLabzMD5key"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]

Key chains support send and accept lifetimes, which is how you rotate keys without an outage: add key 2 on both sides with an accept lifetime that overlaps key 1, cut the send lifetime over, then retire key 1. The key number matters as much as the string, because both are inputs to the hash. Same string under a different key ID fails.

Breaking It on Purpose: The Mismatch Capture

Now the part most articles skip. We change R5's key-string to the wrong value and watch from R3 with debug eigrp packets running:

R5(config)# key chain EIGRP-KEYS
R5(config-keychain)# key 1
R5(config-keychain-key)# key-string WrongKey999

R3# show logging | include authentication|DUAL
*Jul 11 05:23:16.095: EIGRP: received packet with MD5 authentication, key id = 1
*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
*Jul 11 05:23:23.961: EIGRP: pkt key id = 1, authentication mismatch

Three distinct signatures worth memorizing: the debug line authentication mismatch, the Dropping peer, invalid authentication action, and the syslog reason down: Auth failure. The neighbor table confirms the peer is simply gone:

R3# 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.0.13.1               Et0/1                    11 00:07:03   12   100  0  61

Restore the correct key-string on R5 and the adjacency returns within a hold time. No clear commands needed.

The Gotcha That Silently Eats Your Auth Config

One more failure mode we hit live in this lab: classic-mode interface authentication commands are scoped to the AS number. When we later removed router eigrp 100 from R3 during another test, IOS deleted ip authentication mode eigrp 100 md5 and the key-chain binding from the interface along with the process. Recreating the process did not bring them back, and since R5 still required MD5, the adjacency silently refused to form: no error, no log, just hellos being dropped on one side. If an adjacency will not return after process surgery, show run interface is your first stop. More silent-failure patterns like this are cataloged in troubleshooting EIGRP neighbor adjacencies.

Named Mode MD5 and Key Chains

Named mode can also do MD5, and either mode can reference a key chain, which is what you want for rotation even with SHA:

R1(config-router-af-interface)# authentication mode md5
R1(config-router-af-interface)# authentication key-chain EIGRP-KEYS

Set the mode on the af-interface (or under af-interface default to cover every interface at once, which is the sane fleet-wide pattern), and remember: mode and key chain are separate lines in named mode too.

Key Rotation Without an Outage

Shared secrets age. People leave, configs get pasted into tickets, and a key that has been in production for five years should be assumed to be public. Key chains exist so rotation does not require a maintenance window. The mechanism: EIGRP signs outgoing packets with the lowest-numbered valid send key, but accepts incoming packets signed by any valid accept key. Overlap the accept lifetimes and you can never be locked out mid-rotation.

R3(config)# key chain EIGRP-KEYS
R3(config-keychain)# key 1
R3(config-keychain-key)# key-string PingLabzMD5key
R3(config-keychain-key)# accept-lifetime 00:00:00 Jan 1 2026 01:00:00 Aug 1 2026
R3(config-keychain-key)# send-lifetime 00:00:00 Jan 1 2026 00:00:00 Jul 15 2026
R3(config-keychain)# key 2
R3(config-keychain-key)# key-string PingLabz2026H2
R3(config-keychain-key)# accept-lifetime 00:00:00 Jul 14 2026 infinite
R3(config-keychain-key)# send-lifetime 00:00:00 Jul 15 2026 infinite

Deploy this on every router in the domain before July 14 and the cutover happens by itself: on July 15 everyone starts signing with key 2, while the overlapping accept windows absorb any clock skew. That last point is the operational catch: lifetimes are only as good as the clocks. Run NTP everywhere you run key lifetimes, and audit with show key chain, which prints exactly which keys are valid right now. A key chain whose only key has expired is a self-inflicted outage with the same Auth failure signature as a typo.

Fleet-Wide Auth with af-interface default

Configuring authentication one interface at a time invites the classic gap: eleven secured links and the twelfth forgotten. Named mode can set the policy once for every interface in the address family:

R1(config-router-af)# af-interface default
R1(config-router-af-interface)# authentication mode hmac-sha-256 PingLabz!Secure123

Every current and future EIGRP interface on the router now requires authentication, which converts "did we remember?" into "did we deliberately exempt?". For an interface that genuinely should differ (say, a lab port), a specific af-interface block overrides the default. This inheritance model is one of named mode's quiet advantages and works for passive-interface and hello timers the same way.

A short deployment checklist that keeps auth rollouts boring:

• Stage key chains everywhere first; binding them to interfaces is the only disruptive step.
• Roll link by link, watching show ip eigrp neighbors return to a full table after each pair.
• Standardize one key chain name domain-wide. Half the mismatch tickets in mixed environments are two spellings of the same chain.
• Confirm NTP before adding lifetimes, and stagger send/accept windows generously (hours, not minutes).

Key Takeaways

• EIGRP authentication proves packet origin with a shared-secret hash. It stops rogue adjacencies and route injection; it does not encrypt updates.
• MD5 works everywhere and uses key chains. HMAC-SHA-256 is stronger, simpler to configure, and named mode only.
• Key ID and key string must both match. Key chain lifetimes are the mechanism for hitless rotation.
• Know the failure signatures: down: Auth failure in syslog, authentication mismatch in debug, and a neighbor that simply vanishes from the table.
• Removing a classic EIGRP process deletes its AS-scoped interface auth commands. After process changes, audit interfaces before you troubleshoot anything else.

Authentication is cheap insurance on every segment where an unexpected device could appear. For the rest of the protocol, from DUAL to design, return to the EIGRP complete guide.