Breaking up stack

[FrancWest]

Hi,

we have a MS425 stack consisting of 2 switches. Our ESXi host are connected to them using iSCSI. The problem we are facing is that when performing a firmware update through the dashboard both members reboot at the same time, which causes havoc on our vSphere environment since the hosts loose their connection to the VMFS data stores. Up until now, Meraki support was able to update the members one by one so that the connection to the data stores remain online. However, support now state they aren’t allowed to do that anymore.

The only solution for us now is to break up the stack in 2 single switches which I can update one by one.

I have several questions:

When I remove the stack will the configuration on the switches be lost and reset to default?

Do I need to shutdown our vSphere environment to prevent loosing access to the data stores? Or is the reconfiguration procedure so short that vSphere will survive this?

How about the stacking cables, when do I remove them? Before or after breaking up the stack? If I leave them in place during breaking up the stack, will this causes a loop? Or are they protected by RSTP?

[alemabrahao]

Check this discussion.

https://community.meraki.com/t5/Switching/Remove-member-from-stack-and-create-a-new-stack/m-p/29858

[FrancWest]

That discussion doesn’t say anything about if and how long there’s downtime for the switches,

[alemabrahao]

Have you opened the suggest documentation?

Maybe you should have to open a support case.

[Ryan_Miles]

@FrancWest when you delete a stack you will get this warning message. So, just be aware in case there are L3 interfaces configured on the stack today.

Aside from that, no, the config of the switchports is not impacted nor will it reboot either switch. You can delete the stack then remove the stack cables later and it should be fine.

If you have any cross stack LACP aggregation groups configured that will of course be impacted and you'll need to accommodate with a new design.

With any network changes/maintenance though always prepare for the unexpected should something not go as planned.

[FrancWest]

Hi,

Thanks! We don’t use L3 features on the stack nor LACP trunks, so that’s not an issue. I can safely split-up the stack then.

[PhilipDAth]

Hi @FrancWest .

I'm not going to answer your question - instead, I'm going to tell you how I have handled this design decision in the past.

As soon as someone tells me they want to run storage over IP I adopt fibre channel principles - of having two fabrics.  I create two separate Meraki networks, "A" and "B", and I put a switch into each.  Being in separate networks, you pretty much don't need to do anything special as the networks never seem to get automatic upgrades at the same time (it becomes "set and forget").

Make sure the time for scheduled maintenance is different on the two network (in case you cloned "A" into "B").

If you want, you can have all your switches except one in the "A" network, but there must always be a separate standalone switch in the "B" network.

[FrancWest]

Hi,

ok, thanks. That indeed works to. However, once I break up the stack I can also do a stage upgrade and update the switches at a different time. I’ve disabled automatics updates anyway, since I need control when the updates are being rolled out and I want to monitor the update progress.