Spanning-tree

[mducharme]

Hello,

When we first started using Netonix, on firmware 1.4.2, we encountered a spanning tree issue, where when any Ubiquiti SU was rebooted, spanning tree would block the entire AP.

Since then we have had spanning tree disabled on all ports that connect to our APs. I would prefer to be able to leave it enabled, but first I wanted to find out if this issue was fixed at some point, and whether it is safe to enable spanning tree again. Please let me know.

Thanks.

[mike99]

Spanning tree should be disable on AP facing your customer, only on backbone ports.

As for you issue, never saw this. Is spannig-tree enable on Ubnt radios ?

[mducharme]

Yes, we enable spanning tree on our UBNT radios. We had numerous cases where a customer connected a hub into their radio, and then plugged the hub into itself, which would bring down the entire VLAN of customers.

[sirhc]

This is why we NEVER allow customers to have Layer 2 access to our network.

If residential customer CPE is always in router/NAT mode.

If commercial customer the CPE is in Router mode and the customer default gateway is assigned to the Ethernet side of the CPE.

Allowing customers Layer 2 access to your network is dangerous.

[mducharme]

I disagree - we use isolation going all the way back to the switch. Client isolation on all APs, switchport isolation on the Netonix, so that customers cannot contact each other directly through layer 2. Even though the customers are bridged, they are fully isolated from each other as though they were on separate VLANs - the only impact is a customer creating a loop with themselves.

We are not the same as your network - we use PPPoE and all customers get a public IP on their own router.

Or are you saying it is better to give all of our Ubiquiti radios public IPs? I think that would be worse, given the vulnerabilities that are going around. As it stands, our radios are on management VLANs etc with private addresses only so they are protected if some new vulnerability becomes known.

[sirhc]

We use access lists on the CPE to prevent access to the CPE from all but our admin IP ranges on the outside wireless interface and we also use an access list on the inside Ethernet port to prevent the customer from being able to access the CPE from inside.

We do this by adding a secret secondary IP (what UBNT calls IP aliasing) on the inside interface that only our techs know.

The tech MUST have that one allowed IP on his laptop and can only talk to the CPE UI/CLI via this secondary IP on the CPE from the secret IP that is allowed to talk to the CPE. The secondary IP is in an invalid B class so even if the customer snoops it out he must also know the only IP in that range that is allowed to talk to it.

These access lists are scripted and take seconds for the tech to implement during installation.

SO if the customer goes to the default gateway (the CPE) it rejects communications.

But hey everyone runs their network differently, do what works best for you. But i never have to worry about customers creating loops, or arp storms, or anything like that as they never have Layer 2 access only routed access to my network.

[sirhc]

Every now and then (a couple times a month) we run port probs at our network from our Amazon cloud cluster looking for any device that is accessible from the outside world.

The only thing that usually shows up is a commercial customer router or server that does not have Layer 2 access to our network anyway.

There have been a couple occasions where a tech forgot to run the script that installs the access list during installation which we quickly fix.

[mducharme]

We haven't had these hub loop problems in a few years, I think most customers have moved to switches, but we kept the STP on, just in case.

In any event, I wouldn't trust all my installers to set up the firewall correctly. I've had a few issues with devices getting misconfigured that makes me hesitant to rely so heavily on every SU getting configured in a completely correct way to ensure the security of the network.

Also, my point was that STP worked fine on our Cisco switches and our MikroTik devices where we use STP on the bridges - never had problems with them blocking a port when an SU was rebooted. That has only happened with Netonix.

[sirhc]

Well as I said it is scripted but our NOC verifies the install when the installer is finishing up and loading his truck.

You keep saying STP and not RSTP. there is a difference between STP and RSTP, by default we are set to RSTP not STP, their behavior is different you know?

If using RSTP you need to look at your RSTP settings to determine who is active Root and what happens when the customer reboots their radio and RSTP is talking deciding what to do next.

[mducharme]

Well as I said it is scripted but our NOC verifies the install when the installer is finishing up and loading his truck.

You keep saying STP and not RSTP. there is a difference between STP and RSTP, by default we are set to RSTP not STP, their behavior is different you know?

If using RSTP you need to look at your RSTP settings to determine who is active Root and what happens when the customer reboots their radio and RSTP is talking deciding what to do next.

Our NOC guys have made mistakes before - I've had 'verified' configs that a NOC guy 'double checked' that were half wrong.

We have better guys now who are by and large more careful, but we manage so much equipment with so little staff - the simpler that we make things, the less that can go wrong.

For STP, Cisco uses per-VLAN-STP and MikroTik uses RSTP. Ubiquiti has a checkbox for STP but does not allow config of the priority or any other settings - I don't know whether it is regular STP or RSTP underneath. The MikroTik running RSTP was the active root. Also, I read that RSTP and STP are supposed to be compatible with one another, so if you have a device running regular STP, it should work fine with another device doing RSTP.