cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
231
Views
0
Helpful
3
Replies

VSS upgrade: fastest procedure

gnijs
Enthusiast
Enthusiast

Hello,

 

What is the fastest procedure with minimum downtime to upgrade a VSS pair, NOT using any EFSU (assume non-compatible software versions) ?

A simultanious full boot will take minimum 15 minutes, it is a 6500 (assuming there is no firmware upgrade needed of the line cards, then it will be more like 30 minutes). Any procedure that works faster ?

 

Booting the secundary with a different software version, will put it in cold standby mode (not bringing up the linecards, but it will bring up the VSL). When the active is lost, the secundary will reboot anyway (full). Result: the same 15 minutes (assuming no linecard flashing)

 

Is there anyway i can boot the secundary and force it to become active, immediatly followed by a boot of the old active one (even when VSL is up or down for example, i don't mind potentially having a dual active situation for some very short seconds) ?? But as far as i remember, if i force the VSL down at boot, it won't boot at all (or will it boot as "standalone" ?)

3 Replies 3

balaji.bandi
VIP Community Legend VIP Community Legend
VIP Community Legend

it all depends on what firmware you running now, what sup card, and what is the target version you looking to upgrade.

 

in general you can do below ( again depends on what kind of setup you have)

 

 

  • Copy the IOS to the primary bootflash: and  secondary bootflash: 
  • Remove the boot variable string pointing to the old IOS and  pointing to the new IOS
  • config-registry is 0x2102
  • Save the config

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Reza Sharifi
Hall of Fame Master Hall of Fame Master
Hall of Fame Master

Hi,

You can reload one chassis one at a time, and that would lower the downtime to about 4 to 5 minutes. But in other to achieve this, you have to make sure all your uplinks and downlinks are connected to both chassis. You also have to load the IOS into both primary and backup chassis ahead of time, change the boot variable and verify. Also, before doing anything,  make sure that one switch is operating as "active" and the other one as "hot standby". (show redundancy will show you all these). You also have to make sure your line cards are all functioning correctly, your config-register is correct, running-config has been saved and backed up, and have console access to the switches. If all is well, you can first try the below command to reload the standby chassis:

redundancy reload peer 

Once this chassis reboots completely, it will come up and load the new software in rpr mode. See below:

"Operating Redundancy Mode = rpr Reason: Software mismat" 

 

At this time, you can now switch the traffic to the other switch and reboot the primary by using this command:

redundancy force-switchover

 Once this switch reboots completely, it will also load the new IOS as well, the old standby switch will be the primary, and the old primary switch will be standby. Now, if you want to switch back to the old primary you would have to repeat the last command one more time. 

Caution: All these procedures have to be performed in a maintenance window and not during production hours.

HTH

Hello Reza,

 

I was aware of this procedure, but i am not so confident that initializing from RPR mode to full will or can be done in 4-5 minutes.

(anyway, it won't be longer compared against a full boot)

 

"With RPR, the backup supervisor engine is partially initialized and must reload every switch module after the primary engine fails."

 

When the secundary switches from RPR to full, it still has to reboot every linecard (will the supervisor reboot also ??)

We are running on a (single) old SUP720-10G (per chassis) with old software 12.2(33)SXI1 (uptime > 10 years) and +/- 4 linecards/chassis. If i need to boot and have a downtime window, i would rather go to the latest software at the same time also (15.1.2-SY16)

 

I read somewhere of a "non-official" procedure in which you had to disable the VSL (or the dual active detection, don't remember) and boot the secundary. It would then come up as active and it would trigger a dual active,but if you then immediatly boot the old one, downtime could be limited to a couple of (dual active) seconds. Although, i haven't tested this and personally, i don't think it will work, because if the software version is different, the secondary will never fully boot and become active, even if VSL or dual active detection is disabled (my opinion, but is this true ?)

CORRECTION: From the manual: "If you boot only one switch (in a pair, and keep the other one shutdown), the VSL ports remain inactive, and the switch boots as VSS active.". So if i put the software on both, keep the VSL down and dual active detection down, they will come up both as dual active. i could disconnect the downstream and upstream fibers first and let the chassis fully initialize in the new software version (ie linecard upgrades etc). Then i let it come up as dual active for a couple of seconds. The question is: will a downstream switch with a MEC do anything to the Portchannel (WORST CASE: error disable it ?) when it senses dual active upstream switches ? PS. We are using fast-hello links as dual active (so they can be disconnected), we are not using PAGP+. I guess if we are not using PAGP+ it will not sens this dual active at all (??). We are using LACP, so the link in the portchannel might not come up at all (??) or in LACP suspended mode. mmm , i need a lab

haha

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers