Hello everyone!
Hope you're doing great! That's a very interesting discussion.
TL/DR: only configure Root Guard in your CORE switch on trunk ports connecting to downstream switches; only configure BPDU Guard on ports connecting to end-user devices/hosts and never on a trunk connecting to any switch; Meraki switches can only run Rapid Spanning Tree so make sure STP types are compatible by running RSTP on all switches or tweak MSTP to be more like RSTP.
@michalc made a good point about compatibility between spanning tree types and interoperability, while @alemabrahao also raised a point to how STP is configured in Catalyst 3560.
To your point, @alemabrahao , it's true that the best action would be just to change STP type on the 3560s to RSTP so then every switch would run the same and the root election would be predictable.
However, not all IOS firmware offer you RSTP. An even more compatible approach would be to run MSTP (check if your IOS supports - most likely yes, it does). But MSTP needs some tweaks:
- Single instance (0); running single instance 0 means there will be only one single STP process running in memory
- single region (region1), and single revision (revision 1); doing this together with step-1 basically makes MSTP behave like RSTP
- have your trunk ports configured as Native VLAN 1 and switch Management IP in VLAN1; you must to this because VLAN1 is used by MSTP to interact with other STP types
Making MSTP more compatible is described on section "Enable RSTP Globally" in Configuring Spanning Tree on Meraki Switches (MS).
Having said that, I want to dial back to the issue that raised @Mark-SPS 's post: "The trigger for this was that today a trunk port on a different switch went to "STP root guard activated" today."
@Mark-SPS , I need you to be careful when configuring STP Guard options. In a nutshell:
- Root Guard will protect the switch from losing the STP election or changing the current Root. The way Root Guard protection does it is by transition the port to an STP-inconsistent state it the ports receives a superior BPDU (i.e. a STP management packet showing there's a better Root); the port in this state still processes BPDUs but will not learn MAC addresses or forward traffic. As a result, hosts upstream that port won't be reachable and you may lose access to your switch until the previous Root gets elected again. This is why you only configure Root Guard in your CORE switch on trunk ports connecting to downstream switches.
- BPDU Guard protects the switch against "alien switches" and small loops. The way it does this is by putting port in a disabled state if it receives any BPDU at all. So if someone messes with the cables and create a loop or maybe if someone connects a hub or switch, the port would receive BPDU and then shutdown. This protection is useful when you are 100% positive that the devices connecting to this port will be only ip-phones and end-user hosts. This is why you only configure BPDU Guard on Access port type - never on a trunk connecting to any switch, as @michalc suggested.
- Loop Guard protects your switch from an exceptional situation where a switch believes there's a loop and starts transitioning port states and trying to check root election. It's recommended to configure this protection on redundant ports connecting to non-root downstream switches and also enable UDLD together with this.
Lastly, @Mark-SPS , you mentioned "Currently the STP Guard is disabled for these ports, as under no circumstances can these connections be blocked." I'm assuming your Catalyst 3560 upstream is your CORE switch and it has STP Root role. If that's the case here, then don't configure any STP Guard option on the Meraki switches' trunk ports connecting upstream to your CORE.
Hope this information is useful. Feel free to post here anytime if you have further questions / concerns.
If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it.
