Cisco commands are implemented using a specific hierarchy. When you type the command ip eigrp ?, the resulting commands all have to do with EIGRP and its functionality. They are limited to routing EIGRP and nothing else. However, authentication is a different entity and must be placed within a different category. This is why the commands fall under the ip authentication keywords even though the authentication is being configured for EIGRP. Anything under the ip authentication ? will belong to the authentication functionality of the router.
So by typing ip authentication mode eigrp AS_NUM md5 you are not configuring something specific to EIGRP but something specific to the authentication functionality of the router.
Iām a bit late but I want to add this for the future.
If you use show running-config you wonāt see if you inadvertently typed a space in the password. show key chain on the other hand will show the configured key-string in quotation marks ("MY_Key_String ") so on a misconfiguration you will see "MY_Key_String " for example.
I should add to this that if you want to confirm that your EIGRP authentication is working you can do this by using the command debug eigrp packets
In the debug output, look for the below:
*Sep 26 18:22:09.785: EIGRP: received packet with MD5 authentication, key id = 1
Here is the link to the Cisco docs where i found out about this, as it would be nice to know if it is working rather than configuring it and assuming it is working.
In my topology, the R1 and R2 routers were able to establish neighbor relationship via GRE tunnel. Iāve changed the cryptographic algorithm of R1 to cryptographic-algorithm hmac-sha-256 while R2 is cryptographic-algorithm md5 but the neighbor status is still up. Iāve also tried to do packet capture before and after changing the algorithm and the message digest is still the same. Is there an additional command if you want to change the algorithm? Thank you!
Thatās interesting. I tried reproducing your results, but I found that whenever I changed the cryptographic algorithm on one end of the link, the adjacency went down until the other end was reconfigured appropriately. I didnāt create a GRE tunnel in my case, but I donāt believe that would cause a change in the behaviour. Are you running encryption on the GRE tunnel as well? Are you sure that your authentication configuration on the EIGRP neighbors is correct? Feel free to share your EIGRP configs on both ends so we can take a look tooā¦
Please see that the crypt-algo of each router key chain are different but for some reason, EIGRP neighborship is still up.
R1(config)#do sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(10)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.1.2 Tu1 11 00:07:10 19 1470 0 27
R2(config)#do sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(10)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.1.1 Tu1 11 00:07:39 9 1470 0 17
For EIGRP MD5 authentication, you must configure an authenticating key and a key ID on both the sending router and the receiving router. Each key has its own key ID, which is stored locally. The combination of the key ID and the interface associated with the message uniquely identifies the authentication algorithm and MD5 authentication key in use.
This means that it is the configuration in the ip authentication mode eigrp command that is used to determine the applied algorithm. In your case, this is the same on both ends of the link, so this is why your implementation works.
Although I have not found any documentation explicitly stating this, I believe that when configuring EIGRP authentication, any configuration made using the cryptographic-algorithm command within the key chain configuration mode is ignored. Only the key ID, the key string, and the interface associated with the authentication are used to create the MD5 digest.
Now in order to confirm this, try changing or even eliminating the cryptographic-algorithm command in the key string configuration. You should find that the authentication still functions normally ignoring any configuration with this command.
Does that mean that the algorithm used will depend on the interface authentication configuration? Or will it be chosen by the IOS itself? And what if I want to use the hmac-sha algorithm, does that mean I have to use the named EIGRP?
Iāve looked for the commands on the interface and the only option that can be chosen is MD5.
Yes, it seems that only the algorithm used with the ip authentication mode eigrp command will be used. Any algorithm defined within the key-string configuration mode is ignored. It seems that your test has also confirmed this.
It looks like EIGRP authentication only supports MD5 on that specific platform. According to this Cisco Documentation, IOS XE Release 3S supports hmac-sha-256 encryption as well.
Q- if we enable the EIGRP authentication , it only validates the neighbor or it encrypt the payload also ,
Q- lets say we have enabled the EIGRP authentication, does it mean it will check the source of every eigrp packet and check the authentication password , if it does then how it works ??
EIGRP authentication performs only authentiation. That is, it will validate that the packet received does indeed come from the expected neighbor. If you take a look at some EIGRP packets on Wireshark, of two routers using EIGRP authentication, you will see that the contents are cleartext, but you will see an extra section called āAuthenticationā that contains the various parameters needed.
Every single packet is authenticated using the authentication process described in the lesson. If there is an authentication mismatch, the packets will not be authenticated.
I would like to add a real world scenario question in here:
In situation where you have two data centers, which we will call Data Center A and B, with a layer two circuit between the data centers and over this layer two circuit your running a router on each side that connects via EIGRP.
In addition, you reach the other Data center B from A over EIGRP. if you setup EIGRP authentication on one side you would lose your connection to Data Center B as you have to bring up authentication one side at a time correct?
Is there a work around for this issue other than making sure you have a way into the router from Data Center B from the internet or from Data Center B?
The reason I ask this is many times in real world situations you may have a site to site VPN setup to the customer to access their network. In addition, in the cases such as these where you have sent the customer a Firewall device or connected to only one Data Center configuring something like this could cause you to lose connection from yourself to the clients other Data Center.
Granted it makes more sense to have sent a firewall to both data centers but often this is not done as you normally only have monitoring/administration access setup. Also while there may be a secondary route from one data center to the other its not always active/active sometimes its active/standby.
For EIGRP authentication, as far as I know, there isnāt a way to overcome this momentary loss of connectivity. You need to have either a secondary link to the remote device to make the change almost simultaneously or have a technician there to do the change at the same time as you.
Even if you could do it, itās still not recommended to do so during working hours. Itās always best practice to make any kind of changes during a maintenance window even if no downtime is expected.
Hello network lessons, great content as usual.
It seems on wireshark that the routers exchange an md5 hash, what are we hashing exactly? as I saw that the hash may change from packet to another.
Specifically, the router uses an algorithm based on the routing protocol packet itself, the key, and the key ID to generate the MD5 digest or hash. Now you will find that the digest will be different from packet to packet because the contents of the packet itself are being used to make the hash, and each packet will contain different information, and thus the hash will be different. Using the packet as part of the algorithm ensures the integrity of the packet as well as the correctness of the keys being used.
Hello @ReneMolenaar Thank you for your amazing lessons. I have a question about EIGRP authentication. We donāt use plain text authentication, because anyone who can launch āman-in-the-middle attackā can easily steal password which is travelling through the network as a plain text.
Please correct me, if Iām wrong: Thatās why use MD5 authentication or SHA authentication, which make hash function from password and send it to the another router as hash and another router just compare it with its hash of the same password and if theyāre the same, then everything is ok. But there is something, I donāt understand: Why someone who is the man in the middle, canāt just steal hash function, in the same was as he / she can do with password in plain text? What I mean, someone can just steal hash function, put it in update packets and thatās it. Itās not an encryption, itās just hash function, which must be the same at both ends and malicious user doesnāt need to know actual password, he / she can just use hash function, put it inside update packets and thatās it. Could you please explain this, how hash function really protects communication between routers?
This is an excellent question and Iāll do my best to answer it clearly. The short answer is that even if there were a man-in-the-middle attack, they wouldnāt be able to intercept enough information to learn the password, because the password itself alone is never transmitted. Hereās a detailed look at the process to further understand this. Letās take the example of using SHA-256:
Configuration:
We start by configuring a key-chain that contains one or more keys (with key IDs and key strings). This is essentially your password
Then we enable SHA-256 authentication on the desired EIGRP interface and associate it with the key-chain.
Sending Router Operation:
When the router prepares an EIGRP packet for transmission, it calculates an SHA-256 hash of the entire packet (excluding the hash field) concatenated with the secret key.
The resulting SHA-256 hash is included in the EIGRP packet.
The packet is transmitted.
Receiving Router Operation:
The receiving router extracts the SHA-256 hash from the incoming EIGRP packet.
The router computes its own SHA-256 hash using the packet (excluding the received hash field) concatenated with its own copy of the shared secret key.
The computed hash is compared to the received hash.
If they match, the update is authentic and processed.
If not, the packet is discarded, potentially generating an authentication error.
Letās say there was a malicious man in the middle attacker that intercepts all of this interchange.
The one thing that the attacker is missing in order to be able to ācrackā the communication is the password itself. The password is never transmitted over the link, whether encrypted or plain text,
However, the password is necessary to ādehashā the incoming communication for it to be accepted and processed.
Now there are other situations where a key or password needs to be transmitted and shared over the medium itself. Take a look at this NetworkLessons note on the topic. There are methods such as the Diffie Hellman key exchange that can be used for this purpose. More about this can be found here:
This is a mathematical method of security exchanging cryptographic keys over a public channel. However, this is not the case in the EIGRP Authentication process.