Pakketverlies en MTU-problemen vinden
Pakketverlies en MTU-problemen lijken op elkaar en vragen een heel andere aanpak. Het onderscheid is gelukkig goed te maken: MTU-problemen treffen alleen groot verkeer, echt verlies treft alles.
Loop je hier nu tegenaan?
Bel en leg het voor. Vaak is in tien minuten duidelijk waar het aan ligt. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Herken je dit?
- Kleine verzoeken werken, grote downloads of uploads blijven hangen.
- Sommige websites laden wel en andere niet, zonder logisch patroon.
- Het gaat mis zodra verkeer door een VPN-tunnel loopt.
- Ping werkt prima, maar echte toepassingen haperen.
- Onverklaarbare latency of verlies dat komt en gaat.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
Te grote pakketten die niet passen
Elke encapsulatie (VPN, PPPoE, VXLAN, GRE) kost ruimte. Blijft de MTU op 1500 staan, dan zijn pakketten net te groot voor het pad en worden ze gefragmenteerd of gedropt.
Path MTU Discovery die geblokkeerd is
PMTUD leunt op ICMP fragmentation needed. Blokkeert een firewall onderweg alle ICMP, dan hoort de verzender nooit dat het pakket te groot is en blijft de verbinding hangen. Dit is de klassieke black hole.
MSS niet geclampt
Op tunnels en PPPoE-verbindingen zet je tcp-mss-clamp zodat TCP zelf kleinere segmenten kiest. Vergeet je dat, dan doet alles het behalve groot verkeer.
Echt pakketverlies op één hop
Een slechte poort, een volle uplink, een kapotte SFP of een overbelaste hop onderweg. Dit raakt alle pakketgroottes, niet alleen grote.
Congestie en bufferbloat
Een volle uplink zonder queueing geeft verlies en oplopende latency onder belasting. Dat voelt als een defect, maar is capaciteit plus ontbrekende prioritering.
Duplex-mismatch of hardwarefout
Op koperverbindingen: een mismatch of een kapotte kabel geeft errors op de interface. De teller op de poort vertelt dat direct, mits iemand kijkt.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Test de werkelijke MTU van het pad
Met
ping -M do -s 1472 <host>(Linux) ofping -f -l 1472(Windows) test je 1500 bytes totaal. Verlaag tot het lukt: daarmee weet je de echte MTU van het pad. - 2
Meet over tijd, niet één keer
mtr --report --report-cycles 300 <host>laat verlies en jitter per hop zien. Één traceroute is een momentopname; verlies dat komt en gaat, zie je alleen over tijd. - 3
Interpreteer de hops goed
Verlies op een tussenliggende hop dat verderop verdwijnt, is bijna altijd rate limiting op ICMP en geen echt probleem. Alleen verlies dat vanaf een hop blíjft, telt.
- 4
Lees de interfacetellers
ip -s link,ethtool -Sof de tellers op je switchpoort. Errors, drops en CRC-fouten wijzen direct naar kabel, optiek of duplex, en niet naar routing. - 5
Clamp de MSS op tunnels
Op elke tunnel- of PPPoE-interface MSS clampen en de MTU expliciet zetten. Dat lost een grote categorie "sommige sites doen het niet"-klachten definitief op.
- 6
Laat ICMP door
Blokkeer nooit alle ICMP op een firewall. Type 3 code 4 (fragmentation needed) is noodzakelijk voor werkend internet. Dit is een van de meest gemaakte en meest schadelijke firewallfouten.
Eerst onderscheiden, dan oplossen
De eerste vraag bij elk verliesprobleem: raakt het alle verkeer of alleen groot verkeer? Alleen groot verkeer is MTU, en dan is de oplossing configuratie: MSS clampen, MTU zetten, ICMP doorlaten. Alle verkeer is echt verlies, en dan zoek je naar een hop, een poort of capaciteit.
Die vraag kost vijf minuten en bespaart vaak dagen. Ik zie regelmatig teams weken achter een “instabiel internet” aanjagen dat een verkeerde tunnel-MTU blijkt te zijn.
Meekijken bij een meting
Verlies dat komt en gaat, is het lastigst: op het moment dat iemand kijkt, is het weg. Ik zet daarvoor continue metingen op vanaf meerdere punten, zodat je bij de volgende storing niet hoeft te reconstrueren maar gewoon kunt terugkijken.
Veelgestelde vragen
- Waarom werken sommige sites wel en andere niet?
- Dat patroon is bijna het handelsmerk van een MTU-probleem. Sites die kleine antwoorden geven, werken; zodra het antwoord groot genoeg is om tegen de MTU-grens aan te lopen en PMTUD is geblokkeerd, blijft de verbinding hangen. Test de padgrootte, dan weet je het.
- Ik zie verlies op hop 4 in mijn traceroute. Is dat de schuldige?
- Waarschijnlijk niet. Routers geven ICMP-antwoorden lage prioriteit, dus verlies dat alleen op één tussenliggende hop zichtbaar is en verderop verdwijnt, is een meetartefact. Alleen als het verlies vanaf die hop tot het eind doorzet, is het echt.
- Hoe weet ik of het mijn probleem is of dat van mijn provider?
- Door vanaf beide kanten te meten en het pad te vergelijken. Zit het verlies pas voorbij jouw uplink en in beide richtingen op hetzelfde punt, dan heb je een onderbouwd verhaal voor je provider. Zonder die meting wordt het een welles-nietes.
- Kun je dit voor mij meten?
- Ja. Ik meet vanaf mijn eigen netwerk en vanaf jouw kant, leg de resultaten naast elkaar en kom met een conclusie. Meestal is dat een kwestie van uren, niet dagen.
Verwante problemen
VPN-tunnel komt niet op of is instabiel
Site-to-site VPN die niet opkomt, elke paar uur wegvalt of waar alleen groot verkeer misgaat. WireGuard, IPsec en OpenVPN: dit zijn de oorzaken.
[Gesprekskwaliteit]Gesprekken vallen weg of haperen
Gesprekken die na 30 seconden wegvallen, haperende audio of robotstemmen. Meestal RTP-timeouts, jitter, MTU of QoS. Dit check ik als eerste.
Zelf geen tijd of geen zin om te blijven zoeken?
Ik kijk mee, zeg eerlijk wat er aan de hand is en los het op. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Terug naar BGP- en netwerkspecialist inhuren