February 23, 2026

MTU Troubleshooting: Fragmentierung, PMTUD und OSPF/BGP Side Effects

MTU Troubleshooting ist in Cisco-Netzen eine der unterschätztesten Disziplinen, weil MTU-Probleme selten „laut“ sind. Statt klarer Hard-Down-Symptome sehen Sie häufig diffuse Effekte: bestimmte Anwendungen brechen ab, Dateiübertragungen hängen, VPN-Tunnel sind instabil, einzelne Webseiten laden nicht vollständig oder VoIP/Video verhält sich „sporadisch“ schlecht. Besonders tückisch wird es, wenn MTU als Nebenwirkung andere Protokolle trifft: OSPF-Neighbors bleiben in ExStart/Exchange hängen, weil die Datenbank-Deskriptoren (DBD) nicht sauber ausgetauscht werden können, oder BGP-Sessions flappen scheinbar ohne Grund, weil TCP-Segmente fragmentiert werden müssen und ICMP-Fehlermeldungen für PMTUD nicht zurückkommen. In großen Enterprise- und Datacenter-Umgebungen treffen dabei unterschiedliche MTU-Domänen aufeinander: Campus (meist 1500), WAN (Subrate, Provider-Overhead), Datacenter (Jumbo Frames), Overlay/Encapsulation (MPLS, GRE, VXLAN, IPsec). Ein professioneller Diagnose-Workflow arbeitet deshalb nicht mit Vermutungen („ist bestimmt MTU“), sondern mit einer messbaren Kette: Pfad-MTU bestimmen, Fragmentierung/DF-Verhalten prüfen, PMTUD-Funktion validieren und danach die Side Effects auf OSPF/BGP sauber einordnen. Dieser Artikel liefert einen praxisnahen Cisco-Workflow für IOS/IOS XE und NX-OS, um MTU-Probleme schnell zu finden, sicher zu beheben und dauerhaft zu vermeiden.

Table of Contents

MTU-Grundlagen, die im Troubleshooting zählen

Für eine saubere Diagnose müssen Sie drei Begriffe unterscheiden, die im Alltag oft vermischt werden:

MTU (Layer 3 MTU): Maximale IP-Paketgröße (ohne L2-Header), die ein Interface senden/empfangen kann, bevor Fragmentierung nötig wäre.
L2 MTU: Maximale Ethernet-Frame-Größe inklusive L2-Header (und je nach Betrachtung inkl. VLAN-Tag). Relevant bei Switch-Pipelines und Encapsulation.
Path MTU (PMTU): Die kleinste MTU entlang eines End-to-End-Pfads. Sie bestimmt die maximale Paketgröße, die ohne Fragmentierung durchkommt.

Wichtig ist außerdem der Unterschied zwischen IPv4 und IPv6: Bei IPv4 kann Fragmentierung durch Router erfolgen (sofern DF nicht gesetzt ist). Bei IPv6 dürfen Router nicht fragmentieren; Fragmentierung passiert nur am Sender, weshalb PMTUD bei IPv6 betrieblich noch wichtiger ist.

Typische Symptome: Woran Sie MTU-Probleme erkennen

MTU-Probleme zeigen sich häufig in Mustern, die auf den ersten Blick nicht zusammenhängen. Diese Indikatoren sind in Cisco-Umgebungen besonders typisch:

„Kleine“ Pings funktionieren, große nicht: ICMP Echo mit kleiner Payload ok, mit DF/large Payload nicht.
TCP hängt bei bestimmten Anwendungen: TLS-Handshakes, große HTTP-Responses, Dateiübertragungen oder VPN-Traffic brechen ab.
OSPF hängt in ExStart/Exchange: Adjacency kommt nicht auf Full, oft bei Jumbo/Transit-Links.
BGP flappt oder bleibt in Active/Open: TCP steht instabil, Keepalives/Updates kommen nicht zuverlässig durch.
„Blackhole“ nach Encapsulation: Nach GRE/IPsec/MPLS/VXLAN funktionieren bestimmte Flows nicht mehr, andere schon.

Praxisregel: Wenn ein Problem „größenabhängig“ ist (kleine Pakete ok, große nicht), ist MTU/Fragmentierung/PMTUD immer ein Top-Kandidat.

Der wichtigste Diagnose-Schritt: Pfad und Engpass definieren

Bevor Sie an Interfaces schrauben, brauchen Sie ein klares Bild des Pfads. MTU ist selten ein Einzelgerätproblem, sondern ein Pfadproblem.

Quelle/Ziel: Von welchem Host zu welchem Ziel tritt der Fehler auf?
Pfad: Welche Hops liegen dazwischen (Access, Distribution, Core, WAN, Firewall, VPN-Gateway)?
Encapsulation: Gibt es Overhead (VLAN, QinQ, MPLS, GRE, IPsec, VXLAN)?
Domänen: Campus 1500 vs. Datacenter Jumbo vs. WAN/Provider-Constraints.

Ohne Pfaddefinition ist MTU-Troubleshooting wie „Kabel suchen im Dunkeln“: Sie ändern lokale MTU-Werte, aber die PMTU bleibt an anderer Stelle der Flaschenhals.

Workflow: MTU-Probleme in 5 Schritten sicher finden

Ein robuster Cisco-Workflow folgt einer festen Reihenfolge, die schnell zwischen „Fragmentierung ist ok“ und „PMTUD ist kaputt“ unterscheidet.

Schritt 1: Interface-MTUs entlang der kritischen Links prüfen (L2/L3), besonders an Übergängen (WAN, Tunnel, DC-Fabric).
Schritt 2: PMTU testen (Ping mit DF, graduell erhöhen, um die maximale MTU ohne Fragmentierung zu finden).
Schritt 3: PMTUD-Funktion prüfen (kommen ICMP „Fragmentation Needed“/„Packet Too Big“ zurück?).
Schritt 4: Encapsulation-Overhead einrechnen und MSS/MTU-Strategie ableiten.
Schritt 5: Protokoll-Side-Effects validieren (OSPF/BGP) und nach Fix verifizieren.

Schritt 1: Interface MTU auf Cisco prüfen – und nicht nur auf einem Gerät

In Cisco-Umgebungen ist es entscheidend, sowohl die Interface-MTU als auch die Plattform-/VLAN-/System-MTU zu verstehen. Häufig ist an einem Punkt Jumbo aktiv, an einem anderen nicht. Prüfen Sie entlang des Pfads gezielt die Transitinterfaces und Tunnelinterfaces.

IOS/IOS XE: Typisch über show interfaces <int> (MTU wird im Output angezeigt).
NX-OS: Zusätzlich systemweite MTU-Settings und Feature-spezifische MTU (z. B. für Fabric/Overlay) beachten.
Port-Channel: MTU muss mit Membern konsistent sein (je nach Plattform), sonst entstehen subtile Drops.

Praxis-Tipp: Ein einzelnes Interface mit niedrigerer MTU ist ausreichend, um PMTU zu senken. Deshalb ist „ein Gerät zeigt 9000“ kein Beweis – entscheidend ist die niedrigste MTU im Pfad.

Schritt 2: Fragmentierungstest mit DF – PMTU praktisch messen

Der schnellste Test, um MTU-Probleme zu beweisen, ist ein Ping mit DF (Don’t Fragment) und variierender Größe. Ziel: die größte Payload finden, die ohne Fragmentierung durchkommt. Auf Cisco ist DF-Ping je Plattform möglich, alternativ testen Sie vom Host.

Vorgehen: Start mit kleiner Payload (z. B. 1200), dann schrittweise erhöhen (z. B. 1400, 1472), bis es fehlschlägt.
Interpretation: Wenn DF-Ping ab einer Größe scheitert, ist PMTU kleiner als erwartet oder ICMP/PMTUD blockiert.
Hinweis: Bei Ethernet mit 1500 MTU ist ein typischer maximaler ICMP-Payload-Wert 1472 (1500 minus IP/ICMP-Header), aber Encapsulation verändert das.

Wenn DF-Ping scheitert, prüfen Sie im nächsten Schritt, ob das korrektes PMTUD-Verhalten ist (ICMP kommt zurück) oder ob Sie ein PMTUD-Blackhole haben (ICMP wird gedroppt).

Schritt 3: PMTUD prüfen – das „Blackhole“-Muster erkennen

Path MTU Discovery (PMTUD) funktioniert, indem Geräte bei zu großen Paketen ICMP-Fehlermeldungen senden. Bei IPv4 ist das typischerweise ICMP Type 3 Code 4 („Fragmentation Needed“), bei IPv6 ICMPv6 „Packet Too Big“. Wenn diese ICMP-Meldungen unterwegs gefiltert werden, entsteht ein klassisches Blackhole: Große Pakete kommen nicht an, aber der Sender erfährt nie, welche MTU er nutzen soll.

Typisches Blackhole-Symptom: TCP-Verbindungen hängen, Retransmits steigen, aber keine klare Fehlermeldung.
Häufige Ursache: Firewall/ACL blockt ICMP zu aggressiv („ICMP ist unsicher“), CoPP blockt Control-Plane-ICMP.
Diagnose: Capture/Logs an der Engpassstelle: Werden ICMP „Fragmentation Needed“ erzeugt? Kommen sie zurück?

Professionelle Security-Policies blocken ICMP nicht pauschal, sondern erlauben die relevanten Typen für PMTUD. Andernfalls ist MTU-Troubleshooting ein Dauerzustand.

Schritt 4: Encapsulation und Overhead korrekt einrechnen

In modernen Netzen ist der häufigste Grund für „plötzliche MTU-Probleme“ nicht der physische Link, sondern zusätzlicher Overhead: MPLS Labels, GRE Header, IPsec, VXLAN, QinQ oder Kombinationen daraus. Dadurch sinkt die effektive Nutzdaten-MTU.

MPLS: Pro Label zusätzlicher Overhead, plus ggf. weitere Header je Provider-Design.
GRE/IPsec: Overhead hängt von Algorithmus, NAT-T, zusätzlichen Optionen ab; die effektive MTU kann deutlich unter 1500 fallen.
VXLAN: Overlay benötigt typischerweise Jumbo im Underlay, sonst entstehen Drops oder Fragmentierung.
QinQ: Zusätzliche VLAN-Tags erhöhen L2-Framegröße; ohne passende L2 MTU kann es droppen.

Best Practice: Definieren Sie MTU-Domänen bewusst (z. B. DC Underlay 9000, Overlay 1500/1600 je Design) und dokumentieren Sie Overhead. Ohne diese Klarheit entstehen „zufällige“ MTU-Fallen bei jeder Einführung eines neuen Encapsulation-Features.

Schritt 5: MSS-Clamping als pragmatische Stabilisierung (vor allem bei TCP)

Wenn Sie nicht überall MTU erhöhen können (z. B. über das Internet oder durch Provider-Limits), ist TCP MSS-Clamping ein bewährtes Mittel, um Blackholes zu vermeiden. Es reduziert die TCP Segment Size so, dass IP-Pakete nicht fragmentieren müssen.

Wann sinnvoll? Bei IPsec/GRE/WAN-Edges, wenn PMTUD unsicher ist oder Overhead stark schwankt.
Was löst es nicht? Nicht-TCP Traffic (z. B. UDP-basierte Echtzeitprotokolle) profitiert nicht direkt; dort brauchen Sie MTU/Fragmentierungsstrategie.
Risiko: Zu aggressives Clamping reduziert Durchsatz, ist aber oft besser als Instabilität.

MSS-Clamping ist kein Ersatz für saubere MTU-Domänen, aber eine sehr wirksame Betriebssicherung in heterogenen Pfaden.

OSPF Side Effects: Warum MTU-Mismatch Neighbors in ExStart/Exchange hält

Ein klassisches Cisco-Fehlerbild: OSPF-Neighbors bleiben in ExStart oder Exchange hängen. In der Praxis ist MTU-Mismatch einer der häufigsten Gründe. Dabei ist wichtig zu verstehen, dass OSPF nicht „irgendwie“ kaputt ist, sondern dass der Database Exchange nicht zuverlässig durchläuft.

Typischer Kontext: Migration zu Jumbo Frames im Datacenter, aber ein Transitlink oder ein Port-Channel bleibt auf 1500.
Symptom: Hellos funktionieren (Neighbor sichtbar), aber DBD/LSA-Exchange scheitert oder wiederholt sich.
Warum? OSPF versucht, Datenbankinformationen auszutauschen; wenn Pakete fragmentiert werden müssen oder verworfen werden, kommt die Synchronisation nicht zustande.

OSPF-spezifischer Diagnoseansatz

Interface MTU beidseitig prüfen: Nicht nur auf dem Router, sondern auf Switchports/Port-Channels im Pfad.
Neighbor State korrelieren: ExStart/Exchange ist ein starker MTU-Hinweis; Loading deutet eher auf Drops/Filter/LSDB-Größe.
Packetpfad prüfen: Wenn ICMP/PMTUD blockiert ist, kann auch OSPF indirekt leiden, obwohl es nicht direkt PMTUD nutzt wie TCP.

Wichtig: Änderungen an OSPF „Workarounds“ (z. B. MTU-Ignore) sind betriebsriskant. In Enterprise-Designs ist es meist besser, MTU konsistent zu machen, statt Protokollprüfungen zu umgehen.

BGP Side Effects: TCP, PMTUD und scheinbar „zufällige“ Session-Flaps

BGP läuft über TCP (Port 179). Damit ist BGP besonders anfällig für PMTUD-Blackholes: Wenn TCP-Segmente nicht durchkommen und ICMP „Fragmentation Needed“ geblockt wird, sehen Sie Retransmits, langsame Konvergenz oder Session-Resets. Das wirkt häufig wie „BGP ist instabil“, obwohl die Ursache in MTU/ICMP-Policies liegt.

Symptom: Session kommt hoch, aber Updates dauern extrem lange oder flappen unter Last.
Einordnung: Kleine Keepalives können durchkommen, aber größere Update-Bursts oder bestimmte TCP-Segmente scheitern.
Diagnose: TCP Retransmits im Capture, fehlende ICMP Type 3 Code 4, DF-Ping scheitert ohne Fehlermeldung.

Praxis-Tipp: Wenn BGP nur bei großen Tabellen oder nach Policy-Änderungen instabil wirkt, ist MTU/PMTUD eine realistische Hypothese, weil dann größere Update-Mengen übertragen werden.

Fragmentierung in der Praxis: Warum „Fragmentierung erlaubt“ nicht automatisch gut ist

Bei IPv4 ist Fragmentierung technisch möglich, aber betrieblich oft unerwünscht. Fragmentierte Pakete erhöhen CPU-Last, sind anfälliger für Drops, und viele Security-Geräte behandeln Fragmente restriktiver. In modernen Netzen ist das Ziel meist: Fragmentierung vermeiden und stattdessen MTU/PMTU/MSS sauber einstellen.

Performance: Fragmentierung kostet Ressourcen, insbesondere bei hohen Durchsatzraten.
Security: Fragmente werden in Firewalls/IDS/IPS oft anders behandelt; das kann zu „nur manchmal geht es“ führen.
Fehlersuche: Fragmentierung erschwert Diagnosen, weil Drops nicht immer im gleichen Segment auftreten.

Ein realistisches Betriebsziel ist: Wo immer möglich PMTU ausreichend groß halten und PMTUD-ICMP korrekt erlauben, statt Fragmentierung als Standardpfad zu akzeptieren.

IPv6: PMTUD ist Pflicht, nicht Option

In IPv6 ist Router-Fragmentierung nicht erlaubt. Das macht PMTUD operativ kritischer. Wenn ICMPv6 „Packet Too Big“ geblockt wird, entstehen sehr ähnliche Blackholes wie bei IPv4 – aber ohne die „Fallback“-Option Routerfragmentierung.

Wichtig: ICMPv6 ist nicht „optional“. Viele grundlegende IPv6-Funktionen hängen davon ab.
Fehlerbild: IPv6 wirkt teilweise ok (Neighbor Discovery läuft), aber bestimmte Datenverbindungen hängen oder brechen ab.
Policy: Firewalls sollten ICMPv6-Typen gezielt erlauben, insbesondere PMTUD-relevante.

Häufige Root Causes: Was in Enterprise-Netzen MTU-Probleme am meisten auslöst

Jumbo nur „halb“ eingeführt: Datacenter-Underlay oder Storage-Pfad hat einen 1500-Link dazwischen.
Encapsulation ohne MTU-Plan: VXLAN/GRE/IPsec/MPLS kommt dazu, aber MTU/MSS wird nicht angepasst.
ICMP zu aggressiv geblockt: PMTUD-ICMP wird gefiltert, Blackholes entstehen.
Port-Channel Inkonsistenz: Member-Ports oder Peer haben abweichende MTU/Interface-Profile.
Provider Subrate/Policing: WAN-Link ist nominal größer, aber effektiv kleiner; ohne Shaping/MSS entstehen Drops.

Best Practices: MTU so designen, dass Troubleshooting selten wird

MTU-Domänen definieren: Campus 1500, DC Underlay Jumbo, Overlays mit dokumentierter effektiver MTU.
Encapsulation dokumentieren: Overhead je Tunnel/Overlay klar erfassen, nicht „nach Gefühl“.
PMTUD ermöglichen: ICMP „Fragmentation Needed“/„Packet Too Big“ in Policies bewusst erlauben.
MSS-Clamping gezielt nutzen: Besonders an WAN-/VPN-Edges als Stabilitätsmechanismus.
Golden Configs: MTU/Overhead/MSS als rollenbasierte Standards ausrollen und Drift überwachen.
Preflight bei Changes: Bei OSPF/BGP-Änderungen und Upgrade-Fenstern MTU-Konsistenz prüfen, bevor Sie Protokollprobleme riskieren.

Runbook: MTU Troubleshooting Schrittfolge

Pfad definieren: Quelle/Ziel, Hops, Tunnel/Encapsulation.
PMTU messen: DF-Ping/Path-Tests mit steigender Payload bis zum Failure.
ICMP/PMTUD prüfen: Kommt „Fragmentation Needed/Packet Too Big“ zurück oder entsteht Blackhole?
Interface MTUs prüfen: Transitlinks, Port-Channels, Tunnelinterfaces, System-/VLAN-MTU.
Overhead/MSS: Encapsulation einrechnen, MSS-Clamp/MTU-Plan ableiten.
Side Effects verifizieren: OSPF ExStart/Exchange lösen, BGP Stabilität und Prefix-Updates prüfen.
Nachkontrolle: Lasttest, Applikations-Validierung, Monitoring auf Drops/Errors.

Outbound-Referenzen

RFC 1191 (Path MTU Discovery für IPv4) als Grundlage für PMTUD-Mechanik und ICMP „Fragmentation Needed“.
RFC 8201 (Path MTU Discovery für IPv6) für PMTUD in IPv6 und ICMPv6 „Packet Too Big“.
RFC 2328 (OSPFv2) als Referenz für OSPF-Adjacency und die Phasen, in denen MTU-Mismatches typischerweise sichtbar werden.
RFC 4271 (BGP-4) als Grundlage für BGP über TCP und die Implikationen von Transportproblemen auf Session-Stabilität.
Cisco: OSPF Neighbor Troubleshooting (inkl. MTU-Aspekte) für praxisnahe Zuordnung von Neighbor States und typischen Ursachen.
Cisco: BGP Troubleshooting als Referenz für Session-/Transportanalyse und saubere Diagnosepfade.
Wireshark Dokumentation für Captures, DF/Fragmentierungsanalyse, ICMP PMTUD-Fehlermeldungen und TCP Retransmits.

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.