Without the surrounding context, those chunks of words alone cannot be translated properly. And some of them may have even been used incorrectly where you have found them.
“tagged” and “untagged”, if used when referring to a member port of a (virtual) switch, express how Ethernet frames that belong to a particular VLAN are treated as they pass through that port (details below). etherX may be “tagged” for VLANs I, J, and K, and “untagged” for VLAN L. Any use of the terms “tagged port” or “untagged port” without clearly specifying the VLAN ID(s) that are treated that way is incorrect and causes confusion.
“tagged” and “untagged”, if used when referring to an Ethernet frame, just indicate the presence or absence of the VLAN tag in the header of that frame.
A big part of the confusion comes from the fact that, depending on the context, the term “bridge” may refer to any of
- the virtual switch,
- the virtual port of a virtual switch that is internally connected to a virtual interface of a virtual router
- the virtual interface of a virtual router that is internally connected to a virtual port of a virtual switch
(as explained here).
So:
- both “bridge is VLAN tagged” and “bridge is tagged” means that frames that belong to a particular VLAN pass through the “bridge”, in the meaning “virtual port of a virtual switch”, unchanged (i.e. the VLAN tag is neither added nor removed). But it only means that if it is clearly specified for which VLANs. It may be for one particular VLAN, for a list of VLANs, even for “all VLANs” or for “all VLANs except VLAN X”, but without any specification of the VLAN(s) it relates to, it means nothing.
- “tagged ports”, “bridge ports are tagged”, “ether1 is tagged” all make sense if related to a particular VLAN or a list of VLANs, as described above.
- “VLAN tagged” - this should only refer to an Ethernet frame. A “VLAN tagged” (or just “tagged”, there are not many other types of tags out there) frame does contain the 4-byte header (the tag), inserted between the MAC addresses and the ethertype field (which is the official interpretation; Wireshark visualizes it in a different, and more systematic in my opinion, way).
- “untagged for the VLAN” - refers to a way how a bridge port handles a particular VLAN (removes the tag on egress and adds it on ingress), implying that the same port may allow frames belonging to other VLANs to pass too but keeping their tags.
- “tagged to bridge” - without the context, no idea what this might mean
The configuration alone is not enough, I’d strongly suggest to use /tool sniffer to visualize what actually happens as the frame is forwarded from the ingress port of the bridge to the egress one(s). Create a bridge for testing on a device running at least RoterOS 7.16 with two unused Ethernet interfaces (let’s assume ether4 and ether5 in the example), name it br-test, and enable “vlan filtering” on it:
/interface bridge add name=br-test vlan-filtering=yes
Make those two free Ethernet interfaces member ports of br-test (remove them from the other bridge they may be members of if necessary); make ether4 an access (untagged) port for VLAN 2 and ether5 an access (untagged) port for VLAN 3:
/interface bridge port
add bridge=br-test interface=ether4 pvid=2 hw=no
add bridge=br-test interface=ether5 pvid=3 hw=no
Connect something to each of the two Ethernet ports, as we need them to be up at L1 for the subsequent steps. That “something” must not create an L2 transparent path between the ports, so two laptops are OK, two switches not connected to each other are OK, two interfaces of a single Mikrotik device that are not bridged together are still OK, but a cable connecting ether4 to ether5 is definitely not OK.
At this moment, /interface bridge vlan print where bridge=br-test will show you three dynamic rows, for VLANs 1, 2 and 3, with a comment “added by pvid” or something similar; for those VLANs, there will be a single port in the UNTAGGED column: bridge for VLAN 1, ether4 for VLAN 2, and ether5 for VLAN 3.
Now make ether4 a trunk (tagged) port for VLANs 1 and 3, and ether5 a trunk (tagged) port for VLANs 1 and 2:
/interface bridge vlan
add bridge=br-test vlan-ids=1 tagged=ether4,ether5
add bridge=br-test vlan-ids=2 tagged=ether5
add bridge=br-test vlan-ids=3 tagged=ether4
After this step, /interface bridge vlan print where bridge=br-test will show three more rows, this time static ones, where ether4 will be in the TAGGED column for VLANs 1 and 3 and ether5 will be in the TAGGED column for VLANs 1 and 2.
Finally, attach two VLAN (sub)interfaces to br-test, with VLAN IDs 2 and 3, and attach IP addresses from visually corresponding subnets to these two VLAN interfaces and to br-test:
/interface vlan
add interface=br-test name=br-test.vlan2 vlan-id=2
add interface=br-test name=br-test.vlan3 vlan-id=3
/ip address
add address=10.11.11.1/24 interface=br-test
add address=10.22.22.1/24 interface=br-test.vlan2
add address=10.33.33.1/24 interface=br-test.vlan3
After this step, /interface bridge vlan print where bridge=br-test will show two more dynamic rows, this time with a comment “added by vlan on bridge” or alike, for VLANs 2 and 3, both with br-test in the TAGGED column.
It is critically important for the subsequent steps that the devices connected to ether4 and ether5 would not have addresses fitting to any of the above subnets. We need the ARP requests used to visualise the frame flow to remain unresponded.
Now find the MAC address of br-test - let’s say it is E6:01:23:AB:CD:EF. Create a command line window as wide as your srceen permits, and run /tool sniffer quick mac-address=E6:01:23:AB:CD:EF mac-protocol=arp in it.
In another window, run ping 10.11.11.2 count=1 . The sniffer should show you an ARP request “who has 10.11.11.2? Tell 10.11.11.1” three times:
- coming “in” (from the IP stack to the L2 stack) on br-test, with nothing in the VID column
- leaving through ether4, with 1 in the VID column
- leaving through ether5, with 1 in the VID column
Next, without stopping the sniffer, run ping 10.22.22.2 count=1 in the other window. The sniffer should show you an ARP request “who has 10.22.22.2? Tell 10.22.22.1” four times:
- coming in on br-test.vlan2, with nothing in the VID column
- coming in on br-test, with 2 in the VID column
- leaving through ether4, with nothing in the VID column
- leaving through ether5, with 2 in the VID column
And, similarly, ping 10.33.33.2 count=1 should show you the same picture again, except that the roles of ether4 and ether5 will be swapped for VID 3.