De snelheidslimiet doet niets

Je hebt een limiet ingesteld, met de bedoeling dat een gast niet de hele lijn opslokt of dat je videobellen niet meer hapert. De limiet staat in /queue simple print, maar er verandert niets. De speedtest haalt nog steeds alles, of de prioriteiten die je hebt bedacht zijn niet terug te zien.

Wat het niet is: dit is zelden een verkeerd getal. Een wachtrij die te ruim staat, remt zichtbaar iets af. Een wachtrij die helemaal niets doet, ziet geen enkel pakket. Dat is een ander soort fout.

De belangrijkste reden is de meest verrassende: FastTrack. Dat is het snelle pad dat RouterOS gebruikt voor verbindingen die het al kent, en het slaat de firewall en de wachtrijen over. Je kunt de twee niet allebei hebben.

De snelle controles, op volgorde

1. Loopt de teller? /queue simple print stats, en voor een boom /queue tree print stats. Goed antwoord: de bytes lopen op terwijl je downloadt. Blijft alles op nul, dan komt er geen verkeer langs en heeft de limiet zelf niets met het probleem te maken.
2. Staat FastTrack aan? /ip firewall filter print stats en zoek de regel met actie fasttrack-connection. Goed antwoord bij actieve queues: die regel staat er niet, of hij staat er als commentaar. Staat hij er wel en loopt zijn teller hard op, dan gaat je verkeer om de wachtrijen heen.
3. In welke volgorde? Kijk naar de nummering in /queue simple print. Simple queues worden van boven naar beneden afgelopen en de eerste die past, pakt het verkeer. Staat er een brede queue op de bridge boven je limiet per host, dan komt die host er nooit aan toe.
4. Bij een boom: worden er marks gezet? /ip firewall mangle print stats. Goed antwoord: de regels die connection-marks zetten tellen op, en de regels die packet-marks zetten ook. Een queue tree zonder passende packet-mark is een lege doos.
5. Is de limiet lager dan de lijn? /interface monitor-traffic interface=ether1 tijdens een test. Goed antwoord: de snelheid blijft onder wat je hebt ingesteld. Staat je limiet op 500 Mbit/s en haal je 400, dan doet de queue niets omdat er niets te beperken valt.

De gewone oorzaken, meest voorkomend eerst

De methode staat op Uit, dus er is niets gegenereerd

Dit is de val die in de configurator zelf zit en het is de eerste die je moet uitsluiten. Zet je in het onderdeel QoS de Methode op Uit en vul je daaronder wel een lijstje Limieten per host in, dan komen die limieten niet in het script. Het hele onderdeel houdt op zodra de methode uit staat, ook voor de limieten per host. Er verschijnt geen foutmelding. Kies dus een methode, ook als je alleen per host wilt beperken.

Er hangt nog iets aan vast: zolang de methode uit staat, blijft FastTrack aan. Zou je die limieten met de hand toevoegen, dan zien ze alsnog geen verkeer.

FastTrack pakt het verkeer weg

Fasttracked verkeer gaat langs de firewall en langs de wachtrijen. Een queue op een router waar FastTrack aan staat, ziet alleen de eerste pakketten van elke verbinding en daarna niets meer. Het is niet mogelijk om allebei te hebben; je kiest tussen piekdoorvoer en controle over de verdeling.

De limiet staat boven de werkelijke lijnsnelheid

Zet de limiet iets onder wat je lijn echt haalt, ongeveer 90 tot 95 procent. Staat hij erboven, dan wordt de wachtrij bij het modem van je provider gevormd en niet bij jou, en daar heb je geen controle over. Dat is ook de kern van bufferbloat: de vertraging ontstaat in een buffer die van iemand anders is.

Het verkeer komt niet langs de router

Twee apparaten in hetzelfde VLAN op dezelfde switch praten via de switch-chip en komen nooit bij de CPU. Geen enkele queue kan dat beperken.

Bij een queue tree ontbreekt de mark

Een queue tree werkt op packet-marks. Klopt er iets niet in de mangle-regels, of markeert een eerdere regel het verkeer al anders, dan hangen er takken zonder verkeer. Kijk altijd eerst bij mangle en pas daarna bij de boom.

Wat de configurator hiervan doet

• In het onderdeel QoS / bandbreedte kies je een methode: uit, één totaallimiet, eerlijk delen per host met CAKE, fq_codel of PCQ, of prioriteiten via een queue tree. Eerlijk delen met CAKE is de standaard en voor de meeste netwerken het juiste antwoord.
• Zodra er een methode aan staat, zet de firewall FastTrack uit. De tool zegt dat er ook bij: QoS actief betekent FastTrack uit, dat verhoogt de CPU-belasting en kost op kleine routers doorvoer. In het script staat op de plek van de FastTrack-regel een commentaar dat zegt waarom hij ontbreekt.
• Kies je een queue tree op een oudere MIPS-router en vul je meer dan 200 Mbit/s in, dan rekent de tool het voor: dit apparaat shapet in software en haalt met FastTrack uit naar schatting 200 tot 300 Mbit/s, dus de CPU wordt de bottleneck en de prioriteiten kloppen niet meer. Met het advies erbij om eerlijk delen met CAKE of fq_codel te gebruiken: één wachtrij, geen mangle-regels, fors minder CPU.
• Bij twee WAN-lijnen met een queue tree waarschuwt de tool dat de upload-wachtrij aan de eerste WAN-interface hangt en de tweede niet geshapet wordt.
• De queue tree zelf is gebouwd om goedkoop te zijn: het dure matchen gebeurt alleen op het eerste pakket van een verbinding, dat een connection-mark krijgt, en elk volgend pakket wordt met één vergelijking geclassificeerd.
• Wat de tool niet doet: hij waarschuwt je niet als je limieten per host invult terwijl de methode op uit staat. Dat is de gaatje waar de meeste mensen in stappen.

Als het niet aan je router ligt

• Wifi. Een langzame client op wifi vertraagt de rest op een manier die geen wachtrij op de router oplost. Zie Wifi is traag.

Verder lezen: QoS en bandbreedte, CPU op 100 procent en Controles over snelheid.