MikroTik Bandbreitenverwaltung: Queues

Zusammenfassung Die MikroTik-Bandbreitenverwaltung stützt sich auf drei Werkzeuge: Simple Queues für eine schnelle Begrenzung pro Client, Queue Trees für Hierarchie und Priorität und PCQ für Fair-Sharing unter vielen Nutzern, ohne für jeden eine eigene Queue anzulegen. Queue Trees arbeiten mit Firewall-mangle-Marks zusammen und geben Ihnen Garantien, Obergrenzen und Prioritäten. Dieser Leitfaden zeigt, wann Sie was einsetzen, die RouterOS-Befehle und wie Sie dieselbe Richtlinie über eine ganze Router-Flotte konsistent halten.

Was ist Bandbreitenverwaltung auf MikroTik?

Bandbreitenverwaltung auf MikroTik ist der Einsatz von RouterOS-Queues, um zu steuern, wie viel eines Links jeder Kunde, jedes Subnetz oder jede Traffic-Klasse verbrauchen darf — Raten begrenzen, Mindestwerte garantieren und entscheiden, wer zurücksteckt, wenn der Link voll ist. RouterOS setzt Queues mit einem Hierarchical Token Bucket (HTB)-Scheduler um, der an zwei Stellen verfügbar ist: Simple Queues, eine der Reihe nach abgearbeitete geordnete Liste, und der Queue Tree, eine Hierarchie, die an Interfaces oder an Packet-Marks aus der mangle-Funktion der Firewall angehängt wird (MikroTik-Dokumentation — Queues).

Diese Unterscheidung entscheidet, wie weit Ihr Design skaliert. Eine Simple Queue beantwortet „begrenze diesen Kunden auf 50 Mbps“. Ein Queue Tree beantwortet „dieser 500-Mbps-Uplink wird von 300 Teilnehmern geteilt, VoIP geht zuerst, niemand kommt zu kurz, und starke Downloader ruinieren nicht den Abend“. Jeder ISP braucht irgendwann die zweite Antwort.

Schritt 1 — Einen Client mit einer Simple Queue begrenzen

Simple Queues sind der kürzeste Weg vom Problem zur Lösung. Zielen Sie auf eine IP, ein Subnetz oder ein Interface, setzen Sie die Obergrenze, und Sie sind fertig:

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

max-limit wird aus Sicht des Routers als upload/download geschrieben. Regeln werden der Reihe nach ausgewertet, und der erste Treffer gewinnt — eine frühe, breite Regel verschluckt also stillschweigend die spezifischen, die Sie später hinzufügen. Diese Reihenfolge ist der häufigste Grund, warum eine „funktionierende“ Queue nicht mehr arbeitet, nachdem jemand darüber eine Regel eingefügt hat (MikroTik-Dokumentation — Queues).

Simple Queues lassen sich auch mit der Teilnehmerauthentifizierung kombinieren: Das Feld rate-limit eines PPPoE-Profils erzeugt pro Sitzung eine dynamische Simple Queue, sodass Tarife dem Nutzer statt der IP folgen. Unser Leitfaden zum MikroTik-PPPoE-Server für ISPs behandelt die Profilseite.

Schritt 2 — Traffic mit Firewall-mangle markieren

Der Queue Tree sieht weder „VoIP“ noch „Kunde 101“; er sieht Packet-Marks. Erzeugen Sie diese in mangle, indem Sie zuerst die Verbindung und dann die Pakete markieren, was günstiger ist, als jedes Paket erneut zu prüfen:

/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

Halten Sie die Mark-Taxonomie klein und stabil. Marks sind das Vokabular, das Ihre Queues sprechen, und sobald eine Flotte drei Generationen improvisierter Mark-Namen hat, kann niemand mehr sagen, welcher Router welche Richtlinie durchsetzt. Genau hier zahlen sich Konfigurationsaudit und Historie von MKController aus: den mangle- und Queue-Zustand jedes Routers sehen, ihn gegen die beabsichtigte Richtlinie abgleichen und die korrigierten Regeln flottenweit ausrollen, statt dreißig Winbox-Sitzungen zu öffnen, um die eine Box zu finden, die die Änderung nie bekommen hat.

Schritt 3 — Die Queue-Tree-Hierarchie aufbauen

Ein Queue Tree hat einen Parent, der die reale Kapazität des Links hält, und Children, die sie aufteilen:

/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

Drei Felder erledigen die Arbeit. limit-at ist die Garantie, die ein Child selbst dann erhält, wenn der Link gesättigt ist. max-limit ist die Obergrenze, die es erreichen darf, wenn Kapazität frei ist. priority — 1 ist am höchsten, 8 am niedrigsten — entscheidet, welches Child die Reste zuerst bekommt, und gilt nur zwischen limit-at und max-limit (MikroTik-Dokumentation — Queues). Setzen Sie das max-limit des Parents auf das, was der Link tatsächlich liefert, nicht auf das, was der Vertrag sagt, sonst wird die Queue nie zum Flaschenhals und shapt nie etwas.

Schritt 4 — PCQ für Fair-Sharing hinzufügen

Per Connection Queue (PCQ) ist der Grund, warum MikroTik auf Teilnehmerzahlen skaliert, bei denen eine Queue-Liste pro Nutzer unbeherrschbar wird. Ein PCQ-Queue-Typ klassifiziert Traffic nach einem Adressfeld und erzeugt für jeden eigenständigen Wert eine dynamische Sub-Queue, auf die jeweils dieselbe Rate angewendet wird (MikroTik-Dokumentation — PCQ-Beispiel):

/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

Hängen Sie pcq-down als queue des Childs an, das den Download-Traffic der Kunden trägt, und jeder Kunde erhält bis zu 20 Mbps, automatisch zugeteilt. Setzen Sie pcq-rate=0, und PCQ verteilt die Bandbreite des Parents gleichmäßig auf alle Aktiven — die klassische „niemand kommt zu kurz“-Konfiguration. Ein Queue-Typ ersetzt Hunderte handgeschriebener Einträge.

Dieselbe ausgleichende Logik gilt für gemeinsam genutztes WiFi: Das Rate-Limit des Tarifs und ein PCQ-Parent hindern zusammen einen einzelnen Gast daran, den Uplink eines Standorts aufzubrauchen — die Zugangsdatenseite behandelt unser Leitfaden zur MikroTik-HotSpot-Voucher-Einrichtung.

Schritt 5 — limit-at, max-limit, burst und priority abstimmen

Das meiste kaputte QoS ist kein falsches Werkzeug, sondern falsche Zahlen. Halten Sie die Summe der limit-at aller Children auf oder unter dem max-limit des Parents; wenn die Garantien den Link überbuchen, kann HTB sie nicht einhalten, und Prioritäten verhalten sich nicht mehr wie erwartet. Reservieren Sie priority=1 für latenzempfindlichen Traffic — VoIP, Gaming, DNS — und lassen Sie Massentransfers bei 8 mit einer großzügigen Obergrenze leben.

burst verdient eine Warnung. burst-limit, burst-threshold und burst-time lassen einen Client max-limit kurzzeitig überschreiten, solange sein Durchschnitt niedrig bleibt — gut für Speedtests, schlechter für einen überbuchten Link. Messen Sie mit /queue simple print stats oder den Queue-Tree-Zählern, während der Link unter Last steht, nicht um 3 Uhr nachts, wenn alles im Leerlauf ist. Wenn das Ablesen der Zähler zur Spitzenzeit nicht praktikabel ist, hält die Internet-Link-Ansicht von MKController dasselbe Bild kontinuierlich fest — Auslastung gegenüber der vertraglich zugesicherten Geschwindigkeit; Latenz als Durchschnitt, Maximum und P95; und wie viele Stunden jeder Link über 90 % lag — sodass Sie gegen die Historie abstimmen, nicht gegen eine glückliche Momentaufnahme.

Auch die Kapazität verschiebt sich. Bei einem Dual-WAN-Failover-Setup ist das max-limit des Parents, das Sie für Glasfaser abgestimmt haben, in dem Moment Fiktion, in dem Traffic auf dem LTE-Backup landet — planen Sie eine zweite Richtlinie.

Schritt 6 — Die Richtlinie über die Flotte ausrollen

Ein Router ist eine Konfiguration; hundert Router sind ein Betrieb. Die Richtlinie muss nun auf jeder Box identisch sein, den Techniker überstehen, der „vorübergehend“ die Obergrenze eines Kunden angehoben hat, und wiederherstellbar sein, wenn ein Turm-Router per netinstall neu aufgesetzt wird. Nichts in RouterOS erledigt das für Sie.

MKController schon: flottenweite Pushes von Queue-Typen, rate-limit-Profilen und Firewall-Regeln; Konfigurationshistorie, sodass Sie sehen, wann sich ein Limit geändert hat, und die vorherige Version mit einem Klick wiederherstellen; automatische Backups vor einer Änderung; und sicheren ausgehenden Fernzugriff auf Router hinter CGNAT oder an Starlink, ohne öffentliche IP und ohne Port-Forwarding — der Ansatz, den wir in MikroTik-Fernverwaltung hinter CGNAT beschreiben. Und sein Internet-Link-Monitoring überwacht genau die Uplinks, die Sie gerade geshapt haben — Auslastung pro Quelle gegenüber der vertraglich zugesicherten Geschwindigkeit, Latenz mit P95 und Verbrauch, der die 75-%- und 90-%-Schwellen über bis zu vier WAN-Quellen pro Router überschreitet — sodass ein Link, der auf Sättigung zusteuert, auf dem Dashboard und (gepaart mit Telegram-Benachrichtigungen) in Ihren Benachrichtigungen auftaucht, bevor ein Teilnehmer anruft. ISPs und WISPs, die MikroTik im großen Maßstab betreiben, nutzen es, damit die Bandbreitenrichtlinie eine Entscheidung bleibt, nicht hundert.

Tipps

• Shapen Sie auf dem Interface, an dem der Traffic den Router verlässt; Queues steuern den Egress, sodass Downloads auf der LAN-Seite und Uploads auf der WAN-Seite geshapt werden.
• Bevorzugen Sie einen PCQ-Queue-Typ gegenüber Hunderten Simple Queues, sobald Sie einige Dutzend Teilnehmer überschreiten.
• passthrough=no bei mark-packet-Regeln erspart das unnötige Durchlaufen der übrigen mangle-Regeln.
• Sichern Sie immer, bevor Sie Queues an einem produktiven Edge anfassen, und ändern Sie jeweils nur eine Variable.

Hören Sie auf zu raten, wohin Ihre Bandbreite geht

Queues sind der Unterschied zwischen einen Tarif verkaufen und ihn liefern. Simple Queues begrenzen einen Client, Queue Trees geben Struktur und Priorität, PCQ macht Fairness automatisch — und MKController macht aus allen dreien eine Richtlinie, die Sie einmal anwenden und überall durchsetzen: zentralisiertes Flottenmanagement, rate-limit- und Firewall-Pushes an jeden Router, Konfigurationshistorie mit Ein-Klick-Wiederherstellung, Fernzugriff ohne öffentliche IP und Internet-Link-Monitoring, das einen Link meldet, der gegen seine vertraglich zugesicherte Geschwindigkeit sättigt, bevor Ihre Kunden es tun.

Kostenlose MKController-Testversion starten