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:
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.
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”
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,