good evening, I am trying to figure out whether hEX PoE can do what I want or not.
The question is simple, it seems.
I have a Mikrotik RB760iGS router which gives me internet access.
In this router I have created 4 vlans.
PPOE enters eth1
Bridge goes out of eth3 to eth24 of a Mikrotik CR326-24G-2S+ switch
On the switch/settings page of the RB760iGS router I mirrored from eth3 to eth5 for further testing.
So far everything is working perfectly.
I continued by configuring a hAP ac lite as a bridge, connected eth1 to the eth5 port of the RB760iGS router and this also works by bringing me the various vlans on the set ports.
Now the problem arises with the hEX PoE.
If I reset it by setting it as a bridge and connect its eth1 port to the eth5 port of the RB760iGS router hEX does not get the ip address from the router (192.168.88.X) but if I connect it to an internet distribution switch on my network hEX gets the ip address and works as a switch.
Does this mean that hEX PoE cannot transport incoming bridges and is only a PoE switch or am I wrong?
I would say yes you are most likely wrong, and that your configuration on or both devices is wrong.
Please post both for review.
/export file=anynameyouwish ( minus router serial number, any public WANIP information, keys )
When configuring the bridge and VLANs on the hEX PoE, don’t forget that it has a QCA8337 switch chip connecting the five ethernet ports. Which means to configure the VLANs you should use the /interface ethernet switch menu instead of Bridge VLAN Filtering.
So, in that models: C52iG-5HaxD2HaxD-TC (hAP ax2)
C53UiG+5HPaxD2HPaxD (hAP ax3)
cAPGi-5HaxD2HaxD (cAP ax)
Chateau ax
must be set
/int bri set [find] protocol-mode=none
But…
Currently, HW offloaded bridge support for the IPQ-PPE switch chip is still a work in progress. We recommend using, the default, non-HW offloaded bridge (enabled RSTP).
So on hAP ax2, hAP ax3, cAP ax and Chateau ax, is better disable hardware offload with
/int bri set [find] protocol-mode=rstp
I hadn’t noticed that the new models weren’t compatible with hardware offload…
This is turning into a dogs breakfast…
CRS3xx, CRS5xx series switches, CCR2116, CCR2216 and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621, MT7531 and EN7562CT switch chips can HW offload.
Would seem that includes also L1009, RB5009, CCR2004, RB4011, RB1011, Hex S, Hex Refresh
Newer devices in the wifi line use PHYs not chips, capax → QCA8072, ax3 → QCA8081 (ether1 only) and QCA8075
Can anyone speak intelligently on these PHYs and if they would likely be programmable in the future to be HW offloading…
In any case I still use bridge vlan filtering on these and they seem to work fine.
Is this a useful strategy in general… /ip/firewall/filter
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload**=yes** protocol**=tcp**
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload**=no**
add action=accept chain=forward connection-state=established,related,untracked
I read somewhere that fasttrack has limited resources in some cases and this is away to streamline fastrack for specific purpose…
ahh I think it was to ensure fastrack was available for TDP in hardware offloading, and not necessarily UDP, dont ask reasons just something I read…
For normal WAN - LAN usage there might be not much difference, because the offloading of the switch chip is not really being used, the CPU has to do most of the work moving packets between the off-bridge WAN port and any other on-bridge LAN ports. In case the LAN use VLAN then the switch chip might help a bit with removing / adding the headers.
What will make a difference is when you are moving data between the different ports of the same VLAN (not inter-VLAN, because then the CPU will again be involved), where only L2 switching is involved. On the devices with hardware offload that use /interface ethernet switch and /interface ethernet switch vlan, such traffic will not see the CPU. But if on those routers we use Bridge VLAN Filtering to configure the VLANs then that simple traffic between two ports of the same VLAN will need to travel to the CPU and back, and the CPU will need to do the tagging/untagging/filtering of every single frames. Which means the intra-VLAN (not inter-VLAN) switching will use the CPU similar to the routing-without-firewall case, plus any extra processing for the handling of the VLAN tags, instead of being free (CPU wise).
On Monday I’ll be able to bring another wired device to my hAP ac² at another location and will configure the bridge with VLAN in both ways and compare the throughput and CPU usage when using the bridge as L2 switch with VLAN. The hAP ac² has the Atheros8327 switch chip where it’s recommended to use /interface ethernet switch instead of Bridge VLAN Filtering.
Okay so to be accurate, the advantage of using the proper method is when you have the SAME VLAN traversing different ports on the switch ( not the wan port)
AND, the traffic is from user on one port to user on another port, on the same VLAN.
So the right question to ask the OP is what is the bulk of traffic on vlans.
a. vlans to internet
b. vlanA to vlanB
c. traffic within VLANA same port
d. traffic with VLANB same port
e. traffic within VLANA but across ports
f. traffic within VLANB but across ports
Yes, it mostly affects the switching functionality. Like when you have your NAS connected to one port of the router (maybe behind other switches), and your PC on another port (also maybe behind other switches), and both devices are in the same layer 2 network (same VLAN, same subnet let’s say 192.168.20.0/24). Now when you stream movies from the NAS to the PC, with Bridge VLAN Filtering and those old devices, the frames/packets need to be processed by the CPU (and travel up-link to the CPU and down back to the switch chip), including adding/removing VLAN tag. If instead the “switch” menu and it’s vlan submenu were used for the configuration, then no CPU power is consumed when you stream videos from the NAS to your PC, and the frames do not have to leave the switch chip to go to the CPU and back.
If traffic is inter-VLAN then in both configurations the frames will need to go to the CPU and back, and CPU has to do the routing and firewalling in both cases. But in case of Bridge VLAN Filtering the CPU also needs to do the tagging/untagging/filtering/sorting of the VLAN, while if configure with the “switch” menu such tasks are done by the switch chip.
As promised, here are some test results from my hAP ac². Two wired PCs are connected directly to ports ether2 and ether5 of the router and run iperf3 (in one direction).
First the bridge as configured by defconf is used. No VLAN is configured. 10.14.2.0/24 is the subnet of the bridge. CPU usage is minimal (not used for the transfer):
Next, a vlan312 interface is configured with Bridge VLAN Filtering, by just setting PVID on the ports, setting Frame Types, and turning on VLAN filtering on the main bridge. 10.3.12.0/24 is the subnet of the VLAN interface:
iperf3 throughput is maintained at 950Mbps without problem, but we can see that half of a core are now used (13% = 1/8 of 4 cores) because switching is now done by the main CPU. The CPU frequency is only at 50% (448MHz from 896MHz) though.
Finally, Bridge VLAN Filtering is removed. VLAN 312 is now configured with /interface ethernet switch:
CPU usage is again negligible, because now everything is handled by the switch chip again.
The hAP ac² has a quad-core ARM32 CPU @ max 896MHz, but the hEX PoE from OP only has a single core MIPSBE @ 800MHz. Assuming that MIPSBE is efficient as the ARM in the hAP ac² (can do the same amount of work per MHz, which I don’t think it’s the case), we can interpolate that not using hardware offload for VLAN on the hEX PoE may push the CPU load to
13% * 4 cores * 448MHz / 800MHz ≈ 29%
for a half-duplex 1Gbps throughput between two ports. If OP want to use his hEX PoE as a VLAN capable switch, using all 5 ethernet ports, he should definitely use /interface ethernet switch submenu for configuration. Otherwise switching will be limited by of the only available 1Gbps link between the CPU and the switch chip (this effectively only allows wire speed switching between at most two ports at the same time), and will also waste a lot of CPU.
Can you post the text export of the relevant settings for your VLAN 312, both the “bridge” and the “switch” settings, so that I can maybe understand how the “normal” bridge ones are translated into the switch ones?
According to what CGG stated, Yes! The CPU will get less loaded regardless and that should help, also the hint of changing freq may help a bit.
If the OP in question has significant vlan traffic across Ports, the change will be the most significant.
For the Bridge VLAN Filtering tests, port ether2 and ether5 has been switched to become access port of VLAN 312. I did the changes in the WinBox GUI, but it was just this:
/interface bridge port
set [find bridge=bridge interface=ether2] pvid=312 \
frame-types=admit-only-untagged-and-priority-tagged
set [find bridge=bridge interface=ether5] pvid=312 \
frame-types=admit-only-untagged-and-priority-tagged
/interface bridge
set bridge vlan-filtering=yes
Current version of RouterOS automatically creates the dynamic entries in the /interface bridge vlan table as you can see from the screenshot above, and because this was a temporary configuration, so I didn’t bother to explicitly create the static entries in /interface bridge vlan.
Moving to the configuration using /interface ethernet switch, first, the Bridge VLAN Filtering config was undone:
/interface bridge
set bridge vlan-filtering=no
/interface bridge port
set [find bridge=bridge interface=ether2] pvid=1 frame-types=admit-all
set [find bridge=bridge interface=ether5] pvid=1 frame-types=admit-all
As a result, the dynamically created entries in /interface bridge vlan also disappered. Next, I added just the changes to replicate the config above, with ether2 and ether5 being access port of VLAN 312, ether1 stays outside of the bridge and is the WAN port, ether3 and ether4 are access port of the default bridge and are not touched.
This is similar to the port assignment in /interface bridge vlan, with the difference that there is no specific tagged/untagged separation, and instead of the bridge as CPU port, we use the switch1-cpu port.
Next is something similar to the configuration on the VLAN tab of the Bridge → Ports entries.
/interface ethernet switch port
set ether2 default-vlan-id=312 vlan-mode=secure vlan-header=always-strip
set ether5 default-vlan-id=312 vlan-mode=secure vlan-header=always-strip
set switch1-cpu vlan-mode=secure
This worked and was what I used in the test. But in case of my hAP ac² with Atheros8327 and of OP’s hEX PoE with QCA8337, vlan-header is ignored anyway, and can actually be left with the default leave-as-it value. Additionally, if we want to explicitly configure ether3 and ether4 (which are member of the default bridge interface) as VLAN too (access port of VLAN 1), as well as specify the VLAN ID for the switch as 1 instead of default, we can do this instead (for Atheros8327 and QCA8337):
/interface ethernet switch port
set ether2 default-vlan-id=312 vlan-mode=secure
set ether3 default-vlan-id=1 vlan-mode=secure
set ether4 default-vlan-id=1 vlan-mode=secure
set ether5 default-vlan-id=312 vlan-mode=secure
set switch1-cpu default-vlan-id=1 vlan-mode=secure
Here is another example where ether2 is trunk port of VLAN 312, ether3 and ether4 are hybrid ports with 312 tagged and 1 (the bridge) untagged, and ether5 is access port of the bridge. Again, for Atheros8327 and QCA8337 vlan-header should always be leave-as-it, and it’s the default value, which means you don’t need to specify vlan-header, but I am still adding it for the other switch chips:
/interface ethernet switch vlan
add independent-learning=yes ports=ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=1
add independent-learning=yes ports=ether2,ether3,ether4,switch1-cpu switch=switch1 vlan-id=312
/interface ethernet switch port
set ether2 vlan-mode=secure vlan-header=add-if-missing
set ether3 default-vlan-id=1 vlan-mode=secure vlan-header=leave-as-it
set ether4 default-vlan-id=1 vlan-mode=secure vlan-header=leave-as-it
set ether5 default-vlan-id=1 vlan-mode=secure vlan-header=always-strip
set switch1-cpu default-vlan-id=1 vlan-mode=secure vlan-header=leave-as-is
