Cisco EIGRP authentication – what is the key?

How many times have you heard that two potential EIGRP neighbors with md5 authentication configured will neighbor up even if they are not using the same key in their key chains?  Several Cisco texts have made this comment.  I decided that I would put this to the test.  I configured some real routers and I duplicated the test with GNS3.  I got the same results every time I tried it; that is, the neighbor relationship would break if I used mismatched keys.  So even though claims are made that the routers will cycle through the keys in each one’s key chains until it finds a matching key, let’s see what really happens.  In both my real environment and in my GNS3 environment, I have two routers connected via their FastEthernet 0/0 interfaces on a 10.1.1.0 network.  I have configured EIGRP and configured the following network statement on each: 

It is a very simple network and it looks like this:

Cisco EIGRP Authentication simple network image

I have created a key chain named Test and keys with IDs of 1 and 2, with key-string values of key1 and key2, respectively on each router.  With all this in place, I see the neighbor relationship built and maintained successfully, as shown below.


neighbor 1 Cisco EIGRP Authentication image


neighbor 2 Cisco EIGRP Authentication image

Now the goal is to try to verify that changing the key configuration will not break the neighbor relationship.  For instance, I will go to R2 and delete key 1.  Watch what happens…

R2 delete key Cisco EIGRP Authentication image

R2 delete key Cisco EIGRP Authentication

R2 drops the neighbor immediately with the message “Auth failure.”  R1 drops the neighbor, but then re-establishes the neighbor relationship.  It subsequently dies and is reborn repeatedly.  The two key chain configs side-by-side look like this:

chain key 1 Cisco EIGRP Authentication chain key 2 Cisco EIGRP Authentication image

                R1                                                       R2

This example shows that even though both routers agree on key 2 and the key-string value for key 2, authentication does not function correctly and the neighbor relationship is not stable.

Let’s try another one.  Here are the configs:

                   R1                                               R2

Once again the neighbor relationship fails to form, even though the string value of key 2 on R2 matches the string value of key 1 on R1.

Let’s look at one more example.  Here are the configs:

                    R1                                               R2

In this case we have matching key-string values but different key numbers.  Once again, the neighbor relationship fails to form.

The lesson we learn here is that when configuring authentication for EIGRP, make sure both the key id value and the associated key-string values match to ensure the formation of EIGRP neighbors.

If you have found a way to have mis-matched key values and still form neighbors, I would love to hear about it.

Happy authenticating!

Mark Jacob
Cisco Instructor – Interface Technical Training
Phoenix, AZ

Posted in Cisco | Posted in , , , , , , , | Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">