Site icon bintorosoft.com

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

Red Snapper

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.

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.

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).

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

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:

MSS = MTU − IPHeader − 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

Was ein „echter“ MTU-Beweis ist

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.

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.

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

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.

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.

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.

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.

Outbound-Links für belastbare Grundlagen

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:

Lieferumfang:

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.

 

Exit mobile version