Site icon bintorosoft.com

MTU Underlay vs. Overlay: Ursache für „mysteriöse“ VXLAN-Drops

Red Snapper

switch and router

MTU Underlay vs. Overlay ist eine der häufigsten Ursachen für „mysteriöse“ VXLAN-Drops in modernen EVPN/VXLAN- und Overlay-Netzen. Das Gemeine daran: Der Dienst wirkt teilweise gesund. Kleine Pings funktionieren, Control Plane (BGP EVPN) ist stabil, ARP/ND scheint zu laufen – und trotzdem brechen Anwendungen ab, TCP zeigt Retransmissions, Datenübertragungen sind langsam oder instabil, und manche Flows funktionieren, andere nicht. In klassischen VLAN-Netzen wäre MTU oft ein lokales Thema am Access-Port oder an einem einzelnen Trunk. In VXLAN ist MTU ein End-to-End-Problem im Underlay, weil die Overlay-Frames kapsuliert (encapsulated) werden und dadurch größer werden. Wenn an irgendeiner Stelle im Underlay die effektive MTU nicht ausreicht, entstehen Drops oder Fragmentierung – oft ohne klare, leicht sichtbare Alarme. Je nach Plattform werden Fragmente verworfen, ICMP „Fragmentation Needed“ wird gefiltert, Path-MTU-Discovery (PMTUD) scheitert, oder Hardware-Offloads verhalten sich unerwartet. Das Ergebnis ist ein Fehlerbild, das im NOC wie „random“ aussieht: nur große Payloads gehen nicht, nur bestimmte Applikationen sind betroffen, oder nur Inter-Subnets funktionieren instabil. Dieser Leitfaden erklärt praxisnah, warum MTU Underlay vs. Overlay in VXLAN so kritisch ist, wie Sie Overhead korrekt einplanen, welche typischen Symptome auftreten, wie Sie die Fault Domain schnell eingrenzen und welche Mitigations- und Präventionsmaßnahmen verhindern, dass MTU zum wiederkehrenden Outage-Treiber wird.

Begriffe: Underlay-MTU, Overlay-MTU und „effektive MTU“

Damit Troubleshooting reproduzierbar ist, lohnt sich eine klare Begriffstrennung. In VXLAN-Designs hat jedes Paket mindestens zwei „Perspektiven“: das ursprüngliche Ethernet/IP-Paket im Overlay und das transportierte IP/UDP-Paket im Underlay.

Für VXLAN als Kapselungsmechanismus ist RFC 7348 eine gute Referenz. Für EVPN als Control Plane ist RFC 7432 zentral; als Architekturkontext für EVPN/VXLAN über IP-Underlay ist RFC 8365 hilfreich.

Warum VXLAN MTU-Probleme so „mysteriös“ erscheinen

In vielen Netzen ist MTU nicht konsistent dokumentiert oder nicht durchgehend umgesetzt. VXLAN macht das sichtbar, weil das Underlay plötzlich mehr tragen muss als früher. Gleichzeitig maskieren moderne Protokolle Probleme auf verschiedene Weise:

Das Ergebnis sind Tickets, die oft falsch eingeordnet werden: „EVPN ist kaputt“, „Firewall spinnt“, „nur Kundenseite betroffen“. In Wirklichkeit liegt die Ursache häufig in einem einzigen Underlay-Link mit falscher MTU oder einem Zwischenknoten mit Standard-MTU.

Wie viel Overhead VXLAN typischerweise erzeugt

Für Ops muss die exakte Bytezahl nicht auswendig gelernt werden, aber das Prinzip muss sitzen: VXLAN kapselt Ethernet in UDP/IP. Dadurch kommen äußere Header hinzu. Zusätzlich können VLAN-Tags im Overlay existieren (z. B. 802.1Q) oder sogar QinQ in bestimmten Designs. Jede zusätzliche Schicht erhöht die Paketgröße.

Faustregel für die MTU-Bilanz (MathML)

UnderlayMTU ≥ OverlayMTU + EncapOverhead

Wenn Sie die maximal erlaubte Overlay-MTU aus einer gegebenen Underlay-MTU ableiten wollen, ist die Umstellung hilfreich.

Maximale Overlay-MTU aus Underlay-MTU (MathML)

OverlayMTU_max = UnderlayMTU − EncapOverhead

Typische Symptome: Woran Sie MTU-Probleme im VXLAN-Betrieb erkennen

MTU-Probleme können wie viele andere Themen aussehen. Die folgenden Muster sind jedoch besonders typisch und sollten in jedem Runbook als „MTU-Verdacht“ geführt werden.

Symptom 1: „Kleine Pakete gehen, große nicht“

Symptom 2: Intermittierende Drops nur bei bestimmten Flows

Symptom 3: TCP Retransmissions und „spiky latency“ ohne klare Link-Errors

Symptom 4: Control Plane ok, Data Plane nicht

PMTUD und ICMP: Warum „Fragmentation Needed“ häufig fehlt

Path-MTU-Discovery funktioniert über ICMP-Meldungen (bei IPv4: „Fragmentation Needed“, bei IPv6: „Packet Too Big“). In vielen Netzen werden ICMP-Typen aus Sicherheitsgründen gefiltert oder falsch priorisiert. Wenn PMTUD nicht funktioniert, sendet der Endpunkt weiter zu große Pakete – und diese werden im Underlay gedroppt. Das ist die typische Quelle für „mysteriöse“ VXLAN-Drops, weil es keine sichtbare Gegenreaktion gibt.

Best Practice ist nicht „ICMP überall offen“, sondern „die notwendigen ICMP-Typen für PMTUD gezielt erlauben“. Das reduziert Outage-Risiko deutlich.

Step-by-Step Troubleshooting: MTU Underlay vs. Overlay systematisch eingrenzen

Das folgende Vorgehen ist NOC-tauglich und vermeidet Vendor-spezifische CLI. Es zwingt zu klaren „Pass/Fail“-Entscheidungen und führt schnell zur richtigen Fault Domain.

Schritt: Scope und Hypothese sauber formulieren

Schritt: Underlay-End-to-End MTU plausibilisieren

Schritt: Datenebene mit großen Paketen testen (gezielt)

Schritt: ICMP/PMTUD-Path prüfen

Schritt: Overlay-spezifische Overhead-Fallen ausschließen

Schritt: Mitigation festlegen (kurzfristig) und Root Cause beheben (nachhaltig)

Mitigations: Was im Incident wirklich hilft

Wenn Kundenimpact akut ist, zählt eine Maßnahme, die schnell stabilisiert, ohne neue Risiken zu erzeugen. Dabei ist klar: Die nachhaltige Lösung ist eine konsistente Underlay-MTU. Im Incident kann das aber dauern, weil viele Geräte/Links betroffen sein können.

Mitigation 1: MSS-Clamping als „Stop-the-bleeding“

MSS-Clamping reduziert die maximale TCP-Segmentgröße, sodass Pakete kleiner bleiben und nach Encapsulation nicht über die Underlay-MTU hinausgehen. Das hilft sofort für TCP-basierte Applikationen, aber nicht für UDP oder bereits große L2-Frames.

Mitigation 2: Overlay-MTU temporär reduzieren

Mitigation 3: Underlay-MTU-Fix staged ausrollen

Validierung nach Fix: Wie Sie beweisen, dass die Drops weg sind

MTU-Fixes sind nur dann „fertig“, wenn sie messbar stabil sind – und zwar auf mehreren Pfaden (ECMP) und nicht nur für kleine Tests. Eine gute Post-Validation prüft:

Delta-Drop als Nachweis (MathML)

ΔDrops = Drops_after − Drops_before

Prävention: Wie Sie MTU-Probleme in VXLAN-Netzen dauerhaft vermeiden

Die beste Mitigation ist ein Design, das MTU als Pflicht-Constraint behandelt, nicht als Nachgedanke. In der Praxis haben sich folgende Maßnahmen bewährt:

Evidence Pack: Pflichtdaten für MTU/VXLAN-Drop-Tickets

MTU-Probleme eskalieren schnell zu langen, teuren Fehlersuchen, wenn keine standardisierten Daten gesichert werden. Ein Evidence Pack sollte daher minimal, aber vollständig sein:

Outbound-Ressourcen

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