The switch we’re going to talk about today is a 2960S switch. If you look at the back of it, you’ll notice an empty module slot .This module slot is used for making your switch a stackable switch. Basically its a way to take a few switches and make it look like its in a chassis like a 4500 or 6500 switch. You manage everything from the primary switch and you never touch the “slave” switches.
So I recently ran into a situation where I had to upgrade the IOS on the switches. So how was I suppose to do this since this wasn’t a standalone switch?
First off, a good white paper read from Cisco on this. You can skim this one before reading the rest of this post.
**note I’ll call the switches a stack but the “official” terminology for the 2960s is FlexStack. 3750s are called Stackwise **
A quick and dirty overview on the new commands we can use with our 2960S stack switches…
This command shows us a summary of the switches in our stack. Notice the priority. If R&S has taught us anything, geernally the higher the priority the better (wins the election). So this is why from 1-15, switch1 has won the election as is now the master of the stack. You can change the priority on a switch by typing in config mode switch X priority X
Switch/Stack Mac Address : xxx.xxx.xxx
Switch# Role Mac Address Priority Version State
*1 Master xxx.xxx.xxx 15 1 Ready
2 Member yyy.yyy.yyy 10 1 Ready
#show switch stack-ports
This command show us if the actual Flexport ports are OK on our switch modules. We see here that both ports on our stack are OK!
NY-2960S#show switch stack-ports
Switch # Port 1 Port 2
——– —— ——
1 Ok Ok
2 Ok Ok
#reload slot X
this command lets you reboot a certain switch from the master (or any other switch in the stack)
#sh ip int b
The command we know and love, the only different here is that instead of regular 0/1, 0/2, 0/3, etc, we get an additional module. So any ports in switch 1 are now called 1/0/1, 1/0/2. 1/0/3, etc. Any ports in switch slot 2 are called 2/0/1, 2/0/2, 2/0/3, etc.
MASTER LED in front of switch
Another new “command” is that the switch panel in front will have an LED called “Master”. If your switch has the highest priority it’ll be lit solid green. A nice way to eyeball it without having to SSH to it. In the Cisco diagram below, its (3) MSTR
OK so maybe that wasn’t “quick” but its essential to know this information before even trying to upgrade the code! One thing to also note that that as you might imagine, the code needs to be the same on ALL switches in your stack.
Luckily for us, there is a Cisco KB guide on how upgrade the code on all switches in our stack in 1 shot…..and its also just 1 command.
archive download-sw [options] <source-file>
Thats it! Run it on your MASTER switch and we get the following options…as you can see we got a bunch of different places we can pull the image from (flash, SCP, TFTP, the usuals) and some options (show in slashes) like overwriting the existing image, specifying a directory, reload after specifying the image, etc.
NY-2960S#archive download-sw ?
/destination-system specify destination system to receive software
/directory Specify a directory for images
/force-reload Unconditionally reload system after successful sw upgrade
/force-ucode-reload Upgrade UCODE after successful sw upgrade and before an unconditional
/imageonly Load only the IOS image(s)
/leave-old-sw Leave old sw installed after successful sw upgrade
/no-set-boot Don’t set BOOT — leave existing boot config alone
/no-version-check skip version check that prevents incompatible image install
/only-system-type specify individual system type to be updated
/overwrite OK to overwrite an existing image
/reload Reload system (if no unsaved config changes) after successful sw upgrade
/safe Always load before deleting old version
/upgrade-ucode Upgrade UCODE after successful sw upgrade (no reload)
flash1: Image file
flash2: Image file
flash: Image file
ftp: Image file
http: Image file
https: Image file
rcp: Image file
scp: Image file
tftp: Image file
After you pick your option sit tight for a while. Best to have a console connection to your switches if you got some kind of KVM system in place because it took me almost 30 minutes for this command to run when I did it from TFTP. I was starting to get worried but around the 30 minute mark it completed. Also, just to be safe, reboot the switches to ensure the new version not only takes but doesnt cause any issues. Run your #sh switch commands to verify everything is good.
BTW if you do a “sh proc cpu” command you may see a process called HULC archive dnl thats taking up a good amount of CPU. This is the upgrade process doing its magic.