Starting from v6.29rc9, we introduced new and existing feature - FastTrack. Easy way to make your Firewall/NAT router up to 5x faster.
*) ipv4 fasttrack fastpath - accelerates connection tracking and nat for marked connections (more than 5x performance improvement compared to regular slow path conntrack/nat) - currently limited to TCP/UDP only;
*) added ~fasttrack-connection~ firewall action in filter/mangle tables for marking connections as fasttrack;
*) added fastpath support for bridge interfaces - packets received and transmitted on bridge interface can go fastpath (previously only bridge forwarded packets could go fastpath);
*) packets now can go half-fastpath - if input interface supports fastpath and packet gets forwarded in fastpath but output interface does not support fastpath or has interface queue other than only-hw-queue packet gets converted to slow path only at the dst interface transmit time;
*) trafflow: add natted addrs/ports to ipv4 flow info.
Can we get some bigger pictures. I can not see the firewall examples. Also if possible show examples in text version.
If I understand this correctly I have to make a mangle rule to mark packets as fasttrack. But then I guess I need to make another rule to make some processing with them ?
I will wait for 6.29 final before trying this, but in your rules you add a fasttrack rule and then an accept rule. What happens if there is no accept rule. Doesn’t the fasttrack rule here do exactly this - passthrough all packets matched by it ?
Yes, but accept is also needed - it was mentioned in the presentation that a few packets (10%) will still need to be processed outside of fast-track, because of connection integrity checking, out of order delivery, security, etc.
If you didnt have the normal allow, those would be dropped.
For the first moment it looked very exciting and promising.
But now I am not sure that adding additional rules, especially if they break other commonly used features like statistics and queues, will help significantly. Moreover when it is applicable only in some cases.
I would rather see some real improvement then such half-way things. There are surely reserves in packets processing and in memory usage that could be addressed…
If there are some conditions that would allow fasttrack, why I have to create additional user rules for it? Why packets that could be processed in fasttrack mode are not processed so transparently in the background?
The idea is to “fasttrack” some specific machine without slowing it’s traffic for processing. Let’s say you have a network of users, you have firewall and queues for them. But then you have a VIP customer (or your own PC) that you will not filter or slow down, and you want the best available speed for it. This is the situation for fasttrack.
Yeah, but even in those cases, you still want the best available speed… That would not completely block out the rest of the network, so even “VIP” customers need SOME restrictions imposed on them.
I think this feature will be most useful when the MikroTik router is used as a CPE device - in those cases, you don’t want to impose any restrictions onto the device itself, but you want to impose them upstream, at your central router(s). So if both routers are MikroTik routers, you can use fastpath, and fasttrack to get the best inner-network performance, and still apply statistics and queues on the “edge” routers.
Question - if I have no rules in forward chain - only in input chain (typical transit router) - will FastTrack be active?
IMO, if there are no rules in a default chain, that chain should automatically be FastTracked (so I dont have to add rules now to tons of transit routers to take advantage of FastTrack).
It is not about filter rules, it is also about NAT. Basically it is fastpath solution when connection tracking is necessary.
You obviously need to process some packets normal way through the connection tracking to put all local/public IPs in order, so i do not think that automatic fasttrack is possible. Nut i think it should be in all board default config that also have NAT.
Connection tracking can operate without NAT, It is rather a function of the “Full State Firewall”
If the FS firewall and NAT is not necessary, tracking is better forcibly disable
Wow simply adding the filter to accept fasttrack and away it goes…
ip settings print
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 268210
ipv4-fasttrack-bytes: 307676029
I went 6.29rc13 due to the fix of the excessive sector-rewrites. I had a new router go from 1000 to over a million in its total sector-rewrite count due to 6.28 in yes 4 days uptime…
