Bridge VLAN table represents per-VLAN port mapping with an egress VLAN tag action. The tagged ports send out frames with a corresponding VLAN ID tag. The untagged ports remove a VLAN tag before sending out frames.
So what we are doing above is specifying which vlan is allowed to travel on which interface? So in this example vlan 10,20,30,99 is allowed to travel on the interface sfp1 and sfp2, any other traffic with any other vlan tags is dropped? but if that’s so then here’s another word from the documentation specifying the tagged parameter
tagged (interfaces; Default: none) | Interfaces or interface list with a > VLAN tag adding action in egress> . This setting accepts comma-separated values. e.g. tagged=ether1,ether2.
So what are actually the tagged ports doing? is it just filtering traffics based on the allowed vlan ids? or do they also add vlan tags? I’m sorry if I failed to understand the writings here as English is not my first language
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99
I really don’t understand what this is doing, in my head I imagine bridges as a switch that connects the interface in them, so if ether1, ether2, and ether3 is a member of a bridge it is as if they’re connected together by a switch.
Why do we have to include bridge here?
Because I think that every traffic that exits from one of an interface on a bridge also counts as the traffic exiting the bridge itself. So if you have sfp1, sfp2, and ether1 - ether20 on a bridge for example, would frame that exits sfp1 also exits the bridge? because sfp1 is a part of the bridge.
Also what is the need for untagged parameter in /interface bridge vlan if the port will automatically untag tagged traffic by default?
(mod edit: post split from article to keep discussion separate. If needed/useful, can be merged again later)
My take on things:
1- what is the question ?
2- what is the question ?
3- Tagged ports are indeed filtering based on VLAN ids.
4- Your base problem here might be that you are not aware a bridge has multiple personalities as explained in this thread.
IMHO: heavy stuff, may take several readings before you really get it and I will admit I still don’t get it completely myself. RouterOS bridge mysteries explained
So here again, all frames tagged with 99 are allowed for br1, sfp1 and sfp2.
5- Default settings are not visible in export. If you set it explicitly, it will show.
And it is always better for future review that you are aware something is in effect.
While that’s all still true. Version 7.16 and above hide the “VLAN bridging complexity” better… And in @pcunite excellent guide, while still accurate, could be simplified in 7.16 and above. For example,
when you create an [Layer3/IP] /interface/vlan with it’s interface being a bridge, the /interface/bridge/vlans is dynamically (“automatically”) created (so that the bridge interface itself has to access to Layer3 VLAN via CPU). The net result being, in 7.16 the bridge does not need to manually tagged in /interface/bridge/vlan – RouterOS will do that automatically, and will show with D in /interface/bridge/vlan/print.
if you set a PVID on a /interface/bridge/port, it too will dynamically added to /interface/bridge/vlan. The net being for an “access” port, you just need to both setting the PVID on the port & frame-types=admit-only-untagged-and-priority-tagged - RouterOS will again add it a “D” value in /interface/bridge/vlan/print
the default configuration - at least in “Home AP” ones – you can actually safely set “/interface/bridge/set [find] vlan-filtering=yes” as the FIRST step. The only side-effect is a winbox session may drop but will reconnect. Reason being is the default is PVID = 1 for both the bridge and all bridge port, so the above dynamic /interface/bridge/vlan will be fully populated automatically. And then when you add /interface/vlan (and the DHCP stuff and routing stuff @pcunite also shows), you can just change the PVID for a port to use it.
manually adding anything, like per @pcunite, will remove/override any dynamically created config in /interface/bridge/vlan – so if “manual” configuration is still possible and work as it has. But, theoretically, /interface/bridge/vlan configuration only mandatory for truck port.