Bridge filters and vlan tags

RouterOS General
1

I work in school and I (did) filtered multicast/broadcast packets whit bridge filters on every AP we have - until we started using vlans. It is recommended, because mcast and bcast traffic can take quite a lot of airtime in hi dense networks, as hundreds of devices broadcast their mcast groups and broadcasting services they have (Dropbox sync for example). Most of devices on network do not need to know this (also security aspect) or care, so its just wasted transmissions. You can use that airtime for meaningful data.

Functionality in general is simple - its a zero trust type of function whit whitelist. For example, we have two main vlans - one for administration, other for students and guests. On administration vlan I allow mcast fully, so colleagues can find printers, Apple TVs, TVs, interactive boards for casting from tablet etc, but block almost all bcast. ( bcast minimum you need to allow is arp protocol and DHCP related frames (I hope I’m not forgetting something), rest is unneeded traffic for us) Student/guest network have completely blocked mcast and bcast is blocked the same way as administration vlan. Students don’t need to find each other devices or any devices administered by school (yes, vlans do separate printers from students already, but in general).

Creating filters whit out vlans are quite easy, you create allow filters you need and block filter at the end. vlans are not that simple… As far as I can tell, vlan tag is the issue here. Filter cant decapsulate vlan tag, as result filter cant filter out needed frames. Lets look at example filter:


/interface bridge filter
add action=passthrough chain=forward ip-protocol=udp mac-protocol=ip out-interface-list=VLAN20

Simple filter rule, that filters out all UDP traffic in out direction and passes it thru. I use it to see if filter work, as count goes up it initially works. But when I change it to in direction:


/interface bridge filter
add action=passthrough chain=forward in-interface-list=VLAN20 ip-protocol=udp mac-protocol=ip

It no longer counts any packets… In this case frames are filtered on wifi interfaces (VLAN20 is a wifi interface group). As frames are coming in wifi interface they do not have any vlan tag, so they can be processed correctly, but if they are coming from network side, they have vlan tag and that cannot be processed by filter, as filter cant decapsulate vlan tag as I mentioned before.

In attachments I added one of our APs full config (sanitized a bit), we use ac lineup devices whit ww2 driver, so configuration is what it is.


Any comment from staff or forum members how to get these filters working again when vlans are used? Maybe I don’t know proper solution for this and there might be a way already, so do please comment. This is why I raise this question in forums, not created ticket/improvement request in support portal.
AP.rsc (7.66 KB)

2

I asked about that before, and the answer was that it cannot be done. The bridge filters see the VLAN-tagged packets, so the filters act upon the VLAN tag, not the IP header. And you cannot add a VLAN tag into a filter (for the purpose of filtering A VLAN-tagged packet with some specific content).

In your use case it may be possible to do filtering anyway, as a multicast packet has some specific destination MAC address and you can filter on that, even for a VLAN tagged packet (the header sequence is MAC, VLAN, IP).

3

I’m more interested to get bcast filters working, but principal is the same. If there is no option to get filters working in native way, then vlan have to be decapsulated for filters to work. I did tried to make more bridges and add them under main bridge, but at the end I noticed that solution mentioned in L2 misconfiguration page in wiki, so its a no go. Also you need to take into consideration processing overhead, if solution is complex it will add latency and CPU load.

4

Yes, when you make separate bridges on the VLAN-interface side of the main bridge, it can be done.
I know it is mentioned as not optimal, but I have done it for ages and have not noticed any performance problem.
I started doing this before the VLAN-aware bridge and the interface list was introduced and it still remains in some of my config.
At that time, for every outside connection I made a separate bridge, which has the advantage that you can put all your configuration on that bridge, and do not have to change much when you want to use a different physical port.
E.g. I would have a bridge-internet which would have 1 ethernet port only, it would be set to “fast forward” and no STP.
That means that when I want to use another port, e.g. SFP, I can just change that one bridge port and all is done, instead of having to go all through the configuration. Very convenient, and it works well.

As the internal networks are on a VLAN trunk, there I have a VLAN-aware bridge and a couple of VLAN subinterfaces, each with a bridge on them. That allows me to do the filtering that you want as well, as I can apply filters to these separate bridges. So it can be done, if you really want it.
The “1-port bridges” should not be the one which gets the hardware acceleration, so make sure that remains on your main bridge.

5

Most realistic way how to get it working as concept is this: Layer2 misconfiguration - RouterOS - MikroTik Documentation . But issue as mentioned is bridge table - one MAC address lands in two interfaces.

6

In my case I always have only one port in those special bridges, and the bridge gets the MAC address of that only port (I did not set an admin MAC).
In the case of the VLANs I have 5 bridges on them, and they all have the same MAC (because a VLAN as the same MAC as the parent).
This has never caused any problem so far, both on RouterOS v6 and v7.
Of course it is possible to make configurations that cause problems, true.
But it is also true that the “solution of all problems” as described on that page (the VLAN-filtering bridge with all ports and all VLANs as members) does not solve the problem you mentioned in this topic (having bridge filters for specific traffic on VLANs), while having a separate bridge for each VLAN does solve that.