Hello, this is my first week into the Mikrotik and RouterOS world. I am having some trouble understanding VLAN Mode as described on https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features. I just have some questions about the following table describing VLAN Mode = secure:
According to the table, all untagged ingress traffic is dropped. Does this mean access ports get their data only from trunk ports? i.e. if there are two access ports with same VLAN ID, untagged traffic is not forwarded from one access port to the other?
Since I intend to have the wireless interface be in the same VLAN as one of the (access) ports, is ingress traffic from the wireless interface considered tagged or untagged? I want to use VLAN Mode = secure as much as possible to minimize traffic reaching the CPU.
Hello Jotne, thank you for the reply. Unfortunately, I’m using a hAP ac lite (RB952Ui-5ac2nD), which uses the AR8227 switch chip. So I’m actually using the switch way of implementing the VLANs.
In your thread, you use the bridge/software way wherein you use /interface bridge vlan to specify which vlans are tagged/untagged on which ports. In my case, I use /interface ethernet switch vlan and /interface ethernet switch port to do the same. It involves the VLAN Mode and VLAN Header settings as described in https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features.
So, I tried the following experiment on a hAP ac lite:
Port 1 - trunk port for VLAN2 & VLAN3
Port 2 - access port for VLAN2
Port 3 - access port for VLAN2
Port 4 - access port for VLAN3
Port 5 - access port for VLAN3
Where vlan-mode=secure for all Ports 1 to 5, vlan-header=add-if-missing for Port 1, vlan-header=always-strip for Port 2 to 5.
A laptop connected to Port 2 can successfully obtain an IP address from a DHCP server connected to Port 3.
But shouldn’t the setting vlan-mode=secure on Port 2 prevent the laptop from communicating with the DHCP server? Since the DHCP server is VLAN-unaware and therefore data from Port 3 (ingress port) is untagged, shouldn’t they be dropped since vlan-mode=secure drops all untagged ingress traffic?
And no, ether2 and ether3 are part of the same layer2 network and can communicate with each other, similarly ether4 and ether5 are another layer2 network and communicate with each other but there is no direct communication between ether2/3 and ether4/5.
Just because devices have switch chips doesn’t mean they are used for switching - unless you have a master port setup (firmware < 6.41) or a hardware accelerated bridge (firmware >= 6.41) the physical ethernet ports are presented as separate interfaces and the Mikrotik hides how the packets are actually transported from the ports to the CPU.
It might be better to explain what you are trying to achieve.
Access port means that devices connected to a particular port don’t know anything about VLANs and use untagged frames. Switch adds VLAN tag on ingress and removes VLAN tag on egress. Which is exactly what you configured with setting vlan-header=always-strip and (I presume) default-vlan-id=2.
Setting vlan-mode=secure defines that if device, connected to the port, was VLAN-aware and tried to inject frame with VLAN tag other than allowed VLANs (e.g. 666), such frame would be dropped by switch on ingress. Likewise on egress switch will not pass frames with nonallowed VLAN tags through this port. If there wasn’t defined default-vlan-id, then switch would reject untagged frames on ingress and would not untag any frames on egress.
Hello mkx, thank you for the explanations, if I may add:
Switch adds VLAN tag on ingress and removes VLAN tag on egress. Which is exactly what you configured with setting > vlan-header=always-strip > and (I presume) > default-vlan-id=2> .
You are right, I set default-vlan-id to 2 for both Ports 2 and 3. This explains how the laptop is able to get IP address from DHCP server. My mistake for missing the following stated very clearly on the wiki page:
If there wasn’t defined > default-vlan-id> , then switch would reject untagged frames on ingress and would not untag any frames on egress.
OK, so, if default-vlan-id is not specified, the AR8227 wouldn’t really know which VLAN the untagged traffic really is for, therefore reject it altogether. Similarly, it cannot untag frames on egress too, since it also doesn’t know what the native VLAN of the egress port is either.
Following is my condensed understanding of the VLAN Forwarding table in https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features, do you see any problem:
I still don’t understand what the Untagged traffic scenario refers to. Is it simply the case when default-vlan-id is not specified?
Net effect is as described in wiki (and highlited by you). However, I still want to believe that switch performs according to individual ports settings. So I believe that in your case, VLAN tag does get added on ingress (on either port 2 or 3), frame traversing switch internal paths does carry VLAN tag, but on egress (either port 3 or 2) the TAG gets removed. Reasoning: if there was a third port member of same VLAN, but that one tagged … why should ingress and egress logic on access ports change just because there’s a third port in the same VLAN that happens to be trunk port?
I don’t see any big problem in your understanding of the table. Mine is slightly different but I can’t tell which understanding is better
.
I still don’t understand what the Untagged traffic scenario refers to. Is it simply the case when > default-vlan-id > is not specified?
My understanding is that the first column of the table refers to VLAN tag of a packet (either ingress or egress) outside switch chip (e.g. on the port itself) … In case of vlan-mode=disabled or vlan-mode=fallback (which are not really VLAN-policy enforcing modes), untagged frames are treated in their own way. But in case of vlan-mode=check or vlan-mode=secure untagged frames are treated as if they were tagged with some alien VLAN id (such as -1) unless port has default-vlan-id set. If port does not have default VLAN id set, ingress logic will always result in “Tagged traffic, no VID match”, hence untagged frames will get dropped (DI).
Mikrotik has this (quite) unique feature that even when one configures VLANs on switch/bridge, untagged frames can still enter switch/bridge. The rest of universe seemingly demands that when you start to use VLANs, you have to stick to it so that inside network device, no untagged frames can live. I tend to go with that logic on Mikrotiks as well so that I don’t get sidetracked by misunderstanding of Untagged scenarios
Mikrotik has this (quite) unique feature that even when one configures VLANs on switch/bridge, untagged frames can still enter switch/bridge. The rest of universe seemingly demands that when you start to use VLANs, you have to stick to it so that inside network device, no untagged frames can live. I tend to go with that logic on Mikrotiks as well so that I don’t get sidetracked by misunderstanding of Untagged scenarios
OK, after a little rethinking, I realize it’s really possible to have untagged frames entering the bridge, such as in the following cases:
Frames from wireless interface where its vlan-mode=no-tag
Frames from VLAN-unaware ports (not present in VLAN Table?)
Basically, since it’s possible to configure a portion of the switch be to be VLAN-unaware, there must exist also a means to specify how it will interact with the remaining VLAN-aware portion.
