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.
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
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:
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.
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.