I have encountered a confusing behavior several times while configuring VLANs in RouterOS, and I wanted to ask about it because it feels limiting in some scenarios, or at least could use clearer documentation.
My scenario is:
- I want VLAN 134 to be tagged on "ether2".
- And the same VLAN 134 to work as untagged on "ether1".
- But without having to manually set a PVID on "ether1".
What I noticed is this:
If I only add "ether1" under the untagged section and "ether2" under the tagged section in the Bridge VLAN Table, the traffic does not behave as expected.
In practice, "ether2" works correctly, but "ether1" does not become untagged as expected.
However, if I set "PVID=134" on "ether1" in the Bridge Port settings and tell RouterOS to assign untagged frames to VLAN 134, then everything works correctly.
So my question is:
In RouterOS, is it always necessary to configure a PVID on a port in order to receive untagged traffic for a VLAN?
Or is there a way to make a port an untagged member of a VLAN only through the Bridge VLAN Table, without mapping incoming untagged frames via PVID?
Logically, I expected that when a port is placed in the untagged section of a VLAN, the system would automatically treat incoming untagged frames on that port as belonging to that VLAN.
If this behavior is intentional and by design, I think clearer documentation would help a lot, because it can be confusing for users who are new to VLAN filtering in RouterOS.
Yes, you should be able to set untagged traffic using /interface/bridge/vlan without apvid= on the port.
My quick guess is you may need to look at the frame-types on the port, since that may affect the behavior (e.g. it's set to "all" if pvid= does not match desired untagged).
But can you provide the config export, since it could be elsewhere (e.g. firewall and/or the /interface/list of ether1 etc.)
If you don't set a PVID on the ether1 bridge-port, then it will use PVID 1, and any untagged traffic received on the port will be assigned to vlan 1 on the switch (or virtual switch if it is being done in software). I don't know if this can be modified by a switch rule or not, but I don't think switch rules "work" in a software only bridge implementation.
Can you explain why you don't want to set the PVID manually? Is it because you only want to have one line that is controlling both functions?
If that's the case, when you set the pvid on a bridge-port, in v7.15+ it dynamically adds the vlan as untagged in the /interface/bridge/vlan line for the vlan. Before that it wasn't mandatory to add untagged, but it was only visible when you used /interface/vlan/print detail (see this) This has been true for a while (all versions of 7 that I have used). v7.15 reworked it and now gives more info about the dynamic entries, and what triggered them to be added.
You can see this with the CLI command: /interface/bridge/port/print or if you use export verbose, you will see the pvid=1 in the bridge port settings.
And it is ROS v7.16+, when you create a vlan interface under the bridge, then it will dynamically add the bridge as a tagged member for the vlan.
You can see this with the CLI command: /interface/bridge/vlan/print
With ROS v7.16+ you aren't required to use the /interface/bridge/vlan unless you want to configure a vlan that isn't being routed, i.e. just being bridged at layer 2 with no connection the routing engine (CPU). So it is still a requirement when configuring a device as a switch where only the management interface is "connected" from the CPU to the switch so the router sees only a single interface with ip address and therefore can't can't route.
The IEEE 802.1Q standard requires every bridge-port to have an non-null PVID. There isn't the requirement that that multiple vlans can't egress from a bridge-port untagged. That's a requirement for asymmetric vlans (which also requires shared vlan learning (SVL), i.e. the "key" to the mac table is just the mac address; this implies that you cannot two devices using the same mac address on two ports, otherwise there will be a lot of thrashing of the port associated with the mac address. ROS only supports independent vlan leaning (IVL), so you can't configure asymmetric vlans with ROS (at least I am not aware of a way to do it). On ROS with IVL, the lookup key for the mac address table is the mac_address+vlan_id, so it is possible to have two devices using the same mac as long as they are in separate vlans, and they won't "collide", e.g. mac abcd on vlan 5 (on port ether3) will have a different mac address table entry than mac abcd on vlan 6 (port port ether2); the mac address table will have more entries for bridge-ports that are members of mulitple vlans. The purpose of asymmetric vlans is to allow for client isolation, and ROS uses a different way to achieve that goal (switch -> port isolation -> forwarding-override)
The implicit-ness is just the other way around than you assume. If you add ether1 to the bridge and set its PVID to 134, the untagged vlan membership magically appears as "D" (dynamic).
Why the direction of the implication is this way and not the other is anyone's guess. Probably a matter of perspective on part of the developers. (The argument can of course be made that the untagged membership -> assume tagging direction fails when a port is an untagged member of multiple vlans... but that of course could be handled by forbidding it, etc.)
