Problems while initializing a LAN enviroment based on MS150's: STP loops

[WojtekMitus]

Hi, we are struggling with STP loops occuring in redundant topology of a small LAN network built out of a six MS150 switches.  We have two MS150's interconnected with a stack cables, providing aggregation layer, and two other MS150 access stacks connected to the central stack. Topology is redundant (stacks are connected to each other with two links). WAN connectivity is provided by two Cisco SDWAN routers connected to the members of the aggregation layer stack. The site is defined as a separate network in Meraki portal.

As soon as we manually remove the site's network from portal, to re-add it later using Ansible playbooks (we are tesing an automation solution using Ansible), an STP loop breaks out in the sites's network (seems like a few hundred megabit broadcast storm). This storm causes instability and prevents the switches from reaching Meraki portal and getting the configuration. The site's network just sits there with unconfigured switches and STP loop raging in the LAN. My guess is that the switches are factory defaulted while being removed from network, is this correct? What are default loop prevention mechanisms on a factory defaulted MS150 switch? Are there any?

To break the STP loop we have to power down all of the switches but the aggregation stack, and power devices up gradually, to  keep the topology non-redundant and prevent switches going into the loop before downloading configuration from Meraki portal. When finally site is configured properly again and all of the switches are able to get their config, the network works fine (switch uplinks are bundled into aggregation groups, all ports have loop guard implemented, there are no loops, everything works as expected).

Is this a known problem? Is there anything we can do to prevent this initial STP loop on a factory defaulted boxes?

Thanks,

Wojtek

[alemabrahao]

When you remove a switch from a Meraki network in the dashboard, it reverts to factory default settings. When the switches are reset to factory default settings and reconnected in a redundant topology, they still do not have the configuration to prevent loops (e.g. no loop protection, no port aggregation).

Since they cannot access the Meraki cloud due to the broadcast storm, they never receive the intended configuration and the loop persists.

My suggestion in this case is before removing the Meraki portal site, physically isolate the switches from each other or from the redundant links and keep only the aggregation stack connected to the WAN and the Meraki cloud.

[WojtekMitus]

Hi Alessandro, ok, thank you for the clarification. We will have to adjust site deployment procedure.

[GIdenJoe · Accepted solution]

I'm not sure of the behavior of the stacking ports when the switches first come online.

The documentation says that you should first bring up the switches individually or if you immediately stack them start with 1 uplink to be sure.  Only after that can they come online and be doubly uplinked.