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.
- IPv4 + DF-Bit: Setzt ein Sender „Don’t Fragment“, muss der Pfad bei zu großen Paketen ICMP „Fragmentation Needed“ zurückmelden. Fehlt dieses ICMP, kommt es zu „Black Hole“-Verbindungen.
- IPv6: Router fragmentieren nicht. Wenn PMTUD/PLPMTUD nicht greift, werden zu große Pakete schlicht verworfen.
- TCP ist nicht gleich MTU: TCP sendet Segmente (MSS), die in IP-Pakete passen müssen. Falsche MSS/MTU-Kombinationen führen zu Retransmits und Timeouts.
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:
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“.
- Overlay-Netzwerke: VXLAN/Geneve kapseln Pakete ein, wodurch das Underlay größere Pakete tragen müsste – oder die Pod-MTU muss sinken.
- Verschlüsselung: IPsec/WireGuard erhöhen den Overhead und machen MTU-Dimensionierung sensibler.
- Cloud-Networking: Manche Pfade (z. B. über NAT-Gateways, Peering, Transit, PrivateLink/Endpoints) haben eigene MTU-/Fragmentierungs-Eigenschaften.
- ICMP-Filter: Security-Teams blocken oft ICMP pauschal. Das bricht PMTUD und erzeugt schwer erklärbare Timeouts.
- Heterogene Nodes: Unterschiedliche Instance-Typen oder Netzwerktreiber mit abweichender MTU führen zu „nur manche Nodes betroffen“.
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).
- HTTP-Uploads brechen ab: Kleine POSTs funktionieren, große POSTs hängen oder timeouten.
- TLS/HTTPS wirkt instabil: Handshakes hängen sporadisch, besonders bei größeren Zertifikatsketten oder bestimmten Cipher-Suites.
- gRPC/HTTP2 „stalled“: Streams bleiben stehen, Retries steigen, aber es gibt keine klare Fehlermeldung.
- Nur bestimmte Pfade betroffen: Pod→Service ok, Pod→Extern nicht (oder umgekehrt), häufig durch NAT/Ingress/Egress-Pfade.
- Nur über VPN/Interconnect: On-Prem-Anbindungen (Site-to-Site VPN, Direct Connect/ExpressRoute) sind prädestiniert für MTU-Mismatches.
- Viele Retransmits: TCP Retransmissions steigen, Latenzen explodieren, aber Paketloss-Metriken wirken „normal“.
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.
- Pod-Interface (veth): Die MTU im Pod kann bereits reduziert sein – korrekt oder falsch.
- CNI/Overlay-Interface: Tunnel-Interfaces (z. B. vxlan) haben eigene MTU-Werte.
- Node-NIC: Die physische/virtuelle NIC bestimmt das Underlay (typisch 1500, manchmal 9001 Jumbo in bestimmten Netzen).
- NAT/Load Balancer: Zusätzliche Hop-Devices können MTU oder Fragmentierung beeinflussen.
- VPN/Tunnel außerhalb des Clusters: IPsec/GRE/WireGuard addieren Overhead; häufigster Ort für „groß bricht“.
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:
- Von einem betroffenen Pod oder Debug-Pod aus Ping zum Ziel mit DF aktivieren (abhängig vom Tool/BusyBox).
- Payload schrittweise erhöhen, bis „Frag needed“ oder Timeout auftritt.
- Den maximal funktionierenden Wert notieren und mit erwarteter MTU vergleichen.
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.
- HTTP-Download/Upload: Testen Sie kleine und große Payloads und vergleichen Sie Verhalten und Dauer.
- iperf3: Hilfreich, um große Segmente über längere Zeit zu senden und Retransmits sichtbar zu machen.
- curl mit großen Bodies: Besonders geeignet, wenn „große Requests scheitern“ Ihr Hauptsymptom ist.
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.
- Symptom präzisieren: Scheitert Pod→Pod, Pod→Service, Pod→Extern oder Extern→Ingress?
- MTU im Pod prüfen: Interface-MTU im Container/Pod (veth) und im Node-Netznamespace vergleichen.
- CNI-Interface prüfen: Tunnel- oder Routing-Interface (vxlan/geneve/wg) MTU prüfen.
- Node-Interface prüfen: MTU der Haupt-NIC und eventueller Secondary NICs prüfen.
- PMTUD testen: Ping/tracepath nutzen; „Frag needed“ vs. Timeout unterscheiden.
- ICMP-Regeln prüfen: Security Groups/NACL/Firewall/NetworkPolicy: wird ICMP „Fragmentation needed“ oder ICMPv6 gefiltert?
- Egress/NAT-Pfad prüfen: NAT Gateways, Egress Gateways, Proxies, Service Mesh Egress, Unternehmens-Firewalls.
- VPN/Interconnect prüfen: IPsec/WireGuard/GRE: Overhead berechnen und MTU anpassen (häufigster Root Cause).
- Nur einzelne Nodes?: Korrelation zu Node-Pools/Instance-Typen; heterogene MTU/Driver/Offload-Einstellungen ausschließen.
- Reproduzierbarer Breakpoint: Maximal funktionierende Paketgröße dokumentieren und als Regressionstest speichern.
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:
- Pfad definieren: Für welche Kommunikation ist Stabilität kritisch? (Pod↔Pod, Pod↔DB, Pod↔Extern, Cross-Region, On-Prem)
- PMTU messen: Mit Ping/tracepath die kleinste MTU entlang des Pfads bestimmen.
- Overhead berücksichtigen: Tunnel- und Crypto-Header einrechnen; im Zweifel konservativ.
- Pod-MTU festlegen: CNI-/Pod-MTU so setzen, dass nach Encapsulation die Underlay-MTU nicht überschritten wird.
- Regressionstest etablieren: Einen Test-Job/Runbook behalten, der die maximale Paketgröße regelmäßig validiert.
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.
- TCP Retransmits: Deutlich erhöht, ohne dass klassischer Paketloss im Underlay sichtbar ist.
- Handshake-Latenz: TLS-Handshake-Zeiten und TCP connect-Latenz steigen, besonders bei großen Zertifikatsketten.
- gRPC Reset/Deadline Exceeded: Häufung bei bestimmten Payload-Größen oder nur auf bestimmten Pfaden.
- ICMP Counters: Wo möglich, ICMP „Fragmentation needed“/ICMPv6 PTB (Packet Too Big) beobachten.
- Node-/CNI-spezifische Metriken: Je nach Plugin existieren MTU-/Drop-Indikatoren in CNI-Exportern.
Outbound-Links zu relevanten Informationsquellen
- Kubernetes Networking Concepts (Überblick über Datenpfade und Komponenten)
- DNS für Services und Pods (wenn MTU indirekt DNS/TCP beeinflusst)
- RFC 1191: Path MTU Discovery (IPv4)
- RFC 8201: Path MTU Discovery (IPv6)
- Cilium Dokumentation: MTU und Encapsulation (Konzept und Betrieb)
- Calico Dokumentation: MTU konfigurieren (Overlay und Routing)
- Amazon EKS VPC CNI: Betrieb und Telemetrie (CNI-bezogene Metriken/Debug)
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.
