I’ve been working with MikroTik since the days when the "RB" in RB450 stood for a board you had to manually case, and RouterOS was still struggling to figure out how to handle multi-core CPUs. If there is one feature that has caused more confusion, broken more QOS trees, and saved more underpowered ARM/MIPS chips than anything else, it is FastTrack.
It’s the classic sysadmin story: You upgrade a client from a 100Mbps fiber line to a 1Gbps circuit. You plug in their trusty hAP ac2 or an RB4011, and you realize the CPU is pinned at 100% while barely pushing 400Mbps. You go into the firewall, add that magical fasttrack-connection rule, and—boom—the throughput hits 950Mbps and the CPU drops to 15%.
You feel like a god. Until ten minutes later, when the VoIP phones start jittering, the IPsec tunnel to the branch office collapses, and your carefully crafted Mangle rules for traffic shaping stop marking a single byte.
Welcome to the FastTrack trade-off. You didn't just "optimize" your router; you told it to start ignoring its own instructions for 90% of your traffic.
The Mechanics: The "Slow Path" vs. The "Fast Path"
To understand why FastTrack breaks things, you have to understand the Standard Packet Flow in RouterOS (which is built on the Linux kernel's Netfilter/Xtables architecture).
1. The Slow Path (The Standard Flow)
In a standard configuration, every single packet in a stream is inspected. It goes through the prerouting chain, gets checked against the forward filter, passes through the mangle table for marking, hits the queue tree for bandwidth limiting, and finally undergoes postrouting (NAT). This is "The Slow Path." It is incredibly flexible, allowing you to do complex layer-7 filtering or per-connection QOS, but it is CPU-intensive because the kernel has to process every header for every packet.
2. The Fast Path (The Shortcut)
FastPath (the precursor to FastTrack) was the first attempt to skip this. If a packet is simple—no NAT, no firewall rules, no mangle—the kernel just shunts it straight from the input interface to the output interface.
3. FastTrack (The Hybrid)
FastTrack is the "Best of Both Worlds" (theoretically). It works by looking at the first few packets of a connection (the "handshake"). Once the connection is established and the firewall marks it as established,related, the FastTrack handler steps in. It marks that specific connection in the conntrack table.
From that point forward, most subsequent packets in that stream completely bypass the Linux kernel's networking stack. They skip the firewall filter. They skip the mangle table. They skip the queue trees. They are routed at near-wire-speed using minimal CPU cycles.
The Mechanics of the Break: Why Things Stop Working
The reason FastTrack "breaks" your firewall is simple: You can't filter what the CPU never sees.
1. The QOS Death
If you are using Simple Queues or a Queue Tree to prioritize VoIP (DSCP/TOS) or throttle a specific user, those queues rely on the kernel seeing the packets to calculate the bandwidth and enforce the limit. Because FastTracked packets bypass the queueing subsystem, your QOS rules become invisible. Your "guaranteed" 5Mbps for the SIP trunk is now competing for air with a FastTracked Steam download.
⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.
Top comments (0)