I haven't been following MikroTik's WiFi developments since I don't really use their wireless except sometimes as a client. After reading up on recent driver changes and doing some tests, I have a question. Do I understand it correctly that when using wifi-qcom-ac, the only way to use VLANs with WiFi is to create VLANs under Bridge menu, create slave wireless interfaces, add them to VLANs as needed, and enable bridge VLAN filtering?
On something like hAP ac2 just turning on bridge VLAN filtering will disable bridging hardware offload. I have been successfully using a number of ac2's for years without wireless and with the "old" switch VLAN method to get the best performance. It appears in this particular case where I need wireless+VLANs I will lose that.
Just wanted to make sure I didn't miss anything.
Re: VLANs with wifi-qcom-ac
You are correct. Documentation in regards to your situation:
https://help.mikrotik.com/docs/spaces/R ... %22package:
https://help.mikrotik.com/docs/spaces/R ... %22package:
Re: VLANs with wifi-qcom-ac
Depending on amount of other tasks that hAP ac2 has to perform, loosing bridge HW offload may not cause loss of wirespeed (on wired ports). Quite a while ago (I guess it was in 6.47 times) I did some tests and found out that hAP ac2 was able to bridge two ethernet ports at wirespeed with HW offload disabled and CPU load was around 30% (load nicely distributed between multiple CPU cores). So I (mentally) extrapolated that to ability to bridge two pairs of ethernet ports without CPU becoming a bottleneck. If one woudl want to include the fifth port, bottleneck would be switch-CPU interconnect (which is 2Gbps full-duplex). WiFi don't load the same interconnect (only in one direction if wireless traffic is then passed to wired ports), but does use considerable amount of CPU cycles.
So yes, disabling HW offload on hAP ac2 likely means seeing much higher CPU loads, but perfromance-wise it shouldn't suffer (at least no too often).
Installing wifi-qcom-ac on hAP ac2 actually comes with a different, but pretty grave, drawback: it uses up almost entire flash storage and many users reported soft-bricking device afterwards (normal activity could cause starvation of flash storage and in that state even normal device reboot is not possible ... ROS upgrades are a lottery even if flash is not completely used up prior to start of upgrade ... etc. So either hAP ac2 should only be used as ethernet switch / AP combo (no routing) or only as wired router (without wifi-qcom-ac installed it has healthy free flash).
So yes, disabling HW offload on hAP ac2 likely means seeing much higher CPU loads, but perfromance-wise it shouldn't suffer (at least no too often).
Installing wifi-qcom-ac on hAP ac2 actually comes with a different, but pretty grave, drawback: it uses up almost entire flash storage and many users reported soft-bricking device afterwards (normal activity could cause starvation of flash storage and in that state even normal device reboot is not possible ... ROS upgrades are a lottery even if flash is not completely used up prior to start of upgrade ... etc. So either hAP ac2 should only be used as ethernet switch / AP combo (no routing) or only as wired router (without wifi-qcom-ac installed it has healthy free flash).
Re: VLANs with wifi-qcom-ac
Depending on your setup, you may be able to work around this limitation by separating hw-offloaded switch ports and wifi interfaces to different bridges. I.e. one hw accelerated bridge for wire speed switching without CPU load and one separate bridge to handle your wifi traffic and vlan tagging on the CPU.
Re: VLANs with wifi-qcom-ac
This post has the recent (7.18.1) measurements with Bridge VLAN Filtering that I made on my hAP ac² (also compared to the setup with /interface ethernet switch), no WiFi interfaces though.
viewtopic.php?t=215359#p1132188
Bridging between two ports at wirespeed with Bridge VLAN Filtering uses about 13% CPU at the minimum clock speed (448MHz, router is capable of 896MHz). About half of a core is loaded.
viewtopic.php?t=215359#p1132188
Bridging between two ports at wirespeed with Bridge VLAN Filtering uses about 13% CPU at the minimum clock speed (448MHz, router is capable of 896MHz). About half of a core is loaded.
Re: VLANs with wifi-qcom-ac
Thank you everyone, a lot of good suggestions.
I actually did some testing myself even before reading the replies. Tried iperf and copying a large file from NAS. Both mkx and CGGXANNX are correct. One CPU core was only 40-50% while 1Gbps link was saturated. I always knew ac2 is a very capable device (which is why I deployed it for several friends and have like 4 spares available
), it just continues to surprise me with its versatility.
I also discovered another possible solution. I noticed Quick Set has the option for a guest WiFi, so I tested it to see what it does. It creates two extra WiFi slave interfaces with guest SSID, adds them to the bridge, and then adds 4 bridge filters.
Since in this particular case I'm setting up an ac2 for my relatives who don't need anything fancy and don't have external APs, I might just use this approach.
I saw someone mentioning a huge switch driver (Prestera?) being part of the base OS. Maybe MikroTik will eventually find a way to split out more things. They have too many 16MB devices to ignore this issue.
I actually did some testing myself even before reading the replies. Tried iperf and copying a large file from NAS. Both mkx and CGGXANNX are correct. One CPU core was only 40-50% while 1Gbps link was saturated. I always knew ac2 is a very capable device (which is why I deployed it for several friends and have like 4 spares available
), it just continues to surprise me with its versatility.This is a good idea, I took note for myself to keep it as plan B.Depending on your setup, you may be able to work around this limitation by separating hw-offloaded switch ports and wifi interfaces to different bridges. I.e. one hw accelerated bridge for wire speed switching without CPU load and one separate bridge to handle your wifi traffic and vlan tagging on the CPU.
I also discovered another possible solution. I noticed Quick Set has the option for a guest WiFi, so I tested it to see what it does. It creates two extra WiFi slave interfaces with guest SSID, adds them to the bridge, and then adds 4 bridge filters.
Code: Select all
/interface bridge filter
add action=drop chain=forward in-interface=wifi3
add action=drop chain=forward out-interface=wifi3
add action=drop chain=forward in-interface=wifi4
add action=drop chain=forward out-interface=wifi4
Thanks for pointing out, I did see discussions about that. I've been using one ac2 as a wireless client with wifi-qcom-ac package installed. With 7.18.2 it has 276 KiB free space, no issues so far. I've been keeping an eye on it, and it has been the same for quite some time now. I don't have anything writing to flash. I know one thing that is being written to disk with default configuration is DHCP leases. But it can be disabled. I suspect this is what causes space issues for many people. But definitely something to watch out for.Installing wifi-qcom-ac on hAP ac2 actually comes with a different, but pretty grave, drawback: it uses up almost entire flash storage and many users reported soft-bricking device afterwards
I saw someone mentioning a huge switch driver (Prestera?) being part of the base OS. Maybe MikroTik will eventually find a way to split out more things. They have too many 16MB devices to ignore this issue.
Re: VLANs with wifi-qcom-ac
Yesterday I was studying the Mikrotik docs on all the information on how to properly setup VLAN on devices with Atheros8327 switch-chip on a CAPsMAN and a CAP using wifi-qcom-ac package. Some questions arised and I found this topic by coincidence and found the comparison very helpful. But as already written, you only compared the switching performance - and not how it affects the wifi ports. And this is something I still need to find out.This post has the recent (7.18.1) measurements with Bridge VLAN Filtering that I made on my hAP ac² (also compared to the setup with /interface ethernet switch), no WiFi interfaces though.
viewtopic.php?t=215359#p1132188
Bridging between two ports at wirespeed with Bridge VLAN Filtering uses about 13% CPU at the minimum clock speed (448MHz, router is capable of 896MHz). About half of a core is loaded.
In the WIFI docs for VLAN + CAP using "wifi-qcom-ac" package they use the bridge method. And I am asking myself if it could improve or make sense to additionally configure VLANs on "/interface ethernet switch" as well? Or is this unnecessary as wifi interfaces traffic go through CPU either way?
Re: VLANs with wifi-qcom-ac
In the WIFI docs for VLAN + CAP using "wifi-qcom-ac" package they use the bridge method. And I am asking myself if it could improve or make sense to additionally configure VLANs on "/interface ethernet switch" as well? Or is this unnecessary as wifi interfaces traffic go through CPU either way?
WiFi traffic is handled by CPU anyway. If bridge (as a whole) has to do anything with frames (e.g. VLAN header manipulation which wifi-qcom-ac driver can't do by itself), then it will be CPU executing code to get those things done. If traffic continues through wired ports, then bridge (the software part) will pass frames to switch chip via CPU-switch interconnect. Then, if bridge is HW offloaded, switch chip might perform some additional tasks (e.g. VLAN header manipulation if actually used port is access port for the involved VLAN).
But most of hard work will be done by CPU. And that's true regardless the way VLANs are handled in any particular device (e.g. entirely in software if bridge isn't offloaded and switch chip configuration is not exposed ... or mostly in software if bridge is not offloaded but switch chip is configured using /interface/ethernet configuration ... or still mostly in software if bridge is HW fully offloaded).
Which means that traffic, which is touching wifi, will load CPU more or less. Setting VLANs in switch chip menus only really helps for wired-only traffic ... and if one does configure device in this manner, then wifi configuration has to be adjusted to it. Once I tried to do it this way on my hAP ac2 ... but ended up with a bunch of bridges (one per VLAN used by radios), it was ugly (to put it mildly). The problem went away due to tight flash disk which mandated removal of wifi functionality on that particular device.
Re: VLANs with wifi-qcom-ac
So basically: on a 0815 CAP traffic usually enters on ether1, goes straight via CPU to wifi interfaces - and back. There is no switch offload possible anyway, right? May be a different case, when someone connects something on ether2 on a "cap ac" and does vlaning. In such a case, does this mean you have to do "combine" bridge and ethernet/switch? Or better stick to "bridge way" to avoid invalid configuration?
Re: VLANs with wifi-qcom-ac
Right.So basically: on a 0815 CAP traffic usually enters on ether1, goes straight via CPU to wifi interfaces - and back. There is no switch offload possible anyway, right?
You can combine bridge and switch ... but since wifi-qcom-ac can't work with VLAN tags, things get very complicated with connecting all the wifi interfaces to correct VLANs. As I mentioned, it can be done by using a number of bridges ... which then adds a bit of overhead to processing of traffic via wifi ... but allows for full hardware processing of traffic between wired ports. So it's a trade-off with regard to CPU utilization (which is better depends on amount of traffic: purely wired vs. wifi) and it makes configuration a mess.May be a different case, when someone connects something on ether2 on a "cap ac" and does vlaning. In such a case, does this mean you have to do "combine" bridge and ethernet/switch? Or better stick to "bridge way" to avoid invalid configuration?
And things get even uglier if the cAP in question is a CAPsMAN client. In such case it's only sensible to go with software bridge solution and accept the CPU load for wired-only traffic.
Or use some ax device as AP.
Re: VLANs with wifi-qcom-ac
The day Mikrotik releases the real successor of "cap ac" - I replace my cap ac in a second. They made a "wap ax" that looks like "wap ac". But they designed a "cap ax" that looks like an UFO or oversized smoke detector - instead of keeping the "cap ac" looks.Or use some ax device as AP.
Re: VLANs with wifi-qcom-ac
Day before yesterday we finalized an install in a shop which is being completely restyled. I had 3 wap AX foreseen there as APs.
The technician commented he liked the cap AC form factor we used in some other shops a lot more since it is much more discrete (I always change the round case for the square version).
I didn't show him cap AX yet
The technician commented he liked the cap AC form factor we used in some other shops a lot more since it is much more discrete (I always change the round case for the square version).
I didn't show him cap AX yet
Re: VLANs with wifi-qcom-ac
I don't think using VLAN tagging via the switch menu along with bridge VLAN filtering would help with performance. The minute you enable VLAN filtering on the bridge, all its ports lose hardware offload. This happens even before configuring any VLANs, and the mere fact of no HW offload is what loads the CPU.In such a case, does this mean you have to do "combine" bridge and ethernet/switch? Or better stick to "bridge way" to avoid invalid configuration?
Re: VLANs with wifi-qcom-ac
How did you make interfaces in different bridges communicate between each other? Wouldn't creating a separate bridge create an isolated L2 domain? Let's say, I want ether2 in bridge1 and ether3 in bridge2 be part of the same VLAN. I'm just trying to learn as these little problems improve my networking understanding.Once I tried to do it this way on my hAP ac2 ... but ended up with a bunch of bridges (one per VLAN used by radios), it was ugly (to put it mildly).
Going back to what @whatever suggested, couldn't I create just one extra non-offloaded bridge, add many wireless interfaces (each with its own SSID), and use VLAN filtering on it? It should work for WiFi-only VLANs, but how do I make them a part of wired VLANs also?
Re: VLANs with wifi-qcom-ac
How did you make interfaces in different bridges communicate between each other? Wouldn't creating a separate bridge create an isolated L2 domain? Let's say, I want ether2 in bridge1 and ether3 in bridge2 be part of the same VLAN.Once I tried to do it this way on my hAP ac2 ... but ended up with a bunch of bridges (one per VLAN used by radios), it was ugly (to put it mildly).
Different bridges span VLAN "sub-interfaces". Example for AP with only 2 ethernet ports (e.g. cAP ac):
Code: Select all
/interface/bridge
add name=bridge # "wired" bridge, no VLAN filtering, that's done via ethernet/switch config
/interface/bridge/port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2
/interface/ethernet/switch/port
# ether1 is trunk port
# ether2 is access port to main VLAN (VID 100)
# switch1-cpu interconnect is trunk because of guest wifi
set [ find name=ether1 ] vlan-header=leave-as-is vlan-mode=secure # vlan-header setting leave-as-is is default
set [ find name=ether2 ] default-vlan-id=100 vlan-header=always-strip vlan-mode=secure
set [ find name=switch1-cpu ] vlan-header=leave-as-is vlan-mode=secure
/interface/ethernet/switch/vlan
add independent-learning=yes ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=100
add independent-learning=yes ports=switch1-cpu,ether1 switch=switch1 vlan-id=200
# VLAN interfaces off the "wired bridge"
/interface/vlan
add interface=bridge name=b-v100 vlan-id=100
add interface=bridge name=b-v200 vlan-id=200
# now the VLAN-bridges
/interface/bridge
add name=vb100
add name=vb200
/interface/bridge/port
add bridge=vb100 interface=b-v100
add bridge=vb200 interface=b-v200
# and IP config ... let's say VLAN 100 is main/trusted/management and VLAN 200 is guest
# If this device is AP, then it only needs IP address in VLAN 100
/ip/dhcp-client
add interface=vb100
# finally add wifi interfaces to appropriate vlan-bridge
# let's say that wifi1 is configured as main LAN SSID and wifi2 is configured as guest LAN SSID
/interface/bridge/port
add bridge=vb100 interface=wifi1
add bridge=vb200 interface=wifi2
The main bridge ("wired" bridge) overlays switch chip ports (and is direct replacement of "master port" as known before ROS 6.41 when bridge as we know it now was born). Other bridges are then there to span VLAN-unaware L2 interfaces (e.g. wifi interfaces) with (tagged) main bridge.
If there's a non-ethernet interface which does "speak" VLANs, it should be atrached to "wired" bridge. Hypothetical example is wifi interface from wifi-qcom package and configured vlan-id (I'm not aware of AX device with switch submenu exposed). And realistic example is wireless interface from legacy wireless package with configured use-vlan=yes and vlan-id (e.g. hAP ac2 running wireless driver).
couldn't I create just one extra non-offloaded bridge, add many wireless interfaces (each with its own SSID), and use VLAN filtering on it?
It might be possible, I never tried. It would work if it's possible to add "wired" bridge (the "switch-facing interface") as trunk port of "vlan-aware bridge". But at the back of my mind there's a thought that bridge interface can not be attached to another bridge as port.
Re: VLANs with wifi-qcom-ac
Thanks! The configuration shown is very informative for me. 
Re: VLANs with wifi-qcom-ac
Thank you for taking time to share your configuration. However, it reminded me of something I saw in RouterOS documentation. Isn't it very similar to configuration shown here?:Different bridges span VLAN "sub-interfaces".
https://help.mikrotik.com/docs/display/ ... einabridge
Either way, it is ugly indeed like you said.
After making my last post, I decided to run some more tests. I tested two ways of configuring guest WiFi.
All tests were done within LAN, nothing going over the firewall, just L2.
Running iperf3 on iPhone to a wired server, a single stream.
Baseline: ~600Mbps
Scenario 1: bridge filters for guest WiFi, no VLANs
WiFi: 419Mbps, one core is 100%
Multiple iperf streams can reach the baseline throughput since more cores are involved
Scenario 2: bridge VLAN filtering
WiFi: 622Mbps, one core is 90%, CPU is not the bottleneck
It turns out merely have those 4 bridge rules affects max throughput over WiFi much worse than VLAN filtering. The rules don't even have anything to do with the wireless interface I was connected to, but the bridge still has to process them.
However, in real world WiFi throughput will be less (I tested 3 meters away from the router), so I would say either approach should work well for my case.