4500 VSS Upgrade with no ISSU

[marcio.tormente]

Hello Folks!

I'd like to ask your help to tell me how to make IOS upgrade on Catalyst 4500 with VSS without impact.

I saw some docs using ISSU, but I believe using the copy command and change the boot sequence is easier, but I'm not sure if the process is the same as we do with other devices.

I'm using the version:  03.06.08.E and need to upgrade to 03.08.08.E.152-4.E8

I have a single sup on each switch:  WS-X45-SUP7L-E.

Thanks

Marcio

[balaji.bandi · Accepted solution]

Good method

1. Take the config backup out of the box

2. read the realse notes of new IOs and understand bugs and caveats

3. create a backup plan in case any issue.

4. connect console cables to capture upgrade information.

Follow below goo thread has all the information.:

https://community.cisco.com/t5/switching/cannot-upgrade-ios-on-4500x-vss/td-p/2475516

[marcio.tormente]

I found in your link this procedure and I believe it will works.
1 IOS download in bootflash and slave bootflash:

Copy tftp: bootflash:
2 Check IOS in bootflash

dir bootflash:
dir slavebootflash:
3 Very with MD5 command

Show version - Register value should be (config-register 0x2102)
verify bootflash: cat4500e-universal.SPA.03.08.08.E.152-4.E8.bin
verify slavebootflash: cat4500e-universal.SPA.03.08.08.E.152-4.E8.bin
ec7258f35dc31aa9ad1e09b8bb4eb8d5 MD5 value for this IOS
4 Set the boot path for current IOS and verify path is set

no boot system bootflash:cat4500e-universalk9.SPA.03.06.08.E.152-2.E8.bin
boot system bootflash: cat4500e-universal.SPA.03.08.08.E.152-4.E8.bin
write
show bootvar
6) Standby switch will be reloading for IOS upgrade in standby device.

redundancy reload peer
show module (after peer come up)
we will verify current IOS in peer switch with show module command

7) Now master device will be reloaded for IOS upgrade.

redundancy force-switchover
This will reload the active unit and force switchover to standby[confirm]

Preparing for switchover...

8) After primary device come up will verify IOS in both of device.

Show inventory
Show version
Show environment
dir bootflash:
dir slavebootflash:
show bootvar
show switch virtual
show redundancy
show switch virtual slot-map
show module
show log

[Leo Laohoo]

Whao. That's not going to work.
You're mixing non-ISSU with ISSU when you use the command "redundancy force-switchover". This forces the active supervisor card to reboot and fail over to the secondary.
When the primary boots up, it will detect that it is running a different firmware to the secondary and will boot into ROMMON.
Instead of using "redundancy force-switchover", just issue the command "reload" to boot both chassis simultaneously.
Finally, what is the current config-registry value of the line cards?

[marcio.tormente]

Hello Leo!
the command reload will reboot only the primary switch, not both. I made this few weeks ago and I had problems with VSS.

[Leo Laohoo]

---

@marcio.tormente wrote:
the command reload will reboot only the primary switch, not both. I made this few weeks ago and I had problems with VSS.

---

The default "reload" will reload both units. 

There should be an additional command "reload both".  

[Reza Sharifi]

Hi,

I saw some docs using ISSU, but I believe using the copy command and change the boot sequence is easier, but I'm not sure if the process is the same as we do with other devices.

It is so much easier if you simply load the IOS into both primary and slave sups, change the boot parameter to reflect the new IOS, save the config and reload both chassis at the same time by using command "redundancy reload shelf" during a maintenance window.

The reload time is usually less than 15 minutes specially if the chassis are not full.

HTH