MTU in MPLS Netzen: Label Stack, Fragmentierung und Debugging

MTU-Probleme sind in MPLS-Netzen einer der häufigsten Gründe für „mysteriöse“ Störungen: Ping geht, aber Applikationen hängen; VPNs sind instabil; bestimmte Flows haben sporadische Drops. Der Grund ist meist simpel: MPLS fügt Header-Overhead hinzu (Label Stack), und wenn die Pfad-MTU nicht überall passt, entstehen Fragmentierung, Drops oder PMTUD-Fehlschläge. Besonders kritisch wird es bei L3VPN (zwei Labels), SR-MPLS (mehr Labels), GRE/IPsec over MPLS oder bei strikten „DF“-Flüssen. Dieser Artikel erklärt, wie MTU in MPLS wirklich funktioniert, wie du den Label-Overhead berechnest und wie du systematisch debugst.

Grundlagen: MTU, IP-MTU und MPLS-MTU

In MPLS musst du zwischen IP-MTU (für reine IP-Pakete) und MPLS-MTU (für gelabelte Pakete) unterscheiden. Viele Outages entstehen, weil IP-MTU „passt“, aber MPLS-MTU nicht – und genau das merkst du erst bei realen Payloads.

• IP-MTU: maximale IP-Paketgröße auf einem Link
• MPLS-MTU: maximale Größe eines gelabelten Pakets auf einem Link
• Pfad-MTU: kleinste MTU entlang des gesamten Pfads

Merker

$\text{Path MTU}=\text{min(MTU pro Hop)}$

Label Stack Overhead: Wie viel „größer“ wird ein Paket?

Jedes MPLS-Label ist 4 Byte groß. Der Label-Stack addiert sich. Bei L3VPN sind häufig zwei Labels im Stack (Transport + VPN), bei SR-MPLS können es deutlich mehr sein (Segment-Liste), und bei zusätzlichen Encaps (GRE, IPsec) wächst der Overhead weiter.

Overhead-Berechnung

$\text{Overhead}=\text{Labels}\times 4\text{Byte}$

• 1 Label: +4 Byte
• 2 Labels (typisch L3VPN): +8 Byte
• 4 Labels: +16 Byte
• 8 Labels (SR Policies): +32 Byte

Praxisbeispiel: „Warum 1500 nicht mehr 1500 ist“

Wenn du am CE eine IP-MTU von 1500 hast und im Core zwei Labels nutzt, wird aus einem 1500-Byte IP-Paket im MPLS-Core ein 1508-Byte Frame (ohne L2-Overhead). Wenn der Core-Link nur 1500 MPLS-MTU hat, dropt er oder fragmentiert (je nach Verhalten). Genau deshalb setzen Backbones oft Jumbo Frames oder mindestens eine MPLS-MTU > IP-MTU.

Beispielrechnung (L3VPN mit 2 Labels)

$1500+2\times 4=1508$

Fragmentierung: Wer fragmentiert wann?

In MPLS-Netzen willst du Fragmentierung möglichst vermeiden. IP-Fragmentierung erhöht CPU-Last, verschlechtert Performance und kann bei Firewalls/NAT zu Problemen führen. Besonders kritisch ist PMTUD: Wenn ICMP „Fragmentation Needed“ blockiert wird, bleibt die MTU zu groß und der Flow wirkt „kaputt“.

• DF-Bit gesetzt: keine Fragmentierung erlaubt → Drops bei zu großer MTU
• PMTUD abhängig von ICMP: ICMP muss durchkommen
• IPsec/GRE: zusätzliche Overheads verschärfen das Problem

MPLS MTU Design: Best Practices für stabile Netze

Die robuste Praxis ist: Core-MTU so groß wählen, dass sie alle Labels und Encaps abdeckt. Wenn das nicht möglich ist, setzt du MSS-Clamping an den richtigen Stellen oder reduzierst die Customer-MTU. Für moderne Backbones sind Jumbo Frames fast immer die sauberste Lösung.

• Core: Jumbo MTU (z. B. 9000+) für Headroom
• Mindestens: MPLS-MTU = IP-MTU + Label-Overhead (+ Reserve)
• MSS Clamping an Edge/WAN, wenn Endgeräte 1500 erwarten
• ICMP für PMTUD nicht blockieren

IOS XE/Cisco: Wo du MTU setzt (IP vs. MPLS)

Auf Cisco unterscheidest du je nach Plattform Interface-MTU, IP-MTU und MPLS-MTU. Das Ziel ist: MPLS-MTU ist nicht kleiner als IP-MTU + erwarteter Label-Stack. Die konkrete Syntax kann je Interface-Typ variieren, das Muster bleibt jedoch: Interface MTU erhöhen und MPLS auf dem Interface aktivieren.

Interface MTU erhöhen (Pattern)

interface gigabitEthernet0/0
 mtu 9216
 mpls ip

IP-MTU gezielt setzen (Pattern, wenn nötig)

interface gigabitEthernet0/0
 ip mtu 1500

Wie du MTU-Probleme erkennst: Symptome und Indizien

MTU-Probleme sind oft „selektiv“: kleine Pakete gehen durch, große nicht. TCP-Verbindungen hängen bei bestimmten Payloads. Typisch ist: Ping ohne DF funktioniert, Ping mit DF und großer Größe nicht.

• „Small works, large fails“
• VPN/Applikationen hängen, aber Control Plane wirkt normal
• Drops steigen, aber nur bei bestimmten Flows

Debugging Schritt 1: Path MTU per Ping mit DF finden

Der schnellste Praxis-Test ist ein Ping mit DF-Bit und steigender Paketgröße. Damit findest du die maximale Paketgröße, die ohne Fragmentierung durchkommt. Für MPLS testest du idealerweise zwischen relevanten Endpunkten (CE↔CE oder PE↔PE).

Ping mit DF (Beispielpattern)

ping 10.20.10.10 df-bit size 1472 repeat 10

Interpretation

• 1472 Byte ICMP Payload + 28 Byte IP/ICMP Header = 1500 IP-MTU
• Schrittweise erhöhen/senken, bis es stabil ist

Debugging Schritt 2: MPLS OAM nutzen (LSP Ping/Traceroute)

Wenn du vermutest, dass der MPLS-Core die MTU bricht, nutzt du MPLS Traceroute, um Pfad und mögliche Problemhops zu sehen. In Kombination mit Interface Counters kannst du den „kleinsten“ Hop finden.

MPLS Traceroute

traceroute mpls ipv4 10.255.0.2

Interface Drops prüfen

show interfaces | include drops|error
show platform hardware qfp active statistics drop

Debugging Schritt 3: Label Stack wirklich beobachten

Für sauberes Debugging willst du wissen, wie viele Labels im echten Traffic genutzt werden. In L3VPN sind es typischerweise zwei (plus evtl. weitere Service Labels). In SR Policies kann der Stack länger sein. Je länger der Stack, desto mehr MTU brauchst du.

Forwarding Table prüfen

show mpls forwarding-table
show ip bgp vpnv4 all

MSS Clamping: Praxisfix, wenn du MTU nicht überall erhöhen kannst

Wenn Endgeräte 1500 erwarten, du aber Overheads hast (MPLS + VPN), ist MSS-Clamping ein gängiger Fix: Du reduzierst TCP MSS so, dass TCP-Pakete kleiner bleiben und nicht fragmentieren müssen. Das ist ein Workaround, aber oft betrieblich notwendig.

MSS Clamping (Pattern)

interface gigabitEthernet0/1
 ip tcp adjust-mss 1360

Faustregel

• MSS = (Path MTU – 40) für TCP/IPv4 (20 IP + 20 TCP)
• Bei IPv6: MSS = (Path MTU – 60)

Typische MTU-Fallen in MPLS-Netzen

Diese Konstellationen führen besonders häufig zu Problemen, weil sich Overheads addieren oder weil ICMP/PMTUD nicht zuverlässig funktioniert.

• L3VPN + zusätzliche Encapsulation (GRE/IPsec) → hoher Overhead
• SR Policies mit vielen SIDs → längerer Label Stack
• ICMP gefiltert → PMTUD kaputt, TCP hängt
• Uneinheitliche MTUs im Core → sporadische Drops je Pfad

Quick-Runbook: MTU-Fehler in 10 Minuten isolieren

Diese Checkliste kombiniert Path-MTU-Tests, MPLS-Checks und Drop-Indizien zu einem schnellen Workflow.

show interfaces | include MTU|drops|error
show mpls forwarding-table
traceroute mpls ipv4 <remote-pe-loopback>
ping <dst> df-bit size 1472 repeat 10
ping <dst> df-bit size 1400 repeat 10
show platform hardware qfp active statistics drop
show logging | include MTU|fragment|drop

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.