Gestione della Banda MikroTik: Code

Riepilogo La gestione della banda su MikroTik si basa su tre strumenti: le simple queue per un tetto rapido per client, le queue tree per gerarchia e priorità, e PCQ per la condivisione equa tra molti utenti senza creare una coda per ciascuno. Le queue tree si abbinano alle marcature mangle del firewall e ti danno garanzie, tetti massimi e priorità. Questa guida mostra quando usare ciascuno, i comandi RouterOS e come mantenere la stessa policy coerente su una flotta di router.

Cos’è la Gestione della Banda su MikroTik?

La gestione della banda su MikroTik è l’uso delle code RouterOS per controllare quanta parte di un collegamento ciascun cliente, sottorete o classe di traffico può consumare — limitando le velocità, garantendo i minimi e decidendo chi cede quando il collegamento è saturo. RouterOS implementa le code con uno scheduler Hierarchical Token Bucket (HTB), esposto in due punti: le simple queue, un elenco ordinato applicato in sequenza, e la queue tree, una gerarchia collegata alle interfacce o alle marcature di pacchetto della funzione mangle del firewall (Documentazione MikroTik — Queues).

La distinzione decide fin dove il tuo progetto potrà scalare. Una simple queue risponde a “limita questo cliente a 50 Mbps”. Una queue tree risponde a “questo uplink da 500 Mbps è condiviso da 300 abbonati, il VoIP passa per primo, nessuno resta a secco e chi scarica molto non rovina la serata”. Ogni ISP prima o poi ha bisogno della seconda risposta.

Passo 1 — Limita un client con una simple queue

Le simple queue sono la via più breve dal problema alla soluzione. Punta a un IP, una sottorete o un’interfaccia, imposta il tetto e hai finito:

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limit si scrive come upload/download dal punto di vista del router. Le regole vengono valutate in ordine e vince la prima corrispondenza — quindi una regola generica messa presto ingoia silenziosamente quelle specifiche che aggiungi dopo. Quell’ordinamento è il motivo più comune per cui una coda “funzionante” smette di funzionare dopo che qualcuno aggiunge una regola sopra di essa (Documentazione MikroTik — Queues).

Le simple queue si abbinano anche all’autenticazione degli abbonati: il campo rate-limit di un profilo PPPoE crea una simple queue dinamica per sessione, così i piani seguono l’utente invece dell’IP. La nostra guida al server PPPoE MikroTik per ISP copre il lato profilo.

Passo 2 — Marca il traffico con il mangle del firewall

La queue tree non può vedere “VoIP” o “cliente 101”; vede le marcature di pacchetto. Creale nel mangle, marcando prima la connessione e poi i pacchetti, il che è meno costoso che re-ispezionare ogni pacchetto:

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

Mantieni la tassonomia delle marcature piccola e stabile. Le marcature sono il vocabolario che parlano le tue code, e quando una flotta ha tre generazioni di nomi di marcature improvvisati, nessuno riesce a dire quale router applica quale policy. È qui che l’audit e lo storico delle configurazioni di MKController si ripagano: vedi lo stato del mangle e delle code di ogni router, confrontalo con la policy prevista e applica le regole corrette su tutta la flotta invece di aprire trenta sessioni Winbox per trovare l’unico apparato che non ha mai ricevuto la modifica.

Passo 3 — Costruisci la gerarchia della queue tree

Una queue tree ha un parent che detiene la capacità reale del collegamento e dei child che la suddividono:

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

Tre campi fanno il lavoro. limit-at è la garanzia che un child riceve anche quando il collegamento è saturo. max-limit è il tetto che può raggiungere quando la capacità è libera. priority — 1 è la più alta, 8 la più bassa — decide quale child ottiene per primo gli avanzi, e si applica solo tra limit-at e max-limit (Documentazione MikroTik — Queues). Imposta il max-limit del parent su ciò che il collegamento effettivamente eroga, non su ciò che dice il contratto, altrimenti la coda non diventa mai il collo di bottiglia e non modella nulla.

Passo 4 — Aggiungi PCQ per la condivisione equa

La Per Connection Queue (PCQ) è il motivo per cui MikroTik scala fino a un numero di abbonati che renderebbe ingestibile un elenco di code per utente. Un tipo di coda PCQ classifica il traffico in base a un campo indirizzo e crea una sotto-coda dinamica per ogni valore distinto, applicando la stessa velocità a ciascuno (Documentazione MikroTik — PCQ example):

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

Collega pcq-down come queue del child che trasporta il traffico di download dei clienti, e ogni cliente ottiene fino a 20 Mbps, allocati automaticamente. Imposta pcq-rate=0 e PCQ divide equamente la banda del parent tra chiunque sia attivo — la classica configurazione “nessuno resta a secco”. Un solo tipo di coda sostituisce centinaia di voci scritte a mano.

La stessa logica di equalizzazione si applica al WiFi condiviso: il limite di velocità del piano e un parent PCQ insieme impediscono a un ospite di consumare l’uplink di un locale — vedi la nostra guida alla configurazione dei voucher HotSpot MikroTik per il lato credenziali.

Passo 5 — Regola limit-at, max-limit, burst e priority

La maggior parte del QoS mal funzionante non è uno strumento sbagliato, sono numeri sbagliati. Mantieni la somma dei limit-at di ogni child pari o inferiore al max-limit del parent; se le garanzie eccedono la capacità del collegamento, HTB non può rispettarle e le priorità smettono di comportarsi come ti aspetti. Riserva priority=1 al traffico sensibile alla latenza — VoIP, gaming, DNS — e lascia i trasferimenti di massa a 8 con un tetto generoso.

Il burst merita un avvertimento. burst-limit, burst-threshold e burst-time permettono a un client di superare brevemente max-limit mentre la sua media resta bassa — ottimo per gli speed test, peggio per un collegamento sovraccarico. Misura con /queue simple print stats o con i contatori della queue tree mentre il collegamento è sotto carico, non alle 3 del mattino quando tutto è inattivo. Se leggere i contatori nell’ora di punta non è pratico, la vista Internet Link di MKController mantiene lo stesso quadro in continuo — l’utilizzo rispetto alla velocità contrattuale; la latenza come media, massimo e P95; e quante ore ciascun collegamento ha trascorso sopra il 90% — così regoli sulla base dello storico, non di uno scatto fortunato.

Anche la capacità cambia. In una configurazione failover dual-WAN, il max-limit del parent che hai regolato per la fibra è fantasia nel momento in cui il traffico finisce sul backup LTE — pianifica una seconda policy.

Passo 6 — Applica la policy su tutta la flotta

Un router è una configurazione; cento router sono un’operazione. La policy ora deve essere identica su ogni apparato, sopravvivere al tecnico che “temporaneamente” ha alzato il tetto di un cliente ed essere recuperabile quando il router di un ripetitore viene reinstallato con netinstall. Niente in RouterOS lo fa al posto tuo.

MKController sì: push su tutta la flotta di tipi di coda, profili rate-limit e regole firewall; storico delle configurazioni, così puoi vedere quando un limite è cambiato e ripristinare la versione precedente con un clic; backup automatici prima di una modifica; e accesso remoto sicuro in uscita ai router dietro CGNAT o su Starlink, senza IP pubblico e senza port forwarding — l’approccio che descriviamo in la gestione remota MikroTik dietro CGNAT. E il suo monitoraggio Internet Link sorveglia proprio gli uplink che hai appena modellato — utilizzo per sorgente rispetto alla velocità contrattuale, latenza con P95 e consumo che supera le soglie del 75% e 90% su un massimo di quattro sorgenti WAN per router — così un collegamento che si avvicina alla saturazione emerge sulla dashboard e (insieme agli avvisi Telegram) nelle tue notifiche, prima che un abbonato chiami. Gli ISP e i WISP che gestiscono MikroTik su larga scala lo usano affinché la policy di banda resti una decisione sola, non cento.

Consigli

• Modella sull’interfaccia da cui il traffico esce dal router; le code controllano l’egress, quindi i download si modellano sul lato LAN e gli upload sul lato WAN.
• Preferisci un solo tipo di coda PCQ a centinaia di simple queue una volta superate qualche decina di abbonati.
• passthrough=no sulle regole mark-packet evita l’inutile attraversamento delle restanti regole mangle.
• Fai sempre un backup prima di toccare le code su un edge di produzione, e cambia una variabile alla volta.

Smetti di indovinare dove è finita la tua banda

Le code sono la differenza tra vendere un piano e consegnarlo. Le simple queue limitano un client, le queue tree danno struttura e priorità, PCQ rende automatica l’equità — e MKController trasforma tutte e tre in una policy che applichi una volta e imponi ovunque: gestione centralizzata della flotta, push di rate-limit e firewall su ogni router, storico configurazioni con ripristino in un clic, accesso remoto senza IP pubblico e monitoraggio Internet Link che segnala un collegamento in saturazione rispetto alla velocità contrattuale prima che lo facciano i tuoi clienti.

Inizia la tua prova gratuita di MKController