Search this Blog

Monday, December 2, 2013

Is it possible to avoid convergence during auth. EIGRP key rollover?


We'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.  Please refer to the below image of the Authenticated EIGRP KEY Exchange.



There is one extreme case that is found in your configuration in which  the EIGRP would re-establish its neighbourship

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.

Below  is the test scenario :
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


Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

 
/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */