Tutorial
MikroTik båndbreddestyring: køer
Slik styrer du båndbredde på MikroTik: enkle køer, køtre med mangle-merker, PCQ-rettferdig deling, burst og prioritet, og flåtevide hastighetsgrenser.
Sammendrag MikroTik båndbreddestyring hviler på tre verktøy: enkle køer for en rask begrensning per klient, køtrær for hierarki og prioritet, og PCQ for rettferdig deling blant mange brukere uten å lage en kø hver. Køtrær kombineres med brannmurens mangle-merker og gir deg garantier, tak og prioriteter. Denne guiden viser når du skal bruke hver av dem, RouterOS-kommandoene, og hvordan du holder samme policy konsistent på tvers av en flåte av rutere.

Hva Er Båndbreddestyring på MikroTik?
Båndbreddestyring på MikroTik er bruken av RouterOS-køer for å kontrollere hvor mye av en lenke hver kunde, subnett eller trafikklasse kan forbruke — begrense hastigheter, garantere minimum, og avgjøre hvem som viker når lenken er full. RouterOS implementerer køer med en Hierarchical Token Bucket (HTB)-planlegger, eksponert på to steder: enkle køer, en ordnet liste som brukes i rekkefølge, og køtreet, et hierarki festet til grensesnitt eller til pakkemerker fra brannmurens mangle-funksjon (MikroTik-dokumentasjon — Queues).
Skillet avgjør hvor langt designet ditt skalerer. En enkel kø svarer «begrens denne kunden til 50 Mbps». Et køtre svarer «denne 500 Mbps-opplenken deles av 300 abonnenter, VoIP går først, ingen sulter, og storforbrukere av nedlasting ødelegger ikke kvelden». Hver ISP trenger til slutt det andre svaret.
Steg 1 — Begrens én klient med en enkel kø
Enkle køer er den korteste veien fra problem til løsning. Rett mot en IP, et subnett eller et grensesnitt, sett taket, og du er ferdig:
/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50Mmax-limit skrives som upload/download sett fra ruterens ståsted. Regler evalueres i rekkefølge og første treff vinner — så en tidlig bred regel svelger stille de spesifikke du legger til senere. Den rekkefølgen er den vanligste grunnen til at en «fungerende» kø slutter å fungere etter at noen legger en regel over den (MikroTik-dokumentasjon — Queues).
Enkle køer kombineres også med abonnentautentisering: en PPPoE-profils rate-limit-felt oppretter en dynamisk enkel kø per økt, slik at planer følger brukeren i stedet for IP-en. Vår MikroTik PPPoE-serverguide for ISP-er dekker profilsiden.
Steg 2 — Merk trafikk med brannmur-mangle
Køtreet kan ikke se «VoIP» eller «kunde 101»; det ser pakkemerker. Opprett dem i mangle, ved å merke tilkoblingen først og pakkene etterpå, noe som er billigere enn å inspisere hver pakke på nytt:
/ip firewall mangleadd chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=noHold merketaksonomien liten og stabil. Merker er vokabularet køene dine snakker, og når en flåte først har tre generasjoner av ad-hoc merkenavn, kan ingen si hvilken ruter som håndhever hvilken policy. Det er her MKControllers konfigurasjonsrevisjon og historikk gjør nytten: se mangle- og køtilstanden til hver ruter, sammenlign den mot den tiltenkte policyen, og push de korrigerte reglene flåtevidt i stedet for å åpne tretti Winbox-økter for å finne den ene boksen som aldri fikk endringen.
Steg 3 — Bygg køtre-hierarkiet
Et køtre har én forelder som holder lenkens reelle kapasitet, og barn som deler den:
/queue treeadd name=download parent=bridge-lan max-limit=500Madd name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8Tre felt gjør jobben. limit-at er garantien et barn mottar selv når lenken er mettet. max-limit er taket det kan nå når kapasitet er ledig. priority — 1 er høyest, 8 lavest — avgjør hvilket barn som får restene først, og gjelder kun mellom limit-at og max-limit (MikroTik-dokumentasjon — Queues). Sett forelderens max-limit til det lenken faktisk leverer, ikke det kontrakten sier, ellers blir køen aldri flaskehalsen og former aldri noe.
Steg 4 — Legg til PCQ for rettferdig deling
Per Connection Queue (PCQ) er grunnen til at MikroTik skalerer til abonnenttall som gjør en køliste per bruker uhåndterlig. En PCQ-køtype klassifiserer trafikk etter et adressefelt og oppretter en dynamisk underkø for hver distinkte verdi, med samme hastighet på hver (MikroTik-dokumentasjon — PCQ example):
/queue typeadd name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-addressadd name=pcq-up kind=pcq pcq-rate=10M pcq-classifier=src-addressFest pcq-down som queue for barnet som bærer kundens nedlastingstrafikk, og hver kunde får opptil 20 Mbps, tildelt automatisk. Sett pcq-rate=0 og PCQ deler forelderens båndbredde likt mellom hvem enn som er aktiv — den klassiske «ingen sulter»-konfigurasjonen. Én køtype erstatter hundrevis av håndskrevne oppføringer.
Samme utjevningslogikk gjelder for delt WiFi: planens hastighetsgrense og en PCQ-forelder stopper sammen én gjest fra å forbruke et lokales opplenke — se vår MikroTik HotSpot-kupongoppsettguide for legitimasjonssiden.
Steg 5 — Juster limit-at, max-limit, burst og priority
De fleste ødelagte QoS er ikke feil verktøy, det er feil tall. Hold summen av hvert barns limit-at på eller under forelderens max-limit; hvis garantiene overtegner lenken, kan ikke HTB innfri dem og prioriteter slutter å oppføre seg som du forventer. Reserver priority=1 for latenssensitiv trafikk — VoIP, spilling, DNS — og la bulkoverføringer leve på 8 med et sjenerøst tak.
Burst fortjener en advarsel. burst-limit, burst-threshold og burst-time lar en klient overskride max-limit kort mens gjennomsnittet holder seg lavt — flott for hastighetstester, verre for en overtegnet lenke. Mål med /queue simple print stats eller køtre-tellerne mens lenken er under last, ikke klokken 3 om natten når alt er inaktivt. Hvis det ikke er praktisk å lese tellere ved topp, holder MKControllers Internet Link-visning det samme bildet kontinuerlig — utnyttelse mot den avtalte hastigheten; latens som gjennomsnitt, maks og P95; og hvor mange timer hver lenke tilbrakte over 90 % — slik at du justerer mot historikk, ikke et heldig øyeblikksbilde.
Kapasitet flytter seg også. På et dual-WAN failover-oppsett er forelderens max-limit du justerte for fiber ren fiksjon i det øyeblikket trafikken lander på LTE-reserven — planlegg en annen policy.
Steg 6 — Rull ut policyen på tvers av flåten
Én ruter er en konfigurasjon; hundre rutere er en operasjon. Policyen må nå være identisk på hver boks, overleve teknikeren som «midlertidig» hevet en kundes tak, og kunne gjenopprettes når en tårnruter netinstalleres. Ingenting i RouterOS gjør det for deg.
Det gjør MKController: flåtevide pushes av køtyper, rate-limit-profiler og brannmurregler; konfigurasjonshistorikk, slik at du kan se når en grense endret seg og gjenopprette forrige versjon med ett klikk; automatiske sikkerhetskopier før en endring; og sikker utgående fjerntilgang til rutere bak CGNAT eller på Starlink, uten offentlig IP og uten portviderekobling — tilnærmingen vi beskriver i MikroTik fjernadministrasjon bak CGNAT. Og dens Internet Link-overvåking holder øye med nettopp de opplenkene du akkurat formet — utnyttelse per kilde mot avtalt hastighet, latens med P95, og forbruk som krysser 75 %- og 90 %-båndene på tvers av opptil fire WAN-kilder per ruter — slik at en lenke som kryper mot metning dukker opp på dashbordet, og (kombinert med Telegram-varsler) i varslene dine, før en abonnent ringer. ISP-er og WISP-er som kjører MikroTik i stor skala bruker det slik at båndbreddepolicy forblir én beslutning, ikke hundre.
Tips
- Form på grensesnittet der trafikken forlater ruteren; køer kontrollerer utgående, så nedlastinger formes på LAN-siden og opplastinger på WAN-siden.
- Foretrekk én PCQ-køtype fremfor hundrevis av enkle køer når du passerer noen titalls abonnenter.
passthrough=nopåmark-packet-regler sparer unødvendig gjennomgang av de gjenværende mangle-reglene.- Ta alltid sikkerhetskopi før du rører køer på en produksjonskant, og endre én variabel om gangen.
Slutt å gjette hvor båndbredden ble av
Køer er forskjellen mellom å selge en plan og å levere den. Enkle køer begrenser en klient, køtrær gir struktur og prioritet, PCQ gjør rettferdighet automatisk — og MKController gjør alle tre om til en policy du bruker én gang og håndhever overalt: sentralisert flåteadministrasjon, rate-limit- og brannmur-pushes til hver ruter, konfigurasjonshistorikk med gjenoppretting med ett klikk, fjerntilgang uten offentlig IP, og Internet Link-overvåking som flagger en lenke som metter seg mot sin avtalte hastighet før kundene dine gjør det.