VLAN tutorial - Understanding menu "/interface bridge vlan"

[moveik]

As I noted earlier, these commands add tagging of the VLAN id to the packets which leave the bridge.

No, these commands don’t add or remove tags. These commands say that frames, tagged with VIDs configured, can pass tagged from bridge (the switch like entity) to bridge interface.

Then I got confused.
I will point out the parts which got me confused:

According to the specs, I understand that the attributes “tagged” or “untagged” do add or remove the VLAN-ID tag from the packets.
This is written in the Bridge VLAN table page - quote:

tagged (interfaces; Default: none) Interface list with a VLAN tag adding action in egress. This setting accepts comma-separated values. e.g. tagged=ether1,ether2.
untagged (interfaces; Default: none) Interface list with a VLAN tag removing action in egress. This setting accepts comma-separated values. e.g. untagged=ether3,ether4

And it is also written in the Bridge VLAN Table #Background section - quote:

Tagged/Untagged - Under /interface bridge vlan menu, you can specify an entry that contains tagged and untagged ports. In general, tagged ports should be your trunk ports and untagged ports should be your access ports. > By specifying a tagged port the bridge will always set a VLAN tag for packets that are being sent out through this port (egress). By specifying an untagged port the bridge will always remove the VLAN tag from egress packets.

…

PVID - The Port VLAN ID is used for access ports to tag all ingress traffic with a specific VLAN ID. A dynamic entry is added in the bridge VLAN table for every PVID used, the port is automatically added as an untagged port.

On the other hand, in the same page we have this:

VLAN-ids - Under /interface bridge vlan menu, you can specify an entry in which certain VLANs are allowed on specific ports. > The VLAN ID is checked on egress ports. If the packet contains a VLAN ID that does not exist in the bridge VLAN table for the egress port, then the packet is dropped before it gets sent out.

So, some parts say that VLAN ID is being added, while other parts say that VLAN ID is being checked.
Not sure which is true, but now I understand that I need to list all the existing VLAN IDs via the “/interface bridge vlan” menu to define the “bridge” as a trunk (which, consequently, would allow the bridge to process packets with those corresponding VLAN IDs).

… (bridge does tag frames on ingress on those ports due to PVID setting and does strip header on egress due to untagged membership).

Apologies for my continued confusion though doesn’t that contradict the previous sentences that you wrote?
If bridge strip header on egress due to “untagged” membership, wouldn’t it be equivalent to say that bridge adds VLAN ID tag on ingress due to “tagged” membership?

Bridge interface being configured as trunk (all tagged) port makes possible for CPU to receive packets neatly marked (with VLAN tag) …

This scenario which you described is equivalent to whatever we configure for the “Router-Switch-AP (all in one)” (as written in this comment) ?
Meaning, we configured BR1 as trunk here (the VLAN IDs 10,20 and 99 are the only VLAN IDs which exist):

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=10
add bridge=BR1 tagged=BR1 vlan-ids=20
add bridge=BR1 tagged=BR1 vlan-ids=99

?

I updated the examples on February 17th. You must have just missed the fixes for this exact sort of situation. As you’ve discovered, firmware updates have changed the [find] construct and can cause configuration issues. Basically [find] would do nothing at times depending on what had been done previous. Please uses the new configuration examples which work with v6 and v7.

Thank you! Highly appreciated.
I noticed that in my v7 I have “/interface wifiwave2” instead of “/interface wireless”, not sure why the difference exist.