Can I avoid convergence during auth. EIGRP key rollover?

[Rob]

Hello,

I've configured several routers for authenticated EIGRP using a key chain. I've configured each key for ~6 months of validity:

R1# show key chain Key-chain EIGRP-Key-Chain:

Key 1 -- text "key1"   accept lifetime (00:00:00 EDT Oct 1 2013) - (23:59:59 EDT Mar 31 2014) [valid now]

   send lifetime (12:00:00 EDT Oct 1 2013) - (11:59:59 EDT Mar 31 2014) [valid now]

key 2 -- text "key2"   accept lifetime (00:00:00 EDT Mar 31 2014) - (23:59:59 EDT Oct 1 2014)

   send lifetime (12:00:00 EDT Mar 312014) - (11:59:59 EDT Oct 1 2014)

This configuration should provide accept overlap between key 1 and key 2 during the entire 24 hours of 31 March 2014. The send key rollover should happen at noon on 31 Mar 2014 (giving the router 12 hours of cushion for time variance).

Unfortunately, during the rollover (forced by manually setting the router's clock ahead), I experience EIGRP convergence. This is unexpected because the router should accept both key 1 and key 2. Am I missing something? Is there any way to avoid convergence?

Thanks,

Rob

[Jan Hrnko · Accepted solution]

Hi Rob,

You don't happen to have some logs/debugs from that event, do you? It would be immense help, I suppose, to see what really happened.

 This configuration should provide accept overlap between key 1 and key 2 during the entire 24 hours of 31 March 2014. The send key rollover should happen at noon on 31 Mar 2014 (giving the router 12 hours of cushion for time variance).

Well, not really. There is one extreme case that I found in your configuration in which  the EIGRP would re-establish its neighborship, so please, bear with me.

key 1  send lifetime until 11:59:59 EDT Mar 31 2014

key 2 send lifetime from 12:00:00 EDT Mar 31 2014

If any router would have to send HELLO packet between 11:59:59 and 12:00:00, there would be NO VALID KEY in that time. Maybe it is not your case and maybe it is kind of extreme, but it could happen. I wasn't really sure about this so I labbed it.

R1 and R2 are interconnected through Serial1/0, IPs 10.0.0.1 and 10.0.0.2 respectively. Don't mind the time, they are out of sync but it really doesn't matter.

R1's perspctive

Mar 31 11:59:59.863: EIGRP: interface Serial1/0, No live authentication keys
Mar 31 11:59:59.867: EIGRP: Sending HELLO on Serial1/0
Mar 31 11:59:59.867:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Mar 31 11:59:59.891: EIGRP: received packet with MD5 authentication, key id = 2
Mar 31 11:59:59.891: EIGRP: Received HELLO on Serial1/0 nbr 10.0.0.2
Mar 31 11:59:59.891:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 31 11:59:59.891:        Inteface goodbye received
Mar 31 11:59:59.891: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.2 (Serial1/0) is down: Interface Goodbye received

R2's perspective

Mar 31 12:10:47.619: EIGRP: received packet with MD5 authentication, key id = 1
Mar 31 12:10:47.623: EIGRP: Received HELLO on Serial1/0 nbr 10.0.0.1
Mar 31 12:10:47.627:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Mar 31 12:10:47.931: EIGRP: Sending HELLO on Serial1/0
Mar 31 12:10:47.935:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Mar 31 12:10:52.067: EIGRP: Dropping peer, invalid authentication
Mar 31 12:10:52.071: EIGRP: Sending HELLO on Serial1/0
Mar 31 12:10:52.075:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Mar 31 12:10:52.083: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.1 (Serial1/0) is down: Auth failure

So if R1 (or any other router) would hit the 1 second interval, it would sent out HELLO packet with no authentication at all which results in dropping the neighborship.

Maybe that is what happened, maybe not. Just an idea.

Btw. if you want to make sure that rollover will pass correctly you should rewrite your key statements to something like this:

key1

accept-lifetime 00:00:00 Oct 1 2013 23:59:59 Mar 31 2014

send-lifetime 12:00:00 Oct 1 2013 12:00:05 Mar 31 2014

key 2

accept-lifetime 00:00:00 Mar 31 2014 23:59:59 Oct 1 2014

send-lifetime 12:00:00 Mar 31 2014 11:59:55 Oct 1 2014

The thing is, as we already know by this point, the send-lifetime of the changing keys need to overlap a little so there wouldn't be a time period without a valid key.

Best regards,

Jan

[Rob]

Hello Jan,

I updated my send-lifetime keys to have a 10 second overlap:

send-lifetime 11:59:55 Oct 1 2013 12:00:05 Mar 31 2014

send-lifetime 11:59:55 Mar 31 2014 12:00:05 Oct 1 2014

During testing, my network no longer converged. It seems that the 1 second of gap was causing the issue. Thanks for the great catch!

Here's my test scenario, in case anyone else stumbles across this post looking for the same or similar info:

Test Setup

• conf t
  
• logg mon debug
  
• end
  
• term mon
  

Test #1

Update clocks with "clock set 23:58:00 30 mar 2014"

Verify all router clocks with "show clock"

Verify valid keys with "show key chain"

Watch routers for convergence messages during rollover

Test #2

Update clocks with "clock set 11:58:00 31 mar 2014"

Verify all router clocks with "show clock"

Verify valid keys with "show key chain"

Watch routers for convergence messages during rollover

Test #3

Update clocks with "clock set 23:58:00 31 mar 2014"

Verify all router clocks with "show clock"

Verify valid keys with "show key chain"

Watch routers for convergence messages during rollover

Thanks again for your help,

Rob

[Jan Hrnko]

Hi Rob,

Glad I could help .

Best regards,

Jan