Hi,
I have an hAP ac2 with RouterOS 7.7 and I have the following two rules at the beginning of my firewall rule base, as explained on the documentation in Offloading Fasttrack Connections section here:
/ip/firewall/filter> export
# feb/18/2023 10:28:09 by RouterOS 7.7
# software id = 8U9P-DH4C
#
# model = RBD52G-5HacD2HnD-TC
# serial number = xxxxx
/ip firewall filter
add action=fasttrack-connection chain=forward comment=\
"FastTrack Established/Related" connection-state=established,related \
hw-offload=yes protocol=tcp
add action=fasttrack-connection chain=forward comment=\
"FastTrack Established/Related" connection-state=established,related \
hw-offload=no
[...]
/ip/firewall/filter> print
Flags: X - disabled, I - invalid; D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
1 ;;; FastTrack Established/Related
chain=forward action=fasttrack-connection hw-offload=yes
connection-state=established,related protocol=tcp
2 ;;; FastTrack Established/Related
chain=forward action=fasttrack-connection hw-offload=no
connection-state=established,related
I have about 50Mbps of TCP flows running in background and I see the counters increasing for almost the same amount on both rules, while I would expect them matching only the first one:
.
If the first rules matches the traffic, it means that it’s related to an established/related TCP connection, so why does it go to the next rule? Is this due to the fact that the traffic can’t be HW offloaded because of insufficient resources and then it falls through the rule and matches the second one?
Those two rules are the first two rules, so they should not be influenced in how they match by following rules.
Then, have you carefully read what I’ve written? I’ve implemented what is suggested in the section of the docs I’ve linked, where you set fast track for tcp traffic with hw offload and then with the second rule you set for the remaining traffic without hw offload.
I’d like to know if someone can confirm that some tcp connections can not be matched by the first rule maybe due to the limited amount of resources available for hw offloading.
True forum guru @sindy mentioned in another topic that filter rule with action=fasttrack doesn’t accept the packet (same as action=accept which terminates rule evaluation), it rather marks connection for fasttracking. This affects subsequent packets of same connection (allowing them to skip firewall filter altogether), but current packet continues through firewall filter rules until it hits a rule that executes decission (either accept or drop/reject). Hence the need for accompanying action=accept rule with simikar match criteria following the fasttrack rule(s).
The explanation sounds plausible to me, but we’d need input from MT to make it absolute truth.
It’s not clear what happens in case like yours where packet hits two fasttrack rules, one marking connection for L3 offload and next without that setting. Probably it us possible to run experiment with high throughput connection (single connection as it’ll hit single CPU core in case it’s not L3 hw offloaded) using iperf. First have the first fasttrack rule disabled meaning packets will be handled by CPU (although highly effectively). Tgen with first rule enabled … to see if CPU usage changes. As last part run experiment with only first rule enabled to make sure L3 hw offload works. Wuth reboots of router between tge runs to make sure configuration change is applied.
True forum guru @sindy mentioned in another topic that filter rule with action=fasttrack doesn’t accept the packet (same as action=accept which terminates rule evaluation), it rather marks connection for fasttracking. This affects subsequent packets of same connection (allowing them to skip firewall filter altogether), but current packet continues through firewall filter rules until it hits a rule that executes decission (either accept or drop/reject). Hence the need for accompanying action=accept rule with simikar match criteria following the fasttrack rule(s).
The explanation sounds plausible to me, but we’d need input from MT to make it absolute truth.
It’s not clear what happens in case like yours where packet hits two fasttrack rules, one marking connection for L3 offload and next without that setting. Probably it us possible to run experiment with high throughput connection (single connection as it’ll hit single CPU core in case it’s not L3 hw offloaded) using iperf. First have the first fasttrack rule disabled meaning packets will be handled by CPU (although highly effectively). Tgen with first rule enabled … to see if CPU usage changes. As last part run experiment with only first rule enabled to make sure L3 hw offload works. Wuth reboots of router between tge runs to make sure configuration change is applied.
[/quote]
I’m trying to understand if my speedtest went from 930Mbps to about 400Mbps after upgrading from 6.x to 7.7 since it seems that when it transfers 200MB of data that data is accounted both on the fast track rule (I’ve tried by letting only the first fast track rule enabled) and on the accept rule, thus meaning that no data is being hw offloaded, or did I misunderstood how it should work? Could it be related to the upgrade to 7.7?
Ps: maybe it’s an issue of my provider limiting download but it happened the same days I’ve upgraded to 7.7.
PPS: I have vlan-filtering enabled on the lan bridge traversed by traffic but I’ve tried disabling that too and nothing changed.
Hi, I’ve cleaned up my config and I’ve found a port-mirroring set on switch1. I’ve disabled it and nothing changed. I’ve also removed unused bridges and
now I have only a single bridge. After a reboot of the device I went back to the usual 930Mbps of throughput :
Speedtest by Ookla
Server: KONVERTO AG - Bozen (id: 25254)
ISP: Telecom Italia
Idle Latency: 4.00 ms (jitter: 0.15ms, low: 3.86ms, high: 4.09ms)
Download: 931.47 Mbps (data used: 455.1 MB)
18.59 ms (jitter: 0.88ms, low: 3.55ms, high: 23.23ms)
Upload: 295.10 Mbps (data used: 279.1 MB)
4.51 ms (jitter: 6.83ms, low: 2.21ms, high: 213.06ms)
Packet Loss: 0.0%
As you can see now the 1.4GB of traffic I’ve did with the speed tests has been counted only by the first dummy rule and the two fast-track rules now matches only very few packets (because I suppose the other ones get HW offloaded). BTW, both rules match almost the same packets, maybe it is due to the fact that my HAP AC2 does not support HW offloading given the following output?
[gianni@MikroTik] /interface/ethernet/switch> print detail
Flags: I - invalid
0 name="switch1" type=Atheros-8327 mirror-source=none mirror-target=none mirror-egress-target=none
cpu-flow-control=yes l3-hw-offloading=no
[gianni@MikroTik] /interface/ethernet/switch> set switch1 l3-hw-offloading=yes
expected end of command (line 1 column 13)
[gianni@MikroTik] /interface/ethernet/switch> /interface ethernet switch l3hw-settings
bad command name l3hw-settings (line 1 column 29)
So, problem solved but I’d like to understand better if the output above is correct about l3-hw-offloading on my router. Docs tells about l3hw-settings available in RouterOS7.6 but on my 7.7 it doesn’t work.
L3HW offloading is not supported by any of “small” routers, only by CRS3xx, CRS5xx and some CCR2xxx. Configuration does indicate the presence of L3HW, but even if you set it to enabled in config, it just won’t be enabled in reality.
I suppose that now the second one is effectively offloading the traffic even without HW acceleration and this is why it matched 3MB of the 1.4GB transferred via speedtest (the same for the standard ACCEPT rule for Established/Related traffic that follows the two fast-track rules). I’ve checked the active connections and fast tracking seems to work (this is one of the 4 connections started by Speedtest cli command):
BTW, now the CPU utilization went back to lower levels and throughput had a 3x boost to the usual 930Mbps over PPPOE (graphs show 3-400Mbps but it is due to the fact that speedtest traffic lasts too few seconds), quite amazing for such a small piece of hardware.
:
