EIGRP Authentication
Written by jlgaddis on July 4, 2009 – 2:03 pm -Here’s another quick little lab, using the same topology as last time:

Two routers, R1 and R2, directly connected via their serial 0/0 interfaces. In the previous lab, we were using RIP. This time we’ll use EIGRP and authenticate our routing updates.
Basic configuration
Just like last time, let’s bring up a loopback interface, our serial 0/0 interfaces and verify connectivity:
R1# configure terminal R1(config)# interface loopback 0 R1(config-if)# ip address 1.1.1.1 255.255.255.255 R1(config-if)# interface serial 0/0 R1(config-if)# ip address 172.16.12.1 255.255.255.252 R1(config-if)# no shutdown R1(config-if)# end
R2# configure terminal R2(config)# interface loopback 0 R2(config-if)# ip address 2.2.2.2 255.255.255.255 R2(config-if)# interface serial 0/0 R2(config-if)# ip address 172.16.12.2 255.255.255.252 R2(config-if)# no shutdown R2(config-if)# end
R1# ping 172.16.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/36 ms R1#
Configure EIGRP
Now that we have connectivity, let’s get EIGRP up and running on R1 and R2 (without authentication, at first). We just want to make sure they’re exchanging EIGRP routing updates at this point.
R1# configure terminal R1(config)# router eigrp 42 R1(config-router)# no auto-summary R1(config-router)# network 172.16.12.1 0.0.0.0 R1(config-router)# network 1.1.1.1 0.0.0.0 R1(config-router)# end
R2# configure terminal R2(config)# router eigrp 42 R2(config-router)# no auto-summary R2(config-router)# network 2.2.2.2 0.0.0.0 R2(config-router)# network 172.16.12.2 0.0.0.0 R2(config-router)# end
Very quickly (EIGRP is *FAST*), we should see an adjacency come up (ignore the timestamps, they’re obviously not correct!):
On R1:
*Mar 1 00:13:12.243: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is up: new adjacency
On R2:
*Mar 1 00:12:47.935: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.1 (Serial0/0) is up: new adjacency
Verify EIGRP
On R1:
R1# sh ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/2297856] via 172.16.12.2, 00:01:26, Serial0/0
On R2:
R2# sh ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2297856] via 172.16.12.1, 00:02:00, Serial0/0
We can see that the loopbacks are being advertised by both routers. If we want, we can ping R2’s loopback from R1’s loopback just for good measure:
R1# ping 2.2.2.2 source 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms
Configure EIGRP authentication
Now that we have full reachability and “basic” EIGRP working, it’s time to configure MD5 authentication.
Just like RIP authentication, we need to create a key chain, key identifier, and key string that will be used for authentication. We’ll use the same values as last time, except that we’ll call our key chain “EIGRP” instead of “RIP”:
R1# configure terminal R1(config)# key chain EIGRP R1(config-keychain)# key 1 R1(config-keychain-key)# key-string RGjtl5ANYa R1(config-keychain-key)# end
R2# configure terminal R2(config)# key chain EIGRP R2(config-keychain)# key 1 R2(config-keychain-key)# key-string RGjtl5ANYa R2(config-keychain-key)# end
We have two steps left to complete on each router: we have to specify the keychain that we want to use for authentication, then we enabled EIGRP authentication. Both of these are done in interface configuration mode under (in our case) the serial 0/0 interfaces. Let’s configure R1 first:
R1# configure terminal R1(config)# interface serial 0/0 R1(config-if)# ip authentication key-chain eigrp 42 EIGRP R1(config-if)# *Mar 1 00:21:51.919: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is down: keychain changed *Mar 1 00:21:52.567: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is up: new adjacency R1(config-if)# ip authentication mode eigrp 42 md5 R1(config-if)# end R1# *Mar 1 00:22:06.083: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is down: authentication mode changed
Note that our adjancency bounced right after we configured the key chain. Then, after actually enabling MD5 authentication, we see in the last log message that the adjacency went down. This is because R1 is now using MD5 authentication, but R2 has not yet been configured to do the same. Let’s run a “debug eigrp packets” and see what’s going on over there:
R2# debug eigrp packets R2# *Mar 1 00:24:18.751: EIGRP: Sending HELLO on Serial0/0 *Mar 1 00:24:18.755: AS 42, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 *Mar 1 00:24:19.087: EIGRP: Serial0/0: ignored packet from 172.16.12.1, opcode = 5 (authentication off or key-chain missing) R2# undebug all All possible debugging has been turned off
Now let’s enable authentication on R2’s side and we should see the adjacency come right back up:
R2# configure terminal R2(config)# interface serial 0/0 R2(config-if)# ip authentication key-chain eigrp 42 EIGRP R2(config-if)# ip authentication mode eigrp 42 md5 R2(config-if)# end R2# *Mar 1 00:26:23.495: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.1 (Serial0/0) is up: new adjacency
Verifying EIGRP authentication
We can verify that authentication is being used using “debug eigrp packets” again:
R2# debug eigrp packets R2# *Mar 1 00:28:32.711: EIGRP: received packet with MD5 authentication, key id = 1 *Mar 1 00:28:32.711: EIGRP: Received HELLO on Serial0/0 nbr 172.16.12.1 *Mar 1 00:28:32.711: AS 42, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 R2# undebug all All possible debugging has been turned off
Looks good, let’s verify we still have full reachability:
R1# ping 2.2.2.2 source 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
Tags: ccna, cisco, eigrp, labs, networking | 3 Comments »




July 6th, 2009 at 8:25 am
pay attention to one interesting thing: if R1 receives hello packet with invalid authentication from address of R2, it immediately drops adjacency (not just ignore incorrect packet). from my point of view, it is security vulnerability
July 6th, 2009 at 11:00 pm
Hmm, is it really a security vulnerability, invalidCCIE? I’m inclined to think that it’s not since, at that point, R1 is only expecting authenticated updates. If an update comes in that isn’t authenticated, I think it’s probably doing the right thing. I’d love to hear more on why you think it is a vulnerability, though.
July 7th, 2009 at 4:32 pm
Could an attacker spoof the address of another router in order to kill a competitor’s adjacency? A flood of such crafted packets could be an effective DoS.