As most of you probably know, I have been studying for my CCNP certification lately. I’m currently working through the EIGRP protocol and one of the topics that keeps coming up (and I continually seem to forget one of the steps for) is EIGRP authentication using key chains. This is just a quick how-to for those who might be in the same spot.

Step 1: Create the key chain

Key chains have three necessary components and two optional componenets. The necessary components are the key chain name, key number and key string (aka password). Optionally you can include an accept-lifetime and a send-lifetime parameter that will dictate which keys on the key chain are used when. Lets get started on the initial configuration…

You’ll need to start in global configuration mode and then enter the following command where <unique_key_chain_name> is any name of your choosing:

key chain <unique_key_chain_name>

You should now be in key chain configuration mode. Create a key with the following command:

key <unique_number>

The number you choose here is important as the sequence of keys play into what keys will be used for particular functions. Assuming that this is a new key chain you will almost always start with key 1. The last step that needs to be accomplished for a functioning key chain is setting the key string. This is essentially the same thing as a shared secret phrase or a password and will need to match the key-strings configured on neighboring routers:

key-string <unique_string>

Of all of the above components the two thing that need to match identically to neighboring devices is the key number and key string. The key chain name is only locally relevant and is not used in the authentication process. So long as the key number and key-string match authentication should work correctly.

So that is all good…we now have a key chain and it is configured with a key and key-string but it doesn’t do us much good until we apply that to something and that brings us to step 2…

Step 2: Apply the key chain to an interface

Authentication is configured in interface configuration mode (not router configuration mode as you might expect). Any interface that has authentication configured on it will not form neighbor relationships out that interface unless the neighbor passes the authentication process. To apply key chain authentication on an interface you must issue the following two commands in interface configuration mode:

ip authentication mode eigrp <ASN> md5
ip authentication key-chain eigrp <ASN> <unique_key_chain_name>

**Note: While configuring authentication, if a neighbor relationship already exists it will be torn down when the first of these two commands is issued on an interface. The neighbor relationship will only re-establish itself when authentication is removed from the interface or the neighbor is configured with a complementary authentication scheme.**

So that’s it for the basics of how to configure EIGRP authentication for neighbor relationships. Let’s take a look at the entire configuration start to finish and then cover some additional configuration items as well as some of the caveats of how the authentication works:

R1>en
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#key chain JKM
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string jordanmartin.net
R1(config-keychain-key)#int fa0/0
R1(config-if)#ip authentication mode eigrp 61 md5
R1(config-if)#
*Mar 1 00:30:49.987: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 61: Neighbor 192.168.1.2 (FastEthernet0/0) is down: authentication mode changed
R1(config-if)#ip authentication key-chain eigrp 61 JKM

R2>en
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#key chain HEM
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string jordanmartin.net
R2(config-keychain-key)#int fa0/0
R2(config-if)#ip authentication mode eigrp 61 md5
R2(config-if)#ip authentication key-chain eigrp 61 HEM
R2(config-if)#
*Mar 1 00:32:57.723: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 61: Neighbor 192.168.1.1 (FastEthernet0/0) is up: new adjacency

Accept-lifetime and Send-lifetime

The accept-lifetime and send-lifetime are configuration parameters that are available while configuring a key of a key string. These two commands are pretty self-eplanitory but essentially they establish a time frame for the validity of a key. One of the primary uses for expiring keys is to change key combinations for security reasons.  By configuring multiple keys with different expiration time frames you can configure the key change in advance without impacting your current authentication methods.  The proper way to configure the commands are:

accept-lifetime 01:00:00 Nov 7 2011 13:00:00 Nov 7 2011
send-lifetime 01:00:00 Nov 7 2011 13:00:00 Nov 7 2011

The above commands would use make the key valid between 1AM and 1PM on November 7th only.  This process is obviously very dependent on synchronized clocks between routers.  If you are going to set accept-lifetime and send-lifetime values for your authentication keys it is highly recommended to make use of a central time server to ensure clock synchronization.  To understand completely what happens when multiple keys are valid at the same time we need to take a look at how EIGRP selects the keys to use when authenticating.

Key Selection

When authentication is configured EIGRP identifies potential neighbors and then goes directly into the authentication process. To select which key it sends to it’s neighbor, the router looks through it’s entire list of keys and sends the key-string of the lowest key number that is currently valid. Assuming that today is November 8th, 2011, key 2 and key 3 would be the only valid keys of the four keys in the chart below. Since key 2 is the lowest numbered key, this is the key that will be used to attempt authentication with the neighboring router.

Based on the same information above, if this router were to receive a key string as part of the authentication process, it would try to validate that key against all currently valid keys. If the received key matched either key 2 or key 3 then the authentication would have been validated and the neighbor relationship would be established.