Community discussions

MikroTik App
 
TheRealBernie
just joined
Topic Author
Posts: 5
Joined: Wed Jan 02, 2019 4:00 pm

cAP AC VLAN Switching - Hardware Offload

Wed Jan 02, 2019 4:47 pm

Thanks to this wiki I found I configured my Cloud Router improperly and was not utilizing hardware switching. I have recently updated this and wanted to update my cAP AC to also utilize hardware switching.

Before I updated it, it used to have a vlan interface for each vlan on ether1, then a vlan specific bridge with vlan filtering enabled with the wireless interfaces added.
After I (attempted) to change the configuration to use hardware switching, I found it only uses ether1 and ether2(not used) on the hardware switch.

With this hardware switch setup on my cAP AC, I found my wifi throughput went from 350+ mbps to about 50 mbps.
Should I go back to using vlan interfaces on a vlan bridge, or is there a better way to do this?

Thanks.
 
robtor
newbie
Posts: 39
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: cAP AC VLAN Switching - Hardware Offload

Wed Jan 31, 2024 2:05 pm

I think when looking at it's block diagram

Image

all vlan traffic and all non-vlan traffic goes through the cpu itself because of the SOC design. I think hardware offloading matters only for switching between ether1 and ether2. For using vlans with wifi you might always create vlan interfaces or use the vlan filtering.

I'm still not sure by myself which is the right approach, because the MT help mentions that QCA8327 should not use the bridge vlan filtering:
https://help.mikrotik.com/docs/display/ ... +switching
but the basic vlan configuration instead. But there's a problem with that: You cannot configure wifi interfaces within the switch menu, instead all traffic must go to cpu and then you can only use vlan interfaces for e.g. with ROS 7.13 and the wifi-qcom-ac drivers, because they don't support vlan tagging yet. I already had a thread on this configuration, maybe I can start the discussion there again to find out if there's another solution.

Then we only need to find out whether the hardware switching (/interface/switch) and vlan's on the bridge is the better solution or if the bridge vlan filtering is faster. I think both solutions are possible but still not optimal. I currently use the vlan filterung but i will try to change one of my AP's to the vlan interfaces on bridge variant for testing.



viewtopic.php?t=202476
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11438
Joined: Thu Mar 03, 2016 10:23 pm

Re: cAP AC VLAN Switching - Hardware Offload

Wed Jan 31, 2024 2:50 pm

It really boils down to the question: do you need traffic between ether1 and ether2 to be wirespeed and no impact on CPU or not?

If the answer is yes, then it's necessary to configure things on switch chip (as @robtor already mentioned). And live with basic bridge which doesn't handle VLAN tags. Since wifi-qcom-ac driver doesn't do any VLAN-related stuff, this then means adding vlan interface and additional bridge, one per VLAN in the game. All of this will pose additional burden on CPU (which already runs wifi driver and handles every single bit of traffic passing to/from radios.

If the answer is no, then it's best to go with single VLAN-enabled bridge and wifi interfaces can be simply added to it as untagged (access) ports with appropriate PVID set. As this setup is then much simpler (only single bridge instead of bridge, vlan interface and another bridge), this means a bit less of work for CPU for traffic to/from radios ... but it means work for CPU for traffic between ether1 and ether2 (mind that traffic between ether of wired ports and radios has to pass the CPU and HW offload doesn't affect it in any way).

It's a common misconception that bridge, when HW offload is active, can offload any of bridge ports. It does not, it only offloads traffic between pair of ports which are handled by same switch chip ... and radios are not handled by switch chip at all.
 
robtor
newbie
Posts: 39
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: cAP AC VLAN Switching - Hardware Offload

Sat Feb 03, 2024 2:12 pm

If the answer is yes, then it's necessary to configure things on switch chip (as @robtor already mentioned). And live with basic bridge which doesn't handle VLAN tags. Since wifi-qcom-ac driver doesn't do any VLAN-related stuff, this then means adding vlan interface and additional bridge, one per VLAN in the game. All of this will pose additional burden on CPU (which already runs wifi driver and handles every single bit of traffic passing to/from radios.
Within this setup why do we need an additional bridge per vlan? Isn't it enough to add the vlan interfaces as slaves to the main bridge? Or is this a misconfiguration scenario?
Maybe you can give a short configuration example?

If the answer is no, then it's best to go with single VLAN-enabled bridge and wifi interfaces can be simply added to it as untagged (access) ports with appropriate PVID set. As this setup is then much simpler (only single bridge instead of bridge, vlan interface and another bridge), this means a bit less of work for CPU for traffic to/from radios ... but it means work for CPU for traffic between ether1 and ether2 (mind that traffic between ether of wired ports and radios has to pass the CPU and HW offload doesn't affect it in any way).
And just for clarification, I currently run this type of configuration, but where's the difference compared to having one non-vlan-aware bridge and sevaral vlan interfaces on that bridge? Or do i confuse sth. here?


Here's an excerpt from my typical cAP configuration:
/interface bridge
add ingress-filtering=no name=brLAN port-cost-mode=short protocol-mode=none pvid=30 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether2 ] disabled=yes
/interface wifi
# managed by CAPsMAN
set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap disabled=no name=wifi2WIRELESS
# managed by CAPsMAN
set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap disabled=no name=wifiWIRELESS
/interface vlan
add comment="MANAGEMENT VLAN" interface=brLAN name=vlanMGM vlan-id=30
/interface wifi
# managed by CAPsMAN
add configuration.mode=ap disabled=no mac-address=1A:FD:74:89:44:87 master-interface=wifiWIRELESS name=wifiFON
# managed by CAPsMAN
add configuration.mode=ap disabled=no mac-address=1A:FD:74:89:44:86 master-interface=wifiWIRELESS name=wifiSMARTHOME
/interface list
add name=MGM
/interface bridge port
add bridge=brLAN ingress-filtering=no interface=ether1 internal-path-cost=10 multicast-router=disabled path-cost=10 pvid=30
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifiWIRELESS pvid=40
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifiSMARTHOME pvid=41
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifiFON pvid=42
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifi2WIRELESS pvid=40
/interface bridge vlan
add bridge=brLAN tagged=brLAN,ether1 untagged=wifiWIRELESS vlan-ids=20
add bridge=brLAN tagged=brLAN,ether1 vlan-ids=30
add bridge=brLAN tagged=brLAN,ether1 untagged=wifiWIRELESS,wifi2WIRELESS vlan-ids=40
add bridge=brLAN tagged=brLAN,ether1 untagged=wifiSMARTHOME vlan-ids=41
add bridge=brLAN tagged=brLAN,ether1 untagged=wifiFON vlan-ids=42
/interface list member
add interface=vlanMGM list=MGM
/interface wifi cap
set caps-man-addresses=172.20.0.1 certificate=CAP-18FD74894484 discovery-interfaces=vlanMGM enabled=yes lock-to-caps-man=yes slaves-static=yes
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11438
Joined: Thu Mar 03, 2016 10:23 pm

Re: cAP AC VLAN Switching - Hardware Offload

Sat Feb 03, 2024 5:32 pm

Within this setup why do we need an additional bridge per vlan? Isn't it enough to add the vlan interfaces as slaves to the main bridge?
It's really about the first sentence in my post which you chose to omit from the quote: if for some reason you can't/don't want to run bridge as VLAN-aware entity, then the setup I explained might be the only possibility.

In this kind of setup multiple bridges are necessary because it's necessary to "bridge" two ports: untagged end of vlan interface and wifi interface. And bridge does that.

And just for clarification, I currently run this type of configuration, but where's the difference compared to having one non-vlan-aware bridge and sevaral vlan interfaces on that bridge?
Non-vlan-aware bridge is ... well, not vlan aware, so e.g. it doesn't manipulate with VLAN tags. But will happily pass frames which have VLAN tags attached. If there's a need to manipulate them but neither hardware itself (e.g. switch chip) nor driver (e.g. legacy wireless driver) does that, then we can resort to using vlan interfaces and bridges. How to pipeline things together depends on what needs to be done (e.g. VLAN tags added on the way between wifi interface and main bridge).

In your example, where bridge is VLAN aware, it's this config that manipulates the tags:
/interface bridge port
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifiWIRELESS pvid=40

If bridge was not VLAN aware, then config which performs the same, is this:
/interface bridge
add bridge=brVLAN40
/interface vlan
add name=brLAN40 interface=brLAN vlan-id=40
/interface bridge port
add bridge=brVLAN40 interface=brLAN40
add bridge=brVLAN40 interface=wifiWIRELESS
(the code above replaces single line mentioned earlier)

So there's a new bridge brVLAN40 which actually passes untagged frames, in example above only between wifi interface and untagged end of vlan interface. Then vlan interface manipulates VLAN tags so that main bridge (spanning e.g. ether ports) actually passes tagged frames (without bridge being aware of that). On ether ports side it's then possible to configure VLANs (per port) in switch chip sections.
If there are several ports with same pvid set, then in the "convoluted" config they are simply added to bridge created to carry traffic of that VLAN.

As I wrote before the whole ordeal depends on a) ability for bridge to offload things to hardware (if it can, then by all means avoid doing things the way I explained above) and b) portion of traffic passing between wired ports (if volume is low, then don't do it this way, use vlan-aware bridge). When I did a quick test, hAP ac2 (which doesn't allow offload of VLAN functions from bridge to switch chip) could bridge between two ether ports at wire speed and CPU load was around 50% (so I gather it could do another pair of ports wirespeed, hard limit is 2Gbps interconnect between CPU and switch chip) with CPU resources to run decent wireless at the same time. cAP is even less problematic since it's only got two ether ports. But if device has much weaker CPU, slower interconnect and slower wireless (e.g. RB951G), then the method I'm describing might allow much better overall device performance (it's not necessary to fuss around if device runs legacy wireless as it supports manipulations of VLAN tags, so my RB951G devices don't run the ugly setup).
 
robtor
newbie
Posts: 39
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: cAP AC VLAN Switching - Hardware Offload

Sat Feb 03, 2024 5:50 pm

Thank you for that clarification. Now I understand the difference. I think with your nice explanation it should be clear for others as well. :D

Who is online

Users browsing this forum: Ahrefs [Bot], dj23 and 23 guests