Bridge with all ports. Default configuration then VLAN filtering enabled. PVID on bridge is 1, frame types are admit all.
any port, lets say port 8.
bridge/ports, open port 8 and set PVID to 108 and leave frame types to admin all and leave ingress filtering unchecked.
bridge/vlans add 108 and set port8 to untagged and set port 1 ( the trunk ) to tagged.
If I plug an AP in on a bridged port w/o any VLAN settings and CPE connected to that, then I add a second link on port 8 to the same site and connect the two together (to provide a primary and failover link for instance) then the NP’s STP will detect duplicate frames and block one of the ports.
looks like:
NP16 port 6 > AP > CPE > dumb switch
NP15 port 8 vlan 108 > ptp link > dumb switch
the logic here is that the ptp link is the primary (usually a 60Ghz) and I don’t really want to run a dedicated 5Ghz backup link so I’m just linking to a sector. Plenty of downsides but it’s a very rare situation that it’s actually used.
So what’s the fix here? Do I need to set all of the non-vlan ports to ‘admit only untagged’? How do I prevent the VLAN 108 from leaking out the other ports and causing this loop?
correct me if I’m wrong, but ingress filtering wont do anything to solve this because the VLAN that is leaking is in the VLANs table. The way I understand it, ingress filtering drops unknown VLANs that don’t exist in the VLANs table.
ok, so where do I need this, on the untagged ports? ie, leave port 8 alone (vlan 108) but do ingress filtering on all the other ports? or should I do filtering on all of the ports including 8?
I second to @tdw in that I don’t get what is the intended behaviour. From what you describe, you’ve connected two bridges by two physical links (it doesn’t matter much that one of them is a 60 GHz PtP one and the other one is a 5 GHz AP-to-CPE one), and you complain that STP cuts one of the connections - but that’s what STP has been designed for, to cut L2 loops.
So what do you actually expect? That one group of VLANs will only ever use the 60 GHz link, whereas another group of VLANs will prefer the 60 GHz one but will use the 5 GHz one as a backup if the 60 GHz one fails? Or that one group will always use the 60 GHz one and the other group will always use the 5 GHz one?
Except the old RSTP implementation on Mikrotik and Cisco’s proprietary PVST+, the STP is VLAN-agnostic so the BPDUs (STP control traffic) are always sent tagless, so VLAN filtering isn’t applicable on these frames. But you can use MSTP - both paths will be available, and each group of VLANs will only use one path at a time.
One port is assigned a vlan and the other port doesn’t have that vlan assigned so there should be no loop. I just don’t see a clear picture in the documents to filter out the unwanted vlan
Other than MSTP (and PVST+ on Cisco) spanning tree is unaware of VLANs so it will consider there to be a loop, even if the VLAN configuration on the various switch ports prevents this. If you really have no possibility L2 loops disable spanning tree.
In virtually all other switches, when you set a port to an access port on a VLAN, that’s all you do. No additional filtering etc is required because it’s implied that an access port. Since mikrotik doesn’t have an explicit access port type labeling. If you take virtually any other managed switch and set port 8 to an access port for vlan 108 and then plug port 8 into port 9, nothing happens. no stp detection etc.
This question could be more broadly asked as ‘How do you make a port and access port for a VLAN on NP16’.
Not on HPE switches - you have specific BPDU filter and guard settings which are completely separate from VLAN configuration for access/trunk ports. Having spanning tree enabled on edge ports is good for blocking loops when someone connects two sockets on an office together, for example.
Historically on Mikrotiks you had to use bridge filters to block BPDUs from being sent, or switch ACL rules to block them from being received, however according to the help pages you can now block them by explicitly setting edge=yes on interface bridge ports, see https://help.mikrotik.com/docs/display/ROS/Bridge#Bridge-Per-portSTP
I think the edge setting would just cause me issues in case of a mistake, ie an actual loop was created. Not much different than turning off STP except it’s per port instead of per bridge.
on HPE port based VLAN (ie port link-type access; port access vlan 108) actually does block BPDUs without extra filtering. I do this frequently without issue. Cisco and Juniper are similar.
That’s kind of off topic though, the question is how do I drop unwanted vlans on the NP16 and other CRS3xx series devices.
Is that a Comware thing, it wasn’t the case on Procurve (now branded Aruba) devices?
That’s kind of off topic though, the question is how do I drop unwanted vlans on the NP16 and other CRS3xx series devices.
Set ingress-filtering=yes for all of the entries under /interface bridge port, this only permits the VLAN IDs as specified under /interface bridge vlan. I don’t know why this isn’t default behaviour, it is only rarely you would wish to leak VLANs on ingress.
Bridge ports are by default access ports, their untagged bridge vlan membership is created dynamically from the pvid= setting. Adding one or more tagged bridge vlan membership makes them hybrid ports, if you specifically want a tagged-only trunk port you have to specify ingress-filtering=yes frame-types=admit-only-vlan-tagged
But the xSTP part is not off-topic - even if you configure access, trunk, hybrid ports as needed and ingress-filtering on all ports, the “loop” will still be detected by xSTP. So if you still want to use the 60 GHz path for some VLANs and the 5 GHz path for other VLANs simultaneously, you can choose between setting up MSTP, using intermediate bridges, and disabling BPDUs on the link carrying the single untagged VLAN if that is the case.