De CPU van de router staat op 100 procent

WinBox laat een CPU zien die tegen de 100 procent aan hangt, of daar gewoon staat. De router reageert traag, een snelheidstest haalt een fractie van je lijn, en soms valt er verkeer weg zonder dat er een foutmelding bij hoort. Vaak is het begonnen na een verandering: VLANs erbij, QoS aangezet, een tweede internetlijn.

Wat het niet is: een CPU-piek van een paar seconden bij het opstarten, bij een export of tijdens een snelheidstest is normaal. En een router die vol zit doordat er een lus in je netwerk zit, heeft geen CPU-probleem maar een lus. Kijk eerst of er iets ongewoons aan verkeer langskomt.

De snelle controles, op volgorde

1. Hoeveel is het werkelijk? /system resource print toont cpu-load, het aantal cores en het vrije geheugen. Een goed antwoord op een rustig moment is onder de 10 procent, en onder belasting ruim onder de 100.
2. Waar gaat de tijd heen? /tool profile duration=5. Dit is het belangrijkste commando van dit hoofdstuk. Het toont per onderdeel hoeveel procent het kost. Veel bij networking of firewall betekent dat je verkeer door de CPU gaat in plaats van eromheen. Veel bij bridging wijst op verkeer dat niet door de switch-chip gaat. Veel bij queue is je QoS, veel bij management is monitoring.
3. Hoeveel verkeer is het eigenlijk? /interface monitor-traffic interface=ether1. 900 Mbit/s door een klein bordje is een verklaring. 20 Mbit/s met een volle CPU is dat niet, en dan zoek je verder.
4. Doet FastTrack zijn werk? /ip firewall filter print stats. Zoek de regel met actie fasttrack-connection. Een goed antwoord is een teller die hard oploopt. Staat de regel er niet, of blijft de teller op nul, dan gaat elk pakket door de hele firewall.
5. Loopt het verkeer door de switch-chip? /interface bridge port print en kijk naar de offload-status per poort. Poorten zonder offload worden door de CPU geswitcht.
6. Hoeveel verbindingen staan er open? /ip firewall connection print count-only. Tienduizenden verbindingen kosten geheugen en rekentijd.

De gewone oorzaken, meest voorkomende eerst

FastTrack staat uit omdat je wachtrijen gebruikt

FastTrack slaat voor bekende verbindingen de firewall en de wachtrijen over. Dat is precies wat hem snel maakt, en precies waarom een wachtrij dat verkeer niet kan zien. Je kunt de twee niet tegelijk hebben. Zet je QoS aan, dan gaat FastTrack eruit en gaat elk pakket door de volledige firewall. Op een klein bordje zie je dat meteen in de doorvoer.

De afweging: zijn de prioriteiten belangrijker dan de pieksnelheid? Voor een lijn waar bufferbloat het probleem is, meestal wel. Voor een lijn die gewoon vol moet kunnen, niet.

PCC-loadbalancing over twee lijnen

Hetzelfde verhaal: PCC werkt met mangle-markeringen, en die zijn niet te combineren met FastTrack. Twee lijnen verdelen kost dus CPU.

VLAN-filtering op een model waar de switch-chip het anders doet

Op de Atheros8327- en QCA8337-familie zit de VLAN-tabel in de switch-chip, bereikbaar via /interface ethernet switch. Bridge VLAN filtering werkt daar wel, maar haalt het verkeer van de switch-chip af en legt het bij de CPU. Een apparaat dat op wire speed kon switchen, doet VLANs dan in software. Dat is de klassieke "hij was sneller vóór ik VLANs invoerde".

Het bordje is gewoon klein

Een hAP lite of een hEX PoE lite heeft 64 MB geheugen of minder en een bescheiden processor. RouterOS draait er prima op, maar een lange firewall, een queue tree, een grote lease-tabel en een tweede pakket vullen het bordje. Een apparaat dat vol raakt zegt dat niet, het wordt traag, verliest verbindingen of herstart.

Iets ondervraagt de router continu

Monitoring die elke vijf seconden alles uitleest, of een script in de scheduler dat te vaak draait, kost meer dan je denkt. Dat zie je bij management in /tool profile.

Wat de configurator hieraan doet

• FastTrack is een vinkje in het onderdeel Firewall en staat standaard aan, met in de hulptekst de reden erbij: het wordt automatisch uitgezet zodra queues of PCC-loadbalancing actief zijn, want fasttracked verkeer slaat die over. Zet je QoS aan, dan schrijft het script in plaats van de regel een commentaarregel die zegt dat FastTrack is weggelaten omdat queues of PCC actief zijn.
• Zodra QoS aanstaat, waarschuwt de tool: FastTrack is uitgeschakeld in de firewall, wat de CPU-belasting verhoogt, en op kleine routers kost dit doorvoer.
• Kies je een queue tree met prioriteiten op een ouder bordje en vul je meer dan 200 Mbit/s in, dan rekent de tool het voor: deze router shapet in software en haalt met FastTrack uit naar schatting 200 tot 300 Mbit/s, dus de CPU wordt de bottleneck. Met de suggestie om eerlijk delen met CAKE of fq_codel te nemen: één wachtrij, geen mangle-regels, fors minder CPU.
• Gebruik je VLANs op een model uit de Atheros8327- of QCA8337-familie, dan zegt de tool precies wat het kost: de switch-chip doet de VLAN-tabel via /interface ethernet switch, deze configuratie gebruikt bridge VLAN filtering, dat werkt maar zet de hardware-offload uit, en het VLAN-verkeer gaat dan via de CPU in plaats van via de switch-chip.
• Hardware offloading (switch-chip) is een eigen vinkje in het onderdeel Bridge & poorten en staat standaard aan. Laat het aan.
• Op modellen met weinig geheugen krijg je een opmerking met de consequentie erbij: houd de configuratie klein, installeer geen pakketten die je niet gebruikt, en kijk met /system resource print wat er over is.

De eerlijke grens

Er is geen instelling die een processor sneller maakt. FastTrack en hardware-offload leiden verkeer langs de CPU, en zodra je iets doet wat elk pakket wil zien, zoals shapen of markeren, vervalt die route. Dat is geen tekortkoming van RouterOS of van dit programma, het is de prijs van de functie. Op een klein bordje kan die prijs hoger zijn dan de functie waard is, en dan is de eerlijke conclusie dat het apparaat te klein is. Wat jouw router werkelijk haalt, meet je met /tool profile onder echte belasting.

Verder lezen: QoS en bandbreedte, Bridge en poorten en Controles over snelheid.