MTU-/Fragmentierungsprobleme: Ursache von „Small works, large fails“

MTU-/Fragmentierungsprobleme sind eine der häufigsten Ursachen für das klassische Fehlerbild „Small works, large fails“: Kleine Pakete kommen an, große Datenübertragungen hängen, brechen ab oder werden extrem langsam. In der Praxis äußert sich das selten als eindeutige Fehlermeldung. Stattdessen sehen Sie Symptome wie: Ping geht, DNS geht, TCP-Handshake klappt – aber Downloads starten nicht, HTTPS-Seiten laden nur teilweise, VPN-Verbindungen sind instabil, Datei-Uploads scheitern oder bestimmte API-Calls time-outen. Das ist besonders tückisch, weil viele Standardtests mit kleinen Payloads arbeiten und das Problem dadurch „unsichtbar“ bleibt. Hinter dem Muster steckt fast immer ein MTU-Mismatch im Pfad oder ein Fehler in der Fragmentierungslogik: Pakete sind zu groß für eine Teilstrecke, Path MTU Discovery (PMTUD) funktioniert nicht zuverlässig, oder ICMP-Meldungen, die für PMTUD nötig sind, werden gefiltert. Dieser Leitfaden erklärt verständlich und praxisnah, wie MTU und Fragmentierung zusammenhängen, warum „klein geht, groß scheitert“ entsteht, welche Umgebungen besonders anfällig sind (VPN, Tunnel, SD-WAN, Provider-Edges, Cloud) und wie Sie die Ursache schnell und reproduzierbar bestätigen – inklusive sauberer Beweisführung für NOC, Support und Eskalation.

Was MTU bedeutet und warum sie im Betrieb so entscheidend ist

Die Maximum Transmission Unit (MTU) ist die maximale Größe (in Bytes) eines Frames oder Pakets, das auf einer Verbindung ohne Fragmentierung übertragen werden kann. Häufig ist im Ethernet-Umfeld eine MTU von 1500 Bytes üblich. Sobald zusätzliche Header ins Spiel kommen – etwa durch VLAN-Tags, PPPoE, IPsec, GRE, VXLAN oder andere Tunnel – reduziert sich die effektiv nutzbare Payload-Größe, weil der Overhead Platz „frisst“. Wenn ein Gerät dennoch Pakete mit zu großer Größe sendet, muss irgendwo im Pfad entschieden werden: fragmentieren, verwerfen oder eine kleinere Pfad-MTU signalisieren.

• MTU ist pfadabhängig: Die kleinste MTU entlang eines Pfades bestimmt die maximale Paketgröße.
• Overhead ist der häufigste Auslöser: Tunnel und Encapsulation senken die effektiv nutzbare MTU.
• Das Problem ist oft selektiv: Nur bestimmte Ziele, bestimmte Pfade oder nur VPN-Traffic sind betroffen.

Fragmentierung und PMTUD: Warum „Small works, large fails“ entsteht

Damit große Pakete trotzdem ans Ziel kommen, gibt es im IP-Bereich zwei Mechanismen: Fragmentierung und Path MTU Discovery (PMTUD). Vereinfacht: Fragmentierung zerlegt ein zu großes IP-Paket in kleinere Teile. PMTUD versucht, Fragmentierung zu vermeiden, indem es die maximale Paketgröße für den Pfad automatisch ermittelt und den Sender dazu bringt, kleinere Pakete zu senden.

IPv4: Fragmentierung ist möglich, aber oft unerwünscht

Bei IPv4 können Router Pakete fragmentieren, wenn ein Paket zu groß ist – außer das Paket ist mit „Don’t Fragment“ (DF) markiert. Viele Systeme setzen DF, um Fragmentierung zu vermeiden, weil Fragmentierung Performance kostet und fehleranfälliger ist. Wenn DF gesetzt ist und ein Router nicht fragmentieren darf, sollte er eine ICMP-Meldung „Fragmentation Needed“ zurücksenden. Kommt diese Meldung nicht zurück (weil sie gefiltert wird), bleibt der Sender bei zu großen Paketen – und die Übertragung „hängt“.

IPv6: Router fragmentieren nicht – PMTUD ist Pflicht

Bei IPv6 fragmentieren Router grundsätzlich nicht. Wenn ein Paket zu groß ist, muss der Sender die Paketgröße reduzieren, basierend auf ICMPv6 „Packet Too Big“. Wird dieses ICMPv6 gefiltert, sind MTU-Probleme unter IPv6 besonders schnell sichtbar, häufig als scheinbar zufällige Timeouts oder einseitig funktionierende Verbindungen.

Für die formalen Grundlagen von IP-Verhalten und Router-Anforderungen ist der Anchor-Text RFC 1812 (Requirements for IP Version 4 Routers) eine belastbare Referenz, und für IPv6-Details ist der Anchor-Text RFC 8200 (IPv6 Specification) hilfreich.

Typische Symptome: So sieht ein MTU-/Fragmentierungsproblem in der Praxis aus

Das Fehlerbild ist oft konsistent, aber nicht offensichtlich. Entscheidend ist, dass kleine Kontrollpakete und einfache Tests funktionieren, während echte Nutzdaten scheitern.

• Ping klappt, aber HTTPS hängt: ICMP ist klein, TLS/HTTP transportiert größere Segmente und reagiert empfindlich auf Drops.
• TCP-Handshake klappt, Datenfluss bricht ab: SYN/SYN-ACK/ACK sind klein; große Datenpakete werden verworfen.
• VPN „verbindet“, aber Traffic ist instabil: Tunnel-Overhead senkt die effektive MTU; ohne MSS-Clamping entstehen zu große Segmente.
• Uploads/Downloads brechen ab oder sind extrem langsam: Retransmits und Backoff dominieren, sobald große Segmente droppen.
• Nur bestimmte Ziele betroffen: Je nach Pfad oder Provider-Strecke ist die minimale MTU unterschiedlich.
• IPv6 auffällig instabil: ICMPv6-Filter blocken „Packet Too Big“, wodurch PMTUD scheitert.

Warum Standardtests täuschen: „Ping ist normal“ ist kein Gegenbeweis

Viele Troubleshooting-Routinen verlassen sich auf Ping und Traceroute. Bei MTU-Problemen liefern diese Tools häufig ein falsches Sicherheitsgefühl, weil sie standardmäßig kleine Pakete senden und weil ICMP-Verkehr im Netz anders behandelt sein kann als TCP/UDP. Ein MTU-Problem zeigt sich oft erst bei größeren Payloads oder bei Protokollen, die größere Segmente erzeugen (z. B. TLS, SMB, bestimmte API-Responses).

• Kleine Pakete gehen immer noch durch: Der Pfad kann für kleine Größen stabil sein.
• Der Fehler ist größenabhängig: Das ist das Kernsignal von „Small works, large fails“.
• Retransmits maskieren die Ursache: Anwendungen wirken „langsam“, obwohl es eigentlich Drops großer Pakete sind.

Die häufigsten Ursachen: Wo MTU im Pfad „kaputt“ wird

In den meisten Umgebungen sind MTU-Probleme kein Zufall, sondern folgen einem von wenigen typischen Ursachenmustern.

Tunnel-Overhead (IPsec, GRE, VXLAN, WireGuard, PPPoE)

Tunnel fügen Header hinzu. Wenn Sie die MTU an den Endpunkten nicht passend reduzieren oder TCP MSS nicht anpassen, erzeugen Clients Pakete, die im Tunnelpfad zu groß werden. Besonders häufig ist das bei Site-to-Site-VPNs, Remote-Access-VPN, SD-WAN-Overlays und Cloud-Interconnects.

ICMP wird gefiltert oder depriorisiert

PMTUD ist auf ICMP-Meldungen angewiesen. Wenn Firewalls oder Security-Policies ICMP (IPv4) oder ICMPv6 (IPv6) blocken, kann der Sender die notwendige Pfad-MTU nicht lernen. Das führt zu stillen Drops großer Pakete und zu dem Eindruck, die Verbindung „hängt“ ohne Fehlermeldung.

Inkonsequente MTU-Konfiguration im Layer-2-/Provider-Umfeld

• Ein Uplink ist auf 1500, ein anderer auf 1492 (z. B. PPPoE), ein dritter erlaubt Jumbo Frames.
• Provider-Edges oder MPLS-Strecken haben eigene MTU-Limits, die nicht sauber dokumentiert sind.
• VLAN-Tagging reduziert den nutzbaren Raum, wenn Geräte knapp konfiguriert sind.

Asymmetrische Pfade und unterschiedliche MTU in Hin- und Rückrichtung

Wenn der Rückweg über eine Strecke mit kleinerer MTU läuft, kann der Hinweg unauffällig sein, während Rückpakete mit größeren Payloads droppen. Das wirkt wie einseitiger Traffic oder wie ein Problem „nur bei Responses“.

Praktischer Rechenanker: Effektive MTU und MSS verstehen

Für die Praxis ist nicht nur die MTU wichtig, sondern auch die TCP MSS (Maximum Segment Size). MSS beschreibt die maximale TCP-Payload pro Segment (ohne IP- und TCP-Header). Wenn MSS zu groß ist, entstehen TCP-Segmente, die im Pfad zu MTU-Problemen führen. Ein grober, praxisnaher Zusammenhang:

$\mathrm{MSS}=\mathrm{MTU}-\mathrm{IPHeader}-\mathrm{TCPHeader}$

Für IPv4 ohne Optionen beträgt der IP-Header typischerweise 20 Bytes, der TCP-Header ebenfalls 20 Bytes. Damit gilt als Faustregel: MSS ≈ MTU − 40. Bei IPv6 ist der Basis-Header 40 Bytes, der TCP-Header 20 Bytes, also MSS ≈ MTU − 60 (ohne Extension Headers). Der entscheidende Punkt: Wenn Sie durch Tunnel-Overhead die effektive MTU senken, müssen Sie entweder die MTU passend setzen oder MSS-Clamping nutzen, damit Endgeräte keine zu großen Segmente erzeugen.

Schneller Nachweis im Betrieb: So bestätigen Sie „Small works, large fails“ reproduzierbar

Eine gute Bestätigung ist immer größenbasiert: Sie zeigen, dass kleine Payloads zuverlässig funktionieren, aber ab einer bestimmten Größe reproduzierbar scheitern. Der Nachweis wird noch stärker, wenn er sich auf dem betroffenen Pfad und im betroffenen Protokoll wiederholen lässt (z. B. innerhalb des VPN-Tunnels oder zu einem spezifischen Cloud-Endpunkt).

Größenbasierte Tests in sinnvoller Reihenfolge

• Baseline (klein): Ein einfacher Connectivity-Test zum Ziel (oder Gateway) mit Standardgröße.
• Schrittweise erhöhen: Payload in Stufen erhöhen, bis ein klarer Schwellenwert erkennbar ist.
• Richtung prüfen: Test in beide Richtungen, wenn möglich, um asymmetrische MTU-Fälle zu erkennen.
• Im Tunnel testen: Bei VPN/SD-WAN nicht nur „außerhalb“, sondern explizit über den Tunnelpfad.

Was ein „echter“ MTU-Beweis ist

• Kleine Payloads sind stabil (nahezu 0% Verlust), große Payloads verlieren reproduzierbar Pakete oder hängen.
• Die Schwelle ist relativ konstant (z. B. ab ~1400 Byte problematisch), nicht zufällig.
• Das Problem korreliert mit einem bekannten Overhead (VPN/Tunnel/PPPoE) oder mit einem ICMP-Filter.

Diagnose entlang des Pfads: Wo genau entsteht der Drop?

MTU-Probleme werden schneller gelöst, wenn Sie nicht nur „es ist MTU“ sagen, sondern zeigen, wo im Pfad die maximale Paketgröße kippt. Dafür eignet sich eine Messkette: Client → Gateway, Gateway → Edge, Edge → Ziel. Der Ort, an dem die „großen“ Pakete beginnen zu scheitern, ist Ihr Hauptverdächtiger: Tunnel-Endpunkt, Firewall, Provider-Edge oder ein spezifischer Übergang.

• Nur Client → Gateway betroffen: lokales Segment (WLAN/LAN), eher nicht klassisches PMTUD-Problem, aber möglich bei lokaler MTU-Fehlkonfiguration.
• Ab Edge/WAN betroffen: sehr häufig PPPoE, Provider-MTU, Tunnel-Overhead oder ICMP-Filter am Rand.
• Nur zu bestimmten Zielen betroffen: Pfadabhängigkeit, z. B. Cloud/Provider-Strecke, Peering, spezielle Tunnelroute.

ICMP und PMTUD: Der häufigste Grund, warum MTU-Probleme bestehen bleiben

Wenn PMTUD korrekt arbeiten soll, müssen bestimmte ICMP-Typen durchgelassen werden. Im Betrieb werden ICMP-Nachrichten jedoch häufig pauschal geblockt („Sicherheitsgründe“), was den Kernmechanismus von PMTUD aushebelt. Das Ergebnis ist ein klassisches MTU-Blackhole: Pakete sind zu groß, dürfen nicht fragmentiert werden (oder können es nicht), und die „Packet Too Big“-Signale kommen nicht zurück.

• IPv4: ICMP „Fragmentation Needed“ ist entscheidend, wenn DF gesetzt ist.
• IPv6: ICMPv6 „Packet Too Big“ ist zwingend notwendig, weil Router nicht fragmentieren.
• Praxisfolge: ICMP nicht „alles oder nichts“ behandeln, sondern gezielt notwendige Typen erlauben.

Für den formalen Hintergrund zu PMTUD und ICMP-Interaktion sind Spezifikationen über den Anchor-Text RFC-Editor (Standards zu IP, ICMP und PMTUD) eine verlässliche Anlaufstelle.

VPN und SD-WAN: Warum gerade Tunnelumgebungen besonders anfällig sind

Die meisten „Small works, large fails“-Tickets entstehen in Tunnelszenarien, weil dort Overhead und Policy-Interaktionen zusammenkommen. Typische Fehlerbilder: Remote-Access-VPN verbindet, aber Webseiten laden nicht; Site-to-Site-IPsec ist „up“, aber Dateiübertragungen brechen ab; SD-WAN-Tunnel laufen, aber einzelne SaaS-Apps sind extrem langsam.

Typische Tunnel-Overheads und ihre Folgen

• IPsec: Zusätzliche Header/Encryption reduzieren effektive MTU; ohne MSS-Anpassung droppen große Segmente.
• GRE/VXLAN: Encapsulation addiert Overhead; bei unterliegenden 1500er Links bleibt weniger Raum.
• PPPoE: Häufige effektive MTU von 1492; in Kombination mit VPN kann die nutzbare Größe deutlich sinken.

MSS-Clamping als pragmatische Stabilisierung

In vielen Umgebungen ist MSS-Clamping die schnellste stabile Lösung, weil es verhindert, dass Endgeräte zu große TCP-Segmente erzeugen. Das ersetzt keine saubere MTU-Planung, ist aber ein effektiver Schutz gegen MTU-Blackholes, wenn PMTUD oder ICMP nicht zuverlässig sind.

IPv4 vs. IPv6: Warum MTU-Probleme unter IPv6 oft „härter“ wirken

Unter IPv6 ist PMTUD nicht optional. Wenn ICMPv6 „Packet Too Big“ blockiert wird, kann der Sender die Segmentgröße nicht anpassen. Dadurch können Anwendungen unter IPv6 deutlich häufiger hängen, obwohl IPv4 noch funktioniert. Dieses Muster wird oft fälschlich als „IPv6 ist instabil“ oder „DNS kaputt“ eingeordnet, ist aber in Wirklichkeit häufig ein ICMPv6-/MTU-Thema.

• Indiz: AAAA-Targets (IPv6) sind langsam oder hängen, A-Targets (IPv4) funktionieren.
• Indiz: Kleine Requests gehen, größere Responses hängen (z. B. bei TLS/HTTP).
• Beweisidee: Getrennte Tests für IPv4 und IPv6, jeweils mit steigender Payload.

Beweissicherung für NOC und Eskalation: So dokumentieren Sie MTU-Probleme sauber

MTU-/Fragmentierungsprobleme werden in Tickets häufig unterschätzt, weil „Netz ist doch up“ und „Ping geht“ die Diskussion dominieren. Eine gute Dokumentation fokussiert daher auf die Schwelle und auf den Pfadkontext. Damit wird aus einer vagen Störung ein reproduzierbarer Nachweis.

• Betroffene Ziele: Ziel-IP/Prefix, Port/Protokoll (z. B. TCP/443), IPv4/IPv6 getrennt.
• Fehlerbild: „Small works, large fails“ mit konkreter Schwelle (z. B. bis X stabil, ab Y reproduzierbar fehlerhaft).
• Pfadkontext: VPN/SD-WAN aktiv? PPPoE? Tunneltyp? Standort/VLAN/VRF.
• Messkette: Wo beginnt das Scheitern (Client→GW, Edge→Ziel, nur über Tunnel)?
• Policy-Hinweise: ICMP/ICMPv6 Filter, Firewall-Logs, Drops oder fehlende „Packet Too Big“-Signale.

Paketanalyse als Schiedsrichter: Wenn Sie es zweifelsfrei belegen müssen

Wenn Monitoring und Tests nicht ausreichen, liefert ein gezielter Paketmitschnitt die endgültige Klarheit: Sie sehen Retransmits, fehlende ICMP-Fehlermeldungen, fragmentierte Pakete (IPv4) oder wiederholte große Segmente ohne Antwort. Wichtig ist, selektiv zu capturen: relevante Host-Paare und Ports, idealerweise direkt am Tunnel-Endpunkt oder am Edge, wo Sie die Encapsulation und die tatsächliche Größe erkennen.

• IPv4: Sichtbare Fragmente oder DF-gesetzte Pakete, die nicht beantwortet werden.
• IPv6: Fehlende ICMPv6 „Packet Too Big“-Meldungen trotz klarer Drop-Schwelle.
• TCP: Retransmissions und Backoff nach dem Versuch, große Segmente zu senden.

Für eine praxisnahe Einführung in Filter und Interpretation ist der Anchor-Text Wireshark-Dokumentation hilfreich, insbesondere für die Analyse von TCP-Retransmits, ICMP/ICMPv6 und Encapsulation.

Checkliste: Schnelles Vorgehen bei „Small works, large fails“

Diese Checkliste ist so aufgebaut, dass Sie in kurzer Zeit zu einer belastbaren Entscheidung kommen, ohne Nebenkriegsschauplätze.

• Ziel definieren: IP und Port (IPv4/IPv6 getrennt), damit DNS nicht stört.
• VPN/Tunnel klären: Läuft der Traffic über IPsec/GRE/SD-WAN/PPPoE? Overhead-Verdacht notieren.
• Größenbasiert testen: Kleine Payload stabil? Payload schrittweise erhöhen, Schwelle festhalten.
• Messkette nutzen: Client→GW, GW→Edge, Edge→Ziel, um den Drop-Ort einzugrenzen.
• ICMP/ICMPv6 prüfen: Werden notwendige PMTUD-Meldungen blockiert oder rate-limited?
• MSS/MTU validieren: Sind MTU und MSS an Tunnel-Endpunkten passend? MSS-Clamping als Stabilisierung erwägen.
• Beweise dokumentieren: Schwelle, Pfad, Zeitpunkt, betroffene Ziele, und ob es nur im Tunnel passiert.

Outbound-Links für belastbare Grundlagen

• RFC 1812 (Requirements for IP Version 4 Routers)
• RFC 8200 (IPv6 Specification)
• RFC-Editor (Standards zu IP, ICMP und PMTUD)
• Wireshark-Dokumentation (Paketanalyse bei MTU-/PMTUD-Problemen)

MTU-/Fragmentierungsprobleme sind dann am schnellsten zu lösen, wenn Sie das Fehlerbild konsequent als größenabhängiges Phänomen behandeln: Nicht „geht oder geht nicht“, sondern „bis zu welcher Größe geht es stabil, ab welcher Größe scheitert es reproduzierbar“. In Kombination mit Pfadkontext (Tunnel, PPPoE, SD-WAN), einer Messkette zur Lokalisierung und dem Verständnis, dass PMTUD ohne ICMP/ICMPv6 nicht zuverlässig funktionieren kann, wird aus dem diffusen Symptom „Small works, large fails“ eine klare technische Ursache – und eine Diagnose, die sich sauber eskalieren und nachhaltig beheben lässt.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.