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 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".
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.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...