Site icon bintorosoft.com

MTU im CNI: Der Fall „Small works, large fails“

Red Snapper

MTU im CNI: Der Fall „Small works, large fails“ ist eines der typischsten und zugleich frustrierendsten Fehlerbilder in Kubernetes-Netzwerken. Kleine Requests funktionieren, Healthchecks laufen grün, einfache DNS-Queries gehen durch – aber sobald Payloads größer werden, brechen Verbindungen scheinbar zufällig ab: TLS-Handshakes hängen, gRPC-Calls timeouten, große HTTP-Responses werden unvollständig, Datei-Downloads bleiben stehen oder Datenbanken verlieren sporadisch Sessions. Hinter diesem Muster steckt sehr häufig ein MTU-Problem im Zusammenspiel aus CNI (Container Network Interface), Encapsulation (z. B. VXLAN/Geneve), Underlay-Netz (VPC/VNet, physisches Netzwerk), optionaler Verschlüsselung (IPsec/WireGuard) und Path MTU Discovery. Der Kern ist einfach: Pakete oberhalb der effektiven MTU passen nicht mehr durch den Pfad. Wenn Fragmentierung nicht möglich ist oder ICMP-Meldungen blockiert werden, kann der Sender die Paketgröße nicht anpassen – und genau dann entsteht „Small works, large fails“. Dieser Artikel zeigt, wie MTU in CNI-Setups tatsächlich wirkt, welche Ursachen am häufigsten sind, wie Sie das Fehlerbild sauber beweisen und welche Mitigation-Maßnahmen in der Praxis dauerhaft stabil sind, ohne die Sicherheit oder Performance zu opfern.

MTU-Grundlagen: Warum eine Zahl so viele Incidents auslösen kann

MTU (Maximum Transmission Unit) ist die maximale Paketgröße, die auf einer Netzwerkschnittstelle ohne Fragmentierung übertragen werden kann. Im Ethernet-Standard sind 1500 Byte üblich, in vielen Rechenzentren und Cloud-Netzen gibt es je nach Umgebung auch Jumbo Frames (z. B. 9001 Byte). In Kubernetes ist MTU jedoch selten „nur 1500“, weil zwischen Pod und Ziel oft zusätzliche Header hinzukommen: Overlay-Tunnel, Verschlüsselung, NAT-Pfade oder Service-Mesh-Encapsulation. Jeder zusätzliche Header reduziert die effektive Nutzlast, die noch in das Paket passt.

Für Hintergrund zu Path MTU Discovery und dem Zusammenspiel mit ICMP ist die IETF-Referenz zu PMTUD ein guter Einstieg: RFC 1191 (Path MTU Discovery). Für IPv6 ist PMTUD ebenfalls zentral, da Router nicht fragmentieren; dazu ist RFC 8201 (IPv6 Path MTU Discovery) relevant.

Warum MTU im CNI besonders oft „unerwartet“ wird

Im klassischen Serverbetrieb ist MTU meist ein Infrastrukturstandard: Interface-MTU, Switches, Router, fertig. In Kubernetes kommt eine zusätzliche virtuelle Schicht dazu: Pods haben eigene Netz-Namespaces, virtuelle Interfaces (veth), virtuelle Bridges oder eBPF-Pfade, und häufig ein Overlay, das Pod-Traffic zwischen Nodes kapselt. Dadurch kann ein Pod eine andere effektive MTU haben als das Node-Interface – und das ohne offensichtliche Hinweise in der Anwendung.

Allgemeine Kubernetes-Networking-Grundlagen, in denen CNI und Pod-Konnektivität eingeordnet werden, finden Sie unter Kubernetes Networking Concepts. Zur CNI-Einordnung dient die Dokumentation unter CNI Dokumentation.

Der Mechanismus hinter „Small works, large fails“

Das Fehlerbild entsteht, wenn große Pakete nicht übertragen werden können und der Sender nicht lernt, kleinere Pakete zu senden. Zwei Mechanismen sind dabei zentral: Fragmentierung und Path MTU Discovery (PMTUD). Bei IPv4 können Router fragmentieren, wenn es erlaubt ist. In der Praxis ist Fragmentierung jedoch oft unerwünscht oder wird durch „Don’t Fragment“ (DF) verhindert. Bei IPv6 fragmentieren Router nicht; PMTUD ist dort noch wichtiger. Wenn ICMP „Fragmentation Needed“ (IPv4) oder „Packet Too Big“ (IPv6) blockiert wird, kann der Sender seine MSS/Packet Size nicht reduzieren – große Pakete droppen einfach.

Warum ICMP-Blocking so gefährlich ist

In vielen Umgebungen wird ICMP pauschal als „unsicher“ geblockt. Das ist einer der häufigsten Gründe für MTU-bedingte Ausfälle. Ohne die passenden ICMP-Typen kann PMTUD nicht funktionieren. Das führt zu schwer reproduzierbaren Problemen, die meist erst unter TLS, gRPC oder großen Payloads auffallen.

Wo MTU im CNI-Stack tatsächlich „lebt“

Um MTU-Probleme zu beheben, müssen Sie wissen, auf welcher Ebene die MTU wirksam wird. In Kubernetes/CNI-Setups gibt es typischerweise mehrere relevante MTU-Stellen:

In der Praxis bedeutet das: Sie können „MTU im Pod“ korrekt setzen und trotzdem Ausfälle haben, wenn der Underlay-Pfad oder ein VPN-Segment kleinere MTU erzwingt. Umgekehrt kann ein zu hoher Pod-MTU-Wert die Wahrscheinlichkeit erhöhen, dass große Pakete entstehen, die dann später droppen.

Die häufigsten Ursachen für MTU-Probleme in Kubernetes-Clustern

Obwohl es viele Varianten gibt, sind die Ursachen in den meisten Incidents erstaunlich ähnlich. Wenn Sie diese Muster kennen, sparen Sie enorm viel Zeit.

Wie Sie den Fehler beweisen: Kleine vs. große Pakete reproduzierbar testen

Die wichtigste Disziplin ist, das Problem als Größenproblem sichtbar zu machen. „Es geht manchmal nicht“ ist für MTU-Diagnosen zu unpräzise. Sie wollen zeigen: bis Größe X geht es, ab Größe Y bricht es. Dazu sind Tests nötig, die kontrollierte Paketgrößen erzeugen.

Praktisches Testprinzip

Wenn Sie dieses Muster sauber nachweisen, haben Sie einen starken Hinweis, dass es nicht primär ein Service-, Ingress- oder Policy-Problem ist, sondern ein Transport-/Pfadproblem.

TCP MSS: Der unterschätzte Hebel zur Mitigation

In vielen Umgebungen ist die praktikabelste Mitigation nicht „MTU überall ändern“, sondern TCP MSS (Maximum Segment Size) so zu clampen, dass TCP-Segmente kleiner sind und gar nicht erst in problematische Größen wachsen. MSS ist die maximale TCP-Nutzlast ohne IP- und TCP-Header. Wenn MSS passend gesetzt ist, entstehen keine oversized Frames, selbst wenn der Pfad eine kleinere MTU hat.

MSS ≈ MTU − IPHeader − TCPHeader

Für IPv4 ohne Optionen gilt häufig: IPHeader = 20 Byte, TCPHeader = 20 Byte, also MSS ≈ MTU − 40. Bei IPv6 ist der IP-Header größer, und zusätzliche Optionen (z. B. TCP Timestamps) erhöhen den Header weiter. In Tunneln kommt Encapsulation-Overhead hinzu, wodurch die effektive MTU sinkt und MSS entsprechend kleiner sein muss.

Wann MSS-Clamping besonders sinnvoll ist

Mitigation in der Praxis: Maßnahmen, die wirklich wirken

MTU-Probleme löst man selten mit einem einzelnen „Schalter“. Stabil wird es meist durch ein Bündel an Maßnahmen: korrekte MTU-Werte, funktionierendes PMTUD, sinnvolles MSS-Verhalten und konsistente Konfiguration über alle Nodepools.

Maßnahmen auf CNI-/Cluster-Ebene

Maßnahmen auf Netzwerk-/Security-Ebene

Maßnahmen auf Applikations-/Traffic-Ebene

Warum MTU-Probleme oft nur bei TLS, gRPC oder „bestimmten“ Services sichtbar werden

TLS und gRPC sind häufige Auslöser, weil sie in der Praxis größere Pakete und empfindlichere Handshakes erzeugen. Ein TLS-Handshake kann durch Zertifikatsketten und Extensions deutlich größer werden als simple HTTP-Requests. gRPC nutzt oft HTTP/2 und kann große Frames oder mehrere Header erzeugen. Wenn zusätzlich mTLS im Service Mesh aktiv ist, kommen weitere Header und Proxy-Schichten hinzu – die effektive MTU wird noch kritischer. Das erklärt, warum ein „einfacher curl“ manchmal funktioniert, während echte Produktionsaufrufe scheitern.

Diagnose-Fallen: Warum klassische Checks Sie täuschen können

Viele Standardchecks testen nicht das, was im Problemfall kaputt ist. Ping testet ICMP und oft nur kleine Payloads. Ein einfacher DNS-Query ist klein. Ein Healthcheck liefert wenige Bytes. Dadurch bleibt das Problem unsichtbar, bis reale Payloads auftreten.

Prävention: Wie Sie MTU im CNI dauerhaft stabil halten

MTU-Stabilität ist weniger „Tuning“ als Standardisierung. Wenn Sie MTU als festen Bestandteil Ihrer Plattform-Baseline behandeln, verschwinden viele der schwer reproduzierbaren Incidents.

Weiterführende Quellen für MTU, PMTUD und CNI-Kontext

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