Community discussions

MikroTik App
 
User avatar
tomranson
just joined
Topic Author
Posts: 6
Joined: Wed Nov 18, 2015 9:35 pm
Location: Chard, Somerset, United Kingdom
Contact:

Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu May 04, 2017 3:00 pm

Hi all,

I have a scenario where I need to filter STP BPDU's which are egressing a bridge port on various CRS models (112/125/226 etc.); this is to prevent transmission of said BPDUs into a remote network. The remote network will also filter them on ingress, however we also need to filter on egress to be safe. This would be the equivalent to the bpdu-filter function on other vendors. Currently testing with 6.38.5 as this is our internally approved "stable" code.

The topology is as follows:

site LAN < all other interfaces << CRS >> via ether1-master > remote network (STP BPDUs must not be transmitted into this network)

Config as below to create a bridge for the CRS switch chip STP in-hardware process (which dynamically adds slave interfaces to the STP bridge). I am attempting to use bridge filter to drop all STP BPDUs (dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF) egressing ether1-master, however the bridge filter ACL has no effect (and STP BPDUs with this destination MAC address are still seen via external Wireshark on ether1-master). I have tested various filter scenarios such as no out-interface defined however there is no change in behaviour.

Code: Select all

/interface bridge
add comment="Switch chip STP bridge" name=bridge-stp
/interface bridge filter
add action=drop chain=output comment="Drop STP BPDUs egress ether1-master" dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF out-interface=ether1-master
/interface bridge port
add bridge=bridge-stp comment="Switch chip master interface" interface=ether1-master
I will appreciate any thoughts/comments :).
 
User avatar
tomranson
just joined
Topic Author
Posts: 6
Joined: Wed Nov 18, 2015 9:35 pm
Location: Chard, Somerset, United Kingdom
Contact:

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu May 04, 2017 3:26 pm

I've also now tested this bridge filter on a non-master interface (as I thought that could be a corner case), i.e. ether8 in this case. It still appears to have no effect (BPDUs are still transmitted).
 
User avatar
tomranson
just joined
Topic Author
Posts: 6
Joined: Wed Nov 18, 2015 9:35 pm
Location: Chard, Somerset, United Kingdom
Contact:

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu May 04, 2017 4:16 pm

It would appear that this (probably?) can't be achieved on a CRS bridge filter when the hardware switch chip is in play...

A switch chip ACL partially works, however it appears I cannot selectively filter the BDPUs when they egress only *specific* ports. The BPDUs are of course sourced from the switch1-cpu, however I only want to filter them out of a specific Ethernet port (ether8 in this example)

### This drops ALL BPDUs on ALL ports which is too aggressive of course

Code: Select all

/interface ethernet switch acl
add action=drop mac-dst-address=01:80:C2:00:00:00 [b]src-ports=switch1-cpu[/b] table=egress
### This would seem the logical configuration required to drop them *only* when egressing ether8, however it does not work and the BPDUs still pass.

Code: Select all

/interface ethernet switch acl
add action=drop mac-dst-address=01:80:C2:00:00:00 [b]src-ports=switch1-cpu dst-ports=ether8[/b] table=egress
### This approach, matching only the egress interface, also does not work.

Code: Select all

/interface ethernet switch acl
add action=drop mac-dst-address=01:80:C2:00:00:00 [b]dst-ports=ether8[/b] table=egress
Thoughts please anyone?
 
expert
Frequent Visitor
Frequent Visitor
Posts: 97
Joined: Sun Dec 04, 2016 1:22 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Sun Jul 15, 2018 5:26 pm

I recently observed similar issue, where BDPUs from the provider were entering my L2 network and interfering with my RSTP instance.

The following filter fixed the problem:
/interface bridge filter add action=drop chain=forward in-interface=wan dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF comment="filter (R)STP from wan"
 
joshhboss
Member Candidate
Member Candidate
Posts: 273
Joined: Thu Aug 01, 2019 2:13 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Sat Dec 31, 2022 8:06 am

Still with this problem in 2022 heading into 2023.. Been looking everywhere to try and figure it out ..
 
bernardthomas
just joined
Posts: 2
Joined: Wed Jan 04, 2023 10:00 am

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Wed Jan 04, 2023 10:03 am

This issue persists as we enter 2023. I've been trying to find an answer to this question everywhere.
 
joshhboss
Member Candidate
Member Candidate
Posts: 273
Joined: Thu Aug 01, 2019 2:13 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Wed Jan 04, 2023 3:47 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
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Wed Jan 04, 2023 7:09 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
Yes, that's the proper way to do it. And you only make your downstream/intra-AS ports/interfaces as member of the bridge. You don't put uplink to your provider as bridge member – That should always be a standalone interface, the BPDU never gets flooded or leaked to other interfaces then. This helps when my provider starts to create a broadcast storm on their end.
 
joshhboss
Member Candidate
Member Candidate
Posts: 273
Joined: Thu Aug 01, 2019 2:13 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu Jan 05, 2023 12:56 am

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
Yes, that's the proper way to do it. And you only make your downstream/intra-AS ports/interfaces as member of the bridge. You don't put uplink to your provider as bridge member – That should always be a standalone interface, the BPDU never gets flooded or leaked to other interfaces then. This helps when my provider starts to create a broadcast storm on their end.
Well that was on my switch so I could get the internet vlan Layer 2.. so just also be able to hand out Publics Layer 2. the router has the internet going to a its own independent port but it is running through that same switch that is pretty much the core for the rest of the network as well.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu Jan 05, 2023 2:15 pm

Then you filter directly on the switch itself against by using the same method I described. That's it. No BUM traffic will leak to other interfaces.
 
laca77
just joined
Posts: 14
Joined: Wed Jun 03, 2015 11:35 am

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu Jan 05, 2023 4:58 pm

Hi, my problem is similar but looks like this methods didn't resolve it.

I have 3 switches:
SW1: BPDU guard enable on all port (non Mikrotik)
SW2: MT device, there is only a bridge and all ports are a member of it, STP set to NONE
SW3: MT device, there is only a brdige, and all ports are a member of it, RSTP enable.

The network setup is
SW1 (eth1) --- (eth2) SW2 (eth4) --- (eth3) SW3

The problem is if on the SW2 the STP set to NONE, it switched the SW3 BPDU packages to the SW1 direction and because of it, the SW1 shut down own eth1 port and i have to keep this topology (need to keep the eth2 on SW2 in the bridge)

So i would like to filtering the outgoing BPDU packages on the SW2 from any port to eth2.

I tried to create a filter like this on SW2:
/interface bridge filter
add action=drop chain=forward comment="stp fiilter" dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="stp log" out-interface=ether2

But it not drop the STP packages and the counter of this filter is 0
[admin@MikroTik] /interface/bridge/filter> print stats
Columns: CHAIN, ACTION, BYTES, PACKETS
# CHAIN    ACTION  BYTES  PACKETS
;;; stp fiilter
0 forward  drop        0        0

But if i set the chain from forward to input, i can see the growing counter number and the log in the logs, but the package forwarded anyway - of couse i changed the input interface to eth4:
[admin@MikroTik] /interface/bridge/filter> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; stp filter
     chain=input action=drop in-interface=ether4 dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="stp log" 
Stats:
[admin@MikroTik] /interface/bridge/filter> print stats
Columns: CHAIN, ACTION, BYTES, PACKETS
# CHAIN  ACTION  BYTES  PACKETS
;;; stp filter
0 input  drop      184        4
Log:
00:15:22 firewall,info stp log input: in:ether4 out:(unknown 0), connection-state:invalid src-mac 6c:3b:6b:40:0c:fc, dst-mac 01:80:c2:00:00:00, eth-proto 0027
 00:15:24 firewall,info stp log input: in:ether4 out:(unknown 0), connection-state:invalid src-mac 6c:3b:6b:40:0c:fc, dst-mac 01:80:c2:00:00:00, eth-proto 0027

I tried to set the eth2 and the eth4 on SW2 to edge port yes (in every combination) but it does not helped.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Thu Jan 05, 2023 5:50 pm

Hi, my problem is similar but looks like this methods didn't resolve it.

I have 3 switches:
SW1: BPDU guard enable on all port (non Mikrotik)
SW2: MT device, there is only a bridge and all ports are a member of it, STP set to NONE
SW3: MT device, there is only a brdige, and all ports are a member of it, RSTP enable.

The network setup is
SW1 (eth1) --- (eth2) SW2 (eth4) --- (eth3) SW3

The problem is if on the SW2 the STP set to NONE, it switched the SW3 BPDU packages to the SW1 direction and because of it, the SW1 shut down own eth1 port and i have to keep this topology (need to keep the eth2 on SW2 in the bridge)

So i would like to filtering the outgoing BPDU packages on the SW2 from any port to eth2.

I tried to create a filter like this on SW2:
/interface bridge filter
add action=drop chain=forward comment="stp fiilter" dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="stp log" out-interface=ether2

But it not drop the STP packages and the counter of this filter is 0
[admin@MikroTik] /interface/bridge/filter> print stats
Columns: CHAIN, ACTION, BYTES, PACKETS
# CHAIN    ACTION  BYTES  PACKETS
;;; stp fiilter
0 forward  drop        0        0

But if i set the chain from forward to input, i can see the growing counter number and the log in the logs, but the package forwarded anyway - of couse i changed the input interface to eth4:
[admin@MikroTik] /interface/bridge/filter> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; stp filter
     chain=input action=drop in-interface=ether4 dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="stp log" 
Stats:
[admin@MikroTik] /interface/bridge/filter> print stats
Columns: CHAIN, ACTION, BYTES, PACKETS
# CHAIN  ACTION  BYTES  PACKETS
;;; stp filter
0 input  drop      184        4
Log:
00:15:22 firewall,info stp log input: in:ether4 out:(unknown 0), connection-state:invalid src-mac 6c:3b:6b:40:0c:fc, dst-mac 01:80:c2:00:00:00, eth-proto 0027
 00:15:24 firewall,info stp log input: in:ether4 out:(unknown 0), connection-state:invalid src-mac 6c:3b:6b:40:0c:fc, dst-mac 01:80:c2:00:00:00, eth-proto 0027

I tried to set the eth2 and the eth4 on SW2 to edge port yes (in every combination) but it does not helped.
Your entire topology is wrong. RSTP (or MSTP, whichever you require) should be enabled on all switches and configured correctly for all trunk ports aka non-edge ports. Fix your topology first and properly configure RSTP end-to-end.
 
laca77
just joined
Posts: 14
Joined: Wed Jun 03, 2015 11:35 am

Re: Filter STP BDPUs egressing a bridge port on CRS a.k.a "BPDU-filter"

Mon Jan 09, 2023 11:35 am



I tried to set the eth2 and the eth4 on SW2 to edge port yes (in every combination) but it does not helped.
Your entire topology is wrong. RSTP (or MSTP, whichever you require) should be enabled on all switches and configured correctly for all trunk ports aka non-edge ports. Fix your topology first and properly configure RSTP end-to-end.
[/quote]

Hi yes, this is working (RSTP + edge: yes), but i would like to do this with the bridge filter option. So i think i had to do this on the bridge filter too. So my question is that the filter has to do this things too?

Who is online

Users browsing this forum: No registered users and 15 guests