cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9203
Views
15
Helpful
8
Replies

Upgrade 4500x VSS cluster to new IOS XE image

M SEB
Level 1
Level 1

Hi,

 

Can anyone help with guidance regarding how to upgrade VSS cluster to a newer image (migrating from 3.5 to 3.6 train).

I tried the ISSU method but it failed. Probably due to the fact that I wish to upgrade to a higher major version.

 

Thank you.

 

SEB

2 Accepted Solutions

Accepted Solutions

Hi,

Would the slave also be aware that the image to load is slavebootflash:NEW_IMAGE_NAME from the commands issued above?

Yes, you only need one boot statement. 

So, you load the image into both switches but only one boot statement on the primary switch.

HTH

View solution in original post

Glad to help

"redundancy reload shelf" command should reload both switches.

View solution in original post

8 Replies 8

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

The easy way is to load the new image in both chassis, change the boot variable, save and reboot both chassis.  This will require a short outage (10 Minutes) but by far faster then using ISSU.

You do need a maintenance window to do this.

HTH

Hi,

Thanks for your reply.

So I uploaded the image to bootflash:NEW_IMAGE_NAME and slavebootflash:NEW_IMAGE_NAME.

 

All I need to do is to issue the following command to get the job done ?

switch(config)#boot system flash bootflash:NEW_IMAGE_NAME

switch#wr

switch#reload

 

Would the slave also be aware that the image to load is slavebootflash:NEW_IMAGE_NAME from the commands issued above?

 

Thanks

 

Hi,

Would the slave also be aware that the image to load is slavebootflash:NEW_IMAGE_NAME from the commands issued above?

Yes, you only need one boot statement. 

So, you load the image into both switches but only one boot statement on the primary switch.

HTH

Thank you, I'll go ahead with that !

 


 

Glad to help

"redundancy reload shelf" command should reload both switches.

Reza, great advice. You saved me from a major headache with my 4500X VSS upgrade today.

Glad the post helped you. Please rate the post so others can benefit from it.

 

So don't listen to Cisco or anyone telling you to do a "redundancy reload shelf" and take a 5 minute outage as both switches reload, there's a way to do a 4500X VSS non-ISSU upgrade with less than 40 seconds of downtime for the links. I've done this multiple times with success. This is assuming you have all your MECs distributed between both 4Ks and aren't single-homed for any connections.

Steps

Pre-step: Set new bootvar on primary and standby 4K and save config.

1. While on the primary, shut all non-VSL ports that are part of the secondary 4K switch. This will effectively force all traffic that are part of a MEC in the VSS to travel through the primary 4K. This step results in maybe a 1 ping loss for some flows.

2. While on the primary, shut down the VSL ports of the secondary 4K switch. This will sever the VSL link and make both 4Ks think they are active. However, per step #1, the secondary 4K has its ports shut down and can't interfere and cause traffic split-brain scenarios. 

3. Now, while on the secondary 4K, you can now run commands as it no longer think its a standby. Ensure your bootvars are set correctly for the new image to load, then do a "copy run start". This is important so that when the 4K comes back up it doesn't try to rejoin the VSL and pass traffic. Reload the switch now.

4. Once the secondary switch has finished reloading, validate the new version loaded fine. You will try to do these next two things simultaneously, as much as you can: a. On the secondary switch that just came back online, unshut all of the non-VSL MEC ports you shut in step #1. b. On the primary, shut all of the non-VSL MEC ports. This will force traffic to converge through the secondary 4K. Here is your biggest chance of an outage, possibly 30-40 seconds, possibly a few pings depending on the flow and convergence times. 

5. Once traffic has converged, confirm your primary 4K has the correct bootvars set, then reload. Do NOT save the config prior to reloading, as we want the primary 4K to restart with all of the ports unshut that you just shut in step #4.

6. While the primary 4K is rebooting, unshut the VSL ports on the secondary 4K. This will allow the VSL to re-establish once the primary 4K comes up and traffic to converge across both 4Ks.

7. Once the primary 4K finishes rebooting check that the version is correct. Check VSL health (show vslp platform, show vslp lmp status). At this time, after VSL health has been confirmed, the secondary 4K will be active for the VSS. Do a write mem on the secondary.

8. Failover the active back to the primary by doing a "redundancy force-switchover" from the secondary 4K. This will force the active back to the primary and result in the secondary 4K rebooting. You may see a ping or two drop here as well.

9. Once the secondary 4K comes back up, you should have your VSS back in its original state! Check VSL health again and do a final "copy run start" to save the config. Viola, minimal downtime.

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: