MTU-/Fragmentierungsprobleme: Identifizieren ohne Rätselraten

MTU-/Fragmentierungsprobleme gehören zu den teuersten Fehlerklassen im Betrieb: Sie erzeugen Symptome, die wie „Zufall“ wirken – mal lädt eine Website, mal nicht; kleine Requests funktionieren, große Downloads brechen ab; VPN oder Overlay ist langsam; TLS-Handshakes hängen; einzelne APIs liefern Timeouts, obwohl „Ping geht“. Wer in solchen Situationen ohne Struktur vorgeht, verliert Stunden in Rätselraten. Der Schlüssel ist, MTU-/Fragmentierungsprobleme als deterministisches Größenproblem zu behandeln: Bestimmte Paketgrößen funktionieren, andere nicht. Sobald Sie das sauber nachweisen und mit Telemetrie unterfüttern, lässt sich der Fehlerbereich stark eingrenzen (Pfad-MTU, Encapsulation-Overhead, ICMP-Filter, MSS-Clamping, PMTUD-Blackhole). Dieser Artikel zeigt einen operativen, reproduzierbaren Ansatz, um MTU- und Fragmentierungsprobleme zu identifizieren – ohne Bauchgefühl, ohne „probier mal“-Änderungen. Sie erhalten ein praxistaugliches Vorgehen für NOC- und On-Call-Teams, inklusive klarer Tests, typischer Symptom-Muster, geeigneter Messpunkte und einer Dokumentationslogik, die Ownership und Fix-Pfad schnell klärt.

Grundlagen: MTU, MSS, Fragmentierung und warum das in der Praxis kippt

Die MTU (Maximum Transmission Unit) beschreibt die maximale Größe eines IP-Pakets, das auf einem Link ohne Fragmentierung übertragen werden kann. Im Ethernet-Standardumfeld sind 1500 Byte MTU weit verbreitet, aber in modernen Umgebungen (VXLAN, GRE, IPsec, PPPoE, Cloud-Tunnels) ist die effektive MTU oft kleiner, weil zusätzliche Header Platz brauchen. Bei IPv4 kann ein Router fragmentieren, wenn „DF“ (Don’t Fragment) nicht gesetzt ist. Bei IPv6 fragmentieren Router nicht; nur der Sender darf fragmentieren. Das macht IPv6 besonders anfällig für sogenannte PMTUD-Blackholes, wenn notwendige ICMP-Meldungen blockiert werden.

• MTU: Maximalgröße eines IP-Pakets auf einem Link (Layer 3 Sicht).
• MSS: Maximalgröße der TCP-Nutzdaten im Segment (ohne IP/TCP-Header); wird im TCP-Handshake ausgehandelt.
• Fragmentierung: Zerlegen eines IP-Pakets in mehrere Fragmente (IPv4 im Netz möglich; IPv6 nur am Sender).
• PMTUD: Path MTU Discovery; der Sender findet die kleinste MTU entlang des Pfades und passt Paketgrößen an.

Für verlässliche Referenzen eignen sich RFC 1191 (Path MTU Discovery für IPv4) und RFC 8201 (Path MTU Discovery für IPv6). Für IPv6-ICMP ist RFC 4443 (ICMPv6) zentral.

Typische Symptome: So sehen MTU-/Fragmentierungsprobleme im Betrieb aus

MTU-Themen haben ein besonderes Muster: Kleine Pakete gehen durch, große nicht – oder nur sporadisch. Das führt zu scheinbar widersprüchlichen Beobachtungen. Wenn Sie diese Muster kennen, ist die Hypothese „MTU/Fragmentierung“ früh auf dem Tisch.

• „Ping geht, aber HTTPS nicht“: ICMP Echo (klein) funktioniert, TLS/HTTP (größer) hängt oder bricht ab.
• „Nur große Downloads brechen ab“: Kleine API-Antworten OK, große Payloads Timeout/Reset.
• „VPN/Overlay nur bei bestimmten Zielen kaputt“: Pfadabhängige MTU-Unterschiede, besonders bei Multi-Cloud/WAN.
• „Nur IPv6 macht Probleme“: ICMPv6 „Packet Too Big“ wird gefiltert; PMTUD scheitert.
• „Nur UDP/QUIC ist schlecht“: Fragmentierung im Netz oder verlorene Fragmente; QUIC über UDP reagiert sensibel auf Path-MTU.
• „Nur manche Nutzer betroffen“: ECMP verteilt Flows über Pfade mit unterschiedlicher effektiver MTU.

Das wichtigste Prinzip: Größe als Hypothese messbar machen

Das Ziel der Incident-Triage ist nicht, sofort die „Ursache“ zu kennen, sondern die Hypothese eindeutig zu bestätigen oder zu verwerfen. Bei MTU geht das über einen sehr einfachen Ansatz: Sie testen systematisch Paketgrößen und prüfen, ab welcher Größe der Pfad bricht. Das ist der Punkt, an dem aus „Gefühl“ Evidenz wird.

Was Sie messen wollen

• Largest Passing Packet: größte Paketgröße, die zuverlässig funktioniert.
• Smallest Failing Packet: kleinste Paketgröße, die zuverlässig scheitert.
• Stabilität: ist der Grenzwert konstant oder schwankt er (Hinweis auf ECMP/Intermittency)?
• Richtung: betrifft es beide Richtungen oder nur eine (z. B. Rückweg über andere Encapsulation)?

Reproduzierbarer Test 1: ICMP „Do Not Fragment“ als MTU-Sonde

Ein klassischer, sauberer Test ist ein ICMP Echo Request mit gesetztem DF-Flag (bei IPv4), also „nicht fragmentieren“. Wenn ein Paket größer als die Pfad-MTU ist, sollte ein Router eine ICMP-Meldung zurückgeben („Fragmentation Needed“). Fehlt diese Meldung, kann ein PMTUD-Blackhole vorliegen. Bei IPv6 ist DF nicht relevant; dort führt ein zu großes Paket zu „Packet Too Big“-Signalen, die ebenfalls ankommen müssen.

• Erwartung bei IPv4: Ab einer bestimmten Größe kommt „Fragmentation Needed“ (oder die Probe erreicht das Ziel nicht).
• Erwartung bei IPv6: Ab einer bestimmten Größe sollte „Packet Too Big“ auftreten.
• Hinweis: Wenn weder Antwort noch ICMP-Fehler kommt, ist Filtering sehr wahrscheinlich.

MTU und Overhead: Warum Payload ≠ Paketgröße ist (MathML)

$\mathrm{IP\_Paket}=\mathrm{Payload}+\mathrm{IP\_Header}+\mathrm{L4\_Header}$

In der Praxis müssen Sie bei Tests berücksichtigen, dass Tools oft die Payload-Größe angeben, während MTU die gesamte IP-Paketgröße betrifft. Bei TCP kommen typischerweise IP- und TCP-Header hinzu. Zusätzlich kann Encapsulation (z. B. VXLAN, GRE, IPsec) weitere Header addieren und die effektive Nutzlast verringern.

Reproduzierbarer Test 2: TCP-MSS und „große Antworten hängen“

Wenn MTU-Probleme auftreten, sehen Sie häufig folgende Kette: TCP-Handshake klappt, weil SYN/SYN-ACK/ACK klein sind. Erst bei größeren TCP-Segmenten (z. B. TLS-Handshake, HTTP-Response) treten Retransmissions oder Stalls auf. Das ist ein starkes Indiz für MSS/MTU-Mismatch oder für fehlendes MSS-Clamping in Tunnels.

• Handshake ok, Datenphase schlecht: typisches PMTUD/MSS-Thema.
• Viele Retransmissions bei großen Segmenten: Segmentgröße überschreitet effektive MTU oder Fragmente gehen verloren.
• „Nur manche Seiten“: unterschiedliche Serverpfade/Anycast/ECMP, unterschiedliche effektive MTU.

Als Referenz für TCP-Grundlagen ist RFC 9293 (TCP) hilfreich, insbesondere in Verbindung mit PMTUD.

Reproduzierbarer Test 3: PMTUD-Blackhole gezielt nachweisen

Ein PMTUD-Blackhole liegt vor, wenn ein Pfad eine geringere MTU hat, aber die notwendigen ICMP-Meldungen nicht zurück zum Sender gelangen. Der Sender versucht dann wiederholt, zu große Pakete zu senden, und wartet auf ACKs oder Fehlermeldungen, die nie kommen. Das Ergebnis sind Timeouts, scheinbar zufällige Hänger und massive Latenzspitzen.

• Indikator: Große Pakete verschwinden „still“, kleine funktionieren.
• Indikator: Retransmissions/Backoff auf TCP, ohne dass ein klares Reject sichtbar ist.
• Indikator: Firewalls/ACLs filtern ICMP „Fragmentation Needed“ oder „Packet Too Big“.

Ein operativer Best-Practice-Punkt ist, ICMP nicht pauschal zu blockieren. Für IPv6 ist ICMPv6 funktional zwingend; RFC 4890 (ICMPv6 Filtering Recommendations) liefert praxisnahe Leitlinien, welche Typen sinnvollerweise erlaubt werden sollten.

Telemetrie, die den Unterschied macht: Wo Sie messen müssen

MTU-Probleme wirken end-to-end, aber die Ursache sitzt meist an einem konkreten Übergang: Tunnel-Encapsulation, Provider-Link, Firewall-Cluster, NIC-Offload, vSwitch oder ein einzelner Pfad. Damit Sie nicht „überall“ suchen, sollten Sie Telemetrie an den richtigen Stellen sammeln.

• Endpunkte: Sender und Empfänger (Host-Stack, Interface-MTU, offload settings, Drop-Counter).
• Tunnel-Edges: Geräte, die encapsulieren/decapsulieren (VXLAN VTEPs, GRE Endpoints, IPsec Gateways).
• Stateful Middleboxes: Firewalls/NAT/LBs (ICMP-Policy, Fragment Handling, Session Logs).
• Provider/WAN: MPLS/PPPoe/Carrier-Links (MTU-Contracts, per-interface MTU, policing).
• ECMP/LACP: pro Member Pfad (unterschiedliche MTUs oder fehlerhafte Member führen zu „nur manche“).

Welche Counters sind bei MTU/Fragmentierung besonders aussagekräftig?

Viele NOCs schauen primär auf CRC/Errors. Bei MTU-Problemen sind jedoch andere Counter oft relevanter: Fragment-bezogene Drops, ICMP-Rate-Limits, „giant frames“, „output drops“ oder „reassembly failures“. Welche Namen die Counter tragen, hängt vom Hersteller und OS ab, aber die Kategorien sind stabil.

• Fragmentation Needed / Packet Too Big: Zähler für gesendete/empfangene ICMP-Meldungen.
• IP Reassembly Failures: Fragment-Reassembly scheitert (Timeout, fehlende Fragmente).
• Fragment Drops: Fragmente werden verworfen (Policy, Ressourcen, Sicherheitsfeatures).
• Oversize/Giant: Pakete größer als Interface-MTU werden gedroppt.
• ICMP Rate Limiting: Zu aggressive Limits verschleiern PMTUD-Probleme.

Fragmentierung in IPv4: Warum „es geht doch“ trotzdem falsch ist

IPv4 kann fragmentieren, wodurch manche Kommunikationspfade „irgendwie“ funktionieren – aber mit Nebenwirkungen. Fragmente erhöhen die Drop-Wahrscheinlichkeit, belasten Geräte (Reassembly), und sie interagieren schlecht mit Sicherheits- und NAT-Funktionen. Bei UDP ist es besonders kritisch: Geht ein Fragment verloren, ist das gesamte Datagram unbrauchbar. Viele Systeme droppen Fragmente bewusst aus Sicherheitsgründen oder behandeln sie strenger.

• Höhere Verlustwahrscheinlichkeit: mehrere Fragmente → mehr Chancen, dass eines fehlt.
• Stateful Devices: Firewalls/NAT müssen Fragmente korrekt zuordnen; nicht jede Policy ist dafür gebaut.
• Performance: Reassembly kostet CPU/Memory; unter Last steigen Drops.

IPv6: Warum MTU-Fehler hier besonders hart sind

Bei IPv6 fragmentieren Router nicht. Das ist grundsätzlich gut für das Netz, aber es bedeutet: Der Sender muss die Pfad-MTU kennen und respektieren. Dafür ist ICMPv6 „Packet Too Big“ unverzichtbar. Wenn dieser ICMP-Typ gefiltert wird, entstehen Blackholes: Große Pakete verschwinden, ohne dass der Sender lernt, kleiner zu senden.

• ICMPv6 ist nicht optional: Blocken Sie es pauschal, brechen Basisfunktionen.
• Encapsulation verstärkt das Risiko: Overlays reduzieren die effektive MTU, ohne dass Applikationen es „sehen“.
• Dual-Stack kaschiert: IPv4 fällt auf IPv6-Fehlern zurück oder umgekehrt; Nutzer sehen „intermittierend“.

Encapsulation-Overhead sauber berechnen: VXLAN, GRE, IPsec und der effektive MTU-Verlust

In der Praxis entsteht ein großer Teil der MTU-Probleme durch zusätzliche Header. Wenn ein Host oder ein Untersegment weiterhin von 1500 ausgeht, der Tunnel aber nur 1450 effektiv zulässt, ist der Fehler vorprogrammiert. Statt zu raten, rechnen Sie den Overhead transparent vor und vergleichen ihn mit den konfigurierten MTUs entlang des Pfades.

Effektive MTU als Subtraktion des Overheads (MathML)

$\mathrm{MTU\_effektiv}=\mathrm{MTU\_link}–\mathrm{Overhead}$

• Beispiel: Ethernet 1500, Overlay-Overhead 50 → effektive MTU 1450.
• Praxispunkt: Lieber konservativ konfigurieren und messen, als an „theoretischen“ Headerlängen zu hängen.

Wichtig ist nicht die perfekte Zahl, sondern Konsistenz: Wenn Ihre Underlay-MTU 9000 ist, ist Overlay oft unkritisch. Wenn Underlay 1500 ist, muss Overlay konsequent mit reduzierter MTU/MSS betrieben werden.

MSS-Clamping: Der schnellste Fix – aber nicht die beste Diagnose

MSS-Clamping (Anpassen der TCP MSS an Tunnelgrenzen) ist eine häufige Mitigation: TCP-Segmente werden kleiner, sodass sie ohne Fragmentierung durch den Tunnel passen. Das kann schnell Nutzerimpact reduzieren. Gleichzeitig ist MSS-Clamping kein Ersatz für Diagnose, denn es hilft TCP, nicht unbedingt UDP, und es kann Symptome maskieren, die später wieder auftauchen (z. B. bei QUIC/UDP oder bei ICMP-Blackholes).

• Pro: Schnelle Stabilisierung für TCP-basierte Services, oft ohne Client-Änderungen.
• Contra: UDP/QUIC profitieren nicht; Root Cause bleibt bestehen; falsche Clamps können Performance kosten.
• Best Practice: MSS-Clamping als Mitigation dokumentieren und parallel Root Cause fixen (MTU/ICMP/Policy).

Decision-Tree für NOC: MTU-Probleme Schritt für Schritt bestätigen

Damit Teams konsistent vorgehen, hilft ein kurzer Entscheidungsbaum. Er basiert auf der Frage: „Ist die Störung größenabhängig?“ und „Gibt es PMTUD-Signale?“

• 1) Größenabhängigkeit prüfen: Funktionieren kleine Pakete zuverlässig und große nicht?
• 2) Richtung prüfen: Fail nur in eine Richtung (Rückweg/Policy/Asymmetrie)?
• 3) ICMP prüfen: Kommen „Fragmentation Needed“/„Packet Too Big“ an? Werden sie geloggt/gezählt?
• 4) Encapsulation prüfen: Gibt es Tunnels/Overlays/VPN/IPsec auf dem Pfad?
• 5) ECMP prüfen: Betrifft es nur manche Nutzer/Flows → per-member MTU/Policy abgleichen.
• 6) Host/OS prüfen: Interface-MTU am Host, PMTUD-Settings, Offloads, Security-Agents.

Dokumentation im Incident: Welche Beweise ins Ticket gehören

Damit aus einem „vagen“ MTU-Verdacht eine saubere RCA wird, sollten Sie Ihre Erkenntnisse standardisiert dokumentieren. Das macht die Eskalation schneller und verhindert „wir sehen nichts“-Diskussionen.

• Grenzwert: größte funktionierende und kleinste scheiternde Paketgröße, inklusive Richtung.
• Pfadkontext: betroffene Quell-/Ziel-IP, Ports, VRF/VLAN, Overlay/Underlay, beteiligte Gateways.
• ICMP-Sicht: ob ICMP-Fehler sichtbar sind (Counter/Logs) oder ob es ein Silent Drop ist.
• Counter-Auszüge: reassembly failures, fragment drops, packet too big counters, output drops.
• Change-Korrelation: neue Tunnel, neue Firewall-Policy, neue Provider-Route, neue MTU-Config.
• Mitigation und Effekt: z. B. MSS-Clamp aktiviert → Fehlerquote gesunken, UDP weiterhin betroffen.

Häufige Root Causes in der Praxis: Die „Top 8“ ohne Rätselraten

Wenn Sie Größe und Pfad eingegrenzt haben, landen Sie meist bei wenigen wiederkehrenden Ursachen. Diese Liste hilft, zielgerichtet zu prüfen, statt breit zu suchen.

• ICMP gefiltert: „Packet Too Big“/„Fragmentation Needed“ kommt nicht zurück.
• Mismatch zwischen Underlay und Overlay: Tunnel-Overhead nicht berücksichtigt, Hosts senden zu groß.
• PPPoE/MPLS/Provider-MTU kleiner als erwartet: WAN-Link limitiert, ohne dass es überall dokumentiert ist.
• Firewall droppt Fragmente: Sicherheitsprofil oder Anti-Evasion-Features verwerfen Fragmenttraffic.
• ECMP-Pfade mit unterschiedlicher MTU: nur bestimmte Hashes betroffen.
• Host-Offload/Driver-Issue: falsche MTU/TSO/GSO-Konstellation in virtuellen Stacks.
• Falsches MSS-Clamping: zu groß oder inkonsistent, führt zu Restproblemen.
• IPv6-spezifischer PMTUD-Blackhole: ICMPv6 fehlkonfiguriert oder geblockt.

Outbound-Links für verlässliche Vertiefung

• RFC 1191 (Path MTU Discovery für IPv4) für Mechanik und erwartete ICMP-Signale.
• RFC 8201 (Path MTU Discovery für IPv6) für IPv6-spezifisches Verhalten und „Packet Too Big“.
• RFC 4443 (ICMPv6) für ICMPv6-Typen, Codes und betriebliche Relevanz.
• RFC 4890 (ICMPv6 Filtering Recommendations) für sichere, funktionale ICMPv6-Filterregeln.
• RFC 9293 (Transmission Control Protocol) für TCP-MSS, Segmentierung und Retransmission-Muster bei MTU-Problemen.

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.