Ende 2023 rief mich ein Kunde an, der frisch einen 250-Mbit/s-Anschluss bekommen hatte und trotzdem beim Backup vom Server nur rund 3 Mbit/s sah. Die Leitung war okay, der Router neu, der Rechner schnell, und interaktives SSH über den Tunnel fühlte sich an wie damals mit Modem. Ich saß in seinem Büro, tippte zwei Kommandos und hatte zehn Minuten später den Schuldigen: eine einzelne Zahl im Netzwerkstapel, die MTU, und der MSS-Wert, den sein VPN-Client dem Server angekündigt hatte. Kein defektes Kabel, kein langsamer Provider, sondern eine Overhead-Frage, die zwei falsch konfigurierte Geräte zu einem stillen Bremsschuh machte.

Dieser Artikel ist die Anleitung, die ich mir damals gewünscht hätte. Er erklärt, was MTU und MSS wirklich tun, warum ein falscher Wert Downloads und SSH lahmlegt, obwohl dein Link gigabit-schnell ist, und wie du das Problem mit ping und iproute2 in zehn Minuten findest. Am Ende geht es um Jumbo Frames, die große Schwester, die im falschen Netz mehr kaputtmacht als sie bringt.

Was die MTU überhaupt ist

MTU steht für Maximum Transmission Unit und beschreibt, wie groß ein einzelnes Datenpaket auf einem Link maximal sein darf. Nicht die Rohdaten, sondern das komplette Paket inklusive Kopf. Für klassisches Ethernet auf Kupfer ist der Standardwert 1500 Byte. Das ist kein Gesetz der Physik, sondern eine jahrzehntealte Konvention, an der sich alle Netzwerkgeräte orientieren, damit sie sich überhaupt verstehen.

Praktisch jedes Gerät, das du einsteckst, geht von dieser Konvention aus. Solange der ganze Weg zwischen zwei Rechnern diese Größe trägt, läuft nichts verkehrt. Das Problem beginnt, sobald irgendwo in der Kette ein Link dünner wird. Und dünner wird er fast immer durch Tunneling: VPN, GRE, PPPoE, jeder Kapselung schlägt Overhead auf das Paket drauf.

Fragmentierung: Wenn Pakete geteilt werden müssen

Wenn ein Paket zu groß für den nächsten Link ist, hat der Router genau zwei Optionen. Er darf das Paket in kleinere Stücke zerlegen, das nennt sich Fragmentierung. Ein 1500-Byte-Paket, das auf einen Link mit MTU 1420 trifft, wird zu einem 1420-Byte-Fragment und einem Rest von grob 80 Byte. Beide reisen getrennt und werden erst am Ziel wieder zusammengesetzt. So weit, so machbar, und genau das macht die Path-MTU-Discovery im Kern sichtbar.

Paketpfad-Diagramm: Ein Sender schickt ein 1500-Byte-Paket zu einem Router, dessen Ausgang nur MTU 1420 erlaubt. Der Router fragmentiert das Paket in 1420 und 80 Byte, gesetztes DF-Bit führt zum Verwerfen mit ICMP-Meldung

Nur hat Fragmentierung einen bösen Preis. Jedes Fragment kostet den Router Rechenzeit, und bei vielen großen Paketen wird der Router zum Flaschenhals. Schlimmer: Ein einziges verlorenes Fragment bedeutet, dass alle Fragmente des Pakets neu geschickt werden müssen. Fragmentierung ist deshalb ein Notnagel, keine Lösung.

Deshalb gibt es das DF-Bit, Don't Fragment, im IP-Header. Ist es gesetzt, was im modernen Internet fast immer der Fall ist, darf kein Router das Paket teilen. Stattdessen verwirft er es und schickt eine ICMP-Meldung zurück: Fragmentierung nötig, und zwar mit genau dieser kleineren MTU. Diese eine Meldung ist der Kern der Path-MTU-Discovery.

Path MTU Discovery: Die Vermessung der Strecke

Der Sender startet mit der vollen Paketgröße und setzt das DF-Bit. Trifft irgendwo unterwegs ein Router auf eine zu kleine MTU, verwirft er das Paket und meldet per ICMP die kleinere Grenze. Der Sender passt seine Paketgröße an und versucht es erneut. So tastet er sich langsam an die kleinste MTU der gesamten Strecke heran. Klingt elegant, und meistens funktioniert es auch.

Das Problem: Die Methode hängt komplett an dieser ICMP-Meldung. Und ICMP ist genau das Protokoll, das übermotivierte Firewalls gern pauschal blockieren. Wenn der Router die Meldung sendet, die Firewall sie aber wegwirft, merkt der Sender nie, dass seine Pakete zu groß sind. Er sendet weiter in der vollen Größe, die Pakete werden mitten auf der Strecke still verworfen, und TCP muss jedes Mal auf den Retransmit-Timeout warten, bevor es merkt, dass etwas fehlt.

Das Ergebnis ist genau das Symptom aus meiner Kundengeschichte: Der Datenverkehr bricht nicht komplett zusammen, aber er schleicht, weil ständig Pakete verloren gehen und wiederholt werden. Bei interaktivem SSH merkst du es zuerst, weil dort jede Verzögerung sofort auffällt. Bei großen Downloads fällt die Geschwindigkeit auf einen Bruchteil, und der Blick auf die Leitung zeigt, dass physikalisch alles in Ordnung ist.

MSS: Die eigentliche Stellschraube

Hier kommt MSS ins Spiel, das Maximum Segment Size. Während die MTU auf Ebene der IP-Pakete wirkt, bezieht sich die MSS auf die Nutzdaten eines TCP-Segments. Bei jedem Verbindungsaufbau, im TCP-Handshake, tauschen beide Seiten ihren MSS-Wert aus.

Der Standard: MSS ist MTU minus 40 Byte. Genau 20 Byte für den IP-Header und 20 Byte für den TCP-Header. Bei MTU 1500 ergibt das MSS 1460. Bei IPv6 wären es 40 Byte IP-Header, also MSS 1440. Beide Seiten leiten ihren Wert aus der MTU ihres lokalen Interfaces ab. Und genau hier liegt die Falle bei jedem Tunnel.

Dein Rechner hat ein Interface mit MTU 1500 und verkündet stolz MSS 1460. Das Paket wandert aber durch einen VPN-Tunnel, der auf der anderen Seite die MTU auf 1420 begrenzt, weil die Kapselung echten Overhead hinzufügt. Der Server sendet nun Segmente, die für eine MTU 1500 gebaut sind. Sie passen nie durch den 1420er-Hals, die Path-MTU-Discovery scheitert an einer blockierten ICMP-Meldung, und dein Download verhungert, obwohl auf dem Papier alles stimmt.

Die Lösung heißt MSS Clamping: Der Router oder der VPN-Client schreibt den MSS-Wert in jedem Handshake auf einen Wert, der zur kleineren MTU passt. Bei einer Tunnel-MTU von 1420 ist das MSS 1380. Der Server sendet dann nie mehr als 1420-Byte-Pakete, und alles passt wieder. Viele Tunnel-Software macht das automatisch, aber nicht jede richtig. Genau das war beim Kunden der Fall.

Diagnose in der Praxis: ping und iproute2

Wie findest du nun die kleinste MTU deiner Strecke? Mit ping und dem DF-Bit. Der Trick: Ein Ping-Paket ist bei MTU 1500 maximal 1472 Byte Nutzlast groß, denn 28 Byte gehen für IP- und ICMP-Header drauf. Sende also mit gesetztem DF-Bit ein 1472-Byte-Paket und schaue, ob es ankommt:

# ping -M do -s 1472 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1472(1500) bytes of data.
1480 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.23 ms
--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Kommt das Paket an, passt MTU 1500 auf dieser Strecke. Schlägt es fehl, liegt die MTU darunter, und du musst die Nutzlast reduzieren, bis es klappt:

# ping -M do -s 1472 10.0.0.1
ping: local error: message too long, mtu=1420
# ping -M do -s 1420 10.0.0.1
# ping -M do -s 1392 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1392(1420) bytes of data.
1400 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.41 ms

Die Nutzlast 1392 plus 28 Byte Header ergibt genau 1420, also die MTU deines Tunnels. Der Fehler message too long, mtu=1420 ist übrigens kein Zufall: Das lokale Interface kennt seine Grenze schon und meckert sofort. Wenn Pakete dagegen mitten auf der Strecke verloren gehen, siehst du stattdessen Timeouts, und genau dann solltest du an eine blockierte ICMP-Meldung denken. In dem Fall hilft ein Blick in die Firewall, und wenn die Meldung wirklich blockiert ist, muss die MTU eben statisch gesetzt werden.

Hast du die MTU gefunden, setzt du sie auf dem Tunnel-Interface und kürzt zusätzlich den MSS-Wert. Mit iproute2 geht beides in einer Zeile:

# ip link set dev wg0 mtu 1420
# ip route change default dev wg0 mtu 1420 advmss 1380

Der Parameter advmss setzt den MSS-Wert, den dein System im Handshake ankündigt, auf 1380. Genau diese Kombination fehlte beim Kunden, und nach den zwei Zeilen lief das Backup mit über 200 Mbit/s statt mit 3. Ich prüfe seither bei jedem neuen Tunnel zuerst die MTU, bevor ich irgendetwas anderes an der Performance verdächtige. Wer die echte Obergrenze seiner Leitung rechnen will, findet im bitcalc Download-Zeit-Rechner eine schnelle Abschätzung, was ein Anschluss theoretisch schafft, auch wenn die MTU gerade streikt.

Der VPN-Fall zum Nachbauen

Damit du das Muster erkennst, hier der konkrete Ablauf beim Kunden. Ein Rechner im Büro mit LAN-MTU 1500 baut einen WireGuard-Tunnel zu einem Server im Rechenzentrum auf. WireGuard setzt auf UDP, und jede Kapselung kostet Overhead, sodass die effektive MTU des Tunnels bei 1420 liegt. Der Server im Rechenzentrum hat seine eigenen Interfaces aber auf 1500 und kennt die 1420er-Grenze des Kunden nicht. Also sendet er Segmente, die nie durch den Tunnel passen, und die Geschichte aus der Diagnose wiederholt sich: stille Drops, Retransmits, ein Backup, das nie fertig wird.

Die Diagnose-Reihenfolge, die ich inzwischen jedem Kunden und mir selbst als Checkliste anlege:

  • Baseline checken: Ping auf den Default-Gateway mit 1472 Byte und DF-Bit. Schlägt das fehl, stimmt schon im LAN etwas nicht.
  • Durch den Tunnel testen: Dieselbe Ping-Größe auf die Gegenseite des Tunnels. Hier zeigt sich, ob der Tunnel die volle Größe trägt.
  • Stückweise reduzieren: Nutzlast in 100er-Schritten senken, bis der Ping durchläuft, dann in kleinen Schritten verfeinern. Ergebnis plus 28 ist deine MTU.
  • MTU und MSS setzen: ip link und ip route auf dem Tunnel anpassen, wie oben gezeigt, und den MSS-Wert auf MTU minus 40 klemmen.
  • ICMP erlauben: Prüfen, dass die Firewall ICMP-Type-3-Code-4 (Fragmentation needed) durchlässt, sonst scheitert die Discovery dauerhaft.

Das klingt nach viel, ist aber in der Praxis ein Einzeiler pro Schritt. Wer sein Netz in Subnetze aufteilt und dabei die Pfade im Kopf behalten muss, dem hilft der bitcalc Subnetz-Rechner dabei, die Routen sauber zu planen, denn jede Route ist letztlich ein MTU-Pfad.

Jumbo Frames: MTU 9000 und wo sie wirklich helfen

Jumbo Frames sind Frames mit einer MTU über 1500, typischerweise 9000 Byte. Sie entlasten die CPU, weil weniger Pakete für dieselbe Datenmenge verarbeitet werden müssen, und sie senken den Overhead pro Byte.

Wo sie richtig gut sind: in einem isolierten Storage-Netz zwischen Server und NAS, bei iSCSI, NFS oder Backups über Glasfaser, wo beide Enden und der ganze Switch Jumbo Frames beherrschen. Dort steigern sie den Durchsatz messbar und senken die CPU-Last auf den beteiligten Rechnern. Ich setze sie in genau einem Segment ein, dem Backend-Netz zwischen zwei Backup-Servern und dem NAS, und dort laufen die Backups messbar schneller.

Wo sie weh tun: überall dort, wo irgendein Gerät die 9000 nicht kann oder will. Jumbo Frames funktionieren nur, wenn der komplette Pfad, also beide Netzwerkkarten, alle Switches und jede CPU auf dem Weg, die größere MTU beherrscht. Ein einziger Switch oder eine falsch eingestellte Karte auf dem Weg bricht die Verbindung, und zwar auf die nervige Art: Erst läuft alles, dann hängt ein Transfer, weil ein Segment auf einen 1500er-Link trifft.

Noch wichtiger: Jumbo Frames gehören nie in ein Segment, das mit dem Internet oder einem VPN verbunden ist. Öffentliche Netze und Tunnel arbeiten mit 1500 oder darunter, und ein Server mit MTU 9000, der ins Internet gehen muss, erzeugt dort nur Fragmentierungsprobleme. Deshalb gilt die Faustregel: Jumbo Frames nur auf einem isolierten Layer-2-Segment, nie über einen Router, der Richtung Internet zeigt. Wer sie im Storage-Netz einsetzt, sollte alle beteiligten Geräte dokumentieren, denn das Vergessen einer einzigen Karte ist der Klassiker.

Was bedeutet das für den Hausgebrauch? Ein Homelab mit ein paar Geräten und einem simplen Switch gewinnt durch Jumbo Frames kaum etwas, die CPU ist selten der Flaschenhals. Erst bei 10-Gigabit-Storage und vielen parallelen großen Transfers lohnt sich der Aufwand. Prüf den Nutzen also vorher, statt die MTU aus Prinzip auf 9000 zu stellen, denn im schlimmsten Fall machst du dein Netz langsamer, nicht schneller.

Wann ich MTU anfasse

Ein paar feste Anlässe, zu denen ich die MTU aktiv prüfe:

  • Jedes neue VPN oder Tunnel: Nach dem Aufbau teste ich sofort die maximale Ping-Größe durch den Tunnel und klemmte den MSS-Wert passend. Das erspart den allermeisten Support-Stress.
  • Downloads, die trotz schneller Leitung schleichen: Bevor ich Provider oder Hardware verdächtige, messe ich die MTU-Strecke. In den meisten Fällen ist es Overhead, nicht Bandbreite.
  • SSH oder Remote-Sitzungen, die sporadisch hängen: Das typische MTU-Symptom ist kein kompletter Abbruch, sondern ein Gefühl von Latenz, das kommt und geht.
  • PPPoE-Anschlüsse: Viele Glasfaser- und DSL-Anschlüsse nutzen PPPoE, das 8 Byte Overhead kostet. Deshalb ist die MTU dort oft 1492 statt 1500, und ein statisches MSS Clamping auf 1452 gehört zum Setup.
  • Nach einer Änderung am Netz: Neuer Switch, neue Firewall-Regel, neue WAN-Leitung. Jede Änderung kann die kleinste MTU verschieben.

Interessant ist dabei, wie selten die Leitung das Problem ist. Die Netzwerkkarte, der Router und der Provider liefern fast immer die versprochene Bandbreite, aber die Konfiguration der Paketgrößen darüber entscheidet, ob du sie auch nutzen kannst. Der bitcalc Download-Zeit-Rechner hilft, die realistische Obergrenze zu sehen, denn wenn die Theorie 100 Mbit/s verspricht und du bei 3 hängst, ist der Verdacht auf MTU oder MSS fast immer richtig.

Fazit

MTU und MSS sind keine trockene Theorie, sondern die häufigste unsichtbare Ursache für lahme Verbindungen. Die MTU begrenzt die Paketgröße pro Link, die Path-MTU-Discovery findet die kleinste Grenze der Strecke, und der MSS-Wert sorgt dafür, dass TCP-Segmente von Anfang an passen. Sobald ein Tunnel Overhead hinzufügt, rutscht die effektive MTU nach unten, und ohne MSS Clamping senden beide Seiten zu groß.

Die Werkzeuge dafür hat jeder Linux-Admin schon: ping mit DF-Bit misst die Strecke, iproute2 setzt MTU und MSS in zwei Zeilen, und eine Firewall-Regel für ICMP hält die Discovery am Leben. Beim Kunden hat diese Kombination aus einer 3-Mbit/s-Übung ein Backup gemacht, das seine Leitung tatsächlich ausnutzt. Seitdem ist meine erste Frage bei jeder langsamen Verbindung nicht, wie schnell der Anschluss ist, sondern wie groß die Pakete sein dürfen.