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:
network 10.1.1.0 0.0.0.255
It is a very simple network and it looks like this:
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.
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 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:
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:
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:
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.