This is what is posted:
/ip firewall filter add chain=forward action=fasttrack-connection connection-bytes=10000-0
/ip firewall filter add chain=forward action=act connection-bytes=10000-0
Question 1
Is this correct? For me it looks lat it target the same bytes 10000-0 (for 10K to 0)?
Question 2
Where to put it?
I have previously removed Fasttrack
If I have it in the bottom, it shows som packet passing through and my Qos works normal (throttling)
If I put it on top of the list, my QoS does not work anymore. speedtest.net shows full speed to the clients.
The page #48 solution only addresses a specific problem, which is that information necessary for L7 and tls-host matchers is present in other than the very first packet of a connection, while fasttrack configured the usual (default) way kicks already at the first response packet. So the postponement of fasttracking based on the amount of data bytes transported by the connection allows these classifiers to work. But if the information they classify on wasn’t available in the first 10000 bytes, it becomes useless to continue searching for it and you can switch the gear.
However, packet marking required for policy routing, most QoS policies, and IPsec policy matching require that all forwarded packets take the “slow track”, so the solution above is not applicable on them.
Nevertheless, if one of the above types of processing is necessary for your application but only for part of your traffic, you can still relieve the CPU by identifying the part of the traffic for which they are not necessary and selectively fasttrack that part of the traffic alone. I cannot imagine an actual scenario involving QoS handling where this approach could be applicable, but there are many cases where you need policy routing only for a relatively low share of the traffic, and the same applies for IPsec site-to-site VPNs in tunnel mode (IPsec in transport mode is intrinsically safe against fasttracking as fasttracking only applies to forwarded traffic).