Community discussions

MikroTik App
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Topic Author
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

FastPath / FastTrack / L2HW / L3HW Clarification

Thu Jan 27, 2022 11:36 am

FastPath and FastTrack are two different things. Similar naming may sound confusing, and some people think both are synonyms, but that's not true. I will oversimplify the clarification to keep it short. You can find more info on help.mikrotik.com or other internet resources.
  • FastPath is an ability for the bridge to quickly forward the incoming packet to an egress port, bypassing many processing routines and, therefore, speeding up the process.
  • FastTrack or "Fast path for Connection Tracking" is an ability to quickly route packets within the established IPv4 TCP/UDP connections (and someday, hopefully, IPv6 too).
As I already said, the above explanation is oversimplified, and there is much more to this.


FastPath and VLAN Filtering
  • If the connection goes through a bridge, FastPath is required for FastTrack.
  • Up to RouterOS 7.1 (including), setting vlan-filtering=yes on a bridge disables FastPath, and, therefore, preventing FastTrack for all the connections going through the bridge.
  • Layer 2 Hardware Offloading (L2HW) does NOT care about FastPath. If the switch chip is capable of VLAN filtering (e.g., CRS3xx series), it does that on the hardware level, without invoking software (CPU) at all. For instance, setting vlan-filtering=yes to the hardware-offloaded bridge on CRS317 keeps the wire-speed performance. However, doing the same on CCR1009 decreases the forwarding speed drastically.
  • Since Layer 3 Hardware Offloading (L3HW) depends on L2 hardware processing, it does not care about FastPath either. That's why CRS3xx supports hardware Inter-VLAN routing at near to wire speed.
  • However, the above statement does not apply for FastTrack HW Offloading. FastTrack HW Offloading requires FastTrack connections in the first place; the latter depends on FastPath, which, in turn, does not support VLAN filtering. In other words, setting vlan-filtering=yes disables FastPath, which, in turn, disables FastTrack and FastTrack offloading.

A Better Tomorrow
Ending this post with good news: We have implemented VLAN filtering support by FastPath, and it will be available for testing soon.
UPDATE: Already available in RouterOS 7.2rc2.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11433
Joined: Thu Mar 03, 2016 10:23 pm

Re: FastPath / FastTrack / L2HW / L3HW Clarification

Thu Jan 27, 2022 11:57 am

I was always wondering where exactly fastpath and fasttrack touch each other?

And why do I see fasttrack counters increase on my hAP ac2 running 6.49.1 with vlan-filtering enabled bridge ... I have single bridge with a few VLANs, one of VLANs carries PPPoE (used as WAN) and another VLAN is used as LAN. If I understand the initial post, fastpath should not be working on my setup and neither should fasttrack (I'd expect fasttrack counters rest at zero in this case).
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Topic Author
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

Re: FastPath / FastTrack / L2HW / L3HW Clarification

Thu Jan 27, 2022 12:17 pm

I was always wondering where exactly fastpath and fasttrack touch each other?

And why do I see fasttrack counters increase on my hAP ac2 running 6.49.1 with vlan-filtering enabled bridge ... I have single bridge with a few VLANs, one of VLANs carries PPPoE (used as WAN) and another VLAN is used as LAN. If I understand the initial post, fastpath should not be working on my setup and neither should fasttrack (I'd expect fasttrack counters rest at zero in this case).
There were some bugs due to which FastTrack counters increased despite going the slow path. Moreover, FastTrack counters sometimes may "lie". A classic setup example: vlan-filtered bridge for LAN network + a standalone upstream port to ISP. When a packet is received on the upstream port, it is eligible for FastTrack, and therefore increasing counters. However, later in the chain, the packet enters the bridge, which cannot do FastPath due to VLAN filtering, redirecting it via the slow path. In the end, the packet has traveled through the slow path while still increasing FastTrack counters.

We have fixed a few counter-related issues in the upcoming release. However, solving all of them would require significant performance overhead, which is unacceptable for FastPath/FastTrack.
 
hzdrro
just joined
Posts: 11
Joined: Tue Jan 26, 2021 12:15 pm

Re: FastPath / FastTrack / L2HW / L3HW Clarification

Thu Jan 27, 2022 12:21 pm

As CHR now supports fastpath for virtual adapters, does fasttrack also apply for CHR?
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2096
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: FastPath / FastTrack / L2HW / L3HW Clarification

Thu Jan 27, 2022 2:41 pm

Hi Raimonds,

That is a very nice summary, and some exciting news about coming enhancements.

I think "FastPath is an ability for the bridge to quickly forward the incoming packet to an egress port" under-sells RouterOS's capabilities, and is really only accurate when thinking of Layer2/CHR type "use case"

From my understanding in RouterOS there are 3 "forwarding planes" Kernel, FastPath and Hardware.

Kernel
Packets traverse the standard kernel based packet forwarding mechanisms. Supports _ALL_ protocols and functions of RouterOS but is the slowest performer as performance is bound by the network driver, the kernel and the CPU of the Router or Switch.

FastPath
FastPath is a Kernel bypass mechanism that can accelerate specific protocols e.g. Layer2, Layer3, MPLS, GRE, VLAN, Bridging, PPPoE as long as the FastPath requirements are met. e.g. For Layer2 you cannot have "bridge filters", for Layer3 you cannot have "Firewall Filters". FastPath provides faster performance than the Kernel based packet forwarding, but still uses CPU load.

Hardware
Hardware forwarding makes use of dedicated chips called ASIC's inside the Mikrotik Switch or Router. HW based forwarding is limited to Layer2 Bridging and Layer3 routing and does not support the full MPLS feature set, bridge filters or firewall filtering. Hardware based forwarding is the fastest of all packet forwarding mechanisms, but is at the expense of visibility and flexibility.

Then there is the magical FastTrack

FastTrack is a mechanism for the RouterOS firewall to be able to push "known good" e.g. Established/Related traffic into the FastPath forwarding engine OR more recently the Hardware based forwarding, allowing it to bypass the kernel based slow-path and provide significant performance advantages.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11433
Joined: Thu Mar 03, 2016 10:23 pm

Re: FastPath / FastTrack / L2HW / L3HW Clarification

Thu Jan 27, 2022 2:54 pm

FastTrack counters sometimes may "lie". A classic setup example: vlan-filtered bridge for LAN network + a standalone upstream port to ISP.
My particular case is different: physical perimeter port is hybrid port member of grand unified bridge. The untagged frames from the wire get tagged with PVID=2. Then there's vlan interface with vlan-id=2 and pppoe-client bound to this vlan interface. The pppoe interface is my WAN interface. On the other side I've got VLAN 42 as LAN interface and the rest of physical ports are either access or trunk ports members of same bridge.

Your explanation makes me believe that the huge fasttrack counter value is actually result of bugs? Or is pppoe-out interface eligible for fastpath/fasttrack and the counters lie because of this?

Who is online

Users browsing this forum: Fl3tch and 20 guests