Firewall e QoSAvanzato

FastTrack — Accelerazione delle connessioni e impatto su QoS

FastTrack bypassa la maggior parte della pipeline per le connessioni già verificate, aumentando enormemente il throughput. Ma rende invisibile il traffico a mangle e Queue Tree: capire questo trade-off è cruciale per un WISP.

FastTrack è il meccanismo di RouterOS per accelerare le connessioni già controllate. Quando una regola filter marca una connessione con action=fasttrack-connection, i pacchetti successivi di quella connessione vengono inoltrati attraverso un percorso ultra-veloce (FastPath) che salta conntrack, mangle, NAT e firewall filter. Il risultato è un throughput molto più alto e un uso CPU molto più basso — su router entry-level può triplicare la banda gestibile.

Come si attiva e cosa fa esattamente

FastTrack si attiva con una sola regola nella chain forward, posizionata subito dopo l'accept established/related. Solo le connessioni established,related possono essere accelerate (mai le new: il primo pacchetto deve sempre passare per il firewall completo per essere autorizzato). Una volta accelerata, la connessione mostra il flag F (fasttrack) nella tabella connessioni.

Regola FastTrack standard + verifica

# La regola FastTrack tipica (chain forward, subito dopo l'accept invalid):
/ip firewall filter add   chain=forward connection-state=established,related   action=fasttrack-connection hw-offload=yes   comment="FastTrack established/related"

# SEMPRE seguita da un accept normale come fallback per i pacchetti
# che (per qualsiasi motivo) non vengono accelerati:
/ip firewall filter add   chain=forward connection-state=established,related   action=accept comment="Fallback established/related"

# Verifica le connessioni accelerate (flag 'F' = fasttracked)
/ip firewall connection print where fasttrack=yes

# hw-offload=yes delega l'accelerazione al chip di switching (se supportato).
# Verifica il supporto hardware del modello:
/interface ethernet switch print

Il trade-off: cosa NON vedi più quando FastTrack è attivo

Mangle: i pacchetti accelerati non passano per il mangle → niente mark-packet/mark-routing → policy routing e marcatura QoS NON funzionano sulle connessioni fasttracked.
Queue Tree con packet-mark: senza mark, il Queue Tree basato su packet-mark non vede il traffico.
Simple Queue: anch'esse vengono bypassate per il traffico fasttracked.
Accounting e torch: il traffico accelerato può non comparire (o comparire parzialmente) negli strumenti di conteggio.
Conntrack timeout: le connessioni fasttracked aggiornano comunque lo stato, ma alcune ispezioni avanzate non si applicano.

Per un WISP la scelta è netta: se devi fare SHAPING della banda per piano cliente (cioè quasi sempre), NON puoi accelerare quel traffico. Le strategie sono due: (1) disattivare del tutto FastTrack e gestire tutto con le code (CPU più carica, ma shaping su tutto); (2) ESCLUDERE dal FastTrack solo il traffico dei clienti che vanno shapati, lasciando accelerato il resto (es. traffico di management o backbone).

Escludere selettivamente il traffico dal FastTrack

FastTrack solo per ciò che NON va shapato

# Strategia: marca le connessioni dei clienti da shapare e ESCLUDILE
# dal FastTrack, così le loro Simple Queue/Queue Tree funzionano.

# 1) Marca le connessioni dei clienti (pool CGNAT) come 'no-ft'
/ip firewall mangle add   chain=prerouting src-address=100.64.0.0/10   action=mark-connection new-connection-mark=no-ft passthrough=yes   comment="Clienti da shapare: escludi dal FastTrack"
/ip firewall mangle add   chain=prerouting dst-address=100.64.0.0/10   action=mark-connection new-connection-mark=no-ft passthrough=yes   comment="Download clienti: escludi dal FastTrack"

# 2) FastTrack SOLO le connessioni NON marcate no-ft
/ip firewall filter add   chain=forward connection-state=established,related   connection-mark=!no-ft   action=fasttrack-connection hw-offload=yes   comment="FastTrack solo traffico non-cliente (es. management/backbone)"

# 3) Le connessioni dei clienti passano per le code normalmente
/ip firewall filter add   chain=forward connection-state=established,related   action=accept comment="Clienti: niente FastTrack -> shaping attivo"

Best practice prestazioni: su hAP/RB entry-level con pochi clienti residenziali e nessuno shaping per piano, lascia FastTrack ATTIVO su tutto — il guadagno di throughput è enorme. Su un gateway WISP che shapa centinaia di clienti, FastTrack va escluso per il traffico clienti: in quel caso dimensiona la CPU di conseguenza (CCR o RB con CPU robusta), perché lo shaping software è costoso.

fasttrackfasttrack-connectionhw-offloadhardware offloadfast paththroughputaccelerazioneconnessione accelerataQoS bypassperformance routerOS

Continua con

Packet Flow in RouterOS — Come viaggia un pacchetto Connection Tracking — Firewall stateful in RouterOS Firewall Filter — Ruleset di base sicuro e commentato NAT in RouterOS — Masquerade, Port Forwarding e Hairpin

Configura senza fatica con l'AI

In WispOS l'agente AI genera la configurazione RouterOS dalle tue parole e un tutor ti guida passo passo.

Prova WispOS