Site icon bintorosoft.com

MTU-Probleme im CNI: Warum große Requests scheitern (Checkliste + Tests)

Red Snapper

Futuristic computer lab equipment in a row generated by artificial intelligence

Wenn in Kubernetes „kleine Requests funktionieren, große Requests scheitern“, sind MTU-Probleme im CNI eine der häufigsten und zugleich am schwersten zu erkennenden Ursachen. MTU steht für „Maximum Transmission Unit“ – also die maximale Paketgröße, die ein Netzwerkpfad ohne Fragmentierung transportieren kann. In Container-Umgebungen kommt zusätzlich Overhead durch Tunnel (VXLAN, Geneve), Verschlüsselung (IPsec/WireGuard), Encapsulation durch Cloud-Netzwerke, Load Balancer oder Service Mesh hinzu. Das Ergebnis: Ein Paket, das im Pod-Netzwerk noch „passt“, wird auf dem Weg über die Underlay-Links zu groß und muss fragmentiert oder verworfen werden. Besonders kritisch ist das, wenn Path MTU Discovery (PMTUD) nicht sauber funktioniert – etwa weil ICMP-Meldungen („Fragmentation Needed“) gefiltert werden. Dann entstehen klassische Fehlerbilder: sporadische TCP-Timeouts, hängende TLS-Handshakes, gRPC-Streams, die „stallen“, oder HTTP-Uploads, die bei bestimmten Payload-Größen abbrechen. Dieser Artikel zeigt praxisnah, wie MTU-Probleme im CNI entstehen, welche Symptome wirklich typisch sind und wie Sie mit einer klaren Checkliste und reproduzierbaren Tests die Root Cause finden und dauerhaft beheben.

Grundlagen: MTU, Fragmentierung und warum PMTUD so wichtig ist

Die MTU wird üblicherweise pro Interface definiert (z. B. 1500 Bytes in vielen Ethernet-Netzen). Wenn ein IP-Paket größer ist als die MTU eines Links, gibt es zwei Möglichkeiten: Fragmentierung oder Drop. Bei IPv4 kann fragmentiert werden (wenn nicht explizit verboten), bei IPv6 ist Fragmentierung durch Router nicht vorgesehen – hier ist funktionierendes PMTUD besonders wichtig. PMTUD sorgt dafür, dass Endpunkte die maximal mögliche Paketgröße entlang des Pfads automatisch ermitteln und ihre Segmentgrößen (MSS) anpassen. Das klappt aber nur zuverlässig, wenn ICMP-Feedback nicht blockiert wird.

Faustregel: Effective MTU ist Underlay-MTU minus Overhead

In Kubernetes treffen Sie selten nur „reines Ethernet“. Tunnel und Verschlüsselung fressen Bytes. Eine vereinfachte Rechnung hilft bei der Orientierung:

MTU_effektiv = MTU_underlay − Overhead

Der Overhead hängt vom Setup ab. Beispielhaft: VXLAN oder Geneve (Encapsulation), zusätzlich IPsec/WireGuard (Crypto-Header), ggf. Cloud-spezifische Encapsulation. Wenn Ihr Underlay 1500 ist, kann die effektive Pod-to-Pod-MTU schnell deutlich darunter liegen. In der Praxis wird daher häufig eine Pod-MTU von 1450 oder 1400 gewählt – aber der korrekte Wert ist immer pfadabhängig.

Warum MTU-Probleme im CNI so häufig sind

Container Networking basiert auf mehreren Schichten, die jeweils eigene MTU-Einstellungen und eigene Failure Modes haben. Ein Pod spricht über ein virtuelles Interface (veth) in ein Overlay oder direkt ins VPC/VNet. Ab dort geht es über Node-Interfaces, Routing, NAT, Load Balancer und ggf. VPN/Interconnect. Schon eine einzige Stelle mit niedrigerer MTU, fehlerhaftem PMTUD oder geblocktem ICMP kann große Pakete „blackholen“.

Typische Symptome: „Small works, large fails“ in realen Workloads

MTU-Probleme sind selten sofort offensichtlich, weil kleine Pakete weiterhin funktionieren. Der Fehler zeigt sich oft erst ab bestimmten Payload-Größen oder in Protokollphasen, die größere Records erzeugen (z. B. TLS, HTTP/2, gRPC).

Erste Einordnung: Wo kann die MTU im Kubernetes-Pfad „kleiner werden“?

Um MTU-Probleme schnell zu lokalisieren, hilft eine mentale Karte der Schichten. Für Debugging ist entscheidend, ob das Problem innerhalb des Clusters (Pod↔Pod/Service) oder auf dem Weg nach außen (Egress/Ingress) entsteht.

Tests: MTU-Probleme reproduzierbar nachweisen (ohne Ratespiel)

Die beste Diagnose ist ein Test, der die maximale funktionierende Paketgröße ermittelt. Idealerweise führen Sie Tests entlang des echten Pfads durch (Pod→Pod, Pod→Service, Pod→Extern, Extern→Ingress→Pod). Dabei müssen Sie zwischen IP-Paketgröße und Payload unterscheiden. Für viele Szenarien reichen Ping/tracepath und ein kontrollierter TCP-Test.

Test mit Ping und DF-Bit (IPv4): maximale Paketgröße finden

Der klassische Ansatz: Ping mit „Do not fragment“ und variierender Payload. Funktioniert ein bestimmter Wert nicht, ist die Pfad-MTU kleiner. Beachten Sie: Ping-Payload ist nicht gleich IP-Paketgröße; ICMP- und IP-Header kommen hinzu. Als Vorgehen:

Wenn statt einer „Frag needed“-Meldung nur Timeouts entstehen, ist das ein starkes Indiz, dass ICMP-Feedback geblockt wird und PMTUD deshalb versagt.

tracepath/traceroute: PMTU sichtbar machen

Viele Linux-Tools wie tracepath können PMTU-Änderungen entlang des Pfads anzeigen. Das ist besonders hilfreich, wenn Sie nicht wissen, auf welchem Hop die MTU sinkt. In Kubernetes nutzen Sie dafür oft ein Debug-Image mit iputils oder ähnlichen Tools.

TCP-Test: Große Transfers gezielt provozieren

Für echte Applikationsnähe ist ein TCP-basierter Test sinnvoll, etwa über HTTP oder ein simples Transfer-Tool. Ziel ist nicht maximaler Durchsatz, sondern reproduzierbare „Breakpoints“ bei bestimmten Größen.

Paketdiagnose: Retransmits und Fragmentierung erkennen

Wenn Sie tiefer gehen müssen, ist eine Paketdiagnose auf Node-Ebene hilfreich. MTU-Probleme zeigen sich häufig als wiederholte Retransmits (TCP) oder als fehlende ICMP-Meldungen. In Produktionsumgebungen ist dabei wichtig: minimalinvasiv arbeiten, nur kurzzeitig mitschneiden und die Datensicherheit beachten.

Checkliste: MTU-Probleme im CNI systematisch debuggen

Diese Checkliste ist so aufgebaut, dass Sie schnell von Symptom zu Ursache kommen, ohne sich in Tooling zu verlieren. Arbeiten Sie von „nah“ (Pod/Node) nach „fern“ (Underlay/VPN/Cloud-Hop) und testen Sie stets den real betroffenen Pfad.

Häufige Root Causes und wie Sie sie dauerhaft beheben

Bei der Remediation ist das Ziel: konsistente MTU-Einstellungen entlang des Pfads, funktionierendes PMTUD (inkl. ICMP) und – wenn nötig – MSS-Clamping, um TCP-Segmentgrößen automatisch zu begrenzen.

Overlay-Encapsulation ohne angepasste Pod-MTU

Wenn Ihr CNI VXLAN/Geneve nutzt und das Underlay 1500 MTU hat, müssen Sie die Pod-MTU typischerweise reduzieren. Andernfalls erzeugen Pods IP-Pakete, die nach Encapsulation zu groß werden. Dauerhafte Lösung: Pod-MTU in der CNI-Konfiguration korrekt setzen und sicherstellen, dass alle Nodes konsistent sind.

ICMP wird geblockt: PMTUD bricht (Black Hole)

Das klassische „groß hängt“ entsteht oft, weil ICMP pauschal blockiert wird. Dauerhafte Lösung: ICMP (insbesondere „Fragmentation Needed“ bei IPv4 und relevante ICMPv6-Typen) gezielt erlauben – nicht „alles ICMP“, sondern die nötigen Typen. So bleibt PMTUD funktionsfähig, ohne Sicherheitsziele zu untergraben.

VPN/IPsec/WireGuard-Overhead nicht berücksichtigt

Bei verschlüsselten Tunneln ist Overhead der Normalfall. Wenn Sie On-Prem oder Multi-Cloud über VPN koppeln, ist eine niedrigere effektive MTU oft unvermeidlich. Dauerhafte Lösung: Tunnel-MTU explizit setzen und Pod-/Node-MTU so abstimmen, dass der kleinste Pfad dominiert. Zusätzlich kann MSS-Clamping auf den Tunnel-Gateways helfen, damit TCP automatisch kleinere Segmente nutzt.

MSS-Clamping als Schutznetz (wenn Sie nicht überall MTU kontrollieren)

MSS-Clamping begrenzt TCP MSS so, dass Segmente sicher in die Pfad-MTU passen. Das ist besonders nützlich, wenn Sie nicht alle Zwischenhops kontrollieren (z. B. Unternehmens-Firewalls, Drittanbieter-Netze). Es ersetzt keine saubere MTU-Architektur, kann aber Ausfälle verhindern. Wichtig: MSS-Clamping wirkt nur für TCP, nicht für UDP.

Jumbo Frames und gemischte MTU-Domänen

Manche Umgebungen nutzen Jumbo Frames (z. B. 9001) in Teilen des Netzes, aber nicht überall. Wenn ein Pfad zurück auf 1500 oder kleiner fällt, entstehen schwer reproduzierbare Probleme. Dauerhafte Lösung: Entweder Jumbo konsequent end-to-end oder bewusst auf eine konservative MTU dimensionieren und alle Pfade daran ausrichten.

Praxisleitfaden: MTU-Werte sinnvoll wählen (ohne blindes Raten)

Eine robuste Strategie ist, die kleinste MTU im realen Pfad zu ermitteln und dann eine Sicherheitsmarge einzuplanen. Das verhindert, dass seltene Hops (z. B. über bestimmte Gateways) sporadische Ausfälle erzeugen. Vorgehen:

Operative Absicherung: Observability-Signale für MTU-Probleme

MTU-Probleme werden oft erst als Applikationssymptom sichtbar. Besser ist es, Netzwerkindikatoren zu beobachten, die typische Muster früh zeigen.

Outbound-Links zu relevanten Informationsquellen

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