@BrechtSchamp wrote: Hmm you're right sorry. If I find some time I will do some testing of my own. Awesome!  Will be anxious to see what you find.  Thanks! ... View more

What's really interesting is that I'm seeing Dist 2 switch ports 26,27, & 28 in the topology as designated ports and can see them forwarding BPDUs in the wireshark packet captures but when I run a packet capture on all of the LAN interfaces on the MX the only STP traffic is from the root switch (Agg1).    I've verified that Dist 2 ports 26,27 & 28 are all in the forwarding state and forwarding traffic including BPDUs but it doesn't appear the MX is receiving them or forwarding them even though they are directly connected.  My thought process was that if a BPDU was sent out on port 26 and received by the MX250 it would forward the frame out all ports.  When Dist 2 ports 27 and 28 received that BPDU from the MX250 they would then go to the backup port state since they had now received Dist 2's BPDU on those ports.  Thoughts?  Thanks for all the help!!!  This is truly helping my understand of RSTP and the MX! ... View more

@BrechtSchamp wrote: Actually, I think the capture only contains BPDU's from the root switch because it's the only one sending BPDU's. Once Agg2 receives a BPDU from Agg1 via whichever path, it knows it's not root so it stops sending BPDU's. That's part one of the STP process. Determining the root bridge.   Now for the second part the port states. You have to imagine the MX not altering anything in the BPDU's but just forwarding it out of all ports. If you look at it from that point of view you'll see that the switchports will receive lots of duplicate BPDU's due to MX's flooding. In those cases tie breakers will be used to determine root ports. After that, for all segments designated ports will be defined. All other ports will be set to blocking.   I would indeed be surprised if none of the three ports connecting the Dist 2 to the MX (26, 27, 28) are put in blocking, as with the MX not blocking ports either, that would mean multiple loops.   What I would do is draw out the full schematic, put the port statusses on it and see what the topology looks like. See if you can find any loops. If you can, double check your port settings. Make sure all have rstp enabled on all switchports and switches.   Thanks for the response but that isn't correct.  RSTP neighbors receive on root ports and send on designated ports.  I verified this with wireshark and labeled the sending BPDUs in the topology as in accordance with that in a fully converged topology.  You are thinking of traditional STP.    As for the switches, all have RSTP on.  Agg1 has 0 priority and Agg2 4096.  The distribution switches are default priority.  I have already checked port status for all switches and indicated the state in the diagram by marking the blocked ports with an x.  ... View more

@jdsilva wrote: One note about that example... It's an old diagram I had lying around and shows the MX's directly connected to each other  (heartbeat cable). That link is no longer considered best practice so it should not actually ever be used.  Thanks for the explanation!!!  So just to be clear, only the root BPDUs are forwarded from the MX250?  For example, in my topology only Agg1 (root switch) frames would be forwarded out from the MX250s not BPDUs from the Dist 2 switch?  I'm guessing this is because the MX250 received a superior BPDU from the root switch?  Which is exactly how a switch would behave.  Thanks for all the help!! ... View more

@BrechtSchamp wrote: MX doesn't participate in STP! It will just forward all your BPDUs. So make sure whatever STP algorithm you use is configured correctly on (all) the switches.   Source: https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair   You didn't mention what switches you use but if it's Cisco traditional, they will indeed build spanning-trees per VLAN so the states of the ports depend on how your trunks are configured.   MS does support RSTP. If you're interconnecting Cisco traditional switches with Meraki MS keep in mind the following: This is a Cisco proprietary protocol on Catalyst/Nexus switches that is compatible with Spanning tree (802.1D) and RSTP (802.1w). It is important to note however that because Rapid-PVST is a multi-VLAN spanning tree protocol, in order for the MS series switches to participate in spanning tree a spanning tree instance must be running on VLAN 1 of all switches and VLAN 1 is allowed on all trunk ports running Rapid-PVST so that BPDUs are seen by the Meraki switches in the topology.  In this configuration, the MS series switches should never be the STP Root Bridge. Source: https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide      I understand that the MX250 doesn't participate in STP I apologize for wording it wrong. My question more less relates to the transmission of the BPDUs. I don't understand how three separate links coming from Distribution 2 are in the forwarding state. If all BPDUs are forwarded from each switch then I don't understand how two of the ports wouldn't be in the blocking state since we are using all Meraki switches using RSTP which causes a Common Spanning Tree. In fact, when I do a packet capture on the MX LAN interfaces the only RSTP traffic I see is from the root switch. So does the MX250 only forward BPDUs from the root? Thanks ... View more

All switches are Meraki ... View more

Awesome suggestions! Will implement this very soon and am confident it will work well!! ... View more

Thanks for your help!  I haven't had a chance to implement this yet but I feel confident it will work.  I didn't know about the flexible stacking feature and actually I was told by several Meraki techs that stacking wasn't available on the 420 switches but I can see that it is with flexible stacking!  Thank you very much for the help! ... View more

I agree it's a strange situation but building A is the rstp root for the entire network.  I believe it may have something to do with the fact that the links between building a and b and building a and c are trunk links that are allowing a few vlans across which is extending the layer 2 broadcast domain.  I'm wondering if setting the links to access ports would fix this and allow the separation of rstp instances? ... View more

Can you illustrate or explain?  We already have static routes between each building that do the routing and since Meraki doesn't allow for routed ports how can we do purely L3? ... View more