A couple of words about FastPath and FastTrack in MikroTik

It is not a secret for anyone that MikroTik produces Software-Baser routers and CPU takes over most of the traffic processing. This approach has an advantage, since You can program almost any functionality and maintain a relatively unified system for all devices. But in speed they will always lag behind routers with specialized chips.

Software processing packages has several disadvantages:

1. The lack of wire speed - the processor (especially single-core) can not work faster than specialized chips.
2. Locks With really large amounts of traffic (for example, DoS / DDoS) you may not be able to connect to the router even through the console interface, since all processor time will be occupied by traffic processing.
3. The difficulty of scaling. You cannot add a module that increases packet processing speed by hardware.

Developers go to various hardware and software solutions to improve the situation:

1. Switch-chip on inexpensive models, allows processing Layer2 traffic bypassing the CPU.
2. SoC with a good network chip (CCR line).
3. Using hardware encryption
4. Various technologies reduce the number of software processing packages (FastPath and FastTrack), and they will be discussed.

SlowPath vs FastPath

SlowPath is the basic traffic path through the internal MikroTik subsystems, it can be quite diverse and, the longer the path, the higher the CPU load and the more the speed drops.

FastPath - algorithms for transmitting traffic bypassing rather large processing blocks.

Operating conditions and support on devices

Most modern routers and motherboards from MikroTik support FastPath, but the wiki has a detailed list:

And a separate list for interfaces other than ethernet:

For the full-fledged operation of FastPath, support is needed from both the incoming and the outgoing interfaces. Interfaces should only include hardware queues.

Last but not least, FastPath doesn’t like fragmented traffic. If a packet is framed, it will definitely get stuck on the CPU.

FastPath and Bridge

Bridge is a software interface used to create a Layer2 connection between multiple hardware (or software) interfaces. If you connect a 4 ethernet interface to the bridge (and enable hw=yes ) and one wireless on the router, the traffic between the ethernet interfaces will go past the software interface, and the traffic between ethernet and wireless will enable the software bridge. On routers with several chips (for example, RB2011), the traffic between interfaces from different chips will use the capabilities of the software bridge (sometimes, to reduce the load, interfaces simply join the patch cord and, in general, it works).

FatsPath - refers only to traffic coming through the CPU (software bridge), usually the traffic between interfaces from different chips, or the option hw=yes disabled.

On Packet Flow, the traffic passing through Bridge looks like this:

And more:

It is included in the bridge settings (the setting is the same for all bridge interfaces) [Bridge] -> [Settings] -> [Allow FastPath], there you can also see the counters.

For FastPath to work in Bridge, the following conditions must be met:

1. There is no vlan configuration on the bridge interfaces (I think this is not relevant for the CRS series, where the vlan are configured at the hardware level, but I could be wrong)
2. There are no rules in /interface bridge filter and /interface bridge nat , these are the same blocks from the second scheme that the frame goes through.
3. Ip firewall is not enabled ( use-ip-firwall=no ). A good feature for capturing traffic and debugging the network, but on an ongoing basis is rarely included.
4. Do not use mesh and metarouter
5. The interface is not running: sniffer, torch and traffic generator.

FastPath and Tunnel

If in two words: a tunnel interface is the encapsulation of some packets into the load part of other packets. If you go along PacketFlow, then the red lines mark the original packet, the blue ones - the original packet encapsulated in the tunnel protocol packet (for example, ipip or gre; eoip gets (and comes from) in bridging decision; with tunnel ipsec is still more interesting, but not related to fastpath).

FastPath tunnel traffic will not be visible in: firewall, queues, hotspot, vrf, ip accounting. But some packets will continue to be transmitted over SlowPath, this must be taken into account when configuring the Firewall.

For FastPath to work in tunnel interfaces, the following conditions must be met:

1. Do not use ipsec encryption
2. Avoid packet fragmentation (properly configure mtu)
3. Enable allow-fast-path=yes on the tunnel interface

FastPath and Layer3

Layer3 is the transfer of packets between subnets, the router builds routing tables and proceeds from them forwards the packet to the next hop.

On Packet Flow, the transit traffic on the network layer looks like this:

go deep

and even deeper

For FastPath to work on Layer3, the following conditions must be met:

1. Do not add rules to the firewall (at all, even nat).
2. Do not add entries to Address Lists.
3. Do not configure Simple Queues and Queues Tree for parent=global , or interfaces on which you plan to get a working FastPath.
4. Do not use mesh and metarouter.
5. Disable Connection tracker. The auto option was introduced specifically for the operation of FastPath in the absence of rules in the firewall.
6. Do not use /ip accounting .
7. Do not use /ip route vrf .
8. Do not configure /ip hotspot .
9. Do not add ipsec policies.
10. Route Cache must be enabled.
11. Do not use active: /tool mac-scan and /tool ip-scan .
12. Launched sniffer, torch and traffic generator interfere with the operation of FastPath.

It is enabled in the ip settings: [IP] -> [Settings], there you can also see the counters of successfully processed packets.

Screenshot from home router. I have a fairly heavy firewall, several constantly enabled L2TP / IPSec connections and queues. About FastPath you can not even dream.

Fasttrack

Technology marking ip packages for quick passage through Packet Flow.

For FastTrack to work, you must comply with the following conditions:

1. Route Cache and FastPath must be enabled and active.
2. Correct configuration of traffic marking.
3. Works only for UDP and TCP traffic.
4. Do not use mesh and metarouter.
5. Do not use active: /tool mac-scan and /tool ip-scan .
6. Launched sniffer, torch and traffic generator interfere with the operation of FastTrack.

Traffic marked as fasttrack will not be processed in:

1. Firewall filter (although this is debatable, in the example I will show why);
2. Firewall mangle;
3. IPSec;
4. Queues with parrent = global;
5. Hotspot;
6. VRF.

If something interferes with the fasttrack packet, it will be transmitted like all the remaining packets along a slow path.

Enabled by adding a rule (see below) to the Firewall. FastTrack marks only packets from the established connection (it is possible to mark new, but then there will be problems with NAT). The filter table is used because When marking fasttrack in prerouting, again there will be problems with NAT.

Synthetic test

And (for the last test) what was configured and how it worked:
Filtering rules continued to process traffic (if you disable permissive for established, related traffic went to drop), postrouting + mangle captured packets that did not fall into FastTrack.

In Connection Tracker you can track FastTrack connections by the flag of the same name.

In the [IP] -> [Settings] counters, you can see that FastTrack is active and working, but FastPath is not.

 /ip firewall filter add action=fasttrack-connection chain=forward connection-state=established,related add action=accept chain=forward connection-state=established,related add action=accept chain=forward connection-state=new add action=drop chain=forward /ip firewall mangle add action=mark-packet chain=postrouting connection-state=established,related new-packet-mark=q1 passthrough=no src-address=20.20.20.0/24 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 

Instead of conclusion

Use or not?

• FastPath for Bridge - Definitely yes. At least reduces the load on the CPU.
• FastPath for Tunnels - No. It works dull, turns off if you have encryption.
• FastPath for Layer3 - Arguably, most of the router's capabilities are lost. In a large, closed from the wild Internet, the network may have its (small) win.
• FastPath for MPLS / VLAN / Bonding / VRRP - Turns on automatically if there is a possibility. There is no separate option for management.
• FastTrack - For home and SOHO configurations without queues and a paranoid firewall will do. Synthetic tests with one client look good, in practice, it is necessary to closely monitor the traffic that leaked past FastTrack and look for the cause.

Links in addition

https://wiki.mikrotik.com/wiki/Manual:Fast_Path
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
http://mum.mikrotik.com/presentations/UA15/presentation_3077_1449654925.pdf