MTU verstehen
Warum manche Seiten nur halb laden, Downloads bei 90 % stehen bleiben und im VPN plötzlich gar nichts mehr geht.
Diese Seite kann deine MTU nicht ändern — das kann keine Webseite. Was sie kann: dir zeigen, was von deiner Einstellung hier ankommt. Du änderst den Wert an deinem Rechner (Befehle stehen unten), misst hier erneut und vergleichst im Verlauf. Aus einer abstrakten Zahl wird damit ein Versuch mit sichtbarem Ergebnis.
Die MSS wird beim Verbindungsaufbau angekündigt und ändert sich danach nie mehr. Genau genommen wird sie nicht ausgehandelt: Jede Seite nennt im SYN unabhängig die Größe, die SIE empfangen kann — die beiden Werte dürfen verschieden sein. Was du hier siehst, ist der Wert, den deine Seite angekündigt hat, und er begrenzt, was der Server dir schicken darf. Dein Browser hält Verbindungen offen (bei HTTP/2 sogar eine einzige für alles). Wer seine MTU ändert und einfach neu lädt, bekommt hier deshalb oft noch den alten Wert zu sehen.
Jede Messung holt ihre Daten unter einer eigenen Adresse, damit kein Zwischenspeicher dazwischenfunkt — eine neue Verbindung kann eine Webseite aber nicht erzwingen. Sie kann nur nachsehen, ob es eine gab: Genau das steht unten in der Spalte „Verbindung“. Steht dort wiederverwendet, gilt der MSS-Wert für die alte Verbindung.
So bekommst du zuverlässig eine neue: privates Fenster öffnen und dort messen (eigener Verbindungsvorrat, sicherste Variante) — oder alle Tabs dieser Seite schließen, eine Minute warten und neu öffnen. Im privaten Fenster ist der Verlauf allerdings leer; er gehört zum normalen Fenster.
Dauert rund zehn Sekunden. Am besten einmal vor der Änderung messen, damit du etwas zum Vergleichen hast.
- Die MSS folgt sofort — auf einer neuen Verbindung
Setzt du 1400, bietet dein System beim nächsten Verbindungsaufbau 1360 an (1400 − 40). Hier steht danach ein paar Bytes weniger, weil der Kernel die TCP-Optionen gleich mit herausrechnet — deshalb ist die abgeleitete MTU eine Untergrenze. Aussagekräftig ist nicht die letzte Stelle, sondern der Sprung um rund hundert Bytes. Das ist der schärfste Nachweis, dass deine Änderung wirkt.
- Die Pfadmessung zeigt danach oft ein schwarzes Loch
Und das ist kein Fehler dieser Seite, sondern der Lehrsatz der ganzen Seite in freier Wildbahn: Du hast deinen Rechner angewiesen, große Rahmen nicht mehr anzunehmen — aber kein Router im Weg weiß davon, also meldet auch niemand „zu groß“ zurück. Genau das Bild aus Schaubild 3, selbst gebaut.
- Die Antwortgrößen bleiben meistens sauber
Weil TCP sich über genau diese MSS einigt: Der Server schneidet seine Antworten von sich aus kleiner. Weh tut eine zu kleine MTU dort, wo es keine MSS gibt — UDP, QUIC, VPN-Tunnel. Deshalb ist ein sauberes Ergebnis hier kein Freispruch für den Rest.
- Notiere den jetzigen Wert. Er steht in der ersten Zeile jedes Blocks unten — und er ist dein Weg zurück. Ohne ihn rätst du beim Zurücksetzen.
- Bleib über 1280. So viel muss jede IPv6-Strecke tragen (RFC 8200); Linux schaltet IPv6 auf einer Schnittstelle darunter ab — das ist Verhalten dieses Betriebssystems, keine Vorgabe des Standards, andere Systeme können anders reagieren. Bei IPv4 liegt die kleinste Link-MTU bei 68 Byte; die oft genannten 576 sind etwas anderes, nämlich die Größe, die ein Ziel mindestens wieder zusammensetzen können muss. Zum Ausprobieren reicht 1400 völlig: klein genug, um sich hier zu zeigen, groß genug, dass alles weiterläuft.
- Nicht auf einem Rechner, den du gerade fernwartest. Änderst du die MTU der Schnittstelle, über die deine SSH-Sitzung läuft, kann sie dir mitten im Befehl abreißen.
- Danach eine neue Verbindung erzwingen — sonst misst du hier den alten Wert: privates Fenster, oder alle Tabs schließen und eine Minute warten.
Windows
netsh interface ipv4 show subinterfacesnetsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistentnetsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistentEingabeaufforderung als Administrator. „Ethernet“ ist der Name aus der ersten Ausgabe — bei WLAN heißt er meist „WLAN“. store=persistent überlebt den Neustart; genau deshalb musst du hier auch wirklich zurücksetzen.
Linux
ip -br link showsudo ip link set dev eth0 mtu 1400sudo ip link set dev eth0 mtu 1500eth0 durch die eigene Schnittstelle ersetzen. Der Wert ist flüchtig: Ein Neustart der Verbindung oder des Rechners stellt den alten ohnehin wieder her — dauerhaft wäre er nur in NetworkManager, netplan oder systemd-networkd.
macOS
ifconfig en0 | grep mtusudo ifconfig en0 mtu 1400sudo ifconfig en0 mtu 1500en0 ist meist das WLAN; networksetup -listallhardwareports zeigt, welcher Name zu welchem Anschluss gehört. Auch hier ist der Wert flüchtig — WLAN aus und wieder ein setzt ihn zurück.
Warum zwei Messungen verschiedene Zahlen zeigen
MTU gilt je Richtung. Das erklärt den häufigsten Stolperstein beim Nachmessen: Du stellst deine MTU herunter, und die Pfad-MTU oben ändert sich trotzdem nicht.
Unser Server schickt dir Pakete wachsender Größe. Gemessen wird, was auf dem Weg zu dir durchkommt — meist der Wert deiner Leitung, etwa 1492 bei DSL mit PPPoE. Deine lokale Einstellung sieht diese Messung nur begrenzt: Eine Interface-MTU wirkt in erster Linie auf das, was dein Rechner SENDET. Ob er auch größere Pakete annimmt, ist damit nicht gesagt — das hängt an Karte und Treiber und ist nicht zugesichert. In der Praxis kommen sie meist an, verlassen sollte man sich nicht darauf.
Die angekündigte Segmentgröße oben stammt aus deiner Verbindung und folgt damit deiner lokalen MTU. Genau hier siehst du eine Änderung sofort. Dasselbe gilt für ping -D -s …: Ist das Paket größer als deine Interface-MTU, kommt „Message too long“ — dein eigener Rechner lehnt ab, bevor etwas das Haus verlässt.
WLAN-MTU von Hand auf 1345 gesetzt, alles andere unverändert. Die Messungen sagen dann:
- · Pfad-MTU 1492 — der Weg zu dir trägt weiterhin 1492
- · ping -D -s 1350 → „Message too long“ ab 1345
- · MSS 1293 → 1293 + 40 + 12 = 1345
Kein Widerspruch, sondern zwei Richtungen. Die 12 Bytes sind die TCP-Optionen (Zeitstempel und SACK), die dein System zusätzlich mitschickt — deshalb steht bei der abgeleiteten MTU „mindestens“.
Das Wichtigste in vier Sätzen
- 1Die MTU ist die größte Menge, die ein Netzabschnitt in einem Stück befördert — bei Ethernet 1500 Bytes.
- 2Für deine Verbindung zählt nicht deine MTU, sondern die kleinste auf dem ganzen Weg. Die kennt vorher niemand.
- 3Jeder Tunnel — PPPoE, VPN, GRE — nimmt sich seinen Platz aus derselben 1500-Byte-Scheibe. Innen bleibt entsprechend weniger.
- 4Passt ein Paket nicht, soll eine ICMP-Meldung das mitteilen. Wird die weggefiltert, hängt die Verbindung, statt einen Fehler zu zeigen.
Diese Seite misst nichts. Deine tatsächliche Pfad-MTU lässt sich von außen nicht ehrlich bestimmen — die Befehle zum Selbernachmessen stehen weiter unten.
1 — Es zählt die kleinste Stelle
Diese kleinste Stelle heißt Pfad-MTU. Sie steht nirgends fest: Sie ergibt sich erst aus dem Weg, den deine Pakete gerade nehmen — und der kann sich ändern, wenn dein Provider umroutet oder du dich in ein anderes WLAN einbuchst. Deshalb ist ein Wert, der gestern gestimmt hat, kein Beweis für heute.
2 — Jede Schicht nimmt sich ihren Platz
- 8 — PPPoE (DSL)
- 20 — IPv4-Kopf · 40 — IPv6-Kopf
- 20 — TCP-Kopf
- 24 — GRE · 20 — 6in4
- 50 — VXLAN · 58 — GENEVE
- 60 — WireGuard über IPv4 (80 über IPv6)
- 41–69 — OpenVPN, je nach Verfahren und tun/tap
- 50–73 — IPsec/ESP, je nach Verfahren und NAT-Traversal
- 4 — VLAN-Etikett, aber außerhalb der 1500 (Rahmen wächst auf 1522)
Dann addiert sich alles. Ein WireGuard-Tunnel über einen DSL-Anschluss, der wiederum durch ein IPsec-Firmennetz läuft, kommt schnell bei 130 bis 140 Bytes Overhead heraus — innen bleiben dann noch rund 1360 Bytes MTU.
Deshalb reicht es nicht, den Overhead einer Schicht zu kennen. Du musst wissen, wie viele Schichten übereinanderliegen.
Übliche Werte — und wofür sie stehen
| MTU | Wo |
|---|---|
| 1500 | Ethernet, WLAN, Kabel- und Glasfaseranschluss Der Normalfall bei Ethernet.Warum dieser WertDer Normalfall. Jeder andere Wert auf dieser Liste rechnet sich von hier herunter. |
| 1492 | DSL mit PPPoE PPPoE kostet 8 Bytes.Warum dieser WertDer PPPoE-Kopf kostet 8 Bytes (6 für PPPoE, 2 für das Protokollfeld). Zwingend ist das nicht mehr: Mit dem PPP-Max-Payload-Tag aus RFC 4638 handeln Router und Gegenstelle auch volle 1500 aus, wenn die Strecke die vier bis acht Extrabytes trägt. Manche Provider können das, die meisten deutschen DSL-Anschlüsse nicht — deshalb bleibt 1492 der Wert, mit dem man rechnet, bis eine Messung etwas anderes sagt. |
| 1480 | 6in4 — IPv6 durch einen IPv4-Tunnel Äußerer IPv4-Kopf, 20 Bytes.Warum dieser WertDer äußere IPv4-Kopf kostet 20 Bytes. |
| 1476 | GRE-Tunnel IPv4-Kopf plus 4 Bytes GRE.Warum dieser Wert20 Bytes äußerer IP-Kopf plus 4 Bytes GRE. |
| 1500 (Rahmen 1522) | VLAN nach 802.1Q Das Etikett vergrößert den Rahmen, statt die 1500 zu kürzen.Warum dieser WertDer Sonderfall, über den am meisten Verwirrung herrscht: Das VLAN-Etikett kostet 4 Bytes, aber sie gehen NICHT von den 1500 ab — der Rahmen wird auf 1522 größer. Jeder Switch, der VLANs kann, lässt das durch („Baby Giants“). Nur wo ein Gerät in der Kette stur bei 1518 bleibt, musst du auf 1496 herunter. QinQ (zwei Etiketten, 802.1ad) kostet 8 Bytes. |
| 1492 (VDSL meist) | VDSL / VDSL2 Nicht VDSL entscheidet, sondern die Einwahlart.Warum dieser WertVDSL selbst kostet nichts extra — entscheidend ist, wie eingewählt wird. Mit PPPoE (Telekom, 1&1, die meisten Reseller) sind es 1492. Wer per DHCP ins Netz kommt (viele Kabel- und einige Glasfasertarife), behält 1500. Kommt ein VLAN-Etikett vom Provider dazu (Telekom nutzt VLAN 7), ändert das an der MTU nichts — das Etikett trägt die Leitung, nicht dein Paket. |
| 1460 | DS-Lite — IPv4 durch einen IPv6-Tunnel (viele Kabel- und Glasfasertarife) Der äußere IPv6-Kopf kostet 40 Bytes.Warum dieser WertKein NAT-Effekt, sondern Kapselung: Dein Router (das B4-Element) packt jedes IPv4-Paket in einen IPv6-Kopf, bevor es zum Provider geht. Die 40 Bytes gehen von deinen 1500 ab. RFC 6333 verlangt darum ausdrücklich, dass der Provider die Strecke bis zum AFTR um mindestens 40 Bytes größer auslegt — tut er das, merkst du nichts und behältst 1500. Tut er es nicht, landest du bei 1460, ohne dass irgendwo „Tunnel“ draufsteht. Erkennungszeichen: Du hast keine eigene öffentliche IPv4-Adresse, IPv6 dagegen schon. |
| 1450 | VXLAN — Proxmox-SDN, Kubernetes-CNI, Virtuozzo 50 Bytes Kapselung.Warum dieser Wert50 Bytes für äußeren IP- und UDP-Kopf, VXLAN-Kopf und den mitgeschleppten inneren Ethernet-Rahmen. Über IPv6 als Transport sind es 70, also 1430. |
| 1442 | GENEVE — OpenStack mit OVN, Cilium 58 Bytes im üblichen OVN-Profil.Warum dieser WertDer GENEVE-Basiskopf misst nur 8 Bytes; die hier gerechneten 58 sind das übliche Profil aus äußerem IPv4, UDP und innerem Ethernet — ohne Optionen kommt man auch mit rund 50 aus. Optionsfelder sind variabel und machen es enger. Weil OVN inzwischen der Standard in OpenStack ist, ist das der Wert, mit dem man dort rechnet — nachrechnen lohnt sich trotzdem. |
| 1420 | WireGuard, Voreinstellung von wg-quick wg-quick rechnet vorsorglich mit 80 Bytes.Warum dieser WertÜber IPv4 kostet WireGuard 60 Bytes, über IPv6 achtzig. wg-quick rechnet vorsorglich mit 80 — daher 1500 − 80. |
| 1400–1427 | IPsec (ESP im Tunnelmodus) 50 bis 73 Bytes, je nach Verfahren.Warum dieser WertJe nach Verschlüsselung, Prüfsumme und NAT-Traversal gehen 50 bis 73 Bytes weg. Deshalb kein fester Wert. |
| 1428–1500 | Mobilfunk (LTE, 5G) Netzabhängig — nachmessen statt raten.Warum dieser WertNetzabhängig. Viele Netze liefern volle 1500, einige deutlich weniger — nachmessen statt raten. |
| 1280 | Kleinster Wert, den jeder IPv6-Weg können muss Untergrenze, die jeder IPv6-Weg tragen muss.Warum dieser WertUnter diesen Wert darf IPv6 nirgends fallen. Als Notwert bei „gar nichts geht mehr“ brauchbar. |
| 9000 | Jumbo Frames im Speicher- und Backup-Netz Nur im abgeschlossenen Netz.Warum dieser WertSechsmal weniger Pakete für dieselbe Datenmenge. Nur in abgeschlossenen Netzen, nie Richtung Internet. |
| 576 | Größe, die jedes IPv4-Ziel mindestens zusammensetzen können muss Mindestgröße beim Empfänger, keine Zusage über den Weg.Warum dieser WertHäufig missverstanden: Das ist die Mindest-Reassemblygröße am EMPFÄNGER, keine zugesicherte Pfad-MTU — RFC 1191 nennt ausdrücklich Wege darunter. Die kleinste IPv4-Link-MTU ist 68 Byte. Als vorsichtiger Notwert brauchbar, aber langsam: Jedes Paket schleppt anteilig mehr Kopf mit. |
3 — Warum es hängt statt zu meckern
Ist ein Paket zu groß, hängt alles am DF-Bit („nicht fragmentieren“). Ist es gesetzt — und das ist bei allem, was Path MTU Discovery betreibt, der Fall —, wird das Paket verworfen und das Gerät schickt eine ICMP-Meldung zurück: „Zu groß, nimm 1420.“ Genau davon lebt Path MTU Discovery . Ohne DF-Bit darf ein IPv4-Router das Paket stattdessen zerlegen und weiterschicken; bei IPv6 gibt es diese Möglichkeit gar nicht, dort fragmentieren Router grundsätzlich nicht. Das Verfahren funktioniert gut — solange die Meldung ankommt.
- IPv4: ICMP Typ 3, Code 4 — „Fragmentation needed“
- IPv6: ICMPv6 Typ 2 — „Packet Too Big“
Bei IPv6 ist das keine Empfehlung, sondern Pflicht: Router dürfen dort gar nicht mehr fragmentieren. Ohne „Packet Too Big“ ist IPv6 kaputt.
Kleine Anfragen laufen, große sterben. ping geht, ping -s 1400 geht nicht mehr. Der Verbindungsaufbau steht in Sekunden, danach passiert nichts. Genau dieses Muster ist der Fingerabdruck.
Warum die Meldung unterwegs verlorengeht
Der häufigste Fall, und meistens gut gemeint. Welche ICMPv6-Nachrichten eine Firewall durchlassen MUSS, steht nicht zur Debatte: RFC 4890 führt „Packet Too Big" ausdrücklich unter dem Verkehr, der nicht verworfen werden darf — mit der Begründung, dass sonst Teile des Internets unerreichbar werden. Für IPv4 gilt dasselbe für Typ 3 Code 4, nur weniger streng formuliert.
NAT ändert die Paketgröße nicht — Adressen und Ports sind vorher wie nachher gleich lang. Aber die ICMP-Meldung trägt den Kopf des zu großen Pakets in sich, und den muss das NAT ebenfalls zurückübersetzen, sonst weiß es nicht, welcher Rechner im Haus gemeint war. RFC 5508 verlangt genau das (REQ-4 und REQ-5). Zustandsbehaftete Implementierungen können es; einfache Geräte werfen die Meldung dann still weg.
Ältere Geräte schicken „zu groß" ohne die Zahl, wie groß es denn sein dürfte. RFC 1191 hat das eingeplant: Der Sender rät dann anhand einer Leiter üblicher Werte — 1500, 1006, 576, 296 — statt jede Größe einzeln durchzuprobieren. Das erklärt, warum eine Verbindung manchmal auf einem krumm wirkenden Wert wie 576 hängen bleibt, obwohl der Weg mehr könnte.
Woran merkst du, dass es die MTU ist?
MTU-Probleme sehen nie wie Netzwerkprobleme aus. Die Leitung ist schnell, der Ping ist gut, alle anderen Geräte gehen — nur eine Sache tut es nicht. Das gemeinsame Muster ist immer dasselbe: klein geht, groß geht nicht.
- SSH läuft flüssig, Webseiten bleiben weiß
Tastenanschläge in SSH sind winzige Pakete, eine Webseite kommt in vollen 1500ern. Nur die großen bleiben stecken — deshalb wirkt „die Leitung geht doch“.
- Der Download bleibt bei 90 % stehen
Verbindungsaufbau und Handschlag sind klein und gehen durch. Erst wenn die Übertragung auf volle Paketgröße hochfährt, verschwinden die Pakete.
- Im VPN gehen kleine Seiten, große nicht
Der Klassiker. Die Tunnel-MTU ist zu groß eingestellt: Was hineingegeben wird, passt außen nicht mehr durch.
- Die Videokonferenz bricht ab, sobald jemand den Bildschirm teilt
Sprache besteht aus kleinen Paketen, eine Bildschirmfreigabe aus vollen. Genau dann kippt es.
- Eine einzelne große Mail hängt beim Abruf
Derselbe Effekt: Der Anhang füllt die Pakete aus, der Rest des Postfachs nicht.
- Genau ein Anbieter geht nicht, alle anderen schon
Auf genau diesem Weg liegt eine kleinere MTU — oder eine Firewall, die die Rückmeldung darüber wegwirft.
4 — Jumbo Frames: alles oder nichts
In einem abgeschlossenen Netz — Speicher, Backup, Virtualisierung — kann man die MTU auf 9000 heben. Dann trägt jedes Paket sechsmal so viel Nutzlast, und die Prozessoren an beiden Enden müssen sechsmal weniger Pakete anfassen. Der Haken: Das funktioniert nur, wenn jedes Gerät im Segment mitmacht.
- Nur in einem eigenen, abgeschlossenen Segment (Storage-VLAN, Backup-Netz) — nie auf dem Weg ins Internet.
- Server, Switch-Ports, Uplinks, VMkernel-Ports und das Storage-Array müssen alle denselben Wert tragen.
- Manche Switche zählen den Ethernet-Rahmen statt der MTU. 9000 MTU heißt dort 9014 oder 9216 — Handbuch lesen.
- Nach dem Umstellen gegenprüfen: ping -M do -s 8972 <storage-ip> muss durchgehen.
Was stellst du wo ein?
Wo willst du die MTU setzen?
Router, WAN-Seite
Bei DSL mit PPPoE gehört hier 1492 hin. Bei Kabel, Glasfaser und DHCP bleibt 1500 richtig — setze den Wert nur herunter, wenn du weißt warum.
Das Trägernetz muss größer sein als das, was hindurchläuft — mindestens um den Kapselungs-Overhead. Zwei Wege führen dahin: den Unterbau auf Jumbo heben (9000 auf allen physischen Strecken) und die Gäste bei 1500 lassen, oder den Unterbau bei 1500 lassen und die Gäste absenken. Der häufigste Fehler beim Absenken ist, den Unterbau versehentlich mitzusenken — dann fehlt der Kapselung genau der Platz, den man ihr schaffen wollte, und es bricht später und schwerer auffindbar: erst bei großen Übertragungen.
5 — Die Segmentgröße wird über Kreuz vereinbart
Beim Verbindungsaufbau sagt jede Seite, was sie selbst empfangen möchte — und die Gegenseite hält sich daran. Nicht umgekehrt. Deshalb begrenzt deine MTU nicht, was du sendest; sie begrenzt, was du ankündigst.
UDP, QUIC, ICMP, GRE und ESP haben keine MSS. Stehen dort zwei verschiedene MTUs im selben Netzsegment, bricht es still — und nur in eine Richtung: von groß nach klein. Der Empfänger verwirft den zu großen Rahmen im Treiber, und weil im selben Segment kein Router steht, meldet das niemand zurück.
MSS-Clamping — der übliche Rettungsanker
Beim Verbindungsaufbau sagt jede TCP-Seite, wie große Stücke sie annehmen kann: die MSS. MSS-Clamping heißt, dass der Router diese Zahl im Vorbeigehen herunterschreibt — auf das, was durch seinen Engpass tatsächlich passt. Dann verhandeln beide Seiten von vornherein eine Größe, die durchgeht, und niemand ist auf eine ICMP-Meldung angewiesen.
Am besten sitzt die Regel auf dem Gerät, das den Engpass terminiert: dem Router mit dem PPPoE-Anschluss, dem VPN-Endpunkt, der Firewall vor dem Tunnel. Dort kennt es die kleinere MTU und kann sie mit --clamp-mss-to-pmtuselbst einsetzen. Zwingend ist das aber nicht: Auch ein Gerät MITTENDRIN kann clampen, solange die Verbindungsaufbau-Pakete über es laufen — genau dafür ist die FORWARD -Kette unten da. Es muss dann nur den passenden Wert fest vorgegeben bekommen, weil es die Engstelle nicht kennt.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtunft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtuIn den meisten Heim- und Firmenroutern heißt derselbe Schalter „MSS Clamping“, „TCP MSS Adjust“ oder „Clamp MSS to MTU“ und steht bei den WAN- oder VPN-Einstellungen.
MSS-Clamping wirkt nur auf TCP. UDP hat keine MSS — und darüber laufen DNS, WireGuard, Videokonferenzen und QUIC, also ein großer Teil des heutigen Webverkehrs. Wenn nach dem Clamping Webseiten gehen, aber Videoanrufe weiter abbrechen, ist das kein Zufall, sondern genau diese Lücke. Was dann hilft, steht im nächsten Abschnitt.
Clamping setzt voraus, dass dir ein Gerät im Weg gehört. Tut es das nicht — fremdes Firmennetz, Hotel-WLAN, Mobilfunk —, bleibt der Weg über den eigenen Rechner: Linux kann einen Blackhole an den ausbleibenden Bestätigungen selbst erkennen und sich ohne jede ICMP-Meldung nach unten tasten (RFC 4821).
sysctl -w net.ipv4.tcp_mtu_probing=11 heißt „erst wenn ein Blackhole aufgefallen ist", 2 heißt „immer". Als Dauerlösung unschön, weil es erst nach einer spürbaren Hängephase greift — als Notausgang brauchbar.
UDP hat keine MSS — was dann?
Die MSS ist ein Feld im TCP-Verbindungsaufbau. UDP hat keinen Verbindungsaufbau und deshalb auch nichts, was ein Router im Vorbeigehen kleinerschreiben könnte. Jeder Rat der Form „mach MSS-Clamping an“ endet hier — und ausgerechnet die Dienste, bei denen Paketgrößen wehtun, laufen über UDP: WireGuard, QUIC (also HTTP/3), DNS, Videokonferenzen und Spiele.
Statt einer Aushandlung unterwegs gibt es drei Wege, und welcher greift, entscheidet die Anwendung selbst:
WireGuard handelt nichts aus: Was du in MTU = schreibst, gilt. Deshalb ist der Wert dort kein Feinschliff, sondern die einzige Stellschraube — und er muss auf beiden Seitenpassen. wg-quick nimmt ohne Angabe 1420: 1500 minus 80, also vorsorglich mit dem teureren IPv6-Kopf gerechnet. Hinter DSL mit PPPoE sind schon 1412 richtig, hinter einem weiteren Tunnel entsprechend weniger.
Erkennungszeichen für einen zu großen Wert: Der Tunnel steht, Ping läuft, kleine Abfragen gehen — und sobald etwas Größeres kommt (eine Datei, ein Bild, eine Datenbankantwort), bleibt es hängen.
QUIC verlässt sich bewusst nicht auf ICMP. Es sendet zwischendurch absichtlich größere Testpakete und merkt an der ausbleibenden Bestätigung selbst, wo die Grenze liegt — das Verfahren heißt DPLPMTUD (RFC 8899). Es beginnt bei 1200 Bytes — so groß muss ein UDP-Datagramm mit einem QUIC-Initial-Paket mindestens sein, das ist nicht die Nutzlast der Anwendung — und tastet sich nach oben. Deshalb funktioniert HTTP/3 auch dort noch, wo eine falsch eingestellte Firewall alles ICMP wegwirft. Einstellen musst du dafür nichts — es ist der Grund, warum manche Seiten über HTTP/3 laden, während dieselbe Seite über HTTP/2 hängt.
DNS über UDP hat das Problem am längsten und löst es am schlichtesten: Der Fragende sagt in der EDNS0-Option, wie große Antworten er annehmen kann. Früher standen dort 4096 Bytes — die Antwort wurde dann unterwegs fragmentiert und ging bei kaputter PMTUD verloren. Seit dem DNS Flag Day 2020 ist 1232 der verbreitete konservative Wert: klein genug, um selbst über einen IPv6-Pfad mit der Mindest-MTU 1280 unfragmentiert anzukommen. Zwingend ist er nicht — RFC 9715 nennt inzwischen 1400 als sinnvolle Obergrenze und lässt kleinere Werte ausdrücklich zu. Passt die Antwort nicht hinein, schickt der Server ein Kürzungszeichen und der Fragende wiederholt über TCP.
Wenn also DNSSEC-Antworten oder große TXT-Einträge sporadisch ausbleiben, während normale Abfragen laufen, ist das dasselbe Muster wie bei den halb geladenen Seiten — nur eine Schicht tiefer.
Geht Surfen nach dem MSS-Clamping wieder, aber Videoanrufe brechen weiter ab, hast du das TCP-Problem behandelt und das UDP-Problem stehen lassen. Dann hilft nur, was ohnehin die saubere Lösung ist: die richtige MTU auf dem Engpass-Gerät setzen und ICMP durchlassen — konkret ICMPv4 Typ 3 Code 4 und ICMPv6 Typ 2. Clamping ist ein Verband, keine Heilung.
Selbst nachmessen
Du schickst ein Paket fester Größe mit dem Vermerk „nicht zerlegen“. Kommt eine Antwort, passt es. Kommt stattdessen „Paket müsste fragmentiert werden“, war es zu groß. Dann verkleinerst du, bis es durchgeht.
ping -f -l 1472 ocalhost.net-f heißt „nicht fragmentieren“, -l ist die Nutzlast in Bytes.
ping -M do -s 1472 ocalhost.net-M do heißt „nicht fragmentieren“, -s ist die Nutzlast in Bytes.
ping -D -s 1472 ocalhost.net-D heißt „nicht fragmentieren“, -s ist die Nutzlast in Bytes.
Die Zahl, die du eingibst, ist nicht die MTU, sondern nur die Nutzlast. Dazu kommen 8 Bytes ICMP-Kopf und 20 Bytes IPv4-Kopf:
Rechenkarte — trag deine MTU ein
- MSS IPv4
- 1460
- − 20 IP − 20 TCP
- MSS IPv6
- 1440
- − 40 IPv6 − 20 TCP
- ping-Nutzlast IPv4
- 1472
- − 20 IP − 8 ICMP
- ping-Nutzlast IPv6
- 1452
- − 40 IPv6 − 8 ICMPv6
- Rahmen auf dem Draht
- 1518
- + 14 Ethernet + 4 FCS · mit VLAN-Etikett 1522
Die angekündigte Segmentgröße rechnet nur mit den festen Köpfen — TCP-Optionen zählen ausdrücklich nicht hinein (RFC 6691). Wer Zeitstempel und SACK nutzt, kündigt weiterhin 1460 an, bringt aber nur 1448 Bytes Nutzdaten je Segment unter: Der Sender muss seine Optionen selbst abziehen. Deshalb stimmen der angekündigte Wert und die tatsächlich gesendete Menge nie ganz überein — das ist kein Fehler, sondern so vorgesehen.
Geht 1472 nicht durch, aber 1464, dann liegt deine Pfad-MTU mindestens bei 1492 und unter 1500 — mehr sagt dieses Paar nicht. Die Leiter springt in Achterschritten, der genaue Wert kann also 1492 bis 1499 sein. In der Praxis ist es fast immer 1492 (der DSL-Wert), aber gemessen ist die Spanne. Wer es genau wissen will, tastet sich vom größten durchgehenden Wert in Einerschritten nach oben. Bei IPv6 rechnest du +48 statt +28 (40 Bytes IPv6-Kopf, 8 Bytes ICMPv6).
- Mit 1472 anfangen. Geht durch? Dann trägt der Weg mindestens 1500 — und mehr braucht Ethernet nicht.
- Sonst runter: 1464, 1452, 1440, 1420, 1392. Der erste Wert, der durchgeht, plus 28 ist die Untergrenze deiner Pfad-MTU; der wahre Wert liegt zwischen ihr und dem nächsten gescheiterten Schritt.
- Miss zu mehreren Zielen. Ein einzelnes Ziel sagt dir nur etwas über genau diesen Weg.
- Miss aus dem VPN heraus und daneben. Der Unterschied ist genau der Overhead des Tunnels.
Wichtig: Wenn das Ziel ICMP grundsätzlich nicht beantwortet, misst du gar nichts — dann ist das Ergebnis „nicht prüfbar“ und nicht „MTU zu klein“. Nimm in dem Fall ein anderes Ziel.
Bevor du dich mit ping nach unten tastest: Drei Befehle verraten, was dein System längst gelernt hat. Alle drei lesen nur und laufen ohne Root.
tracepath ocalhost.netZeigt die Pfad-MTU je Abschnitt und meldet am Ende, wo sie kleiner wurde. Bricht die Ausgabe ab einem Abschnitt in lauter „no reply" um, während oben noch ein großer Wert steht, ist das genau das Schwarze Loch von oben. Ein einzelnes „no reply" mittendrin, nach dem es weitergeht, ist dagegen harmlos — ein Router, der seine Antworten begrenzt.
ip route get 1.1.1.1Zeigt, ob dein System für dieses Ziel bereits eine kleinere Pfad-MTU gelernt hat. Steht dort ein Wert, hat Path MTU Discovery funktioniert. Linux vergisst ihn nach etwa zehn Minuten wieder.
ss -tim dst ocalhost.netDie aussagekräftigste Einzelmessung bei laufendem Verkehr: „advmss" ist, was dieser Rechner angekündigt hat, „mss" was tatsächlich gesendet wird, „pmtu" was über den Weg gelernt wurde. Eine große „mss" zusammen mit vielen „retrans" ist das Bild eines Schwarzen Lochs.
Im Mitschnitt nachsehen
Wenn die Zahlen sich widersprechen, hilft der Blick auf die Pakete selbst.
tcpdump -i any -nn -vv 'tcp[tcpflags] & tcp-syn != 0'Was beide Seiten beim Verbindungsaufbau ankündigen. Das -vv ist Pflicht, sonst zeigt tcpdump die TCP-Optionen gar nicht.
tcpdump -i any -nn -vv 'icmp[icmptype] == 3 and icmp[icmpcode] == 4'Kommt „Fragmentation needed" überhaupt zurück? Bleibt das still, während große Pakete verschwinden, ist die Meldung unterwegs weggefiltert.
tcpdump -i any -nn -vv 'icmp6 and ip6[40] == 2'Dasselbe für IPv6: „Packet Too Big".
Im Mitschnitt tauchen Pakete von 16000 oder 64000 Bytes auf, die so nie über die Leitung gingen: Die Netzwerkkarte setzt große Blöcke erst danach in echte Rahmen um (TSO/GSO), und ankommende fasst sie vorher zusammen (GRO). Betroffen ist ausschließlich die Paketlänge — Verbindungsaufbau, ICMP und die Fragment-Kennzeichen laufen nicht durch diese Pfade und bleiben aussagekräftig. Wer wirklich Drahtgrößen braucht, schneidet woanders mit: am Spiegelport des Switches oder auf dem Router. Die Beschleunigung am produktiven Server abzuschalten kostet Durchsatz und Rechenzeit.
Häufige Irrtümer
„1500 ist immer richtig.“
Meistens, aber nicht immer. Sobald PPPoE, VPN oder ein anderer Tunnel im Spiel ist, ist 1500 innen zu groß — und zwar genau um den Overhead dieser Schicht. Auch ohne Tunnel ist 1500 keine Zusicherung: Die Pfad-MTU richtet sich nach dem SCHMALSTEN Abschnitt des aktuellen Weges, und der kann in einem Richtfunkabschnitt oder bei einem Provider-Übergang enger sein. Deshalb misst man, statt zu setzen.
„Ich habe 1500 gepingt, also ist meine MTU 1500.“
Nein: Die Zahl hinter -l bzw. -s ist die Nutzlast. Plus 8 Bytes ICMP-Kopf plus 20 Bytes IPv4-Kopf ergibt die MTU. Wer 1500 Nutzlast durchbekommt, hat also eine Pfad-MTU von mindestens 1528 gemessen. Entscheidend ist dabei, ob das DF-Bit gesetzt war: MIT DF (-f, -M do, -D) ist Fragmentierung ausgeschlossen — der Weg trägt die Größe dann wirklich, was auf Jumbo Frames im lokalen Netz hindeutet. OHNE DF sagt der Erfolg gar nichts über die Pfad-MTU aus, denn dann durfte unterwegs jeder Router zerlegen.
„ICMP komplett zu blocken ist sicherer.“
Es baut genau das Schwarze Loch von oben. Ohne „Fragmentation needed“ (IPv4) beziehungsweise „Packet Too Big“ (IPv6) kann kein Gegenüber seine Paketgröße anpassen.
„MSS-Clamping löst das Problem.“
Für TCP ja, und das ist viel. Für UDP, QUIC und alles Getunnelte nicht — moderne Browser holen viel über QUIC, und das läuft an der MSS vorbei.
„Jumbo Frames überall einschalten bringt Tempo.“
Nur in einem abgeschlossenen Netz, in dem jedes einzelne Gerät mitspielt. Ein Gerät auf 1500 dazwischen, und große Übertragungen sterben still.
„MTU höher = schneller.“
Eine höhere MTU spart anteilig Kopfdaten, mehr nicht — im einstelligen Prozentbereich. Eine falsch gesetzte MTU kostet dagegen die halbe Funktion.
Wenn du jetzt weitersuchen willst
Ein MTU-Verdacht lässt sich mit dem Weg zusammenlesen: Wo wechselt der Pfad das Netz, wo beginnt der Tunnel?
Worauf sich das hier stützt
Die Zahlen und Regeln auf dieser Seite stammen aus den folgenden Normen, nicht aus Foren.
- RFC 1191 — Path MTU Discovery — das DF-Bit-Verfahren, die Werteleiter und die Untergrenze von 68 Bytes
- RFC 8201 — Path MTU Discovery für IPv6 — dort Pflicht, nicht Kür
- RFC 8200 — IPv6 — Mindest-MTU 1280, und Router fragmentieren nicht
- RFC 2923 — Die bekannten Probleme mit PMTUD, einschließlich des Schwarzen Lochs
- RFC 6691 — Die angekündigte Segmentgröße rechnet ohne TCP-Optionen
- RFC 9293 — TCP — löst RFC 793 ab und definiert die MSS-Option
- RFC 4821 — PLPMTUD — Größe finden ohne ICMP
- RFC 8899 — Dasselbe für Datagramme, davon lebt QUIC
- RFC 9000 — QUIC — mindestens 1200 Bytes je Datagramm
- RFC 4890 — Welche ICMPv6-Nachrichten eine Firewall durchlassen muss
- RFC 5508 — Was ein NAT mit ICMP-Fehlermeldungen zu tun hat
- RFC 2516 — PPPoE — Ursprung der 1492
- RFC 4638 — PPPoE mit voller 1500er-MTU, wenn die Strecke es hergibt
- RFC 6333 — DS-Lite — IPv4 im IPv6-Tunnel, 40 Bytes Kapselung
- RFC 7348 — VXLAN
- RFC 8926 — GENEVE
- RFC 9715 — DNS über UDP kleiner halten statt fragmentieren