QoS en bandbreedte

QoS gaat niet over sneller internet. Het gaat over wie er wacht als de lijn vol zit. Zolang er ruimte over is doet een wachtrij niets. Zodra iemand een grote upload start, beslist de wachtrij of jouw videogesprek daar last van heeft of niet.

Waar het staat

In geavanceerde modus is het het onderdeel QoS / bandbreedte, standaard uit. In de wizard kun je het als extra aanzetten ("Bandbreedte (QoS)"); je krijgt dan alleen de methode en de twee snelheden te zien, de rest staat in geavanceerd.

Eerst de snelheden, en iets te laag

Je vult Download en Upload in Mbit/s in. Vul hier niet in wat op je contract staat, maar ongeveer 90 tot 95 procent van wat je werkelijk meet. Dat klinkt als weggooien, maar het is de kern van het hele verhaal: de wachtrij werkt alleen als hij zelf de rem is. Zet je de limiet op of boven de echte lijnsnelheid, dan ontstaat de file in het modem van je provider, en daar heeft jouw router niets meer over te zeggen. Dat is precies waarom een verbinding met "genoeg bandbreedte" toch kan haperen tijdens een gesprek.

De vier methodes

Uit

Geen wachtrijen. Er wordt niets gegenereerd.

Totaallimiet

Eén simple queue voor het hele LAN met een maximum omhoog en omlaag. Handig als je een lijn wilt aftoppen, bijvoorbeeld omdat je hem deelt. Er wordt niets verdeeld en niets voorgetrokken.

Eerlijk delen per host

De standaardkeuze, en voor de meeste netwerken de juiste. Elke host krijgt ongeveer een even groot deel, en de latentie blijft laag ook als de lijn vol staat. Je kiest het algoritme: CAKE (aanbevolen, RouterOS 7.1 en hoger), fq_codel, of PCQ (klassiek, met een optioneel maximum per host).

Prioriteiten

Een queue tree met drie klassen, zodat spraak en interactief verkeer voorrang krijgen op downloads. Dit is de zwaarste optie en de enige die mangle-regels nodig heeft.

Eerlijk delen

Bij CAKE maakt de tool twee wachtrijtypes aan, één voor elke richting, met diffserv4, per-host verdeling (dual-dsthost omlaag, dual-srchost omhoog) en cake-nat=yes, want achter NAT ziet de router anders alleen zijn eigen adres. Op de upload staat ook een ACK-filter, omdat die richting meestal de smalle is. Daarna komt er één simple queue op het LAN met jouw limiet.

fq_codel doet in grote lijnen hetzelfde met minder knoppen. PCQ verdeelt per host op bron- of bestemmingsadres, met een optioneel maximum per host.

Wat je hiermee oplost is bufferbloat: die seconde vertraging die opkomt zodra iemand begint te downloaden. Het verschil is direct meetbaar.

Prioriteiten met een queue tree

Hier wordt eerst bepaald wat verkeer is, en daarna hoe het behandeld wordt. Drie schakelaars bepalen wat voorrang krijgt:

• VoIP en video: DSCP EF en AF41, SIP op UDP 5060 en 5061, en kleine UDP-pakketten in de RTP-poortreeks.
• Kleine UDP-pakketten, voor gaming.
• DNS, ICMP en ACK.

De classificatie gebeurt één keer per verbinding, niet per pakket: het eerste pakket krijgt een connection mark, elk volgend pakket wordt met één vergelijking afgehandeld. Daarna staan er twee bomen, download aan het LAN en upload aan de eerste WAN-interface, elk met drie takken: spraak op prioriteit 1, interactief op 2 en de rest op 8. Elke tak heeft een gegarandeerd minimum en mag lenen tot de volle lijnsnelheid.

Twee dingen om te weten. De upload-boom hangt aan de eerste WAN-interface; heb je twee uplinks, dan wordt de tweede niet geshaped en zegt de tool dat ook. En op de oudere MIPS-routers (hAP ac, hEX en familie) shapet dit in software met een plafond rond 200 tot 300 Mbit/s. Vul je daar een hogere snelheid in, dan waarschuwt de tool en stelt hij "eerlijk delen" voor.

Limieten per host

Onderaan staat een tabel waarin je per host of netwerk een maximum omhoog en omlaag zet, met een prioriteit van 1 tot 8. Dit werkt naast de gekozen methode. Gebruik het voor de back-upserver die 's middags niet de hele lijn mag vullen, of voor een gastennetwerk met een plafond. Elke regel wordt een simple queue met een naam die van het adres is afgeleid.

Fasttrack gaat uit

Dit is het belangrijkste neveneffect. Fasttrack stuurt bestaande verbindingen langs de firewall en langs de wachtrijen. Dat is precies wat je wilt voor doorvoer, en precies wat QoS onmogelijk maakt: een fasttracked pakket komt nooit in een queue terecht. Daarom zet de firewall fasttrack automatisch uit zodra QoS actief is, met een regel in het script die uitlegt waarom hij weggelaten is. De tool waarschuwt erbij, want op kleine routers kost dit doorvoer. Dezelfde afweging geldt bij PCC-load balancing. Zie Firewall en NAT.

Wat QoS niet kan

• Een volle uplink leegmaken. Je verdeelt schaarste anders, je maakt hem niet minder. Als vier mensen tegelijk videobellen op 10 Mbit upload, helpt geen enkele wachtrij.
• De download echt sturen. Downloadverkeer is je lijn al over voordat jouw router het ziet. Je kunt het afremmen zodat de afzender zich inhoudt, en dat werkt verrassend goed, maar het blijft indirect. Upload heb je volledig in de hand, download half.
• Congestie bij je provider oplossen. Zit de knoop in het netwerk van je ISP of ergens op internet, dan verandert jouw router daar niets aan. Een lijn die alleen in de avond hapert terwijl je eigen grafieken leeg zijn, is een gesprek met je provider, geen QoS-probleem.
• DSCP afdwingen buiten je netwerk. Markeringen die je meestuurt worden onderweg vaak genegeerd of gewist.

Meten voor en na

Doe een bufferbloat-test terwijl de lijn leeg is, en dezelfde test terwijl er een grote upload loopt. Het verschil in latentie tussen die twee is wat je aan het repareren bent. Op het apparaat zie je met /queue simple print stats of er daadwerkelijk verkeer door je wachtrij gaat, en met /system resource print of de CPU het bijhoudt.

Verder lezen

Recept: bellen blijft helder voor een uitgewerkt geval, Firewall en NAT voor fasttrack, en Meerdere uplinks als je twee lijnen hebt.