spanning tree issues with Meraki and Cisco Classic Distri-Switches

[redsector]

Hello,

I had an well working network with three Cisco WS-3850 distri. switch stacks .

I connected the three stacks with port-channels to a triangle running with STP to block ports to prevent an loop (see picture).

One of the stacks I tried to replace with a Meraki MS425-16 Stack. Now I run into spanning-tree issues.

The Meraki stack runs with MS14.25 software.

Have you got any ideas? And remember: with Cisco "classic" it works very well.

[ww]

Do you run mstp? 

https://community.meraki.com/t5/Switching/Mekari-Cisco-MSTP-and-RSTP-Configuration-Questions/td-p/35...

https://community.meraki.com/t5/Switching/Cisco-3850-Access-layer-switch-connection-to-Meraki-425-co...

[PhilipDAth]

Best option, remove the loop.  Make one stack the core, and the other two just hang off the core.

Second best option, on your 3850's:

spanning-tree mode mst

Also, configure one of your stacks to be the deliberate spanning-tree root by setting the priority rather than just allowing them to choose themselves.  That should be the core switch, refer best option above.

[GIdenJoe]

I really hate that kind of design with a vengeance.

I had a few colleagues that also get clients to have 3 "datacenters" with a triangle like topology just like that one in layer 2.  That makes no sense at all and should be avoided at all costs.  Usually you see these design choices when the customer used to have HP comware switches runnning IRF stacking.

Better designs:

Or you have two datarooms with a stackmember in each doing a virtual stack and connect all your access switches to both.  Also WAN/Internet should be spread over these rooms then.

Or you only connect access switches to dataroom 1 or 2 with two links and you have layer 3 between them.  And your WAN or Internet outbreak should only be connected to one of those rooms.

[cmr]

@redsector we run one site sort of like you do but the differences are:

One stack of 3850s that do all the routing, two stacks of MS225s/MS210s and the links between the stacks aren't in a portchannel as 10Gb is enough.  STP seems to cope, even with one stack that seemed to have 3 links to another (no more once found).

I don't think we did anything special, but @uccert might know better!

[redsector]

Thank you all,

@cmrport-channel because sometimes a SFP fails, and so we have an redundancy. It´s not only for the speed.

[redsector]

@GIdenJoeit´s a funfair park on a large area. We need this for security reasons. And: it worked with Cisco ´classic´ 20 years. I expect that we can do this with Meraki too.

[cmr]

@redsector we have the 'circle' for redundancy and even multiple links between stacks, we just don't put them in a portchannel and haven't had any issues.  STP seems to do a good job of keeping the majority in blocking mode.

[GIdenJoe]

That it "works" was not my criticism.

Bad designs always work great until they break 😉
I just wanted to highlight that these large layer 2 designs have inherent issues and will set you up for failure at some point in time.

The thing with Meraki is that they will only support features that conform to their best practices.  And yes if you have a background is regular Cisco gear that usually has every feature or possible use-case on board than you could be in for some surprises 😉

It's true that Meraki deployments are quick and easy, but they do require planning if they will support the design.
The biggest issue you will always have even when using other vendors in combination with regular Cisco switches is the fact they by default run PVST or RPVST which does not always play well with other vendors.  I have had Cisco switches shutting down ports due to etherchannel guard misconfig because when re-converging the core switches that were another vendor passed through a few RPVST BPDU's causing a massive outage!

Normally if you use MSTP in the CORE with forcing the CORE to be the root for all instances (try running single instance IST if possible since stacking and MEC's remove the need for multiple STP topologies).

Circling back to the design, the whole reason wireless has the possibility to tunnel clients between controllers or between AP's in Meraki world is because if you have a L3 CORE as you should you can still provide mobility for wireless clients that roam from an AP that has X subnet vs another that has Y subnet because it is connected to an access switch that connects to a different distribution switch.