About parameter frame-types in bridge

RouterOS General
1

I find a little confusing the 2 parameters “frame-types”, that appear in 2 different places:

  • At the port level. This make sense to me.
  • At the bridge level. I can’t understand its function.

At the bridge level, the documentation is not very clear to me. It says: “Specifies allowed frame types on a bridge port.”. But we are not at the port level.

I see that in the examples it is configured to be “frame-types=admit-only-vlan-tagged”, but I can’t understand why.

2

It’s a long explanation that’s better explained by a few sources below.

In short, this is a feature of modern day VLAN-aware bridging using DSA in Linux networking stack. It allows you to ensure the bridge itself will accept only tagged to prevent possible VLAN leaks due to misconfig and to block native VLAN traffic or tagged/untagged for hybrid ports or accept all.

https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-42/Layer-2/Ethernet-Bridging-VLANs/Traditional-Bridge-Mode/

https://docs.kernel.org/networking/dsa/dsa.html

https://docs.bisdn.de/network_configuration/vlan_bridging.html#:~:text=The%20traditional%20bridging%20mode%20in%20Linux%2C%20created%20without%20VLAN%20filtering%2C%20accepts%20only%20one%20VLAN%20per%20bridge%20and%20the%20ports%20attached%20must%20have%20VLAN-subinterfaces%20configured.%20For%20a%20large%20number%20of%20VLANS%2C%20this%20poses%20an%20issue%20with%20scalability%2C%20which%20is%20the%20motivation%20for%20the%20usage%20of%20VLAN-aware%20bridges

https://developers.redhat.com/articles/2022/04/06/introduction-linux-bridging-commands-and-features#:~:text=and%20so%20on.-,VLAN%20filter,-The%20VLAN%20filter

3

Bridge in ROS has a few personalities without clear distinction which setting is about which personality. I suggest you to read about these perdonalities in this nice description.

Spoiler: frame-types set on bridge has nothing to do with VLANs passing bridge between ports, it’s got to do with traffic between CPU and the rest of networks.

4

Bridging in ROS is no different from bridging in Debian, RHEL, Cumulus etc. It’s Linux DSA.

I never get these half-baked explanations on the forums when it comes to Linux networking, which is what ROS is, a Linux-based CLI daemon that abstracts underlay Linux Kernel with ROS v6/v7 CLI/UI configuration daemon(s).

5

Yeah, well baked or not, new users should avoid anything fancy on the bridge unless the functionality is explicitly required.
All can be done quite easily at the ports level ( only thing needed in 99% of case on the bridge itself is to turn on vlan-filtering=yes)

6

I’m hinting at something completely different: ROS overloads bridge (as created with /interface/bridge/add …) with a few distinct functions:


  1. switch-like entity which passes L2 frames between member ports
    I guess that’s exactly what bridges in Linux and other vendors do. And this might be full story if bridge device is either unmanaged or is managed out-of-band.
  2. CPU-facing port which allows ROS (as L3+ entity) to communicate with L2 network(s) passing bridge the switch-like entity (bullet #1 above)
  3. L3 interface which is able to carry L3 traffic
    In ROS interface is always untagged. If one wants to communicate with VLANs, then one has to use vlan interfaces (or set PVID on port which then makes this port “on the far side from bridge” untagged for that VLAN). And this includes bridge port (personality #2 above).

When one understands the various personalities of bridge, it’s easier to understand how different properties (and settings) of bridge (as a whole) affect its functionality.

I don’t know how other vendors deal with items #2 and #3 above. Perhaps the same way. But (mental) dissection of ROS bridge does help one to configure bridge properly according to needs.

In particular: @OP is asking about frame-types set on “bridge level” … I’m assuming he means the setting under /interface/bridge. When one understands the 3 personalities, it becomes clear that the setting mentioned by @OP is about personality #2 above.

7

Bridge VLAN filtering options is not MikroTik exclusive:
https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge
https://docs.bisdn.de/network_configuration/vlan_bridging.html

8

Did anybody day so?