07-07-2011 01:00 PM - edited 03-04-2019 12:54 PM
When I entered the command the response was like "New value will take effect upon reboot."
Can I reboot the standby Supervisor and then fail over without the switch module interfaces all resetting?
Single Chassis, Dual Sup720, MSFC3, PFC3, IOS Version 12.2(33)SXH4.
Thanks,
Scott
07-07-2011 02:27 PM
Yes, you can just reboot the stand-by sup. This is how you do image upgrade when you have 2 sups and don't want to bring the system down. You have to be in SSO mode. "sh redu" will show you that.
hw-module module x reset
HTH
Reza
07-20-2011 12:18 PM
Thank you for your response. This is very close to what I was looking for. In fact it may lead me to the answer.
My issue is that I need to do a Lot more preparation for a failover where the switchport modules get reset than I do for one where they don't. According to the doc that you referenced:
"Note:
In middle of the software upgrade procedure, the operational redundancy mode is RPR. This is evident from the
show redundancy states command output shown in step 12. In RPR redundancy, during switchover, all switching modules are powered on again. So there is be a few minutes of downtime. During normal switchovers, if the operational redundancy is SSO, the installed switching modules are not reloaded, as both the startup and running config are synchronized continually from active to standby supervisor engine. The new active supervisor engine uses the current configuration."
So, I know that when I change my IOS the switch will reset all of the switchport modules. In my current situation all I have done is to change the mls cef maximum-routes value.
I guess what I'll have to do is to look at show module and show redundancy after rebooting the standby supervisor. If the new value taking effect upon reboot causes it to drop into RPR mode then I am stuck with that. If it stays in SSO then I get to do an easy failover.
-Scott
08-11-2011 10:56 AM
In case anyone is interested - I did a reload of the standby Supervisor and redundancy remained sso. I then failed over (which worked well), and did a reload of the "new" standby Supervisor. When this was complete the sh mls cef maximum-routes value HAD NOT CHANGED.
The instructions that I just got from TAC are "Physically pull the standby Supervisor, reboot the remaining Supervisor, physically pull the remaining Supervisor (I don't know what the switch does now), re-insert the original standby Supervisor, after it boots up check to see if table has new value - otherwise reboot this Supervisor, re-insert the original active Supervisor, double-check that the table is now the right size.
This is not cool. I'm stuck between not being able to get such a large maintenance window and running with "
Current IPv4 FIB exception state = TRUE" and worrying about a crash. (Note: Switch hasn't crashed due to table exception since I upgraded to 1G of RAM but this is still not a good condition).
I'm now planning to combine this table expansion with an IOS upgrade so as to take full advantage of the required mega-reboot. I hope that doesn't overly confuse the Supervisors.
-Scott
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide