hey all, current switches in stack are non-E version (WS-C3750G-24TS) and running c3750-advipservicesk9-mz.122-44.SE2.bin. We're adding E version switches (WS-C3750E-24TD) to the stack. We should be ok as long as all switches are running 12.2(44)SE2? The reason we ask is that the E version switches are running this "universal" image (c3750e-universalk9-tar.122-44.SE2.tar). should we leave the E version switches on this universal image or upgrade them to the non-E image? Thanks for the help.
You can't put a non-E version on the 3750E. I think that putting a E version switch in the stack means that you'll lose the ability to do auto-upgrades within the stack- you'll need to update each swtich individually, because they fundamentally don't run the same code.
You might get in a situation where you have to copy the image to each switch in the stack individually, set the boot string, and then reboot. I'd definitely lab this up first before attempting it, lest there's any versions of code that don't quite match.
The E version adds a few features related to the stack ring as well, that I'd hate to lose that. I'm not sure why cisco enabled mixing and matching in the stack, because it seems like a very big potential for problems.
I'd probably run a stack of Es and a stack of Non-Es, and trunk between them. Which defeats the purpose of the stack, but the only other option is to upgrade all ports to Es at once- or save some money and buy Non-Es as long as you're putting them in an existing stack.
hey nate, thanks for the reply. there are no non-E 10GE switches (aside from the 1-port Xenpak model that is end-of-sale). we had no choice since we needed 10GE in the stack to uplink via 10GE to another stack of switches.
You can definitely mix E and non-E in a stack. As it is two different images for E and non-E switches, respectively, you will have to do two upgrades, when the stack is to be upgraded.
Use the "archive download-sw" option. It has an option where you can specify which switches in the stack that is to receive the image. Use it without the reboot option in order to make sure that all switches in the stac have the new images present in their flash, before the entire stack is reloaded.
By doing it like that you should be in safe waters - I'd done it like that without any problem.
I didn't mean to imply that you COULDN'T mix and match the stack. But unless you're very careful about using the archive download-sw option and copying the appropriate software to the appropriate members of the stack, as well as always keeping the versions of the software between the members of the stack at the exact same rev- no problems at all.
But as soon as you end up in a software mismatch mode, you're in for an evening of headache as you're pretty much forced to break the stack, reload the new software on the offending switches, and then re-inserting it into the stack once you've manually resolved the issues. I wish I could say I was speaking from theoreticals.
Archive-download-sw when everything in the stack uses the same code is a great way to manage the code. Trying to manage different code-bases within a stack just screams "potential problems" to me, especially when you're dealing with a large-scale distributed network. So I'd avoid it IF POSSIBLE, but if not (as budgets tend to dictate) then you're left to manage it as you mentioned.
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 custome...