Connecting switch to MX & STP

[iores]

Hi,

What will happen if a switch is connected to MX with one trunk port, and one access port?

Will RSTP block one of the two ports on the switch given the fact that MX doesn't speak STP?

[alemabrahao]

Not necessarily; you can have multiple MX ports connected to the same switch and they won't be blocked.

Note: The MX does not run STP in any capacity, and will not exchange BPDUs with other switches or participate in the root bridge election process.

If the MX received BPDUs on the LAN, these BPDUs will be re-forwarded within the broadcast domain that they were received on. If there are multiple switches connected to the LAN of the MX participating in an STP election, all BPDUs sent to the MX will be forwarded to other links with the same VLAN allowed, which can cause switches to see BPDUs from multiple other switches, causing ports to get into an unknown/unidentifiable state and impacting the root bridge election process.

Below is a diagram illustrating how the STP election process can be affected by this MX LAN forwarding behavior - when 3+ switches are connected in the same broadcast domain, each switch will receive BPDUs from 2 or more switches on their connected uplinks. In the case of switches 2 and 3, the uplink is both a root port and a designated port from the switches' perspectives, causing the ports to go into an unknown state. In practice, this can also result in rapid STP port status changes for uplinks on multiple switches.

https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Networ...

[iores]

Since RSTP doesn't tag BPDUs, then MX somehow tracks in which VLAN it receives BPDUs?

Then, if acces VLAN is not allowed on trunk, I guess everyrhing should be fine.

But, if access VLAN is also allowed on the trunk, then MX should forward BPDUs, and the switch should block the port since RSTP doesn't create separate topology for each VLAN?

[alemabrahao]

It will not be blocked.

There are a few things that can be done to prevent this from occurring:

• Avoid connecting more than two switches in the same STP domain directly to the LAN of the MX

• Isolate the MX in its own broadcast domain by implementing Layer 3 switching downstream

The STP Root Bridge doesn't generate TCNs to notify of topology changes, only the non-root switches do. This can cause longer failover and STP convergence times and should be considered when setting up the root bridge and/or redundant links in the environment.

[iores]

I am interested only in this specific case from the initial post.

How it will not get blocked since access port also send BPDUs?

[alemabrahao · Accepted solution]

Yes, access ports also send BPDUs (because STP runs on all switch ports by default). So in your scenario,

The access port sends BPDUs for the single spanning-tree instance, the trunk port also sends BPDUs for the same instance, the MX doesn’t process them, it just forwards them like normal frames if both ports are in the same bridge domain and the VLAN carrying those BPDUs is allowed on both links.

When the switch receives its own BPDU back on the other port, RSTP detects a loop and will block one of the two ports (usually the one with the higher port ID or cost). This is because STP doesn’t care about VLAN separation here, it’s one topology for all VLANs.

So the only way STP does not block is if, the access VLAN is not allowed on the trunk, BPDUs never loop back, STP sees no loop, both ports stay forwarding.

If the access VLAN is allowed on the trunk, the MX forwards BPDUs, STP sees a loop, blocks one port.

If the trunk includes the access VLAN, RSTP will block one port. If the trunk excludes the access VLAN, STP won’t see the loop and both ports will forward (which is risky).

[iores]

Could you, please, explain in a more detail why do you consider it 'risky'?

[alemabrahao]

The risk is that without STP intervention, you have two active Layer 2 paths between the same devices, and the MX will happily forward frames between them, creating a loop that STP cannot detect.

That's all for today. 😉

[alemabrahao]

MX does not process or generate BPDUs.
If the MX receives a BPDU on one port, it treats it as normal Layer 2 traffic and forwards it out other ports in the same bridge domain (unless the MX is in routed mode and the VLANs are isolated).
So yes, if the access VLAN is allowed on the trunk, the MX will forward those BPDUs between the trunk and access port.

[iores]

And in such case, the switch will block one port?

[Ryan_Miles]

BPDUs are passed through the MX LAN ports. So your scenario is effectively like connecting a switchport to another switchport on the same switch.

Basic example.

MX LAN ports trunk, native VLAN 185, allow all VLANs.

Switchport 1 configured as trunk, native VLAN 185, allow all. Switchport 2 access VLAN 185.

Switchport 2 blocking.

This example is using a Meraki switch. Other switches may behave differently depending on what STP modes they support/are configured for.

[RaphaelL]

Both Ryan and alemabrahao are right. 

Also keep in mind that trunking on small MX behaves really weird. If you put allowed vlan ALL , this "All" only includes the vlan created on the MX. So if your switch sends BPDU on a vlan that doesn't exist , it won't be forwarded. This is the equivalent of bpdu filter and can cause nasty issues.