Yeah, i am probably going to split the stack into two...but then i have to setup HSRP. I was hoping to keep it as one stack so that wouldnt have to be done, but it doesnt look like its going to be possible.

Thanks guys.

But what happens, then, when you reload the stack master? In my thoughts it will result in at reload of the complete stack.

Anyone who've tried to do this?

You can lose the master of the stack and still have the stack remain operational. That is one of the benefits of having a stack of switches. You can lose any single switch and still have the rest of the switches remain operational.

My concern is having some type of software mismatch and causing the switch stack to segment.

What I meant was that the previous posting suggested how to reload one switch at a time in order to upgrade it to a newer version. how, then, do we get to upgrade the master switch without the whole stack reloading?

By forcing another switch to be master and then reload the one switch which was previously master?

In other word, I'd like to know whether it's possible to do a swithc-by-switch upgrade without having the downtime, as also asked in the original posting.

Thanks & Regards.

It's not a question of reloading a single switch stack member, but what happens as the 3750s try to function as a stack.

See: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/configuration/guide/swstack.html#wp1189553 starting with "All stack members must run the same Cisco IOS software version to ensure compatibility in the stack protocol version among the members. "

[edit]

I suspect, upgrading individual switches within the same train, e.g. 12.2(44)SE1 to 12.2(44)SE2, might be "safe", but jumping versions not as safe.

Even if it's safe, what does it save you? When the master resets, if all other switches are running the "newer" version, you'll may only need to wait for the master to migrate to another stack member. I.e. this might be (is?) faster than full stack reload.

The former master, if it follows the rules for a lost and restarted stack member, likely will not reclaim being a master until there's a new stack election. This has implications such as gateway MAC change. Plus, other services might be interrupted with the master change (some of these might be further mitigated with certain configurations; software and hardware).

The choice then is trying to shave some time off a stack reload to a new version vs. all the issues that might arise attempting to do so incrementally.

Thanks.

So in other words, there's no feasible way of upgrade a stack in phases in order to take advantage of the NIC teaming from servers to avoid dowbntime for servers?

Considering what Cisco documents, I don't believe bumping individual 3750 stack member switches is a feasible approach for routine operation. It looks like it's possible in some situtations.

If there's a routine requirement for keeping servers on-line, 24/7 365, then the network should be designed with this in mind. The 3750 series, used as a single stack, doesn't, it appears, meet such a requirement.

Hello Ingolf, Joseph.

I agree with Joseph and as I wrote in my first post we had a very bad experience in an attempt to upgrade a 4 C3750 stack from 12.2(25)SE to 12.2(44)SE instead of one hour out of service we had extended out of service for hours because two switches didn't like the new image, they have gone in rom monitor and only xmodem worked for them to load an usable ios image.

They were used in a wiring closet and people couldn't work that day.

The release had been suggested by Cisco TAC to try to solve an issue.

So I don't imagine is possible to upgrade one switch of the stack at a time.

Hope to help

Giuseppe

Correct- if you want your design to include availability during a software upgrade, you'll need two different switches/stacks. Having multiple versions of code running in a stack means you'll end up with version mismatches and be unable to reach boxes without physically removing them from the stack and upgrading them manually. It made for a very long night.

Use the tar files, and use the archive function. It takes a long time, but it's a pretty simple process.

If you're trying to keep uptime at a core level, the best thing to do is split the stack and take the administrative overhead. Granted, the bandwidteh the stack provides is now gone.