Hope some of you already have some hands-on experience with that - if you're adding a new switch to the stack and you get IOS version mismatch, can you still copy the bin image from the master to the new member over the stack cables?
8
-
You need to make sure that you have matching versions before attaching a switch to the stack.– Ron Maupin ♦Commented Jan 21, 2021 at 17:45
-
That is not an answer to the y/n question which was asked. I'm talking about a real-life scenario, where you don't have physical access to the switch and as a remote engineer you're dependent on an onsite technician with whom you communicate over extremely unreliable mobile network connection while he's sharing his laptop screen with you and he has no USB drive with him nor any IOS image on his computer or access to Cisco portal to download it and the end customer gives you both up to 30 minutes to replace a faulty stack member...– Martin LedermannCommented Jan 21, 2021 at 17:56
-
I did not post an answer, I posted a comment, and it is a correct comment. You must make sure the version match before connecting a switch to a stack. That is really all there is to it. We do remote installations all over the world, and we have set up a system where the switch gets the correct versions before it gets shipped to the site.– Ron Maupin ♦Commented Jan 21, 2021 at 18:00
-
Well, in that case kudos to your company for having such a system. Mine does not and the external company which provides us with onsite technician and hardware delivery isn't contractually obliged to provide the expected IOS version.– Martin LedermannCommented Jan 21, 2021 at 18:01
-
The reason I've asked and phrased my question in the manner in which I did is because I've heard from my more experienced colleagues that this is supposedly possible - however I have unfortunately never seen it done in practice, that's why I'm hoping that perhaps someone from this community has already had a chance to try such a scenario out.– Martin LedermannCommented Jan 21, 2021 at 18:03
|
Show 3 more comments
3 Answers
Major Stack Protocol Version Number Incompatibility Among Stack-Capable Switches
Switches with different major Cisco IOS software versions usually have different stack protocol versions. Switches with different major version numbers are incompatible and cannot exist in the same switch stack.
Minor Stack Protocol Version Number Incompatibility Among Stack-Capable Switches
Switches with the same major version number but with a different minor version number are considered partially compatible. When connected to a switch stack, a partially compatible switch enters version-mismatch (VM) mode and cannot join the stack as a fully functioning member. The software detects the mismatched software and tries to upgrade (or downgrade) the switch in VM mode with the switch stack image or with a tar file image from the switch stack flash memory. The software uses the automatic upgrade (auto-upgrade) and the automatic advise (auto-advise) features.
The port LEDs on switches in version-mismatch mode will also remain off. Pressing the Mode button does not change the LED mode.
So, if the version are "close", the auto-update feature should take over. Otherwise, a manual upgrade will be required. (copy the firmware from the existing switch via usb, scp, etc. to the new switch.) I know this can be a pain when they're both in your hands, trying to walk someone through it remotely is tough.
I was finally able to test it in the production environment at my company and can confirm that no USB was necessary, despite the "Major Stack Protocol Version Number Incompatibility" - it was still possible to access the flash of the mismatched member from the master of the stack.
As for the auto-update feature, I must say that we only use bin images at our company and so that feature has never ever worked with our 2960x stacks, unlike what Cisco brags about in its documentation. Each time the IOS had to be upgraded manually, regardless of how close or distant to one another the IOS versions were.
I just ran into the same issue and was also able to copy the firmware from the other stack members over the stacking cables (copy flash1:<> flash2:<>) but I wasn't able to update the firmware while the stack was connected (the command boot system switch... didn't stick) and it's unclear if the original poster was yes able.
I did find a workaround preventing the need to break the stack (and having a console cable into the mis-versioned switch) just to update firmware. I deleted all other firmware versions from the mis-versioned switch flash which caused the switch to failover to the correct firmware image.
