Hoppa till innehåll
InstagramYouTubeFacebook

Tutorial

MikroTik bandbreddshantering: köer

Så hanterar du bandbredd på MikroTik: enkla köer, köträd med mangle-märken, rättvis PCQ-delning, burst och prioritet, och flottövergripande hastighetsgränser.

Sammanfattning MikroTik bandbreddshantering vilar på tre verktyg: enkla köer för ett snabbt tak per klient, köträd för hierarki och prioritet, och PCQ för rättvis delning mellan många användare utan att skapa en kö åt gången. Köträd paras med brandväggens mangle-märken och ger dig garantier, tak och prioriteter. Den här guiden visar när du ska använda vart och ett, RouterOS-kommandona, och hur du håller samma policy konsekvent över en flotta routrar.

Arbetsflöde för MikroTik bandbreddshantering: begränsa en klient med en enkel kö, märk trafik med brandväggens mangle, bygg ett köträd med föräldra- och barnköer, lägg till en PCQ-kötyp för rättvis delning per användare, justera limit-at, max-limit, burst och priority, och rulla sedan ut samma policy över varje router.

Vad är bandbreddshantering på MikroTik?

Bandbreddshantering på MikroTik är användningen av RouterOS-köer för att styra hur mycket av en länk varje kund, subnät eller trafikklass får förbruka — genom att begränsa hastigheter, garantera miniminivåer och avgöra vem som viker undan när länken är full. RouterOS implementerar köer med en Hierarchical Token Bucket-schemaläggare (HTB), exponerad på två ställen: enkla köer, en ordnad lista som tillämpas i sekvens, och köträdet, en hierarki fäst vid gränssnitt eller vid paketmärken från brandväggens mangle-funktion (MikroTik-dokumentation — Köer).

Distinktionen avgör hur långt din design skalar. En enkel kö svarar på “begränsa den här kunden till 50 Mbps.” Ett köträd svarar på “den här 500 Mbps-upplänken delas av 300 abonnenter, VoIP går först, ingen svälter, och tunga nedladdare förstör inte kvällen.” Varje ISP behöver till slut det andra svaret.

Steg 1 — Begränsa en klient med en enkel kö

Enkla köer är den kortaste vägen från problem till lösning. Rikta mot en IP, ett subnät eller ett gränssnitt, ställ in taket, så är du klar:

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

max-limit skrivs som upload/download sett från routerns perspektiv. Regler utvärderas i ordning och första träffen vinner — så en tidig bred regel sväljer tyst de specifika du lägger till senare. Den ordningen är den vanligaste orsaken till att en “fungerande” kö slutar fungera efter att någon lagt en regel ovanför den (MikroTik-dokumentation — Köer).

Enkla köer paras också med abonnentautentisering: en PPPoE-profils rate-limit-fält skapar en dynamisk enkel kö per session, så att planer följer användaren i stället för IP:n. Vår MikroTik PPPoE-serverguide för ISP:er täcker profilsidan.

Steg 2 — Märk trafik med brandväggens mangle

Köträdet kan inte se “VoIP” eller “kund 101”; det ser paketmärken. Skapa dem i mangle genom att märka anslutningen först och paketen sedan, vilket är billigare än att inspektera varje paket på nytt:

/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

Håll märktaxonomin liten och stabil. Märken är det vokabulär dina köer talar, och när en flotta väl har tre generationer av ad hoc-märknamn kan ingen längre säga vilken router som tillämpar vilken policy. Det är här MKControllers konfigurationsrevision och historik gör sig förtjänt: se mangle- och kötillståndet för varje router, jämför det mot den avsedda policyn, och driv ut de korrigerade reglerna över hela flottan i stället för att öppna trettio Winbox-sessioner för att hitta den enda lådan som aldrig fick ändringen.

Steg 3 — Bygg köträdets hierarki

Ett köträd har en förälder som håller länkens verkliga kapacitet, och barn som delar upp 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 fält gör jobbet. limit-at är garantin ett barn får även när länken är mättad. max-limit är taket det får nå när kapacitet är ledig. priority — 1 är högst, 8 lägst — avgör vilket barn som får överskottet först, och gäller endast mellan limit-at och max-limit (MikroTik-dokumentation — Köer). Sätt förälderns max-limit till vad länken faktiskt levererar, inte vad kontraktet säger, annars blir kön aldrig flaskhalsen och formar aldrig något.

Steg 4 — Lägg till PCQ för rättvis delning

Per Connection Queue (PCQ) är anledningen till att MikroTik skalar till abonnentantal som gör en kölista per användare ohanterlig. En PCQ-kötyp klassificerar trafik efter ett adressfält och skapar en dynamisk delkö för varje distinkt värde, och tillämpar samma hastighet på var och en (MikroTik-dokumentation — PCQ-exempel):

/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

Koppla pcq-down som queue för det barn som bär kundernas nedladdningstrafik, så får varje kund upp till 20 Mbps, tilldelat automatiskt. Sätt pcq-rate=0 så delar PCQ förälderns bandbredd lika mellan alla som är aktiva — den klassiska “ingen svälter”-konfigurationen. En kötyp ersätter hundratals handskrivna poster.

Samma utjämnande logik gäller delat WiFi: planens hastighetsgräns och en PCQ-förälder hindrar tillsammans en gäst från att förbruka en lokals upplänk — se vår guide för MikroTik HotSpot-vouchers för uppgiftssidan.

Steg 5 — Justera limit-at, max-limit, burst och priority

Det mesta trasiga QoS är inte fel verktyg, det är fel siffror. Håll summan av varje barns limit-at på eller under förälderns max-limit; om garantierna översäljer länken kan HTB inte uppfylla dem och prioriteter slutar bete sig som du förväntar dig. Reservera priority=1 för latenskänslig trafik — VoIP, spel, DNS — och låt massöverföringar leva på 8 med ett generöst tak.

Burst förtjänar en varning. burst-limit, burst-threshold och burst-time låter en klient överskrida max-limit en kort stund medan snittet hålls lågt — utmärkt för hastighetstester, sämre för en översåld länk. Mät med /queue simple print stats eller köträdets räknare medan länken är under belastning, inte klockan 3 på natten när allt är stilla. Om det inte är praktiskt att läsa räknare vid toppar håller MKControllers Internet Link-vy samma bild kontinuerligt — nyttjande mot den kontrakterade hastigheten; latens som snitt, max och P95; och hur många timmar varje länk låg över 90 % — så att du justerar mot historik, inte en lyckträff.

Kapaciteten rör sig också. I en uppsättning med dual-WAN-failover är förälderns max-limit som du justerade för fiber ren fiktion i samma stund trafiken landar på LTE-reserven — planera en andra policy.

Steg 6 — Rulla ut policyn över hela flottan

En router är en konfiguration; hundra routrar är en verksamhet. Policyn måste nu vara identisk på varje låda, överleva teknikern som “tillfälligt” höjde en kunds tak, och gå att återställa när en tornrouter netinstalleras. Inget i RouterOS gör det åt dig.

Det gör MKController: flottövergripande utrullningar av kötyper, rate-limit-profiler och brandväggsregler; konfigurationshistorik, så att du kan se när en gräns ändrades och återställa den föregående versionen med ett klick; automatiska säkerhetskopior före en ändring; och säker utgående fjärråtkomst till routrar bakom CGNAT eller på Starlink, utan publik IP och utan portvidarebefordran — tillvägagångssättet vi beskriver i MikroTik fjärrhantering bakom CGNAT. Och dess Internet Link-övervakning bevakar just de upplänkar du nyss formade — nyttjande per källa mot kontrakterad hastighet, latens med P95, och förbrukning som korsar 75 %- och 90 %-banden över upp till fyra WAN-källor per router — så att en länk som kryper mot mättnad dyker upp på panelen, och (parat med Telegram-aviseringar) i dina notiser, innan en abonnent ringer. ISP:er och WISP:ar som kör MikroTik i stor skala använder det för att bandbreddspolicy ska förbli ett beslut, inte hundra.

Tips

  • Forma på det gränssnitt där trafiken lämnar routern; köer styr egress, så nedladdningar formas på LAN-sidan och uppladdningar på WAN-sidan.
  • Föredra en PCQ-kötyp framför hundratals enkla köer när du passerat några dussin abonnenter.
  • passthrough=nomark-packet-regler sparar onödig genomgång av de återstående mangle-reglerna.
  • Säkerhetskopiera alltid innan du rör köer på en produktionskant, och ändra en variabel i taget.

Sluta gissa vart din bandbredd tog vägen

Köer är skillnaden mellan att sälja en plan och att leverera den. Enkla köer begränsar en klient, köträd ger struktur och prioritet, PCQ gör rättvisan automatisk — och MKController förvandlar alla tre till en policy du tillämpar en gång och upprätthåller överallt: centraliserad flotthantering, rate-limit- och brandväggsutrullningar till varje router, konfigurationshistorik med återställning i ett klick, fjärråtkomst utan publik IP, och Internet Link-övervakning som flaggar en länk som mättas mot sin kontrakterade hastighet innan dina kunder gör det.

Starta din kostnadsfria MKController-provperiod