It seems that i'm not able to catch and drop mndp udp port 5678 broadcast traffic going out from an interface in a Brdige.

mndp is enabled on this bridge because it is a Lan bridge, But there is a Wan interface in it to bridge IPv6 (hybrid setup where i need to route IPv4 and bridge IPv6 because the provider is not allowing IPv6 routing).

I tried to use an output rule in the firewll without success. I tried with the bridge filters, without more success.

Seems like mndp is not catchable.

This seems related to the upgrade to Router OS 6.47.4. I was previously on 6.43.2.

I suspect MNDP may be sent directly from the member interfaces rather than from the bridge, which is why bridge filter cannot catch it (leaving aside that there were some endianness-related issues with bridge filter on some CPU architectures). Check which interface-list is configured as discover-interface-list under /ip neighbor discovery-settings; I suggest to define your own interface list and only add to that list the interfaces on which you want the discovery protocols to work.

I suspect MNDP may be sent directly from the member interfaces rather than from the bridge, which is why bridge filter cannot catch it (leaving aside that there were some endianness-related issues with bridge filter on some CPU architectures). Check which interface-list is configured as discover-interface-list under /ip neighbor discovery-settings; I suggest to define your own interface list and only add to that list the interfaces on which you want the discovery protocols to work.

The bridge interface is set in the discover interface list. Not the member interface.

If i disable this bridge interface in the discover list, then mndp leaking stop.

I tried to filter it with a switch rule without success neither. That is even more strange. This should works here because the switch cpu output port is after the software cpu output, according to this diagram. So any filtering here should works regardless the origin of the packet.

Here is the rule i'm using :

0 switch=switch1 ports=ether3-sw1-ISP-IPv6-INFO mac-protocol=ip protocol=udp dst-port=5678 copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""

This should drop the packet because there is no new-dst-port defined.

According to the manual :

"Changes the destination port as specified, multiple ports allowed, including a switch CPU port. An empty setting will drop the packet. When the parameter is not used, the packet will be accepted"

I did use this kind of rule before to filter other things and it was working.

I suspect that something is broken inside this version 6.47.4 for the switch filter.

If i disable this bridge interface in the discover list, then mndp leaking stop.

If so, the bridge filter rule is either incorrect or affected by the endianness issue. Can you show the rule?

I tried to filter it with a switch rule without success neither. That is even more strange. This should works here because the switch cpu output port is after the software cpu output, according to this diagram. So any filtering here should works regardless the origin of the packet.

Here is the rule i'm using :

0 switch=switch1 ports=ether3-sw1-ISP-IPv6-INFO mac-protocol=ip protocol=udp dst-port=5678 copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""

This should drop the packet because there is no new-dst-port defined.
...
I did use this kind of rule before to filter other things and it was working.

I suspect that something is broken inside this version 6.47.4 for the switch filter.

The key here is that the switch chip rules are processed at ingress. So you have to link this rule to ports=switch1-cpu to make it filter the frames carrying the MNDP packets on their way from the CPU to the wire. To make it filter only frames that egress via ether3-sw1-ISP-IPv6-INFO, you have to set new-dst-ports to a list of egress ports of the switch on which the MNDP is allowed.

The key here is that the switch chip rules are processed at ingress.

Thanks a lot i did reverse the rule. Ingress processing !

We would need a clear diagram of the switch chip signal flow in the manual to avoid mistakes like this.

With this in mind i'm able to filter traffic entering a physical interface with a switch filter rule, but i'm not able to catch traffic going from the switch CPU to an interface.

It seems that there is no Ingress filter available for traffic coming from a switch-cpu port.

It seems that there is no Ingress filter available for traffic coming from a switch-cpu port.

As you mention this, I can recall there was an issue with switch rules on the CPU port on the 8237 chip, as I could only match frames by MAC addresses there, but not by higher level headers. I suspect that this is related to the fact that on this port a proprietary tag is used, which informs the CPU what was the ingress port of the frame being egressed to the CPU, and which instructs the switch through which port to egress the frame being ingressed from the CPU. And if this is the case, it is beyond my knowledge whether the switch rules would work if properly offset by the size of this tag in RouterOS, or whether it is a design issue of the switch chip, which cannot be overcome in RouterOS.

I haven't opened a case with Mikrotik back then because a workaround was available for the particular scenario where I needed it (filtering by MAC address was sufficient); if you decide to open yours, I'd be interested in the response. In your case, preventing all traffic with destination MAC address ff:ff:ff:ff:ff:ff and source MAC address of the ether3-... from being egress via ether3-... could be sufficient, but it requires that you create a static ARP record for the IPv4 WAN gateway and that you don't need DHCP to get an IPv4 address assigned from the ISP. The trouble with a static ARP record is that if your ISP changes their gear (like mine did recently), you'll have a mystery to solve (in my case, there was a bridge filter rule linked to the MAC address of the old gateway, but the outcome was the same, everything fine but no traffic was received).

But still, can you post the bridge filter rule? If the MNDP frames are sent from the bridge interface, it must be just an issue with the bridge rule, possibly complicated by the endianness issue - what's the RB model we're talking about?

In your case, preventing all traffic with destination MAC address ff:ff:ff:ff:ff:ff and source MAC address of the ether3-... from being egress via ether3-... could be sufficient, but it requires that you create a static ARP record for the IPv4 WAN gateway and that you don't need DHCP

I tried to filter with destination MAC address ff:ff:ff:ff:ff:ff / ff:ff:ff:ff:ff:ff and source mac of ether3 without success neither.

I even tried to filter all broadcast of switch1 removing the source mac in the rule. Without success neither.

I don't need DHCP because the isp box is doing it and bridge the gateway to my RB 3011UiAs router (Router OS 6.47.4 and updated firmware to the same version number).

Anyway i'm using another port for IPv4 entering the box switch. I needed that because Wan IPv4 and Wan IPv6 ports are not in the same Bridges in Router OS. I think i did split that to make things clearer and safer.

The different bridges for each traffic explain why i need more than 1 port to enter in the ISP box (it is not possible to put an interface in two bridges at the same time). Perhaps i would have been able to create a bridge cascade (is that possible ?) containing the other bridges and filter IPv4/ IPV6 here instead of using rules scattered in Bridges rules and switch filter rules.

Anyway all is working except for this mndp traffic. It's not a big deal as i think that it does not leak deeper than the ISP box switch. And anyway i can disable it.

The complication does come from the fact that this ISP is not providing a routable IPv6. That's why i need to bridge IPv6 from all my subnetworks and from the ISP together and keep IPv4 routed with NAT.

The interesting point was to be able to create a bridged IPv6 / routed IPv4 solution with a single Mikrotik router to replace routing of the ISP box. And another interesting point was to success in using the switch filter, regardless the poor documentation and unintuitive design.

Here is the Bridge filter rule to remove IPv4 output traffic from IPv6 interfaces :

3 ;;; drop L2 and all proto different from IPv6 from Router to WAN
chain=output action=drop out-interface-list=Wans-Bridge-IPv6 mac-protocol=!ipv6 log=no log-prefix=""

Should filter mndp IPv4 traffic here isn't it ?

Anyway i'm using another port for IPv4 entering the box switch.

This is the bit I was missing. On the diagram you've posted a few posts above, you can see that the "switch decision" is only taken if hardware "offload" is permitted, and I'm afraid that the "switch decision" includes the processing of the switch chip rules. So if the "IPv6-only" uplink port is configured for hw=no on the relevant /interface bridge port row, it is well possible that this is the reason why the switch chip rule is bypassed.

So if I get you right, the "IPv6 uplink" port is part of the "IPv4 LAN" bridge, and the "IPv4 uplink" port is either a member of its own bridge or not a member of any bridge at all, correct?

Also, bear in mind that frames forwarded between two ports with hw=yes bypass any bridge filter rules as they never leave the switch chip. So if you want to do any IPv6 filtering using bridge filter rules (as I suppose), you cannot use hw=yes on the "IPv6 uplink" port.

Here is the Bridge filter rule to remove IPv4 output traffic from IPv6 interfaces :

3 ;;; drop L2 and all proto different from IPv6 from Router to WAN
chain=output action=drop out-interface-list=Wans-Bridge-IPv6 mac-protocol=!ipv6 log=no log-prefix=""

Should filter mndp IPv4 traffic here isn't it ?

If you have tested that it does remove any other traffic than IPv6 one (and the MNDP), then yes, the rule is correct but it doesn't act on the MNDP packets.

There is a hint in the manual, which suggests that the member interfaces of a bridge actually do not forward MNDP packets sent by the bridge interface but inherit the task to send them on their own from the bridge interface. Which explains why the MNDP packets do not pass through the bridge, hence bridge filter rules cannot catch them.

A remedy is described there as well: instead of adding the bridge interface to the interface-list used for discovery, put the individual interfaces to the list.

So if the "IPv6-only" uplink port is configured for hw=no on the relevant /interface bridge port row, it is well possible that this is the reason why the switch chip rule is bypassed.

i did see that too, and i tried to enable and disable hardware offload to verify if the switch filter is influenced by this setting.

But that make no difference.

I suspect that the "set new destination ports" action in the switch filter does not work if the source port is the switch CPU. Or perhaps that there is no filter available at all for this direction of traffic.

Badly, this is not documented, i think, at least in the Mikrotik help. Should be in the chip documentation nevertheless but i'm not ready to digest that.

So if I get you right, the "IPv6 uplink" port is part of the "IPv4 LAN" bridge, and the "IPv4 uplink" port is either a member of its own bridge or not a member of any bridge at all, correct?

Exact. In fact i have three entities that manage this IPv4 routing / IPv6 hybrid setup :

- A single router port for ISP IPv4, not inside a bridge because there was here no other L2 network to bridge with.

- A Bridge for the main data network, where the ISP IPv6 "main data" port is.

- A bridge for the guest data network, where the ISP IPv6 "guest data" port is.

Other subnetworks don't have IPv6 so they are only routed to the default route (SIP telephony, management and wifi Capsman backbone network for example). They don't have an ISP IPv6 port for bridging IPv6 to them.

Those three physical ports are connected to the ISP box switch. Before i bought the RB3011, i was bridging those 3 ports and filtering them in a Metarouter instance. But in the RB3011 there is no more Metarouter so to avoid a bridge cascade, i idid use three cables to the ISP box.

Another solution, i think, to remove the need for an external switch and 3 cables, would be to use a single bridge for all ports, activate Brige VLAN filter for more safety, and put VLAN interfaces on top of this bridge instead of between each bridge and each bridge port needing vlan unencapsulation .

Nevertheless this would make filtering inside this big Bridge more error prone. I did try it i think a couple years ago but gave up because of the complexity.

Anyway, soon i will change this ISP old box disaster and get a solution with routable IPv6 and direct connection to the fiber !! It's still here mainly because providers here rise their price 30% up if you upgrade with a new box.

But the story was very interesting and formative.

Thanks for the mndp interface discovery trick, i thought to this this morning and i'm going to try it.

Adding the desired bridge ports interfaces in the discover address list, and removing the Bridge interface from this list does work. No more mndp traffic on the ISP port.

Problem solved, but Mikrotik switch filter problem not solved.

I feel that switch filters inside Router OS is mostly untested, under documented and because of that not understood by users.

They can be very useful in some situations, but dangerous as well because of this bad documentation and low testing.

An example of bad testing at the development side is that Winbox 3.27 is coloring added switch rules in RED for this router or OS version. But added rules are working. Seems that this is only a Winbox display problem.