Is it possible to upgrade a c3750-stack without downtime?

[jilahbg]

Hi

Is it possible to upgrade a c3750-stack one member at a time to avoid downtime? I need to keep L3-functionality up.

If I have one etherchannel from access-switch (2 channel-ports in 3750, in different stack-members), my 3750-stack as a distribution layer switch, and another etherchannel (also spread over multiple stack members) to core, can I upgrade the entire stack without traffic interruption?

[Giuseppe Larosa]

Hello Jimmy,

I don't think this is possible: if one stack member is restarted and loads the new image the risk is to have the stack logically partitioned.

Suggestion is to follow upgrade procedure during a big maintanance window.

Be also aware that is something goes wrong the only way to load an IOS image from rommonitor is to use Xmodem no tftp option is possible.

We had a very bad experience during an attempt to upgrade a L2-only stack: we were unlucky and we had to load the image by xmodem on two switches of the stack = hours of out of service.

so be prepared.

Hope to help

Giuseppe

[John Blakley]

In addition to what Giuseppe said, I've upgraded my stack with no problems. I had uploaded the IOS to each switch individually before reloading the stack. Of course, you'll need to still reload the stack, or individual, but I *think* the primary switch is supposed to copy its version of the IOS to all of the members of the stack if they aren't the same. I avoided that by uploading the same version to all switches and reloading the complete stack. I was only down for about 5 - 7 minutes.

HTH,

John

[Lucien Avramov]

In general, we cannot achieve zero downtime with 3750 stack upgrade. However, if you are is running the 3750 as a L2 device with dual attachments from two different stack members, *AND* you are upgrading to a new version that is compatible with the version currently running on the stack, you may be able to do something like this to minimize downtime:

1) Use "archive download-sw" to download the new code to all stack members without reloading the stack

2) Use "reload slot " to reload the stack member which one of the redundant link is connected to

3) Wait until switch come back up, rejoins the stack and become fully operational (i.e. STP state fully converges on all ports) - this is possible only if the new version running on switch is compatible with the old version running on the rest of the stack. Otherwise switch will stay in Version Mismatch state, and automatically downgraded back to the old version unless auto-upgrade is disabled, so this scheme will not work.

4) Use "reload slot " to reload the stack members still running the old version - you will need to issue this command multiple times, once for each of the remaining stack members.

Please note there will be a master switchover during upgrade, which may cause STP to reconverge, in which case there might be some traffic disruption.

[ROLF FLEISCHHANS]

Problem with converting STP is  solving with command stack-mac persistent timer 0. MAC address for whole stack remains the same.

Regards, Rolf

[Leo Laohoo]

I agree with Lucien's post (+5). This is the same procedure I did to a stack of 5 switches. Reboot the switches in a stack one at a time ... Don't want to repeat this because it sure took forever, particularly when the IOS has to upgrade the Bootstrap like the new 12.2(50) and up.