Question about MS Switch Stack Firmware Upgrade Behavior (Both Units Reboot Simultaneously)

[Ryos]

I have a question regarding the firmware upgrade behavior on Meraki MS switches configured in a stack (2 units).
When performing a firmware update, both switches reboot at the same time. I understand that this is the expected behavior, but I’d like to better understand the technical reasoning behind it.

Is the logic such that once the firmware on one switch is updated, the other switch must instantly align its firmware version, triggering an immediate upgrade and reboot on both devices?

I’ve already explained to the customer that this is by design, but they find it difficult to accept that a stacked system reboots simultaneously despite being redundant.
I’d like to be able to explain this behavior in the context of Meraki’s design philosophy or architecture principles — if anyone could share insight or a good way to articulate this, I’d really appreciate it.

Thanks in advance for your advice and experience!

[RWelch]

All switches in a stack form a single logical unit, sharing one control plane, configuration and all members run the same firmware version to maintain stack integrity.

During an upgrade, both switches reboot simultaneously to ensure a consistent state and prevent version mismatches.

[RWelch]

Upgrading a Switch Stack

In addition to supporting staged upgrades, Meraki also simplifies managing a switch stack. As part of our upgrade toolset, we automatically handle the upgrade of the entire switch stack. This upgrade manages the upload of firmware to each switch and takes care of each reboot within the switch stack. If you are upgrading switch stacks within your staged upgrade, Meraki will automatically upgrade the switch stack as part the staged upgrades. The upgrade process for a stack follows the same high-level process outlined previously, with each stack member rebooting close to the same time and the stack then automatically re-forming as the members come online

Best Practices for Meraki Firmware 

[Ryos]

Thank you very much for your precise and easy-to-understand advice.

Do you think a warm spare setup would be the best option if we want to maintain redundancy for the core L3 switches while avoiding simultaneous reboots during firmware upgrades?

I’m thinking that with a warm spare configuration, we could divide the devices into groups using the Staged Upgrade Group feature and upgrade the firmware one unit at a time, minimizing network downtime.

[PhilipDAth]

Warm spare MS technology is now deprecated.  Do not do new warm spare MS configurations.

[Ryos]

I’m surprised to hear that the warm spare configuration has been deprecated — this is the first time I’ve heard about it.
Is this mentioned in any official documentation?
If so, I’d really appreciate it if you could share the link.

[PhilipDAth]

This is what support are advising people.

Note that on C9300 and above and IOS-XE 18.2 things change (new approach being released).

Reach out to Brennan Martin internally about this upcoming change.

[Ryos]

Got it, so this is the advice from Support.

Just to make sure my understanding is correct —
Currently, the warm spare configuration is fine with the MS series, but since the MS series is being gradually phased out and expected to transition to the C9300-M or C9300 Cloud Management models, does this mean that the warm spare configuration used on MS may no longer be supported in the future, and therefore we should avoid building new warm spare setups with MS going forward?

[PhilipDAth · Accepted solution]

100% yes.

[Ryos]

Thank you very much for your detailed explanation.
I completely understand the situation now.

[cmr]

@Ryos, yes that is the only option.  Bear in mind though that you cannot use warm spare with stacks.  So if you wanted 4 switches as a core without downtime during upgrades you would have to have two switches as core with warm spare and the other two either as a stack or two separate switches (depending on how critical the other connected devices are).