Note that I manage the network in the blue box, but both red devices are not managed by me. My three managed switches are running MSTP instances, and are currently sending BPDUs through the edge ports towards the ISP-ACCESS-SWITCH. I’m using CRS326-24S+2Q+RM switches. As seen on the wiki, I can simply add a bridge filter for frames with destination 01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF. This works in GNS3, but I haven’t tried it live yet because the edge port is carrying around 7.5 Gbps of traffic, and I’m concerned the bridge filter could trigger CPU usage.
I would also like to ignore BPDUs received through this edge ports, but it doesn’t seem to be possible. I couldn’t do it even on GNS3, I’m guessing it is because of this (taken from the wiki): Dropping received BPDUs on a certain port can be done on some switch chips using ACL rules, but the Bridge Filter Input rules cannot do it if bridge has STP/RSTP/MSTP enabled because then received BPDUs have special processing in the bridge.
Apparently, there’s no way to forbid BPDU frames on those links without configuring the ISP switch. Can someone confirm this, and/or give alternatives?
At some point setting a bridge port edge=yes stops BPDUs from being sent and ignores any received. This is not mentioned in the old wiki but is in the new help pages, so not sure in which version it was introduced. It certainly works in v6.47.10 and v6.48.6, see https://help.mikrotik.com/docs/display/ROS/Bridge#Bridge-Per-portSTP.
That’s great, thanks. I had already configured the ISP facing ports as Edge Ports. But checking out the status of the port, I see the Edge Port box isn’t checked. I don’t get why:
/interface bridge port prin det where interface~"plus1-"
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 H interface=sfp-sfpplus1-TO-WAN-FIBEX bridge=bridge1 priority=0x80 path-cost=10 internal-path-cost=10 edge=yes point-to-point=auto learn=auto horizon=none hw=yes auto-isolate=no restricted-role=no restricted-tcn=no pvid=1 frame-types=admit-only-vlan-tagged ingress-filtering=no unknown-unicast-flood=yes unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no multicast-router=temporary-query fast-leave=no
/interface bridge port monitor numbers=[find interface~"plus1-"]
interface: sfp-sfpplus1-TO-WAN-FIBEX
status: in-bridge
port-number: 1
role: root-port
edge-port: no
edge-port-discovery: no
point-to-point-port: yes
external-fdb: no
sending-rstp: yes
learning: yes
forwarding: yes
root-path-cost: 42010
designated-bridge: 0xF000.00:23:8A:77:45:00
designated-cost: 42000
designated-port-number: 8
hw-offload-group: switch1
-- [Q quit|D dump|C-z pause]
i had unknown source of stp incoming in one CRS-317 ros 6.48.6 switch interface using hardware switching causing the port go in backup state, tested “edge-port yes” and don’t solve the problem, ACL rule dropping incoming BPDUs does solves problem
It certainly works with hardware offloading on the Qualcomm/Atheros chips in the smaller switches, and others have used it with successfully on some CRS devices so may be a bug in the implementation for specific switch chips.
I’m not sure if it might be a bug, I tried edge-port=yes on GNS3 and it wouldn’t go to edge-port until I put the port on the other end of the link as edge-port too. In my real life situation this would imply doing some configuration on the ISP switch. From what I’m seeing, it does not actually ignore BPDUs.
I’m guessing the expected behaviour for an edge-port implies it should go to designated port role, and stay that way. Also, setting a port as edge-port means you’re not expecting to receive BPDUs through that port, that makes me think that this is not an appropriate solution.
that sounds more like yes discover which transitions immediately to edge, sends BPDUs and will become non-edge if BPDUs are received, similar to portfast on Cisco