MikroTik RouterOS ima jedan od najsofisticiranijih packet processing pipeline-a u SOHO/SMB tržištu — sa 4–5 različitih “putanja” kroz koje paket može da prođe (slow path, fast path, FastTrack, hardware offload, switch chip forwarding). Razlika u throughput-u između najsporijeg i najbržeg je 10–20x. Ovaj članak razlaže šta je svaka putanja, kad RouterOS automatski bira koju, i kako eksplicitno upravljati izborom za maksimalnu performance bez gubitka security funkcionalnosti.

Pet putanja kroz MikroTik packet processing

                                 [Paket stigne na port]
                                          |
                                          v
                            [Switch chip — Layer 2 forward]
                                  ovde paket može završiti  ← ASIC, 100% line-rate
                                          |
                                          v (ako mora L3)
                            [Hardware offload — L3 HW forward]
                                  CRS3xx, CCR2xxx samo      ← ASIC L3 routing
                                          |
                                          v (ako ne može HW)
                                   [Fast path]
                              CPU-bound, no firewall        ← ~5x brži od slow
                                          |
                                          v (ako mora conntrack/firewall)
                                   [Fast track]
                            Conntrack-based fast path        ← compromise
                                          |
                                          v (everything else)
                                   [Slow path]
                            Full firewall + queue + NAT      ← ~150-300 Mbps po CPU core

1. Switch chip forwarding (Layer 2)

Najbrža opcija. Paket koji ulazi na port 1 i izlazi na port 2 unutar istog bridge-a a oba porta su na istom switch chip-u — ne dotiče CPU uopšte. ASIC radi forwarding po MAC tabeli na line-rate (1Gbps, 10Gbps, ili više). Provera: /interface bridge port print where hw=yes.

2. Hardware offload Layer 3 (CRS3xx/CCR samo)

CRS328-24P-4S+, CCR2004-1G-12S+2XS i noviji modeli imaju L3 hardware offload — switch chip može da radi IP routing bez CPU intervencije. Throughput: line-rate na svim portovima istovremeno (npr. 24× 1G + 4× 10G).

3. Fast path

Kad paket mora kroz CPU ali ne treba conntrack — npr. transit IP routing između 2 interfejsa bez firewall pravila. RouterOS preskače conntrack lookup i radi direkt route lookup. ~5-10x brži od slow path-a.

4. FastTrack

Kompromis: prvi paket konekcije ide kroz slow path (full firewall + conntrack), ali se “fast-track” labela stavlja na conntrack entry. Sledeći paketi iste konekcije idu kroz fast path. Najbolji default za firewall + NAT scenario.

5. Slow path

Sve ostale situacije. Full pipeline: ingress chain → conntrack → mangle prerouting → routing decision → mangle forward → filter forward → mangle postrouting → NAT → egress queue → egress chain. CPU intensive, throughput limit.

Kada se automatski bira koja putanja

RouterOS automatski downgrade-uje putanju ako bilo koje pravilo zahteva pristup paketu:

Aktivirano	Putanja koja se mora koristiti
`/queue tree` ili `/queue simple`	Slow path (queue requires full processing)
`/ip firewall mangle` u prerouting/forward	Slow path
`/ip firewall nat` (masquerade)	FastTrack (ako fasttrack je dozvoljen)
`/ip firewall filter` u forward	FastTrack ako pravilo je `accept`, slow ako je `drop`/`reject`
Bridge sa VLAN filtering + 1 VLAN	Hardware offload na CRS3xx
Bridge sa VLAN filtering + multiple VLANs + bond + …	Slow path (CPU bridge)

Ključna spoznaja: dodavanjem jednog queue ili mangle pravila, ceo router downgrade-uje na slow path. Ako CCR2004 ima 4Gbps capacity ali jedan tek-vidi queue tree pravilo, throughput pada na 1.5Gbps.

CLI komande za upravljanje fast path-om

FastTrack pravilo (bitno za default firewall)

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related \
  comment="defconf: fasttrack established"
add action=accept chain=forward connection-state=established,related \
  comment="defconf: accept established"
add action=drop chain=forward connection-state=invalid \
  comment="defconf: drop invalid"

Bitno: fasttrack-connection mora biti iznad accept established u listi. Sve konekcije sa fasttrack labelom prelaze u fast path posle prvog paketa.

Provera throughput-a per-path

/interface monitor-traffic ether1
# rx-packets-per-second: 145290
# rx-bits-per-second: 1.45Gbps
# fp-rx-packets-per-second: 145289   <-- fast-path packets
# fp-rx-bits-per-second: 1.45Gbps

Ako fp-rx-bits-per-second ≈ rx-bits-per-second, sve ide kroz fast path. Ako je mali, mnogo paketa ide kroz slow path → check za dodatna pravila.

Disable conntrack za max throughput

/ip firewall connection tracking
set enabled=no

Posledica: NAT prestaje da radi, FastTrack prestaje da radi, sve queue tree konfiguracije više nisu efikasne. Koristi se samo za routing-only scenarije (ISP edge router gde neka druga oprema radi NAT/firewall).

Hardware offload provera

/interface bridge port print detail
# 0  H interface=ether1 bridge=br-lan hw=yes
# 1  H interface=ether2 bridge=br-lan hw=yes
# H = hardware offload aktivan

Ako “hw” piše “no”, port radi software bridging (CPU). Razlozi: pogrešna combinacija (kombinovanje portova iz različitih switch chip-ova, bond na bridge, ili CRS1xx koji nema HW bridging).

Switch chip stats (CRS3xx)

/interface ethernet switch monitor switch1
# total-bytes: 4.5T
# total-packets: 3.2G
# fp-bytes: 4.5T            <-- forwarded by switch chip (no CPU)
# fp-packets: 3.2G

Ako fp-* matchuje total-*, sve ide kroz hardware. Ako ne, neki traffic ide kroz CPU (verovatno zbog VLAN-ova koje ASIC ne razume ili ACL pravila).

Realan throughput test: CCR2004-1G-12S+2XS

Setup: Iperf3 server na laptopu sa Mellanox ConnectX-4 10G NIC, klijent isto sa 10G NIC. CCR2004 router između, oba klijenta u različitom VLAN-u (VLAN 10 i VLAN 20) sa /24 subnet-ima. Test: iperf3 -c <server> -t 30 -P 8.

Konfiguracija	Throughput	CPU%	Putanja
Switch L2 (isti VLAN)	9.41 Gbps	0–2%	Switch chip
L3 routing, no firewall	9.21 Gbps	8–12%	HW offload (jer CCR ima L3)
L3 + firewall accept rule	9.18 Gbps	12–18%	HW offload
L3 + FastTrack + masquerade	8.85 Gbps	18–24%	FastTrack
L3 + queue tree	3.42 Gbps	70–85%	Slow path
L3 + 1 mangle prerouting rule	3.61 Gbps	65–80%	Slow path
L3 + connection tracking off	9.40 Gbps	5–8%	Hardware (no conntrack overhead)

Pad sa 9.21 Gbps na 3.42 Gbps dodavanjem queue tree pravila — to je 63% gubitka throughput-a! CCR2004 nije čak ni kvar — sve to je očekivano, ali ljudi koji ne razumeju pipeline-u dodaju queue za “QoS for VoIP” i čude se zašto download pada sa 1Gbps na 300Mbps.

Rešenje: queue samo na “border” interfejsu (WAN), ne na inter-VLAN trunk-u. Ili use hierarchical queue sa parent na bridge, individual VoIP marking samo specifične flow-ove.

Gotchas i česte greške

/ip settings rp-filter=strict odbacuje pakete bez reverse path validacije — fast path ne podržava (zahteva full route lookup), forsira slow path. Default loose je dovoljan u 90% slučajeva.
/queue tree na hot path-u — najveći trošak performance-a. Ako MUST imati queue, ograniči na single interface (npr. ka ISP-u za upload shaping) ne na inter-VLAN trunk.
Firewall NAT bez fasttrack — masquerade pravilo sam ne forsira slow path, ali svaki novi connection ulazi kroz slow path, a fasttrack rule mora biti pre accept established. Bez fasttrack, dugotrajne TCP konekcije (ssh, RDP) bivaju u slow path-u.
Bridge sa VLAN filtering + bonded link — hardware offload se isključuje kad bridge ima bond port. Workaround: koristiti LACP na switch chip strane (ne bridge port).
/ip dhcp-client na bridge interface — dhcp-client podiže snmpd-like procese koji uzimaju 1–2% CPU-a; mali ali primetan na low-end modelima (RB951, hAP ac).
Loop u routing tabeli — slabo dokumentovano: ako je default route ka WAN-u i ima static route ka pod-net-u koji već postoji u connected, RouterOS ulazi u “evaluate twice” mode što duplira CPU usage.

Vendor-specific quirk

CCR2004 (najpopularniji enterprise MikroTik 2026): ARM 64-bit Cortex-A72 sa 16 cores, dedicated CPU cores za switch chip i routing. Hardware offload za bridge L2 + L3 routing istovremeno. Oprez: bond + bridge + VLAN filter kombinacija zna da fall back u software bridge — testiraj pre produkcije.

CRS328-24P-4S+ (najpopularniji SMB): ima L2 hardware offload, L3 HW offload zavisi od firmware verzije — 7.10+ podržava L3 routing u hardware-u za do 1500 routes; preko toga slow path. Dobro za SMB ali ne za ISP-edge.

hEX series (RB750Gr3, hEX S): NE podržava hardware offload za L3, sve routing ide kroz CPU. Max throughput ~700Mbps sa fasttrack, ~150Mbps sa queue tree. Adekvatno za fiber 500/100 connection ali ne za 1Gbps fiber.

CRS305-1G-4S+ (smallest 10G switch): L2 hardware offload odličan, L3 nema. Koristi kao 10G switch + L3 router (hEX/CCR) zasebno.

Naša preporuka po veličini projekta

SOHO (jedan router, <100Mbps internet): RouterBoard hEX dovoljan. Default config sa fasttrack je optimalna. Ne dodavaj queue tree osim ako MUST za QoS.

Mali biznis (1Gbps internet, do 50 korisnika): CCR2004-1G-12S+2XS. Hardware offload + FastTrack default. Queue tree samo na WAN interface za upload shaping. Throughput: 9+ Gbps inter-VLAN.

Srednji (1-10Gbps internet, multi-site, VPN): CCR2216 ili CCR2116. Disable conntrack na trunk linkovima između core router-a, koristi conntrack samo na WAN edge. Hierarchical QoS sa parent classes.

Enterprise (10Gbps+ internet, ISP-grade): CCR2216-1G-12XS-2XQ ili Cisco/Juniper ako MikroTik ne pokriva BGP scale. Conntrack disabled, hardware-offload routing, FRR ili dedicated routing daemon. Treba inženjer sa CCNP-level networking ekspertizom.

MikroTik RouterOS fast forwarding vs IP routing