MikroTik baandbreddestyring: koer

Resumé MikroTik-båndbreddestyring bygger på tre værktøjer: simple queues til et hurtigt loft pr. klient, queue trees til hierarki og prioritet, og PCQ til fair deling mellem mange brugere uden at oprette en kø for hver. Queue trees går hånd i hånd med firewall mangle-marks og giver dig garantier, lofter og prioriteter. Denne guide viser, hvornår du bruger hver enkelt, RouterOS-kommandoerne, og hvordan du holder den samme politik ensartet på tværs af en flåde af routere.

Hvad er båndbreddestyring på MikroTik?

Båndbreddestyring på MikroTik er brugen af RouterOS-køer til at styre, hvor meget af et link hver kunde, subnet eller trafikklasse må forbruge — ved at begrænse hastigheder, garantere minimumsniveauer og afgøre, hvem der viger, når linket er fyldt. RouterOS implementerer køer med en Hierarchical Token Bucket (HTB)-scheduler, som er tilgængelig to steder: simple queues, en ordnet liste, der anvendes i rækkefølge, og queue tree, et hierarki knyttet til interfaces eller til packet-marks fra firewallens mangle-facilitet (MikroTik-dokumentation — Queues).

Forskellen afgør, hvor langt dit design kan skalere. En simple queue besvarer “begræns denne kunde til 50 Mbps.” Et queue tree besvarer “dette 500 Mbps-uplink deles af 300 abonnenter, VoIP går først, ingen sulter, og storforbrugende downloadere ødelægger ikke aftenen.” Enhver ISP får før eller siden brug for det andet svar.

Trin 1 — Begræns én klient med en simpel kø

Simple queues er den korteste vej fra problem til løsning. Ret mod en IP, et subnet eller et interface, sæt loftet, og så er du færdig:

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

max-limit skrives som upload/download set fra routerens synspunkt. Regler evalueres i rækkefølge, og det første match vinder — så en tidlig bred regel opsluger stille og roligt de specifikke regler, du tilføjer senere. Den rækkefølge er den hyppigste årsag til, at en “fungerende” kø holder op med at virke, efter nogen tilføjer en regel oven over den (MikroTik-dokumentation — Queues).

Simple queues går også hånd i hånd med abonnentgodkendelse: en PPPoE-profils rate-limit-felt opretter en dynamisk simple queue pr. session, så planer følger brugeren i stedet for IP’en. Vores MikroTik PPPoE-servervejledning for ISP’er dækker profilsiden.

Trin 2 — Marker trafik med firewall mangle

Queue tree kan ikke se “VoIP” eller “kunde 101”; det ser packet-marks. Opret dem i mangle ved at markere forbindelsen først og pakkerne derefter, hvilket er billigere end at genundersøge hver enkelt pakke:

/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

Hold mark-taksonomien lille og stabil. Marks er det ordforråd, dine køer taler, og når først en flåde har tre generationer af ad hoc-marknavne, kan ingen sige, hvilken router der håndhæver hvilken politik. Det er her, MKControllers konfigurationsaudit og historik gør nytte: se mangle- og køtilstanden for hver router, sammenlign den med den tilsigtede politik, og udrul de korrigerede regler på tværs af hele flåden i stedet for at åbne tredive Winbox-sessioner for at finde den ene boks, der aldrig fik ændringen.

Trin 3 — Byg queue tree-hierarkiet

Et queue tree har én parent, der holder linkets reelle kapacitet, og children, der deler den:

/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 felter gør arbejdet. limit-at er den garanti, en child modtager, selv når linket er mættet. max-limit er det loft, den må nå, når kapacitet er ledig. priority — 1 er højest, 8 lavest — afgør, hvilken child der først får resterne, og gælder kun mellem limit-at og max-limit (MikroTik-dokumentation — Queues). Sæt parentens max-limit til det, linket faktisk leverer, ikke det, kontrakten siger, ellers bliver køen aldrig flaskehalsen og former aldrig noget.

Trin 4 — Tilføj PCQ til fair deling

Per Connection Queue (PCQ) er grunden til, at MikroTik skalerer til abonnentantal, der gør en køliste pr. bruger uoverskuelig. En PCQ-køtype klassificerer trafik efter et adressefelt og opretter en dynamisk underkø for hver enkelt værdi, hvor den samme rate anvendes på hver (MikroTik-dokumentation — 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

Tilknyt pcq-down som queue for den child, der bærer kundernes downloadtrafik, og hver kunde får op til 20 Mbps, tildelt automatisk. Sæt pcq-rate=0, og PCQ deler parentens båndbredde ligeligt mellem alle aktive — den klassiske “ingen sulter”-konfiguration. Én køtype erstatter hundredvis af håndskrevne poster.

Den samme udligningslogik gælder for delt WiFi: planens rate limit og en PCQ-parent forhindrer sammen én gæst i at opsluge en lokations uplink — se vores MikroTik HotSpot voucher-opsætningsguide for legitimationssiden.

Trin 5 — Finjuster limit-at, max-limit, burst og priority

De fleste ødelagte QoS er ikke et forkert værktøj, men forkerte tal. Hold summen af hver childs limit-at på eller under parentens max-limit; hvis garantierne overtegner linket, kan HTB ikke honorere dem, og prioriteter opfører sig ikke, som du forventer. Reserver priority=1 til latensfølsom trafik — VoIP, gaming, DNS — og lad masseoverførsler leve på 8 med et generøst loft.

Burst fortjener en advarsel. burst-limit, burst-threshold og burst-time lader en klient kortvarigt overskride max-limit, mens dens gennemsnit forbliver lavt — glimrende til hastighedstests, værre for et overtegnet link. Mål med /queue simple print stats eller queue tree-tællerne, mens linket er under belastning, ikke kl. 3 om natten, når alt er inaktivt. Hvis det ikke er praktisk at aflæse tællere i spidsbelastning, holder MKControllers Internet Link-visning det samme billede løbende — udnyttelse i forhold til den kontraktfastsatte hastighed; latens som gennemsnit, maks og P95; og hvor mange timer hvert link tilbragte over 90% — så du finjusterer mod historik, ikke et heldigt øjebliksbillede.

Kapacitet flytter sig også. På en dual-WAN failover-opsætning er den parent-max-limit, du finjusterede til fiber, ren fiktion i det øjeblik trafikken lander på LTE-backuppen — planlæg en anden politik.

Trin 6 — Udrul politikken på tværs af flåden

Én router er en konfiguration; hundrede routere er en drift. Politikken skal nu være identisk på hver boks, overleve teknikeren, der “midlertidigt” hævede en kundes loft, og kunne gendannes, når en tårnrouter bliver netinstalleret. Intet i RouterOS gør det for dig.

Det gør MKController: flådedækkende udrulninger af køtyper, rate-limit-profiler og firewall-regler; konfigurationshistorik, så du kan se, hvornår en grænse ændrede sig, og gendanne den forrige version med ét klik; automatiske backups før en ændring; og sikker udgående fjernadgang til routere bag CGNAT eller på Starlink, uden offentlig IP og uden portviderstilling — den fremgangsmåde, vi beskriver i MikroTik fjernadministration bag CGNAT. Og dens Internet Link-overvågning holder øje med præcis de uplinks, du lige har formet — udnyttelse pr. kilde i forhold til kontraktfastsat hastighed, latens med P95, og forbrug der krydser 75%- og 90%-båndene på op til fire WAN-kilder pr. router — så et link, der kryber mod mætning, dukker op på dashboardet, og (parret med Telegram-alarmer) i dine notifikationer, før en abonnent ringer. ISP’er og WISP’er, der kører MikroTik i stor skala, bruger det, så båndbreddepolitik forbliver én beslutning, ikke hundrede.

Tips

• Form på det interface, hvor trafikken forlader routeren; køer styrer egress, så downloads formes på LAN-siden og uploads på WAN-siden.
• Foretræk én PCQ-køtype frem for hundredvis af simple queues, når du passerer et par dusin abonnenter.
• passthrough=no på mark-packet-regler sparer unødig gennemgang af de resterende mangle-regler.
• Tag altid backup, før du rører køer på en produktions-edge, og ændr én variabel ad gangen.

Stop med at gætte, hvor din båndbredde blev af

Køer er forskellen mellem at sælge en plan og at levere den. Simple queues begrænser en klient, queue trees giver struktur og prioritet, PCQ gør retfærdighed automatisk — og MKController gør alle tre til en politik, du anvender én gang og håndhæver alle steder: centraliseret flådestyring, udrulning af rate-limit og firewall til hver router, konfigurationshistorik med gendannelse med ét klik, fjernadgang uden offentlig IP, og Internet Link-overvågning, der flager et link, der mætter i forhold til sin kontraktfastsatte hastighed, før dine kunder gør det.

Start din gratis MKController-prøveperiode