I ran across an issue when trying to use different MD5 cryptographic keys on the same interface for multiple neighbors. I originally thought that it was an bug with GNS3/IOU or the IOS version, but after running through multiple versions and even firing up VIRL it acted the same so I had to dig a bit deeper. I’m really glad that I did, because I uncovered a gap in my knowledge.
The topology is simple, 3 routers connected on a single VLAN. iosv-1 is acting as the “hub” with iosv-2 and iosv-3 as the spokes, not forming direct OSPF neighbor relationships.
The idea was to have OSPF MD5 authentication enabled, but with iosv-1 and iosv-3 using key-string 1STKEY and iosv-1 and iosv-2 using key-string 2NDKEY.
router iosv-1 interface GigabitEthernet0/1 description to iosvl2-1 ip address 10.0.0.1 255.255.0.0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 1STKEY ip ospf message-digest-key 2 md5 2NDKEY router ospf 1 network 10.0.0.0 0.0.255.255 area 0 neighbor 10.0.0.3 neighbor 10.0.0.2 router iosv-2 interface GigabitEthernet0/1 description to iosvl2-1 ip address 10.0.0.2 255.255.0.0 ip ospf authentication message-digest ip ospf message-digest-key 2 md5 2NDKEY router ospf 1 network 10.0.0.0 0.0.255.255 area 0 router iosv-3 interface GigabitEthernet0/1 description to iosvl2-1 ip address 10.0.0.3 255.255.0.0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 1STKEY router ospf 1 network 10.0.0.0 0.0.255.255 area 0
But it would never form stable OSPF neighbor relationships with both routers. Looking at the output, it would form with iosv-2 but not iosv-3.
iosv-1#sh ip ospf neighbor 192.168.0.2 0 FULL/ - 00:01:42 10.0.0.2 GigabitEthernet0/1 iosv-1#show ip ospf interface g0/1 .... Cryptographic authentication enabled Youngest key id is 2 iosv-1#debug ip ospf adj iosv-1#debug ip ospf packet iosv-1# *May 24 15:03:19.371: OSPF-1 ADJ Gi0/1: Send with youngest Key 2 *May 24 15:03:48.409: OSPF-1 ADJ Gi0/1: Send with youngest Key 2 *May 24 15:06:40.336: OSPF-1 PAK : Gi0/1: OUT: 10.0.0.1;10.0.0.3: ver:2 type:1 len:48 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:2 seq:0x5561 *May 24 15:06:40.337: OSPF-1 PAK : Gi0/1: OUT: 10.0.0.1;10.0.0.2: ver:2 type:1 len:48 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:2 seq:0x5561 iosv-3# *May 24 15:07:50.676: OSPF-1 ADJ Gi0/1: Send with youngest Key 1 *May 24 15:08:11.110: OSPF-1 PAK : Gi0/1: IN: 10.0.0.1;10.0.0.3: ver:2 type:1 len:48 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:2 seq:0x5561 *May 24 15:08:11.111: OSPF-1 ADJ Gi0/1: Rcv pkt from 10.0.0.1 : Mismatched Authentication Key - Invalid cryptographic authentication Key ID 2 on interface *May 24 15:08:18.060: OSPF-1 ADJ Gi0/1: Send with youngest Key 1
iosv-3 is showing an error, saying that the MD5 key is mismatched. The authentication configuration looks correct and iosv-1 should accept md5 authentications using both keys. So let’s look into MD5 authentication a little deeper. This comes from ospf configuration guide
The system assumes its neighbors do not have the new key yet, so it begins a rollover process. It sends multiple copies of the same packet, each authenticated by different keys. The system sends out two copies of the same packet–the first one authenticated by key 1 and the second one authenticated by key 2…The system detects that a neighbor has the new key when it receives packets from the neighbor authenticated by the new key.
What it doesn’t specify is that when there are two keys on an interface, it will only use the youngest or last configured key when sending OSPF packets. The rollover process kicks in, only when the router receives an OSPF packet with the older key. When that happens the router will send duplicate OSPF packets with each of the MD5 keys.
So why isn’t iosv-3 sending OSPF packets with the MD5 key 1? If we look back at the configuration, iosv-1 has a neighbor statement configured but iosv-3 doesn’t.
By default a router will only send hellos with the last key configured, until it hears incoming hellos using older keys. If an incoming hello packet has a matching configured key, it will start sending hellos using this key as well.
The problem with our configuration is that when OSPF is configured as non-broadcast and only iosv-1 is sending OSPF hello packets as unicast to the configured neighbors iosv-2 and iosv-3. The routers iosv-2 and iosv-3 don’t have OSPF neighbor statements configured, so they never originate an OSPF hello with the configured older MD5 key.
If we configure neighbor statements for iosv-1 on iosv-2 iosv-3 the neighbors come up and if we look at iosv-1 you can see that it now sends duplicate OSPF packets using both MD5 keys (keyid:1 and keyid:2) out to both neighbors.
*May 24 15:22:50.224: OSPF-1 PAK : Gi0/1: OUT: 10.0.0.1;10.0.0.3: ver:2 type:1 len:52 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:1 seq:0x5561 *May 24 15:22:50.225: OSPF-1 PAK : Gi0/1: OUT: 10.0.0.1;10.0.0.2: ver:2 type:1 len:52 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:1 seq:0x5561 *May 24 15:22:50.226: OSPF-1 PAK : Gi0/1: OUT: 10.0.0.1;10.0.0.3: ver:2 type:1 len:52 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:2 seq:0x5561 *May 24 15:22:50.227: OSPF-1 PAK : Gi0/1: OUT: 10.0.0.1;10.0.0.2: ver:2 type:1 len:52 rid:192.168.0.1 area:0.0.0.0 chksum:0 auth:2 keyid:2 seq:0x5561
Looking at iosv-1 OSFP interface details for g0/1, you can see that it thinks that a key rollover is in progress which lets you use multiple keys for different neighbors.
iosv-1#sh ip ospf int g0/1
Cryptographic authentication enabled
Youngest key id is 2
Rollover in progress, 1 neighbor(s) using the old key(s):
key id 1 algorithm MD5
It’s amazing how a lack of basic understanding of a protocol can trip you up with trivial tasks.
Network Thoughts 