Hi all,
I'm getting ready to upgrade the code on a VSS pair of 6509Es that we have tomorrow night. Each switch has a single Sup 2T. We're currently running 15.2(1)SY5, and are going to go to 15.5(1)SY4 (which appears to be the current starred code version).
This is the first time that I've attempted to update the code on a big chassis switch, or a VSS pair. The good news is all of the devices connected to these switches are dual-homed, so we should be able to lose one member of the pair without disrupting traffic (in theory at least).
I've researched the process, but still have a bit of confusion. The documentation that I've found on the process basically says to just copy the images to both switches (done), set the boot variable, then issue a "redundancy reload peer". This should reload the standby chassis, but it then says that it'll come up in RPR mode, as the versions will be different.
Quoth the docs:
"During the FSU procedure, a software version mismatch between the active and the standby chassis causes the system to boot in RPR redundancy mode, which is stateless and causes a hard reset of the all modules. As a result, the FSU procedure requires system downtime corresponding to the RPR switchover time. "
This has me concerned that when we do the next step, the "redundancy force-switchover", we're going to have a downtime on the order of minutes instead of seconds. I was thinking that this should be (mostly) non-disruptive.
Does anyone have experience with this that could maybe help me understand what to expect? Thanks!
No comments:
Post a Comment