Gestió d'amplada de banda MikroTik: cues

Resum La gestió d’amplada de banda a MikroTik es basa en tres eines: cues simples per a un límit ràpid per client, arbres de cues per a la jerarquia i la prioritat, i PCQ per al repartiment just entre molts usuaris sense crear una cua per a cadascun. Els arbres de cues es combinen amb les marques mangle del tallafoc i et donen garanties, sostres i prioritats. Aquesta guia mostra quan utilitzar cadascun, les ordres de RouterOS i com mantenir la mateixa política coherent a tota una flota de routers.

Què és la gestió d’amplada de banda a MikroTik?

La gestió d’amplada de banda a MikroTik és l’ús de les cues de RouterOS per controlar quina part d’un enllaç pot consumir cada client, subxarxa o classe de trànsit — limitant velocitats, garantint mínims i decidint qui cedeix quan l’enllaç està ple. RouterOS implementa les cues amb un planificador Hierarchical Token Bucket (HTB), exposat en dos llocs: cues simples, una llista ordenada aplicada en seqüència, i l’arbre de cues, una jerarquia associada a les interfícies o a les marques de paquet de la funció mangle del tallafoc (Documentació MikroTik — Queues).

La distinció decideix fins on escalarà el teu disseny. Una cua simple respon “limita aquest client a 50 Mbps.” Un arbre de cues respon “aquest enllaç de pujada de 500 Mbps el comparteixen 300 abonats, la VoIP passa primer, ningú es queda sense res i els que descarreguen molt no arruïnen la vetllada.” Cada ISP acaba necessitant la segona resposta.

Pas 1 — Limita un client amb una cua simple

Les cues simples són el camí més curt del problema a la solució. Apunta a una IP, una subxarxa o una interfície, defineix el sostre, i ja està:

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

max-limit s’escriu com a upload/download des del punt de vista del router. Les regles s’avaluen en ordre i la primera coincidència guanya — de manera que una regla àmplia col·locada abans s’empassa silenciosament les específiques que hi afegeixes després. Aquest ordre és el motiu més habitual pel qual una cua que “funcionava” deixa de funcionar després que algú hi afegeixi una regla per sobre (Documentació MikroTik — Queues).

Les cues simples també es combinen amb l’autenticació d’abonats: el camp rate-limit d’un perfil PPPoE crea una cua simple dinàmica per sessió, de manera que els plans segueixen l’usuari en lloc de la IP. La nostra guia del servidor PPPoE MikroTik per a ISP cobreix la part del perfil.

Pas 2 — Marca el trànsit amb el mangle del tallafoc

L’arbre de cues no pot veure “VoIP” ni “client 101”; veu marques de paquet. Crea-les al mangle, marcant primer la connexió i després els paquets, cosa que és més barata que reinspeccionar cada paquet:

/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

Mantén la taxonomia de marques petita i estable. Les marques són el vocabulari que parlen les teves cues, i quan una flota té tres generacions de noms de marca improvisats, ningú sap quin router aplica quina política. Aquí és on l’auditoria i l’historial de configuració de MKController demostren la seva utilitat: veure l’estat del mangle i de les cues de cada router, comparar-lo amb la política prevista i enviar les regles corregides a tota la flota en lloc d’obrir trenta sessions de Winbox per trobar l’únic equip que mai va rebre el canvi.

Pas 3 — Construeix la jerarquia de l’arbre de cues

Un arbre de cues té un pare que conté la capacitat real de l’enllaç, i fills que la divideixen:

/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

Tres camps fan la feina. limit-at és la garantia que rep un fill fins i tot quan l’enllaç està saturat. max-limit és el sostre que pot assolir quan hi ha capacitat lliure. priority — 1 és la més alta, 8 la més baixa — decideix quin fill rep primer les sobres, i s’aplica només entre limit-at i max-limit (Documentació MikroTik — Queues). Configura el max-limit del pare al que l’enllaç ofereix realment, no al que diu el contracte, o la cua mai no es converteix en el coll d’ampolla i mai no modela res.

Pas 4 — Afegeix PCQ per al repartiment just

La Per Connection Queue (PCQ) és la raó per la qual MikroTik escala fins a xifres d’abonats que farien impossible de gestionar una llista de cues per usuari. Un tipus de cua PCQ classifica el trànsit per un camp d’adreça i crea una subcua dinàmica per a cada valor diferent, aplicant la mateixa velocitat a cadascuna (Documentació 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

Adjunta pcq-down com a queue del fill que porta el trànsit de baixada dels clients, i cada client obté fins a 20 Mbps, assignats automàticament. Configura pcq-rate=0 i PCQ divideix l’amplada de banda del pare de manera equitativa entre qui estigui actiu — la clàssica configuració de “ningú es queda sense res”. Un sol tipus de cua substitueix centenars d’entrades escrites a mà.

La mateixa lògica d’igualació s’aplica al WiFi compartit: el límit de velocitat del pla i un pare PCQ, junts, eviten que un convidat consumeixi l’enllaç de pujada d’un local — consulta la nostra guia de configuració de vals HotSpot MikroTik per a la part de les credencials.

Pas 5 — Ajusta limit-at, max-limit, burst i priority

La majoria del QoS trencat no és una eina equivocada, són números equivocats. Mantén la suma del limit-at de cada fill igual o per sota del max-limit del pare; si les garanties sobrepassen la capacitat de l’enllaç, HTB no les pot respectar i les prioritats deixen de comportar-se com esperes. Reserva priority=1 per al trànsit sensible a la latència — VoIP, jocs, DNS — i deixa que les transferències massives visquin al 8 amb un sostre generós.

El burst mereix un avís. burst-limit, burst-threshold i burst-time permeten que un client superi max-limit breument mentre la seva mitjana es manté baixa — genial per als tests de velocitat, pitjor per a un enllaç sobresubscrit. Mesura amb /queue simple print stats o els comptadors de l’arbre de cues mentre l’enllaç està sota càrrega, no a les 3 de la matinada quan tot està inactiu. Si llegir els comptadors a l’hora punta no és pràctic, la vista Internet Link de MKController manté la mateixa imatge de manera contínua — la utilització respecte a la velocitat contractada; la latència com a mitjana, màxima i P95; i quantes hores ha passat cada enllaç per sobre del 90% — de manera que ajustes contra l’historial, no contra una captura afortunada.

La capacitat també es mou. En una configuració de failover dual-WAN, el max-limit del pare que vas ajustar per a la fibra és ficció en el moment que el trànsit passa a la còpia de seguretat LTE — planifica una segona política.

Pas 6 — Desplega la política a tota la flota

Un router és una configuració; cent routers són una operació. Ara la política ha de ser idèntica a cada equip, sobreviure al tècnic que “temporalment” va apujar el sostre d’un client, i ser recuperable quan es reinstal·la (netinstall) un router de torre. Res dins de RouterOS no ho fa per tu.

MKController sí: enviaments a tota la flota de tipus de cua, perfils de rate-limit i regles de tallafoc; historial de configuració, perquè puguis veure quan va canviar un límit i restaurar la versió anterior amb un clic; còpies de seguretat automàtiques abans d’un canvi; i accés remot sortint segur a routers darrere de CGNAT o en Starlink, sense IP pública ni redirecció de ports — l’enfocament que descrivim a gestió remota de MikroTik darrere de CGNAT. I el seu monitoratge d’Internet Link vigila els mateixos enllaços de pujada que acabes de modelar — la utilització per origen respecte a la velocitat contractada, la latència amb P95, i el consum creuant les bandes del 75% i el 90% en fins a quatre fonts WAN per router — de manera que un enllaç que s’acosta a la saturació apareix al tauler, i (combinat amb les alertes de Telegram) a les teves notificacions, abans que un abonat truqui. Els ISP i WISP que fan servir MikroTik a gran escala l’utilitzen perquè la política d’amplada de banda continuï sent una sola decisió, no cent.

Consells

• Modela a la interfície per on el trànsit surt del router; les cues controlen la sortida, de manera que les baixades es modelen al costat LAN i les pujades al costat WAN.
• Prefereix un sol tipus de cua PCQ abans que centenars de cues simples un cop passes d’unes quantes desenes d’abonats.
• passthrough=no a les regles de mark-packet estalvia el recorregut innecessari de la resta de regles mangle.
• Fes sempre una còpia de seguretat abans de tocar les cues en un edge de producció, i canvia una sola variable cada vegada.

Deixa d’endevinar on ha anat la teva amplada de banda

Les cues són la diferència entre vendre un pla i entregar-lo. Les cues simples limiten un client, els arbres de cues donen estructura i prioritat, PCQ fa que l’equitat sigui automàtica — i MKController converteix les tres en una política que apliques un cop i fas complir a tot arreu: gestió centralitzada de la flota, enviaments de rate-limit i de tallafoc a cada router, historial de configuració amb restauració amb un clic, accés remot sense IP pública, i monitoratge d’Internet Link que assenyala un enllaç que se satura respecte a la seva velocitat contractada abans que ho facin els teus clients.

Comença la teva prova gratuïta de MKController