ospf md5 authentication with multiple keys

been mucking with this one for an hour - I couldn't figure out how to keep the Key 2 from sending to the R1/2 and basically not setting up ospf

the suggestion is to put all keys on all 5 routers and then remove key two or one from the two that don't need it - the youngest keys should keep going

that worked - UNTIL I cleared the ospf process on Router 5 - then tu0 wouldn't come back up on R1/2

I came up with a workaround hack - (but it fills my console with expried key messages) - I use a key-chain authentication with md5 crypto algorithm so as to meet the requirements - on R5 I set send and accept lifetimes to full - and on R1/R2 I have to set up both keys - but I set the send / accept lifetimes for key 2 to basically, two seconds in 1999 and the key 1 accept and send are infinite

any attempt to remove both keys from R1 or R2 and a proc reset has them trying to install key 2 and failing - this was the only way I could survive an ospf process reset -

anyone else think the task as it stands doesn't exactly provide reliability?



  • Hey Whiskeytown,

    I had the same problem you're having and I figured out the solution which wasn't mentioned in the workbook solution. You'll recall that the DMVPN tunnel interfaces are running in ospf point-to-multipoint non-broadcast mode which means that without a neighbor statement, peering will not occur. Neighbor statements are only required on one of the peers for a neighbor relationship to occur so it makes sense for the hub to have the neighbor configs pointing towards the spokes which is what we have here.

    However, this comes back to bite us in this task. In ospf multiple keys authentication, the router will only send it's youngest key during the peering process and depending on how you configured the keys, one can only only be sent. In my case i configure key one first and then key 2 which meant key 2 was the youngest and thus sent. This means that only spokes 3 and 4 were able to establish peerings with the hub. Spokes 1 and 2 with key 1 will always give an error because key IDs must match. debug output:

    *Oct 24 19:19:08.663: OSPF-1 ADJ   Tu0: Send with youngest Key 1

    *Oct 24 19:19:08.687: OSPF-1 ADJ   Tu0: Rcv pkt from : Mismatched Authentication Key - No message digest key 2 on interface

    Because only R5, the hub, had the neighbor statement, it always initiated the peering process and would send key 2, it's youngest key towards the spoke and once the spoke see the key, it would check its interface for a key matching the ID. If there was none, the peering is dropped. in order to solve this, the spokes also have to initiate peering so the hub can check its own interface for the spokes youngest key ID which it definitely has. So all you need to do is configure a neighbor statement on the spokes 1 and 2 and they should initiate peering to the hub with key ID 1 and should form a neighbor relationship.

    Spokes 3 and 4 don't require it cos the hubs youngest key matches what they already have configured.



Sign In or Register to comment.