Recept: bellen blijft helder als de lijn vol zit

Doel: een gesprek blijft verstaanbaar terwijl iemand anders een grote bestand uploadt of een back-up loopt.

Wat je nodig hebt

Een router die routeert (dus niet de rol switch of access point).
De werkelijke snelheid van je lijn, gemeten, niet die van je contract. Vooral de upload, want daar zit het bij bellen op vast.
De adresreeks die je telefoons krijgen, of het VLAN waar ze op komen.

Waarom een gesprek hapert

Spraak is weinig verkeer, een paar tientallen kilobit per gesprek, maar het is veeleisend in timing. Een pakket dat een halve seconde te laat komt, is net zo goed weg. Zodra iemand een upload start, vult de wachtrij in je modem zich en staan die spraakpakketten achteraan de rij. Het is dus geen bandbreedteprobleem maar een wachtrijprobleem, en daarom los je het op met een wachtrij en niet met een snellere lijn.

Stap 1: een VLAN voor de telefoons

Zet in VLANs een eigen VLAN neer, bijvoorbeeld 40 met 192.168.40.1/24, DHCP aan en internet aan. Laat Geïsoleerd uit als je telefoons een telefooncentrale in je eigen netwerk moeten bereiken; zet hem aan als ze alleen naar een provider in de cloud praten.

Dit is niet alleen netjes. Een eigen VLAN geeft je een adresreeks die je later in één regel kunt aanwijzen, en het houdt broadcast van werkplekken weg bij de toestellen. Zit je telefoon achter een werkplek-pc in de doorlusaansluiting, kijk dan in de handleiding van het toestel welk VLAN het zelf tagt.

Zie VLANs voor de poorttoewijzing: de poorten waar telefoons op komen worden access op dit VLAN, de kabels naar switches en access points worden trunk.

Stap 2: de wachtrij

Zet het onderdeel QoS / bandbreedte aan en vul bij Download en Upload ongeveer 90 tot 95 procent van je gemeten snelheid in. Dat is de stap die het meeste effect heeft en die het vaakst wordt overgeslagen: alleen als jouw router de rem is, kan hij ook kiezen wie er wacht.

Kies dan een van de twee:

Eerlijk delen per host met CAKE. Eén wachtrij, geen mangle-regels, weinig CPU. Het lost bufferbloat op en geeft elke host een eigen deel, waardoor een gesprek in de praktijk al bijna altijd overeind blijft. Begin hier.
Prioriteiten met de queue tree, als eerlijk delen niet genoeg is. Zet Prioriteit: VoIP/video aan. De tool herkent dan DSCP EF en AF41, SIP op UDP 5060 en 5061 en kleine UDP-pakketten in de RTP-reeks, markeert die verbindingen en zet ze op prioriteit 1 in zowel de download- als de uploadboom, met een gegarandeerd deel van de lijn.

De queue tree is zwaarder. Op een hAP ac, hEX of familie shapet hij in software met een plafond rond 200 tot 300 Mbit/s, en de tool waarschuwt als je een hogere snelheid invult. Haal je die grens, dan kloppen je prioriteiten juist niet meer. Neem op zo'n router liever CAKE.

Stap 3: eventueel de rest afremmen

Weet je precies welk apparaat de boosdoener is, de back-upserver bijvoorbeeld, zet die dan in de tabel Limieten per host/netwerk met een maximum en prioriteit 8. Dat is directer dan hopen dat de classificatie het goed ziet.

Stap 4: weet dat fasttrack uit gaat

Zodra QoS actief is, zet de firewall fasttrack uit, want fasttracked verkeer gaat langs de wachtrijen heen. Dat kost doorvoer en CPU. De tool meldt het en laat in het script een regel achter die uitlegt waarom fasttrack er niet staat. Dit is geen fout, het is de prijs.

Testen

Bel terwijl de lijn leeg is. Dat moet goed zijn; is het dat niet, dan zit je probleem niet in de wachtrij.
Start een grote upload en bel opnieuw. Dit is de echte test.
Laat tijdens die upload een /ping lopen naar een vast adres buiten je netwerk. Zonder wachtrij zie je de tijden oplopen van 10 ms naar honderden milliseconden. Met een goed ingestelde wachtrij blijven ze in de buurt van rust.
Kijk met /queue simple print stats of er verkeer door je wachtrij gaat. Staat er nul, dan raakt het verkeer de queue niet.
Bij de queue tree: /queue tree print stats laat per tak zien hoeveel er doorheen ging. Blijft ul-voip op nul terwijl je belt, dan wordt je spraak niet herkend.
Houd /system resource print in de gaten tijdens een volle lijn. Zit de CPU tegen de 100 procent, dan is de router de bottleneck geworden.

Waar het misgaat

De snelheden staan te hoog. Veruit de meest gemaakte fout. De file vormt zich dan in het modem en je router shapet lucht.
Spraak wordt niet herkend. Niet elk toestel markeert met DSCP EF, en sommige providers gebruiken andere poorten dan 5060 of een RTP-reeks buiten de standaard. Loopt het gesprek versleuteld over een tunnel, dan is er van buitenaf helemaal niets aan te zien. In die gevallen werkt een limiet per host op de rest van het netwerk beter dan proberen de spraak te herkennen.
Het gesprek hapert alleen 's avonds. En je eigen grafieken zijn leeg. Dan zit de congestie niet bij jou.

Als het bij je provider zit

Hier houdt het op, en dat is eerlijker om te zeggen dan er nog een knop bij te verzinnen. Jouw router beheert alleen de wachtrij op jouw eigen lijn. Is de knoop in het netwerk van je ISP, op een overvol aggregatiepunt of ergens verderop op internet, dan verandert geen enkele instelling daar iets aan. De download kun je hooguit indirect sturen door hem af te remmen zodat de afzender zich inhoudt; de upload heb je volledig in de hand. Meet daarom eerst waar het misgaat voordat je verder draait: als de latentie al oploopt bij de eerste hop buiten je router terwijl jouw lijn rustig is, is dat een gesprek met je provider.

Verder lezen

QoS en bandbreedte voor alle methodes, VLANs voor het netwerk eromheen, en Als er iets misgaat voor de rest.