Site icon bintorosoft.com

MTU-/Fragmentierungsprobleme: Identifizieren ohne Rätselraten

Red Snapper

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.

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.

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

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.

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

IP_Paket = Payload + IP_Header + 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.

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.

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.

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.

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.

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.

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)

MTU_effektiv = MTU_link – Overhead

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

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?“

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.

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.

Outbound-Links für verlässliche Vertiefung

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