We're in the process of upgrading 3750 switch stacks in our organization. The stack varies from 2 to 5 switches. We have upgraded about 15 stacks so far. But 2 out of 15 stacks, however, have failed during reload. We had to disconnect the switches from the stack, boot them one at a time then reconnect.
It doesn't seem like the IOS is the issue. I'm guessing the issue may have something to do with the priority settings on the switches. All switches in the stack have a priority of 1. However, the other stacks that have successfully reloaded after the IOS upgarde have the same priority 1 on the switches as well.
We have several stacks left to upgrade and we feel that we may run in to the same issue again with one of more of the stacks. Has anyone run in to this issue before? Should we set the priority number of the switches (ex: 15, 14, 13, etc.), instead of leaving the default setting of 1. Or is the issue caused by something else?
In general what I do is that I load the ios into each separate device (tftp the ios .bin file to every flash in the stack)
This is since I only use the .bin file and do not want the web.
Then I set the bootloader to load that file.
To reload the stack I start with a wr mem. (make a backup copy of the config file to your pc at the same time if you do not have one)
Then I check the stack via the system button on the front to see wich is the stack member order ie if you have 3 members in a stack pull the power on nr 3. Let the others come to terms with that they are now only 2 (wait 30 sec) then pull power on nr2 wait 30 sec then wr mem and reload nr1.
wait 3.5 minutes and se that one have started up alright with the new IOS and then plug in nr 2 and if you have the time let it come up properly and resume the role of 2 (if you do not have the time give nr 2 as much headstart as possible) and then add power to 3 and let it come up as number three.
This is something that I do even if I just needs to reload the stack for some reason. I just figure that since they do not all want to do a stack vote at the same time it works better.
This gives the switches a couple of headstarts in the process, the 1 switch will have booted first, it has the latest config and is already up and running when 2 comes up. ie it should make it as switch master. same when 3 comes up. (I use the 1 as master always and it is always at the top of the stack and the stack then comes below it if possible)
I do not remember that I have ever set the stack priority in any of my stacks (except for test).
Generally the upgrade works ok . You should set the priotity of which switch you want as the stackmaster and backup master with the others falling in line 15,14,13 etc... If you are upgrading via the archiving a .tar file it "should" download and upgrade all the switches in the stack automatically . This is not a 5 minute process , it takes awhile. I would also go into each switch when its done upgrading and verify the new image has been transferred into flash. Then verify where it is booting from by looking at the boot statement which is made automatically when using the archive method . If you use the straight .bin file you have have to manually load the bin files into each switch . This can be done by downloading to the stackmaster then just copying from master to the other switches and set the boot statement . Read this doc for a good understanding .
Thank you guys for the comments. The 2 stacks that failed consisted of 3 switches. I think we will set the priority on the switch stack before the upgrade and reload. We will continue to do the conventional reload. If reload fails then we'll just cold boot one switch at a time starting with the master.
We're also using CNA (Cisco Network Assistant) for the upgrade instead of CLI for the first time. So far CNA works for us especially on the switches.
I've been involved in upgrading a number of switches to the 3750 (stacked). Here's what I do:
1. Configure the stack master and ensure the uplinks are working. 2. Configure the stack master as "priority 15". 3. Configure from the stack master the "switch XX provisioning". 4. Install (DO NOT POWER UP THE SWITCH MEMBERS) the remaining members of the switch. 5. Ensure the stacking cables are screwed in correctly. Remember 1 mm of loose contact and the SmartStack won't work. 6. Power up the stack members according to order: Power up stack number 2 wait for about 5 seconds and then power the next. 7. Ensure that each stack member comes up and SmartStack is working.
WARNING: Make sure all stack members have the same IOS version AND IOS feature.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...