@Leo Laohoo
I like the idea, but I tried it tonight and it didn't work for me. I see what you are trying to do though. I think I know why it didn't work.
You looked for "SYS-5-RESTART".
When I rebooted, I had this in the logs:
Nov 7 22:00:16 my-sw 2719: Nov 7 22:00:15: %RF-5-RF_RELOAD: Shelf reload. Reason: Reload Shelf CLI
Nov 7 22:00:16 my-sw 2720: Nov 7 22:00:16: %SYS-5-RELOAD: Reload requested by ME on vty0 (10.6.25.3). Reload Reason: Reload Shelf CLI.
But those entries were just as it was about to reload, not when it came back up.
Of course, remote syslog didn't catch anything from when it reloaded, until it was back booted and routing re-converged.
After it booted up, I did have these messages that made it to the syslog:
Nov 7 22:10:53 my-sw 342: Nov 7 22:10:52: %SSH-3-BAD_PACK_LEN: Bad packet length -288614957
Nov 7 22:10:56 my-sw 343: Nov 7 22:10:55: %SSH-3-BAD_PACK_LEN: Bad packet length -1695192534
Nov 7 22:11:08 my-sw 344: Nov 7 22:11:07: %SYS-5-CONFIG_I: Configured from console by OTHERME on console
Nov 7 22:11:15 my-sw 345: Nov 7 22:11:14: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: ME] [Source: 10.6.250.3] [localport: 22] at 22:11:14 CST Tue Nov 7 2023
Nov 7 22:11:24 my-sw 346: Nov 7 22:11:23: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor
Nov 7 22:11:24 my-sw 347: Nov 7 22:11:23: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized to the standby supervisor
Nov 7 22:12:50 my-sw 348: Nov 7 22:12:50: %OSPF-5-ADJCHG: Process 1, Nbr 172.17.3.4 on Port-channel12 from LOADING to FULL, Loading Done
So you can see it failed with bad packet length a couple times when I tried to log in, but, then from the console I ran the "ip ssh server algorithm kex ...." command and set those old kex's back, and then I was able to log in.
By the way, in my config is still:
event manager applet KEX_ALGO
event syslog pattern "SYS-5-RESTART"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "ip ssh server algorithm kex diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1"
action 4.0 cli command "end"
!
What I'm thinking is, maybe a better thing to watch the syslog for would be:
SSH-3-BAD_PACK_LEN
Then, if you DO get that error, if I'm understanding the event manager thing well enough, it should automatically change the algorithm(s). Right?
I've never used even manager applets before so that's new to me. When you do "enable" I'm assuming that it doesn't make you authenticate like it would if you consoled in? If that's true, then I think your solution would be great.
What do you think?
PS: My 4500x's are in VSS config with 2 of them. My 4510R+E upgrade using the same rev, went just fine, but that upgrade was a little different in that I did the issu process, and so that just keeps the switch running but fails the control back and forth between the redundant supervisors. So it apparently doesn't matter?
Wait, one more theory on why it didn't matter in my case:
My original config on that particular switch only had one of the 2:
ip ssh server algorithm kex diffie-hellman-group14-sha1
So, here's my theory. When I upgraded the other switch, I had both of the 2 KEX algs. Those were the default config, so, when you did a "show run" they didn't show up in the config. So, it assumed the default when it upgraded. When it upgraded to 03.11.09E, the default is now all 5 algorithms. So then you're locked out because it won't accept the other 2 any longer for whatever reason. But since on my 4510 I had a NON-default config, of only the one algorithm, it stayed in the config that way. And when I rebooted, rather than upgrading to the new 5 algorithms, it kept to just the 1 algorithm. It's a theory anyway. It's either that, or when you just do a redundancy force-switchover type issu upgrade, it doesn't actually modify the running config and you're ok.
Well, thanks for your post and I hope someone gets to try this with the "SSH-3-BAD_PACK_LEN" in the syslog event line and that it works for them. That would be pretty cool. What would be cooler? Probably if Cisco would add stuff to the release notes warning people a little, or maybe come out with 03.11.09aE and NOT add those 3 algorithms as default.
