Bridge port egress stop STP/BPDU

jormerod · Wed Jun 10, 2020 4:47 pm

Hi,

We have a CRS326 which we have connected to a peering exchange however they are seeing lots of STP traffic from our network.

I have disabled STP on the bridge and also set the bridge port Edge=Yes. This has had no effect and STP is still being sent to the IX.

Having googled, it appears a bridge filter maybe the way to go but this also didnt work.

Can anyone throw any light on this as it really shouldn't be this difficult

Here's our config :-

/interface bridge
add admin-mac=B8:69:F4:32:CA:AA auto-mac=no name=bridge protocol-mode=none vlan-filtering=yes

/interface ethernet

set [ find default-name=sfp-sfpplus1 ] auto-negotiation=no comment="IX Exchange"
set [ find default-name=sfp-sfpplus2 ] speed=10Gbps

/interface bridge filter
add action=drop chain=forward dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="STP DROP" out-interface=sfp-sfpplus1

/interface bridge port
add bridge=bridge comment=defconf edge=yes interface=sfp-sfpplus1 pvid=150

/ip neighbor discovery-settings
set discover-interface-list=none

/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus2 untagged=sfp-sfpplus1 vlan-ids=150

AlexT · Wed Jun 10, 2020 5:14 pm

...
/interface bridge filter
add action=drop chain=forward dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="STP DROP" out-interface=sfp-sfpplus1
...

make this:
/interface bridge filter
add action=drop chain=output dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="STP DROP" out-interface=sfp-sfpplus1

Nevon · Sat Jan 23, 2021 12:47 am

...
/interface bridge filter
add action=drop chain=forward dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="STP DROP" out-interface=sfp-sfpplus1
...
make this:
/interface bridge filter
add action=drop chain=output dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="STP DROP" out-interface=sfp-sfpplus1

I have tried with this according to wiki and this.. but if I enable the output filter I loose connectivity thru that port... what do I do wrong?..

mducharme · Thu Jul 29, 2021 4:51 am

I've found an issue when using dst-address mac matching in the bridge filter:

dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF

That setting actually matches a lost of destination mac addresses that do not match that. If I log the rule I end up seeing a lot of packets matching other destination mac addresses. It seems to be some kind of bug in the bridge filter.

I have found instead the following filter does the trick:

/interface bridge filter add 802.3-sap=0x42 action=drop chain=output comment="Filter STP" mac-protocol=length out-interface=sfp-sfpplus1

The keys there are mac-protocol=length which means an 802.3 frame where the bytes that normally hold the ethertype hold a length instead, and when that is used, the 802.3 SAP field is 0x42 (which is the protocol identifier for Spanning Tree Protocol). In many ways this should be better than matching the MAC as Cisco PVST uses a different MAC and you would need two rules for the bridge filter. But it seems to be definitely a bug that the dst-mac-address bridge filter matcher is matching packets that it should not.

Guscht · Mon Nov 22, 2021 6:13 pm

I have found instead the following filter does the trick:
Code: Select all
/interface bridge filter add 802.3-sap=0x42 action=drop chain=output comment="Filter STP" mac-protocol=length out-interface=sfp-sfpplus1
The keys there are mac-protocol=length which means an 802.3 frame where the bytes that normally hold the ethertype hold a length instead, and when that is used, the 802.3 SAP field is 0x42 (which is the protocol identifier for Spanning Tree Protocol). In many ways this should be better than matching the MAC as Cisco PVST uses a different MAC and you would need two rules for the bridge filter. But it seems to be definitely a bug that the dst-mac-address bridge filter matcher is matching packets that it should not.

Thank you mducharme, this is genius.
This "bug" broke my whole network in random time intervals.

joshhboss · Wed Mar 23, 2022 1:16 am

I've found an issue when using dst-address mac matching in the bridge filter:

dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF

That setting actually matches a lost of destination mac addresses that do not match that. If I log the rule I end up seeing a lot of packets matching other destination mac addresses. It seems to be some kind of bug in the bridge filter.

I have found instead the following filter does the trick:
Code: Select all
/interface bridge filter add 802.3-sap=0x42 action=drop chain=output comment="Filter STP" mac-protocol=length out-interface=sfp-sfpplus1
The keys there are mac-protocol=length which means an 802.3 frame where the bytes that normally hold the ethertype hold a length instead, and when that is used, the 802.3 SAP field is 0x42 (which is the protocol identifier for Spanning Tree Protocol). In many ways this should be better than matching the MAC as Cisco PVST uses a different MAC and you would need two rules for the bridge filter. But it seems to be definitely a bug that the dst-mac-address bridge filter matcher is matching packets that it should not.

Would this help me here?
and keep hardware offloading enabled?

kriszos · Wed May 18, 2022 7:26 pm

I have found instead the following filter does the trick:
Code: Select all
/interface bridge filter add 802.3-sap=0x42 action=drop chain=output comment="Filter STP" mac-protocol=length out-interface=sfp-sfpplus1

This solution stopped to work after updating to 6.48+ BPDU frames are still received by other side. I got BPDU guard enabled and it disable forwarding on this interface. "bpdu-guard disabling eoip-tunnel due to received bpdu"

Zacharias · Wed May 18, 2022 8:36 pm

Everything you need to know is here https://help.mikrotik.com/docs/display/ ... eedgeports

Create Edge ports so that you restrict the port from sending BPDUs and ignore the received ones :

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1 edge=yes
add bridge=bridge1 interface=ether2

Drop Received BPDUs:

/interface ethernet switch rule
add dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF new-dst-ports="" ports=ether1 switch=switch1

kriszos · Wed May 25, 2022 2:10 pm

Everything you need to know is here https://help.mikrotik.com/docs/display/ ... eedgeports

Thank you. I think that when i first implemented my solution edge port feature was broken, now it is working as expected.

joshhboss · Sat Dec 31, 2022 8:08 am

didn't work for me.. followed everything in the links

joshhboss · Wed Jan 04, 2023 3:40 pm

This worked for me after working with support.

RouterOS supports the standardized M/R/STP protocols, and you can select which ports will not participate in the spanning tree using "edge=yes". So these ports will not send and ignore standardized BPDUs (01:80:C2:00:00:00).
However, RouterOS does not support proprietary PVST, so software and HW-offloaded bridges will simply flood these BPDUs (01:00:0C:CC:CC:CD) just like regular multicast traffic. Depending on your network and what protocols are used, you can select which ingress ports will drop these packets if you do not want them to be forwarded.
Best regards,

add dst-mac-address=01:00:0C:CC:CC:CD/FF:FF:FF:FF:FF:FF new-dst-ports="" ports=combo1,combo2,sfp1,sfp2 switch=switch1

agilbett · Mon Jan 08, 2024 7:05 am

Hi,

Just posting for completeness, when you set edge=yes it stops emitting BPDU's. This was tested in 7.13 with wireshark.

Bridge port egress stop STP/BPDU

Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Re: Bridge port egress stop STP/BPDU

Who is online