CCIE Study: Key chain rotation with EIGRP named mode

Key chain rotation with EIGRP named mode

Here is a simply topology as per the CCIE RS material provided by INE. The DMVPN network is used a lot within the many examples and demonstrations to learn technologies due to the hub-spoke nature of the topology. This allows learners to understand the nuances of routing protocols and technologies on different network topologies.

Topologies


dmvpn

The above shows the connectivity via the topology diagram. Below shows how I have recreated it in Cisco VIRL.

Screenshot 2014-07-21 07.29.26

 

Configuration

The configuration for the routers are below. Simple EIGRP configuration with a rotating key that will allow the update of KEY_ROTATION’s key chain on New Years Day 2030. This will occur due to Key 10 being sent for five minutes past midnight, accepted up to fifteen minutes afterward all while Key 20 being accepted and sent since midnight.

R1-4 Configuration

ntp server 155.1.0.5
router eigrp 100
network 155.1.0.0 0.0.0.255
key chain KEY_ROTATION
key 10
key-string CISCO10
accept-l 00:00:00 Jan 1 1993 00:15:00 Jan 1 2030
send-l 00:00:00 Jan 1 1993 00:05:00 Jan 1 2030
key 20
key-string CISCO20
accept-l 00:00:00 Jan 1 2030 inf
send-l 00:00:00 Jan 1 2030 inf
int tun 0
ip authe mode eigrp 100 md5
ip authe key-chain eigrp 100 KEY_ROTATION

R5 uses the EIGRP named-mode for configuration. Whilst it is still the same implementation of EIGRP under the hood the configuration is optimised for modern networks and there are some new features. New features like SHA authentication is great.

R5 Configuration

int tun0
no ip split
key chain KEY_ROTATION
key 10
key-string CISCO10
accept-l 00:00:00 Jan 1 1993 00:15:00 Jan 1 2030
send-l 00:00:00 Jan 1 1993 00:05:00 Jan 1 2030
key 20
key-string CISCO20
accept-l 00:00:00 Jan 1 2030 inf
send-l 00:00:00 Jan 1 2030 inf

ntp master 1
router eigrp MULTI-AF
address-family ipv4 unicast auto 100
network 155.1.0.0 0.0.0.255
af-int tun0
auth mode md5
auth key-chain KEY_ROTATION

Validation

It is clear that the key KEY_ROTATION is the same for all routers. It has the same two strings and the same send and accept lifetime. The only difference is that under an address-family interface on R5 the key mode and chain is applied.

R1#sh clock
00:04:15.440 UTC Tue Jan 1 2030

So it is four minutes past midnight. What we should expect to see is Key 10 being valid on both send and accept times. So lets validate that the key chain is being used.

R1#sh key chain
Key-chain KEY_ROTATION:
key 10 -- text "CISCO10"
accept lifetime (00:00:00 UTC Jan 1 1993) - (00:15:00 UTC Jan 1 2030) [valid now]
send lifetime (00:00:00 UTC Jan 1 1993) - (00:05:00 UTC Jan 1 2030) [valid now]
key 20 -- text "CISCO20"
accept lifetime (00:00:00 UTC Jan 1 2030) - (infinite) [valid now]
send lifetime (00:00:00 UTC Jan 1 2030) - (infinite) [valid now]

Time to check the EIGRP hello packets to verify which key is being sent.

R1#debug eigrp packet hello
(HELLO)
EIGRP Packet debugging is on
R1#
Jan 1 00:04:41.255: EIGRP: received packet with MD5 authentication, key id = 10
Jan 1 00:04:41.255: EIGRP: Received HELLO on Tu0 - paklen 60 nbr 155.1.0.5
Jan 1 00:04:41.256: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Jan 1 00:04:43.982: EIGRP: Sending HELLO on Tu0 - paklen 60
Jan 1 00:04:43.982: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0un d
Jan 1 00:04:45.984: EIGRP: received packet with MD5 authentication, key id = 10
Jan 1 00:04:45.984: EIGRP: Received HELLO on Tu0 - paklen 60 nbr 155.1.0.5
Jan 1 00:04:45.984: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Jan 1 00:04:48.856: EIGRP: Sending HELLO on Tu0 - paklen 60
Jan 1 00:04:48.856: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
R1#unde all
All possible debugging has been turned off

Note the Hello packets being received here that denote MD5 authentication and key id = 10. This is a good sign. We can also see that this is being received on the interface Tu0 from peer 155.1.0.5. This is our head end router, R5.

Check the time again.

R1#sh clock
00:05:18.406 UTC Tue Jan 1 2030
R1#sh key chain 
Key-chain KEY_ROTATION:
key 10 -- text "CISCO10"
accept lifetime (00:00:00 UTC Jan 1 1993) - (00:15:00 UTC Jan 1 2030) [valid now]
send lifetime (00:00:00 UTC Jan 1 1993) - (00:05:00 UTC Jan 1 2030)
key 20 -- text "CISCO20"
accept lifetime (00:00:00 UTC Jan 1 2030) - (infinite) [valid now]
send lifetime (00:00:00 UTC Jan 1 2030) - (infinite) [valid now]

Now that the send lifetime of key 10 has finished key 20 will now be sending. The send lifetime of Key 10 is no longer valid. That should mean we either have had a successful change over or our neighbors have gone down. Issue a debug of the hello packet again.

R1#debug eigrp packet hello
(HELLO)
EIGRP Packet debugging is on
R1#unde
Jan 1 00:05:52.085: EIGRP: received packet with MD5 authentication, key id = 20
Jan 1 00:05:52.085: EIGRP: Received HELLO on Tu0 - paklen 60 nbr 155.1.0.5
Jan 1 00:05:52.085: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Jan 1 00:05:52.349: EIGRP: Sending HELLO on Tu0 - paklen 60
Jan 1 00:05:52.349: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 all
All possible debugging has been turned off
R1#
Jan 1 00:05:56.865: EIGRP: received packet with MD5 authentication, key id = 20
Jan 1 00:05:56.865: EIGRP: Received HELLO on Tu0 - paklen 60 nbr 155.1.0.5
Jan 1 00:05:56.865: AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Very quickly we can see that the peer between R5 and R1 has stepped keys to now accept key id 20. This means that we have successfully rotated keys.

Next, validate that the neighbors of R5 have not gone down issue a show eigrp address-family ipv4 100 neighbors command.

R5#sh eigrp address-family ipv4 100 nei
EIGRP-IPv4 VR(MULTI-AF) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
3   155.1.0.4               Tu0                      14 09:00:53   32  1398  0  4
2   155.1.0.3               Tu0                      14 09:00:57    8  1398  0  4
1   155.1.0.2               Tu0                      13 09:01:00    5  1362  0  4
0   155.1.0.1               Tu0                      13 09:01:18    7  2097  0  4

 It is important to note that you require the send lifetime value set to sent a key otherwise a peer relationship will experience retry failures due to the router not sending an authenticated hello.

Note the output. It indicate the four neighbors of R5 have been up for over 9 hours. The key has changed from key10 to key 20 without the flapping of neighbors.

2 thoughts on “CCIE Study: Key chain rotation with EIGRP named mode”

  1. Wher did you get the Cisco VIRL from? I’m trying desperately to obtain a copy, are you able to assist with this?

Leave a Reply

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


*