Preskoči na glavni sadržaj

MikroTik RouterOS fast forwarding vs IP routing

switching advanced AV Market tim

MikroTik RouterOS fast forwarding vs IP routing

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:

AktiviranoPutanja koja se mora koristiti
/queue tree ili /queue simpleSlow path (queue requires full processing)
/ip firewall mangle u prerouting/forwardSlow path
/ip firewall nat (masquerade)FastTrack (ako fasttrack je dozvoljen)
/ip firewall filter u forwardFastTrack ako pravilo je accept, slow ako je drop/reject
Bridge sa VLAN filtering + 1 VLANHardware 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.

KonfiguracijaThroughputCPU%Putanja
Switch L2 (isti VLAN)9.41 Gbps0–2%Switch chip
L3 routing, no firewall9.21 Gbps8–12%HW offload (jer CCR ima L3)
L3 + firewall accept rule9.18 Gbps12–18%HW offload
L3 + FastTrack + masquerade8.85 Gbps18–24%FastTrack
L3 + queue tree3.42 Gbps70–85%Slow path
L3 + 1 mangle prerouting rule3.61 Gbps65–80%Slow path
L3 + connection tracking off9.40 Gbps5–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.

Šta dalje?

Iskoristi MikroTik konfiguracioni asistent → — generiše baseline config sa fasttrack + hardware offload za tvoj model.

Povezani članci

Pojmovnik