Netonix Forums

Having an RSTP problem recently where the switches are discovering a customer routers LAN port (due to customer moving cable to wrong port), so the customer router became the root bridge and so a topology change occured on a Netonix switch which is actually another site, not same site as customer connects to.

This should be impossible as I considered this from the start and everything is isolated with VLANs, I've verified before that there is no Layer 2 connectivity between customers or between sites.

or do BPDUs leak through the switches regardless of VLAN configs?

Yes customers have "layer 2 access" as all the UBNT CPEs are bridged in order to maximize performance, but each CPE has its own management VLAN per site.

Each customer then connects straight to the Mikrotik router via PPPoE.

Each AP has its own VLAN, tagged on the switches router interface, untagged on AP interface.
VLAN 1 is excluded from all interfaces on all switches.

For example in this segment of the network:

customer router -> PowerBeam M5 -> Rocket M5 -> ToughSwitch -> Mikrotik RB450G

then from ToughSwitch theres a PtP link to another site, on a tagged VLAN, to the Netonix.


So basically, the Netonix swtich at Site 1 found the customer router connected at Site 2 as the root bridge, and it still happens even if I completely disable RSTP on the ToughSwitch.

RSTP enabled on all ports of Netonix.



Netonix running firmware 1.5.2

Attached images should help

Thanks

RSTP is not aware of VLANs so your methods of isolation won't work with RSTP in this manner, you can use MSTP instead if you wish, but you probably won't want to use it on that firmware, if you follow this thread, you can see the progress we've made with MSTP but you will need to be on the latest firmware to use it. **NOTE** you need to use the 1.5.7rcX release for the latest improvements on MSTP.

Thanks Stephen, yes I just seen that thread also.

Theoretically then with MSTP, each site would be isolated but if a customer plugs into their LAN port or creates a loop then that could still bring down the vlan for that AP?

Wondering if it's better to just disable all STP on switches and just enable STP on UBNT CPEs?

I do generally recommend disabling STP if you are confident you can avoid multiple ports going to the same device in the same broadcast domain.

You should NEVER activate STP on ports facing customer. STP is not a secure protocol and you expose your network to situation like you describe. If you need STP at a customer site, you should add a demarcation device and disable STP on the port facing the customer.

mike99 wrote:You should NEVER activate STP on ports facing customer. STP is not a secure protocol and you expose your network to situation like you describe. If you need STP at a customer site, you should add a demarcation device and disable STP on the port facing the customer.

Indeed, however the problem with the ToughSwitch is that I cannot disable RSTP on a "per port" basis, I can only disable RSTP for the entire switch, and that still allows BPDU packets to get to Site 1 and hit the Netonix.

So it seems I'll have to disable RSTP on all switches.

I have more Netonix and EdgePoint S16s (EdgeMax) switches on other parts of the network, I'm not sure that disabling RSTP on the customer facing ports will prevent BPDUs from passing through?

The customer always has a bridged UBNT CPE, then either a Mikrotik or TP-Link router, some with DD-WRT.

I doubt it'll be a benefit to enable STP on the UBNT CPEs only?

LATER EDIT:

I've tested it myself tonight, disabling RSTP / STP on each customer port does stop topology changes and root bridge changes.
This works on both Netonix and EdgeMax swtiches, but not ToughSwitch since it has minimal controls, I will soon be replacing it anyway.

So the BPDU packets are either blocked or ignored it seems.

Referring back to the example diagram, for the moment I've completely disabled RSTP on ToughSwitch and on the Netonix I've disabled RSTP on customer ports and the ptp port to Site 2.

Look at your RSTP priority on your switches. Devices closer to the internet source should have lower priority value (lower = better root). This can help avoid devices at the edge (CPE) from becoming the root bridge as they should always have a higher priority value which will prevent them from becoming root.