So I understand that PVID isn’t an industry wide technology as Cisco uses simply ‘Untagged’ to identify what VLAN a port is part of (ingress and egress) so why has Mikrotik separated it into Untagged (VLAN on egress at an access port) and PVID (VLAN on ingress at an access port)? Is there a benefit to allowing this? I can only think you would have a different VLAN Untagged to what you would on PVID but what would be the point of this?
PVID is a standards based term. It is in the IEEE 802.1Q specs. “native vlan” and “access vlan” are not; those are “Cisco” terms, and Cisco has two names for untagged vlans, depending on whether the port is a trunk (what MikroTik would call a Hybrid port) (native vlan) or an access port (access vlan).
In the strictest sense, pvid only applies to what vlan a vlan aware switch will classify untagged traffic it receives from the wire (ingress traffic) into. In practice, traffic for the vlan specified will also egress without a tag.
The underlying switch chip usually allow for multiple vlans to transmit traffic untagged on switch-port. In almost all circumstances this is not a good thing to do, but there is a configuration using “asymmetric vlans” where that feature, being able to send multiple vlans untagged from the same switch/bridge port, together with shared vlan learning (SVL) can be used to allow for creating bridge ports that are isolated at the layer 2 level. But usually there are better ways to implement port isolation (per port forwarding tables), because asymmetric vlans work only with untagged traffic, where per port forwarding works at the physical layer, and can work with vlan tagging as well (although I can’t think of any real use case where multiple vlans all isolated would be useful).
It is called asymmetric vlans, because one vlan is used in one direction, another in the other direction.
Consider
port 1 pvid 100 Untagged member of 100, 200, 300
port 2 pvid 200 Untagged member of 100, 200
port 3 pvid 300 Untagged member of 100, 300
Now an untagged device (e.g. a router LAN port) RTR1 is connected to port 1, and untagged PC2 connected to port 2 and another untagged PC3 connected to port 3. In this example, PC2 and PC3 are in the same LAN but can’t communicate with each other, but can communicate with the Router. In other words they are isolated from each other.
When PC2 sends an ethernet frame (untagged), the pvid 200 on port 2 is used to classify the traffic as belonging to vlan 200, so it can transmit only to port 1 (the router) using vlan 200. When it leaves port 1, the frame has no tag. PC3 will not see this traffic, even if it had the group bit set (the least significant bit of the most significant octet of the ethernet frame, e.g. the first bit put on the wire. This is set for both broadcast and multicast addresses.) rfc7042 OUI and reserved MAC addresses, 2.1 discusses the least 2 significant bits of the first octet - group (multicast) and local.
When RTR1 sends traffic (untagged) the pvid 100 of port 1 is used to classify the traffic as belonging to vlan 100, so it can be transmitted to both port 2 and port 3, where both of those ports are set to transmit traffic for 100 as untagged. So it RTR1 sends a broadcast frame, it will be receieve by both PC2 and PC3.
MikroTik ROS was written by engineers for engineers, and provides access to more hardware features that most vendors. But that makes it more complex to configure and there are few blade guards, so you can easily misconfigure things. MikroTik ROS is like the Woman in this picture, and something like Google wifi is the Man.
Where are you getting your info WIKI BS ??
Very helpful Buckeye, thank you! Apologies when I mentioned not industry standard I more meant that it isn’t found throughout all manufacturers as there are some (e.g. Cisco) that do the same thing just in a different way.
If I wasn’t using this for asymmetric VLANs, what would be the benefit of me using Bridge Filtering with PVIDs rather than just putting a VLAN in a bridge with an interface that I want it to be untagged for for example? I suppose if I had lots of VLANs this could get very messy.
A non-vlan-aware bridge acts like an unmanaged switch, any tagged tagged packets are treated no differently to untagged packets which is unlikely to be desired in many setups. Some devices (e.g. anything running Windows) will strip any received VLAN tags which can also cause unexpected side effects.
Also see https://help.mikrotik.com/docs/display/ROS/Layer2+misconfiguration
I think in general it is inconvenient that in VLAN configuration (e.g. in VLAN filtered bridge) there are TWO places to configure untagged ports.
In my opinion it is most convenient when under VLAN configuration, for each VLAN it is defined on which ports that VLAN is to be present, either untagged or tagged.
But setting a port as untagged port there does not (as explained above) make it working.
Fortunately, the other way around it does work: setting a PVID on a port automatically adds the port to the untagged ports for that VLAN. I guess that takes away some of the flexibility.
Anyway, it would be best when all configuration is either at the port level (as described above) or at the VLAN level (as it is now), not a mix of these.
after reading this wiki
https://wiki.mikrotik.com/wiki/Manual:Bridge_VLAN_Table
@ pe1chl
Anyway, it would be best when all configuration is either at the port level (as described above) or at the VLAN level (as it is now), not a mix of these.
agreed.
@ primeyeti
why has Mikrotik separated it into Untagged (VLAN on egress at an access port) and PVID (VLAN on ingress at an access port)? Is there a benefit to allowing this? I can only think you would have a different VLAN Untagged to what you would on PVID but what would be the point of this?
ok. you have a good point.
to put this topic simple, try to understand mikrotik as a second language, in comparison with your other vendors term :
- a port by vlan-id, it means a single port could carry more than 1 vlan. ie. vlan trunking mode.
— edit.
- a port by pvid, it means a single port belongs only to 1 vlan. as an access port.
afaik, any vlan traffic are tagged, and could be stripped off in intervlan routing scheme on each egress port, or otherwise vlans can’t communicate between them.
the thing is, in bridge topic, sometimes it is difficult to know which direction those traffic come in nor come out from the bridge perspective, hence difficult to grasp which ingress egress filtering tagging would be done.
in case of switching mode, those vlan tag are still intact, until subnet routing are needed to strip off those tag once again.
as @ mkx and other gurus have explained. those are very nice explanations 
so… as @ pe1chl said, i think if you try to do some vlan config in mikrotik with those 2 baselines, it should be easy to get along with.
in the meanwhile, let us just enjoy the mikrotik way
While I have seen this (Windows strips vlan tags) stated multiple times, I have never seen the behavior myself. It must be specific to some “smart” adapter/driver combination, or perhaps some non-default setting in windows.
I have in my lab, many trunk (hybrid in MikroTik lingo) ports/links and if I plug a Windows PC into one of these ports, it sees only the untagged vlan, and ignores all the rest. Just like it ignores any other ethertype it doesn’t know how to deal with. I have used multiple wired laptops, (Dell, Lenovo, Toshiba, MSI), multiple desktops/mother boards (Dell, Acer, Gigabyte, MicroCenter, others). I am just saying that if it was a common issue, I would have run into it. Another common report is that dumb switches strip vlan tags, and I haven’t seen one made in the last 15 years where that is true. The only cases where it happens is a vlan-aware switch that is configured with all ports set to the same pvid (usually 1, but it really makes no difference as long as they are all the same). A vlan-transparent dumb switch just does not care what is in the ethertype field, it just uses the dst mac address and its learned mac addresses to determine whether to forward to a specific switch-port or flood out all other ports.
Can you give a specific example of an Adapter/driver combination that “strips any received VLAN tags”? Because that would cause unexpected side effects.
When using wireshark on the PC, you can see the vlan tags in the received frames.
Good advice.
And being successful in networking requires being multiple (vendor) lingual. It seems that every vendor has their own configuration language.
In Windows, the handling of VLAN tags is done in each manufacturer’s driver. When you have a driver from the card manufacturer, and especially when it is a “server” grade card, the driver will have the configuration option to add a tagged VLAN and it will create a virtual “child” driver for that VLAN.
When your driver does not know about VLANs (which for some cards is true for the Windows-supplied driver, even when you can download a better one from the manufacturer), something in the Windows stack strips all VLAN tags.
So, when you connect a Windows machine to a hybrid port, you see a mix of all traffic on all the tagged VLANs.
That normally is not “a problem” at all, except when there is IPv6 RA on some of the tagged VLANs.
Then Windows will assign one or more IPv6 addresses that will not work at all.
(because it transmits only on the untagged VLAN)
I’ve seen it many times, for example on Toshiba laptops with Intel ethernet chipsets, Intel and Asus motherboards.
A quick search comes up with articles such as https://superuser.com/questions/1755413/windows-11-connects-to-separate-untagged-and-vlan-tagged-network-at-the-same-tim and https://learn.microsoft.com/en-us/answers/questions/1110923/windows-vlan-chaos-how-do-i-stop-windows-combining. Also see this discussion https://bugzilla.redhat.com/show_bug.cgi?id=1854416 and the Microsoft documentation https://learn.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords
Be aware that winpcap/npcap behaves differently to the native windows network stack - the received packets do include any tags present, but due to the way WDM is designed they may not be handled correctly by the windows network stack.
@ buckeye
A vlan-transparent dumb switch just does not care what is in the ethertype field, it just uses the dst mac address and its learned mac addresses to determine whether to forward to a specific switch-port or flood out all other ports.
you have beat me to it. i would like to give a small drawing for @primeyeti, but my tongue has made my fingers crippled 
mtik1 ---- unmanaged switch --- mtik2
|
|
Wireshark
unmanaged switch connects to Wireshark,
sees that layer 2 vlan traffic from mtik1 to mtik2. unmodified and those traffics are ok.
vlan100 ----> ingress (intervlan router : strip off 100, rewrite 200) egress ---> vlan200
interesting topic
Thanks @tdk and @pe1chl. I am still reading the links. From what I have read, it seems that the NDIS driver removes the tags but “remembers” it in out of band data. I can understand why that would be done, (to have one standard way for the rest of the stack, just like a /interface vlan does). But why would the frames with “metadata tags” all be delivered to the same logical interface? And why don’t I see that behavior.
I am not using any hypervisors. Are you?
All of the following work “correctly” when plugged into a hybrid port. By “correctly” I mean that they ignore tagged frames.
The Toshiba laptop (Satellite S855) I have (old) has this adapter:
Link speed (Receive/Transmit): 1000/1000 (Mbps)
Link-local IPv6 address: ****************
IPv4 address: 192.168.107.194
IPv4 DNS servers: 192.168.107.1
Primary DNS suffix: home.arpa
Manufacturer: Qualcomm Atheros
Description: Qualcomm Atheros AR8161 PCI-E Gigabit Ethernet Controller (NDIS 6.30)
Driver version: 2.1.0.16
Physical address (MAC): **********
Which isn’t intel.
And it is running
Edition Windows 10 Pro
Version 21H2
Installed on 5/30/2021
OS build 19044.2728
Experience Windows Feature Experience Pack 120.2212.4190.0
I Here’s an example lab config on an EdgeRouter X
If I plug into eth1 with pvid 107, I get an address from switch0.107’s dhcp server, if I plug into eth2 with pvid 101, I get an ip address from switch0.101’s dhcp server. Same as if I use a raspberry pi. Or using an old Dell Optiplex 380 with Broadcom built in Gb ethernet adapter
Link speed (Receive/Transmit): 1000/1000 (Mbps)
Link-local IPv6 address: ******************
IPv4 address: 192.168.101.196
IPv4 DNS servers: 192.168.101.1
Primary DNS suffix: home.arpa
Manufacturer: Broadcom Corporation
Description: Broadcom NetLink ™ Gigabit Ethernet
Driver version: 15.6.1.3
Physical address (MAC): ************
Or using a USB to wired ethernet adapter on OP380 (connected to another router)
Link speed (Receive/Transmit): 100/100 (Mbps)
Link-local IPv6 address: ********************
IPv4 address: 192.168.128.74
IPv4 DNS servers: 192.168.128.1
Manufacturer: ASIX
Description: ASIX AX88772 USB2.0 to Fast Ethernet Adapter
Driver version: 3.16.20.615
Physical address (MAC): **************
Here’s another USB to ether on OP380 (connected to yet another router)
Link speed (Receive/Transmit): 1000/1000 (Mbps)
Link-local IPv6 address: *****************
IPv4 address: 192.168.241.13
IPv4 DNS servers: 192.168.241.1
Manufacturer: ASIX
Description: ASIX AX88179A USB 3.2 Gen1 to Gigabit Ethernet Adapter
Driver version: 2.20.8.0
Physical address (MAC): ****************
@ pe1chl
When your driver does not know about VLANs (which for some cards is true for the Windows-supplied driver, even when you can download a better one from the manufacturer), something in the Windows stack strips all VLAN tags.
true. this was a very old topic included in mcse 2000 track. i think about 20 years ago.
well, never realized that I am that old
which states that windows only supports certain card for vlan to work. i don’t remember which intel or realtek models work at that time.
back then, the vlan type was mostly isl. and dot1q pretty much new to the environment.
but.. all in all, i pretty much don’t see any significant benefits for end devices ie. servers and desktop to have vlan implanted in their card. since server farm usually uses any other method for out of band management.
With DHCP there is no problem, because the client “asks” for an address, it of course sends the request untagged, and it enters in the VLAN configured as PVID, the reply comes back and everything works (after another message exchange).
But as I mentioned, when you have IPv6 on the LAN with SLAAC (a stupidly designed protocol!), there is no message exchange. The client “listens” for announcements from the router. It can request an immediate announcement, but when it does not there still are regular announcements sent as multicasts. In that case Windows receives such an IPv6 RA even when it was sent on a different VLAN and tagged when sent to the PC (it just strips the tag and handles it as if it were untagged), but as there is no negotiation with the router in SLAAC, the PC will just use the info from the RA to setup an address and default gateway, and will start sending traffic using that, but without using VLAN tags.
So this traffic ends up on the untagged VLAN (PVID determined) and will NOT work.
The reason I found this stupid problem is that in our company the VoIP traffic is on another VLAN than the DATA (LAN) traffic. The LAN is untagged, the VOICE is tagged.
In some cases you may want a PC to be able to handle both LAN traffic and VOICE traffic, e.g. when it is an attendant station for the phone system.
Not a problem with Linux: any network card can be used with the kernel 802.1q module for tagged VLAN traffic. Same as in RouterOS (which is Linux, after all).
Not so in Windows: when you configure the port where this PC is attached as hybrid, Windows gets confused because it receives the multicast traffic from the tagged network (e.g. IPv6 RA). And also, you cannot just configure a VLAN on any ethernet card, it must be supported (by the manufacturer) for the specific card. In our case, the onboard ethernet in our desktop machines did not come with a working VLAN-capable driver. The supplied driver in Windows does not know about VLAN at all, and the downloadable driver from the manufacturer had some bug that I forgot about (I think the issue was that it could handle a trunk but not a hybrid port).
So I had to buy a separate PCIe ethernet card from Intel. The Windows built-in driver again supports no VLAN, but there is a driver on the Intel site that does. But then you need to be careful that Windows Update does not replace it with the dumbed-down driver lateron.
So I chose to write these PCs using 2 cables each connected to an untagged port on the respective VLAN (PVID). That offers me a bit more peace of mind.
“not an optimal design”, I would say.
A small point but I recently came across this programme that solves the issue of windows update overwriting newer/better drivers, Windows Update Mini Tool (WUMT). It was written by “stupiduser” and uploaded to a Russian forum but is available via MajorGeeks in English. Further details are shown on Wikipedia.
https://www.majorgeeks.com/files/details/windows_update_minitool.html
It does not appear to contain any malware acccording to tests I’ve done. It works by carrying out its own update request but without installing anything, and then allowing you to “hide” the driver which you want to prevent from being overwritten by windows update. I’ve found it to be very effective but, of course, you will then need to carry out any new manufacturer updates manually. YMMV.
–
Renfrew
The reason I found this stupid problem is that in our company the VoIP traffic is on another VLAN than the DATA (LAN) traffic. The LAN is untagged, the VOICE is tagged.
aaa.. ok. i have forgotten about that voip thing.
are you using soft phone so you needed that vlan enable card?
simple 2 in 1 inline design, 1 cable for 2 purposes, but yet another maintenance task by the network admin.
maybe that’s why that small voip terminal is expensive?
In a way, yes. As I wrote, it is for the attendant stations. Most users have a phone with 2 ethernet ports, one to the switch and the other to the PC, and the phone itself (helped by the LLDP in the switch) goes to the VOICE VLAN and passes on the untagged LAN to the PC.
But the attendant stations are in fact using softphone as part of the attendant application that handles and dispatches the incoming calls.
I don’t use ipv6, so perhaps that is why I don’t “experience” any problem.
Are you saying if I did the following experiment, I would see my PC respond to the ARP request?
Connect the OP380 to eth2 (the port with pvid 101 and tagged 107) and ip address 192.168.101.196
Use scapy on a rpi connected to vlan eth1 (the port with pvid 107 and tagged 101) with ip address 192.168.107.174 and craft an arp request for “who has 192.192.101.196” even though this is on another subnet.
If I understood your claim, the OP380 would receive this broadcast (internally untagged, even though it arrived tagged for 107) and seeing that it was a request for its ip address, respond with its mac address? I should be able to capture with wireshark using an RB260 as network tap (or even tcpdump on the ER-x).
I will have to do this test, but I will be busy this weekend.