Upgrading a Mixed Switch Stack

adam220891

Hey all,

Not really certification-related, but I've got to do some switch upgrades in a new environment and have some concerns.

The 3750 stacks I'm working with are pretty large (some are 9 deep), and not all contain the same model and firmware type. For example, at least one stack contains both 3750G and 3750X switches and some run IP Services while the others run Universal firmware.

I'm believing the automatic TFTP/extract method to the switch master won't work for this. Should I just TFTP the two different BIN files to the appropriate flash#:/ directories and then set the boot parameter individually? My understanding is the last guy that got stuck with this took six hours on a single stack and had all sorts of issues.

I'd greatly appreciate any help on this one. I guess I always got lucky in the past and the switches were all the same...

Find more posts tagged with

Comments

clarson

1) why aren't you calling Cisco and getting their answer on this.

2) why aren't to testing this in a lab environment before making changes to 1000's of switchports.

3) are you really going to beleive what someone tells you on some forum on the internet. You should always test before making changes, even if the OEM says it is ok.

the only one with something to lose if this fails is you. So, make sure your doing it right. the last guy had problems and isn't doing it anymore. You don't want to be that guy.

but, like you said the stack members have to be similar models with similar version of the ios. But, what you describe seems to be quite a strecht. If it can be done, Cisco should have a procedure on how to do it. and what your expectations can be in the event of a switch failure.

Ertaz

clarson wrote: »

1) why aren't you calling Cisco and getting their answer on this.

You really are taking the fun out of this for everyone else.

clarson wrote: »

2) why aren't to testing this in a lab environment before making changes to 1000's of switchports.

Because you don't get the "My job ended because" story out of it if you do it that way.

clarson wrote: »

3) are you really going to beleive what someone tells you on some forum on the internet. You should always test before making changes, even if the OEM says it is ok. The only one with something to lose if this fails is you. So, make sure your doing it right. The last guy had problems and isn't doing it anymore. You don't want to be that guy. But, like you said the stack members have to be similar models with similar version of the ios. But, what you describe seems to be quite a stretch. If it can be done, Cisco should have a procedure on how to do it. and what your expectations can be in the event of a switch failure.

I was just about to tell him that I do this kind of thing all the time and it will be fine...

MitM

Mixing a stack with 3750Gs and 3750X is not so much a problem in itself. You have to be careful mixing feature sets because if a switch with a lower feature set becomes the master, the whole stack will then have those features.

As far as the upgrade, I'm not 100% sure as I've never mixed models but I believe in this scenario, you'll have to upgrade the switches separately.

I agree with clarson that you'll want to open a TAC case. Better safe than sorry

Danielh22185

I can't say I have ever done a stack upgrade when there were different platform types, this honestly is never a good idea (and Cisco will tell you this). From experience if I remember correctly that will cause issues with them joining the stack. Are they currently all joined right now? Or is this what you are trying to accomplish.

However in a perfect world where the switches are all the same platform type all you would need to do is copy the image to the master switch and it will take care of upgrading all the others. You can point your boot variable to the master switch as a central location for all the other switch to grab from or you can do it individually. Problems I've seen before is when the boot variable points to the master switch and you don't have a copy of the image on all the other switches the stack fails if the master dies because the image only existing / pointed to the master switch. So best practice would be to make sure each switch has a copy of it in their flash and upgrade accordingly.

tunerX

make sure you know which switch types are which member number. Download the ipservice and universal of the same version. Copy the correct IOS to each switches flash. Set the boot statement per switch for the correct IOS...

Reload when authorized.

adam220891

clarson wrote: »

1) why aren't you calling Cisco and getting their answer on this.

2) why aren't to testing this in a lab environment before making changes to 1000's of switchports.

3) are you really going to beleive what someone tells you on some forum on the internet. You should always test before making changes, even if the OEM says it is ok.

the only one with something to lose if this fails is you. So, make sure your doing it right. the last guy had problems and isn't doing it anymore. You don't want to be that guy.

but, like you said the stack members have to be similar models with similar version of the ios. But, what you describe seems to be quite a strecht. If it can be done, Cisco should have a procedure on how to do it. and what your expectations can be in the event of a switch failure.

1. CCO account got disabled for some reason so in meantime thought I'd talk to like-minded folks. I've since fixed that issue and opened a TAC case.

2. I don't have any access to a lab environment. I have been here a total of two months and the fact that we have 100 mbps switches everywhere might be indicative of the resource set we are apparently working with. So, instead of doing every single stack at one go I'm doing due diligence first, following the CR process, and going in with a plan turning a scheduled maintenance window.

3. Experience trumps text; if someone here tried this before, I'd like to hear about it.

The guy that did this before and had issues wasn't fired. His team (which is geographically not located at HQ) handles more of the customer-facing resources now. I got minimal info other than (and I'm paraphrasing) "See you have a CR for an upgrade of X switch stack. Nightmare last time. Many hours and hands on deck for it. Good luck."

The senior engineer who could be doing this also does not work at HQ (for some reason none of these guys do, only me, and I started pretty recently). So, I'm stuck with this.

FWIW, TAC tells me what I expected. Copy bin files to each switch, verify MD5 hash, then set the new boot parameter before writing the config and reloading. There can be issues with mixing feature sets when a switch in the stack suffers a failure. In this case, the X version is not the master and that was/is part of the issue. If it was so much trouble, I don't know why it wasn't setup as a standalone switch. I'm guessing because the stacks have L3 uplinks to the core and are not trunked, and the person didn't want want to introduce a L2 trunk into the environment and maybe determined that connecting via L3 wasn't worth the hassle for whatever reason.

We've got issues around here and a serious lack of documentation and consistency. It's a little overwhelming.