Solved: EIGRP authentication-changing keys/time

NormMuelleman · ‎02-13-2012

Hello all!

2nd issue of the day. My network has approximately 241 switches. Take into account some of these are stacked...and I'd say we have about 150 devices that are seen on the network.

We run the typical A-D-C topology. Access layered switches connect to the Distro switch. Each distro switch routes to the core. Multiple VLANs everywhere..I think it was over-engineered and it makes for a jumbled mess sometimes.

So, the routing is done by EIGRP. The network uses EIGRP authentication. I didn't know about this..and just started reading up on this, as it's not discussed in CCNA or CCNA security. I "think" it's discussed in CCNP Route..but I started with CCNP Switch

So, I understand that you create a "key chain", which you call, say, TEST. Within TEST, you make 1, or several, keys. You can specify how long each key is good for.

Our keys are about to expire. When they expire, I'm guessing routing will come crashing to a halt. So, I need to figure a way to renew the keys.

We use Solar Winds to monitor the network. We also have Kiwi Cattools to use for config upgrades, backups, etc. I think Solar Winds can do that as well. Heck, I'm just getting a handle on Kiwi Cattools.

What I'm looking for is a plan of action to renew these keys. Is there a particular set of commands to push out? Also, Kiwi just goes down it's list of devices to configure. I'm thinking that I should work farthest from the core, and work inward, otherwise I'll lose the ability to communicate, and then we'll be stuck.

I think we have 2 keys...1 has a date, and 1 is set to infinite. If I understand the process..if Key 1 doesnt work, it will try Key 2. If key 2 works..then it will keep working. So why even have the first key set to a specific date, if the 2nd one is set to infinite?

Thanks..I feel a migraine coming on with this one

Eugene Khabarov · ‎02-13-2012

Hi once again. I think you can just update existing keys to be something like this:

key chain mykeychain

key 1

key-string yourkeypassword

accept-lifetime 04:00:00 Feb 14 2012 infinite

send-lifetime 04:00:00 Feb 14 2012 infinite

To do this you should synchronize time onn all devices and then push to the each device firs part of the config on the first step:

key chain mykeychain

key 1

accept-lifetime 04:00:00 Feb 14 2012 infinite

And than update your expire lifetime in the second step:

key chain mykeychain

key 1

send-lifetime 04:00:00 Feb 14 2012 infinite

HTH. Please rate if it was helpful. Thank you.

View solution in original post

Eugene Khabarov · ‎02-13-2012

Hi once again. I think you can just update existing keys to be something like this:

key chain mykeychain

key 1

key-string yourkeypassword

accept-lifetime 04:00:00 Feb 14 2012 infinite

send-lifetime 04:00:00 Feb 14 2012 infinite

To do this you should synchronize time onn all devices and then push to the each device firs part of the config on the first step:

key chain mykeychain

key 1

accept-lifetime 04:00:00 Feb 14 2012 infinite

And than update your expire lifetime in the second step:

key chain mykeychain

key 1

send-lifetime 04:00:00 Feb 14 2012 infinite

HTH. Please rate if it was helpful. Thank you.

NormMuelleman · ‎02-13-2012

Hi Eugene;

Thanks for the reply. I rated it correct. But I have some follow-up...

So, with the config already in place, would I have to do a "no key chain..." to remove it first, then RE-ADD it?

And then should I use Kiwi to push out the first portion of the Accept-Lifetime FIRST to all my devices, then repush the SECOND portion? I just don't want to start pushing then get "cut off" when routing goes WHACK and dies. But if I understand the process, the accept portion will say "hey, I'll accept any key 1 from this time on..."...so it will still accept old key 1...but then when you push it the send-lifetime, it says "ok, start pushing this key from here on out".

Make sense?

Also, we have time configured on our network...we actually had a problem with EIGRP authentication..the far end device lost power. When it came back up, it had reverted to default time/date of March 1, 1993. Well, that wasn't what the core had for time and for authentication...and we lost that whole portion of the network until we got hands on locally with that device and reset the time. I just foresee this being a problem I want to avoid.

Eugene Khabarov · ‎02-13-2012

Yes, your understood me right. First portion to all devices, than second portion - to all devices again. But this is ok only if key will not be updated.

If you would like to change your key value it will be whole another story. What do you prefer?

To make data/time consistent around your network you need to configure ntp server client on all of your devices:

ntp server

It can be external server that you trust, but don't remember to allow access to this ip (maybe nat will be needed). Or you can configure ntp on your central device:

int

ntp broadcast

ntp master

HTH. Please rate if it was helpful. Thank you.

NormMuelleman · ‎02-18-2012

Sorry, got busy and am just getting around to this reply..

So, lay out the procedure to change the key and everything..'cause I think that's what we are going to be doing..and I've got about 10 days before it needs to be done

Oh, we have NTP latest version up and running..everything is time-coordinated

That was easy part