Waarom mag u een MTU van 1500 bytes niet overal overschrijden?
Begrijp MTU, Jumbo Frames, fragmentatie en stille verliezen voordat u een NAS of een lokaal netwerk van 1500 naar 9000 bytes wijzigt.
Een idee duikt vaak op in netwerkdiscussies : de MTU van 1500 naar 9000 bytes verhogen, zou automatisch de snelheid van een NAS verhogen. Jumbo Frames kunnen inderdaad het aantal te verwerken pakketten verminderen. Maar in een heterogeen thuis- of professioneel netwerk levert een geïsoleerde wijziging vaak het tegenovergestelde effect op : instabiele doorvoer, sessies die vastlopen, video die in de buffer loopt of verloren pakketten zonder duidelijke melding.
De juiste vraag is dus niet « wat is de grootste MTU ? », maar « welke maximale grootte wordt van begin tot eind geaccepteerd op het daadwerkelijk gebruikte pad ? ».
Wat is de MTU ?
MTU staat voor Maximum Transmission Unit. Het verwijst naar de grootste data-eenheid die een interface kan verzenden zonder deze te moeten fragmenteren of af te wijzen. Op klassiek Ethernet is de IP-MTU over het algemeen 1500 bytes.
Deze waarde vertegenwoordigt niet de totale grootte van het Ethernet-signaal op de kabel. Een IPv4-pakket dat TCP vervoert bevat, in het eenvoudigste geval :
- 20 bytes IPv4-header ;
- 20 bytes TCP-header ;
- tot 1460 bytes TCP-gegevens, ofwel een MSS van 1460 ;
- Ethernet-headers en controles die rond het pakket worden toegevoegd.
Een VLAN-tag voegt nog eens 4 bytes toe aan het Ethernet-frame. PPPoE vermindert de bruikbare IP-MTU vaak tot 1492 bytes. Een VPN voegt zijn eigen headers toe en kan een nog lagere waarde opleggen. Daarom is een correcte grootte op het lokale netwerk niet noodzakelijk correct na het passeren van een tunnel of op het internet.
Waarom 9000 bytes sneller kan lijken
Met een MTU dicht bij 9000 vervoert elk frame meer nuttige gegevens. Om hetzelfde bestand te verzenden, produceren de machines minder pakketten, minder interrupts en minder verwerkingshandelingen. Deze winst kan interessant zijn op een zwaar belaste snelle verbinding, bijvoorbeeld tussen servers, iSCSI-opslag, een virtualisatiecluster of twee NAS die voor back-ups worden gebruikt.
Maar Jumbo Frames betekenen niet automatisch meer doorvoer. Op een 1 Gbit/s-verbinding die al verzadigd is, laten moderne netwerk-offloadmechanismen vaak toe om de praktische limiet te bereiken met een MTU van 1500. De verhoging van de MTU kan vooral de CPU-belasting of het aantal pakketten per seconde verminderen. Het resultaat hangt af van de hardware, de stuurprogramma's, het protocol en het type lading.
Het probleem van een netwerk met meerdere MTU's
Op hetzelfde Ethernet-segment verdeelt een switch een frame dat te groot is voor de volgende poort niet op. Als een NAS een Jumbo-frame verzendt naar een apparaat of poort dat beperkt is tot 1500, kan het frame simpelweg worden afgewezen. Het gedrag lijkt dan willekeurig omdat kleine uitwisselingen nog slagen, terwijl grote overdrachten mislukken.
Het is niet nodig dat elk verbonden object in het hele gebouw dezelfde MTU gebruikt. Daarentegen moet elk element op het pad dat door de Jumbo Frames wordt gevolgd de gekozen grootte accepteren : interfaces van beide uiteinden, switch-poorten, geaggregeerde verbindingen, VLAN's, bruggen, virtuele interfaces en eventuele routers.
Televisies, smartphones, Wi-Fi-toegangspunten en verbonden objecten blijven over het algemeen rond 1500 bytes. TCP kan de grootte van zijn segmenten aanpassen, maar het herstelt geen pad waarvan de MTU-detectie defect is. SMB, NFS, HTTP, Plex, Jellyfin of Syncthing kunnen lijken te werken, om dan te vertragen of vast te lopen wanneer een groter pakket de verkeerde interface tegenkomt.
Wanneer een MTU van 9000 gerechtvaardigd is
Jumbo Frames worden coherent in een gesloten en gedocumenteerd segment :
- directe verbinding tussen twee servers of twee NAS ;
- gescheiden opslagnetwerk voor iSCSI of NFS ;
- intern netwerk van een cluster of een virtualisatieplatform ;
- 10, 25, 40 of 100 Gbit/s-infrastructuur waarvan alle poorten zijn gevalideerd ;
- massief back-upverkeer dat het toegewezen VLAN nooit verlaat.
Op een Synology-cluster kunnen bijvoorbeeld de poorten die voor intern verkeer zijn gereserveerd, worden geconfigureerd in MTU 9000, terwijl de interfaces die voor gebruikers bestemd zijn, op 1500 blijven. De scheiding is veiliger dan de globale activering op het hoofdnetwerk.
Wanneer moet u 1500 behouden ?
- Internettoegang : het pad doorkruist netwerken die u niet beheert.
- VPN : WireGuard, IPsec of OpenVPN voegen headers toe en verkleinen de beschikbare MTU.
- PPPoE : de gangbare waarde is vaak 1492, behalve bij specifieke ondersteuning van een hogere MTU.
- Wi-Fi en verbonden objecten : het park is heterogeen en zelden end-to-end configureerbaar.
- VoIP, videoconferentie en games : stabiliteit, latentie en jitter zijn belangrijker dan een kleine vermindering van het aantal pakketten.
- Ongedocumenteerd netwerk : als u niet elk doorkruist apparaat kent, blijft 1500 de interoperabele instelling.
Fragmentatie, PMTUD en netwerk-« trous noirs »
In IPv4 kan een router een te groot pakket fragmenteren als de vlag Don't Fragment niet is ingeschakeld. Elk fragment moet dan afzonderlijk worden verwerkt en het verlies van één enkel fragment compromitteert het volledige pakket. In de praktijk proberen moderne systemen fragmentatie eerder te vermijden.
In IPv6 fragmenteren tussenliggende routers de pakketten niet : alleen de bronmachine kan dit doen. De router stuurt informatie terug die aangeeft dat het pakket te groot is, zodat de zender zijn grootte verkleint.
De detectie van de MTU van het pad, of Path MTU Discovery, is gebaseerd op deze ICMP-berichten. Als een firewall deze blokkeert, blijft de zender te grote pakketten verzenden zonder te begrijpen waarom ze verdwijnen. Kleine verzoeken werken, maar een pagina, een SMB-overdracht of een VPN-sessie blijft geblokkeerd : dit is het klassieke PMTU black hole.
Voor TCP door een tunnel kan MSS clamping een aangepaste segmentgrootte aankondigen en voorkomen dat het verkeer de werkelijke MTU overschrijdt. Deze instelling vervangt echter geen coherente configuratie van het pad.
Praktische test tussen twee NAS met iperf3
De oorspronkelijke test verbindt twee Synology-NAS direct op een 1 Gbit/s-interface. De ene NAS voert de iperf3-server uit, de andere start een client met vijf stromen gedurende zestig seconden :
iperf3 -c 192.168.69.10 -t 60 -i 5 -P 5-cgeeft het adres van de iperf3-server aan ;-t 60stelt een duur van 60 seconden in ;-i 5toont elke 5 seconden een overzicht ;-P 5opent vijf parallelle stromen.
Met een MTU van 1500 op beide uiteinden bereikt de geaggregeerde doorvoer ongeveer 941 Mbit/s, wat praktisch de nuttige limiet is van een Gigabit-verbinding.
Met een correct geconfigureerde MTU van 9000 op beide interfaces blijft het resultaat ook dicht bij 941 Mbit/s. Op deze 1 Gbit/s-verbinding en voor deze test leveren Jumbo Frames dus geen meetbare doorvoerwinst op.
De derde poging gebruikt 9000 op de zender en 1500 op de ontvanger. De gemeten doorvoer daalt naar ongeveer 562 Mbit/s, met één stroom op nul en een sterke verdeling tussen de andere. Dit cijfer beschrijft deze specifieke opstelling, geen universele regel, maar illustreert goed de kost van een inconsequent pad.
Tijdens een andere passage blijven de vijf stromen tijdelijk op nul. De opname bewijst op zich niet de exacte oorzaak van een verbroken verbinding, maar toont het symptoom dat de gebruiker waarneemt : het verkeer wordt onderbroken terwijl de interfaces nog steeds geconfigureerd lijken.
Hoe het pad valideren voordat u Jumbo Frames activeert
- Noteer alle interfaces en alle poorten die daadwerkelijk worden doorkruist.
- Controleer in de documentatie de maximale grootte die door elk apparaat wordt geaccepteerd.
- Configureer beide uiteinden en de tussenliggende poorten, nooit slechts één machine.
- Test eerst de afwezigheid van fragmentatie, dan de doorvoer en de stabiliteit.
- Behoud een beheersinterface in MTU 1500 om te kunnen terugkeren.
Onder Linux kan een IPv4-test met de vlag die fragmentatie verbiedt, als volgt worden uitgevoerd voor een pad in MTU 1500 :
ping -M do -s 1472 192.168.69.10De 1472 bytes ICMP-gegevens, toegevoegd aan de 28 bytes IPv4- en ICMP-headers, geven 1500. Voor een Jumbo-pad op 9000 gebruikt u 8972. De opties variëren afhankelijk van het besturingssysteem ; controleer altijd de lokale syntaxis.
Conclusie
Een grotere MTU is geen gratis versnelling. Het wordt nuttig in een snel, gesloten, homogeen en gemeten segment. Op een netwerk dat Wi-Fi, internet, VPN, televisies, verbonden objecten en apparaten van verschillende generaties mengt, blijft 1500 bytes de meest voorspelbare keuze.
Als u 9000 moet activeren, isoleer dan het betrokken verkeer, valideer elke schakel en meet het resultaat met iperf3. Als u het end-to-end-pad niet precies kunt beschrijven, wijzig de MTU dan niet.
Technische referenties
Daarna lezen
Over de auteur
Jeremy Kraft beheert de infrastructuur en de zelfgehoste diensten van het IBCSC. Deze gidsen beschrijven configuraties die echt zijn uitgerold en voor publicatie opnieuw zijn nagekeken.
Discussie
Reacties
Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.