Enabling EIGRP Authentication

Problem

You want to authenticate your EIGRP traffic to ensure that no unauthorized equipment can affect your routing tables.

Solution

To enable MD5-based EIGRP packet authentication, you must first define a key chain for the encryption, and then apply the authentication commands to the interface as follows:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#key chain ORA
Router1(config-keychain)#key 1
Router1(config-keychain-key)#key-string oreilly
Router1(config-keychain-key)#exit
Router1(config-keychain)#exit
Router1(config)#interface Serial0/1
Router1(config-if)#ip authentication mode eigrp 55 md5
Router1(config-if)#ip authentication key-chain eigrp 55 ORA
Router1(config-if)#exit
Router1(config)#end
Router1#

Discussion

As soon as we configure EIGRP authentication on this router, the neighbor relationship dropped because it failed to authenticate:

IP-EIGRP 55: Neighbor 172.25.2.2 (Serial0/0.2) is down: Auth failure

To bring this neighbor back up, you have to ensure that both routers use the same authentication keys.

It's important to remember that this is just an authentication system. The routers do not encrypt the routing update packets as they send them through the network. They just authenticate these packets using MD5. This prevents people from either accidentally or maliciously injecting routes into your network. This is often useful in environments where you don't control all of the routers.

You can see from the following debug trace that when the authentication fails, EIGRP simply ignores the routing updates:

Router1#debug eigrp packet
EIGRP Packets debugging is on
 (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
Router1#
Oct 3 01:40:59.704: EIGRP: ignored packet from 172.25.2.2 opcode = 5 (invalid authentication)

One of the biggest problems with using this sort of authentication system is that changing the keys can break routing throughout your network. The following example shows a way around this problem. By configuring timed keys, you can roll out a new key throughout your network without disrupting service:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#key chain Mars
Router1(config-keychain)#key 1
Router1(config-keychain-key)#key-string rocket
Router1(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 1993 00:15:00 Nov 1 2006
Router1(config-keychain-key)#send-lifetime 00:00:00 Jan 1 1993 00:00:00 Nov 1 2006
Router1(config-keychain-key)#key 2
Router1(config-keychain-key)#key-string martian 
Router1(config-keychain-key)#accept-lifetime 23:45:00 Oct 31 2006 infinite
Router1(config-keychain-key)#send-lifetime 00:00:00 Nov 1 2006 infinite 
Router1(config-keychain-key)#end
Router1#

In this case, this router will accept the original key string, rocket, until 12:15 AM on November 1, 2006. It will send this same key string until 12:00 AM on the same date. And it will start accepting the new key string, martian, at 11:45 PM. on October 31, 2006. In this way, there is a safe 30-minute transition period that you can configure in advance throughout the network. Then, the next day or whenever it is convenient, you can remove the configuration for the old key string on all the affected routers.

The show key chain command includes information about all of the configured key chains and the corresponding key strings:

Router1#show key chain
Key-chain ORA:
 key 1 -- text "oreilly"
 accept lifetime (always valid) - (always valid) [valid now]
 send lifetime (always valid) - (always valid) [valid now]
Key-chain Mars:
 key 1 -- text "rocket"
 accept lifetime (00:00:00 Jan 1 1993) - (00:15:00 Nov 1 2006) [valid now]
 send lifetime (00:00:00 Jan 1 1993) - (00:00:00 Nov 1 2006) [valid now]
 key 2 -- text "martian"
 accept lifetime (23:45:00 Oct 31 2006) - (infinite)
 send lifetime (00:00:00 Nov 1 2006) - (infinite)
Router1#