Maximum Transmission Unit
Abkürzung: MTU
Die Maximum Transmission Unit (MTU) definiert die maximale Größe eines IP-Pakets, das über eine Netzwerkschnittstelle bzw. einen Netzwerkpfad ohne Fragmentierung übertragen werden kann. Sie ist eine grundlegende Kenngröße von Layer-3-Verbindungen und beeinflusst direkt Durchsatz, Latenz und Stabilität einer Datenübertragung.
Typische MTU-Werte
Die mit Abstand häufigste IP-MTU sind 1500 Bytes. Bei Ethernet können damit IP-Pakete bis zu 1500 Bytes (einschließlich IP-Header) in die Ethernet-Payload aufgenommen werden. Zusammen mit den 14 Bytes des Ethernet-Headers und den 4 Bytes der Frame Check Sequence (FCS) ergibt sich ein maximaler Ethernet-Frame von 1518 Bytes.
Bei PPPoE-Verbindungen (DSL) reduziert sich die effektive IP-MTU durch 8 Bytes zusätzlichen PPPoE-Overhead auf 1492 Bytes. IPv6 schreibt eine minimale Link-MTU von 1280 Bytes verbindlich vor. Ein IPv6-Link muss daher mindestens IPv6-Pakete dieser Größe unterstützen.
Fragmentierung und ihre Folgen
Überschreitet ein IPv4-Paket die MTU einer ausgehenden Schnittstelle, kann es in kleinere Fragmente zerlegt werden, sofern das Don't-Fragment-Bit (DF) nicht gesetzt ist. Diese Fragmentierung erhöht den Protokolloverhead und die Anzahl der zu verarbeitenden Pakete. Außerdem beeinträchtigt der der Verlust eines einzelnen Fragments die Übertragung des gesamten ursprünglichen IP-Pakets.
Firewalls und andere Sicherheitssysteme behandeln Fragmente teilweise gesondert, da Fragmentierung die Paketfilterung und Inspektion erschweren kann und historisch auch für verschiedene Angriffe ausgenutzt wurde. Um das vollständige Paket zuverlässing prüfen zu können, muss eine Firewall alle Fragmenente puffern und zusammensetzen.
IPv4 erlaubt Routern die Fragmentierung. IPv6 hingegen verbietet sie unterwegs im Laufe der Übertragung – nur der Sender darf fragmentieren.
Path MTU Discovery (PMTUD)
Um die optimale Paketgröße Ende-zu-Ende zu bestimmen, setzt der Sender bei IPv4 per default das „Don't Fragment“-Bit (DF). Ein Router, der das Paket wegen einer zu geringen MTU des nächsten Links nicht weiterleiten kann, verwirft es und sendet ICMP Typ 3 Code 4 („Fragmentation Needed“) mit dem benötigten MTU-Wert zurück. Der Sender reduziert daraufhin die verwendete Path MTU und damit die Größe der übertragenen IP-Pakete.
Der Sender trägt diesen Wert in seinen lokalen Path MTU Cache ein. Diesen Cache kann man sich unter Linux und Windows einfach anschauen. Zuerst für IPv6 unter Windows:
PS C:\Users\mku> netsh interface ipv6 show destinationcache Schnittstelle 9: WLAN PMTU Zieladresse Adresse des n. Hops ---- --------------------------------------------- ------------------------- 1500 2001:478:65::53 fe80::1a2b:3cff:fe4d:5e6f 1500 2001:4860:4860::8888 fe80::1a2b:3cff:fe4d:5e6f 1500 2606:4700:440b::6812:2715 fe80::1a2b:3cff:fe4d:5e6f 1500 2a00:1450:4005:802::200a fe80::1a2b:3cff:fe4d:5e6f 1500 2001:db8:f00:100::1 fe80::1a2b:3cff:fe4d:5e6f 65535 2001:db8:1:2300:9c1a:44e2:7b3d:f091 2001:db8:1:2300:9c1a:44e2:7b3d:f091 1500 2001:db8:1:2300:1a2b:3cff:fe4d:5e6f 2001:db8:1:2300:1a2b:3cff:fe4d:5e6f 1500 fd00::1a2b:3cff:fe4d:5e6f fe80::1a2b:3cff:fe4d:5e6f 1500 fec0:0:0:ffff::1 fe80::1a2b:3cff:fe4d:5e6f 1500 fec0:0:0:ffff::2 fe80::1a2b:3cff:fe4d:5e6f 1500 fec0:0:0:ffff::3 fe80::1a2b:3cff:fe4d:5e6f 65535 fe80::c4d5:e6f7:a8b9:c0d1 fe80::c4d5:e6f7:a8b9:c0d1 1500 2001:4860:4842:400:: fe80::1a2b:3cff:fe4d:5e6f 1500 2607:6bc0::10 fe80::1a2b:3cff:fe4d:5e6f 1500 2a00:1450:4013:c06::5f fe80::1a2b:3cff:fe4d:5e6f 1500 2001:db8:f00:200::1 fe80::1a2b:3cff:fe4d:5e6f 65535 2001:db8:1:2300:7e4a:d2c8:9315:b6e0 2001:db8:1:2300:7e4a:d2c8:9315:b6e0
Hier ein Beispiel für IPv4 unter Windows:
PS C:\Users\mku> netsh interface ipv4 show destinationcache Schnittstelle 1: Loopback Pseudo-Interface 1 PMTU Zieladresse Adresse des n. Hops ---- --------------------------------------------- ------------------------- 65535 127.0.0.1 127.0.0.1 Schnittstelle 9: WLAN PMTU Zieladresse Adresse des n. Hops ---- --------------------------------------------- ------------------------- 1500 203.0.113.63 192.168.178.1 1500 8.8.8.8 192.168.178.1 65535 192.168.178.26 192.168.178.26 1500 224.0.0.22 224.0.0.22 1500 192.168.178.130 192.168.178.130 1500 198.51.100.201 192.168.178.1 Schnittstelle 63: vEthernet (WSL) PMTU Zieladresse Adresse des n. Hops ---- --------------------------------------------- ------------------------- 65535 172.21.208.1 172.21.208.1
Unter Linux werden seit Kernel 3.6 nur noch Ausnahmen von der Standard-MTU in den Cache eingetragen. Wenn ein Linux-System also alle Verbindungen mit 1500 Byte abwickeln kann, bleibt der MTU-Cache leer. Hier zwei Ziel-IPs mit kleinerer Path-MTU:
$ ip route show cache
203.0.113.80 via 192.168.178.1 dev eth0
cache expires 594sec mtu 1420
198.51.100.7 via 192.168.178.1 dev eth0
cache expires 128sec mtu 1400Und hier IPv6 unter Linux:
$ ip -6 route show cache
2001:db8:f00:100::1 via fe80::1a2b:3cff:fe4d:5e6f dev eth0 metric 1024
cache expires 552sec mtu 1452 pref medium
2001:db8:cafe::53 via fe80::1a2b:3cff:fe4d:5e6f dev eth0 metric 1024
cache expires 37sec mtu 1280 pref mediumIPv6 arbeitet ohne DF-Bit, da Router ohnehin nicht fragmentieren. Stößt ein IPv6-Paket auf einen Link mit zu geringer MTU, verwirft der Router das Paket und sendet ICMPv6 Typ 2 („Packet Too Big“) mit der MTU des Links zurück, über den das Paket nicht weitergeleitet werden konnte. Der Sender passt seine PMTU entsprechend an.
Wenn ICMP blockiert wird
Werden ICMP-Nachrichten (ICMPv4 Typ 3 Code 4 bzw. ICMPv6 Typ 2) durch Firewalls unterdrückt, funktioniert PMTUD nicht. Der Sender erfährt die erforderliche kleinere MTU dann nicht und sendet weiterhin zu große IP-Pakete. Es entsteht ein sogenannter „PMTUD-Black-Hole“: Die Verbindung steht grundsätzlich, aber größere IP-Pakete werden auf einem Teil des Pfades stillschweigend verworfen.
Typisches Fehlerbild: Ping funktioniert (weil per default kleine ICMP Pakete gesendet werden), Verbindung funktioniert manchmal, manchmal auch nicht. Sobald größere Datenmengen übertragen werden sollen, werden die Pakete verworfen.
Jumbo Frames
Netzwerkkarten und Switches unterstützen oft Frames, die über die klassische Ethernet-Frame-Größe von 1518 Bytes hinausgehen. Solche Jumbo Frames haben typischerweise eine MTU von 9000 Bytes, teils auch 9216 Bytes. Sie verringern den CPU- und Paketverarbeitungs-Overhead und können insbesondere bei großen Datenübertragungen den Durchsatz verbessern. Allerdings müssen sämtliche beteiligten Geräte und Links entlang des betreffenden Pfades die größere MTU unterstützen. Einen einheitlichen IEEE-Standard für eine Jumbo-Frame-MTU von beispielsweise 9000 Bytes gibt es bisher nicht.
Tunnel und VPNs
Jede Tunnelung fügt zusätzliche Protokollheader hinzu und verringert dadurch die für das transportierte IP-Paket verfügbare effektive MTU. Der tatsächliche Overhead hängt vom jeweiligen Tunnelprotokoll und dessen Konfiguration ab.
Beispiele:
- GRE (IPv4): 24 Bytes Overhead → effektive MTU 1476 Bytes
- VXLAN über IPv4: typischerweise 50 Bytes Overhead → effektive MTU 1450 Bytes
- IPsec im Tunnelmodus: je nach Verfahren, Verschlüsselung, Authentifizierung und Konfiguration typischerweise etwa 40–60 Bytes und teilweise mehr
Grade bei IPsec muss man in der Praxis aufpassen, eine Anpassung an den Overhead verändern und zu Problemen mit der Path-MTU führen.
Bei IPv6 als äußerem Tunnelprotokoll fällt der Overhead entsprechend höher aus. Um Fragmentierung zu vermeiden, muss die MTU des Tunnel-Interfaces entsprechend herabgesetzt oder die Endgeräte-PMTU angepasst werden.
Fazit
Die korrekte MTU ist essenziell für eine stabile und performante Datenübertragung. Fehlkonfigurationen oder blockierte ICMP-Nachrichten führen zu subtilen Ausfällen, die sich nur schwer diagnostizieren lassen. Deshalb gehören MTU-Überlegungen bei jedem Netzwerkdesign, bei VPN-Einrichtung und bei der Firewall-Konfiguration auf die Agenda.