PMTUD Probleme lösen: MSS Clamping, ICMP Filtering und Edge-Cases

PMTUD (Path MTU Discovery) ist der Mechanismus, mit dem Endgeräte die maximale Paketgröße entlang eines Pfads ermitteln, ohne zu fragmentieren. Wenn PMTUD scheitert, bekommst du klassische „Blackhole“-Symptome: kleine Pakete gehen, große nicht; Webseiten laden teilweise; TLS-Handshakes hängen; VPN-Traffic wirkt instabil. Die Ursache ist fast immer eine Kombination aus MTU-Mismatch, blockierten ICMP-Meldungen (IPv4: Fragmentation Needed, IPv6: Packet Too Big) oder speziellen Encapsulations-Overheads (MPLS, GRE, IPsec, PPPoE). Dieses Tutorial zeigt, wie du PMTUD-Probleme systematisch löst – mit MSS Clamping, sauberem ICMP-Filtering und einem Workflow für Edge-Cases.

PMTUD in 30 Sekunden: Was passiert technisch?

Ein Sender schickt Pakete mit DF (Don’t Fragment) bzw. in IPv6 ohne Netzfragmentierung. Wenn ein Zwischenhop eine kleinere MTU hat, muss er den Sender informieren. Bei IPv4 ist das ICMP „Fragmentation Needed“, bei IPv6 ICMP „Packet Too Big“. Nur wenn diese Meldung zurückkommt, reduziert der Sender seine Paketgröße.

Merker

$\text{PMTUD ok} \to \text{MTU passt sich an}, \text{PMTUD fail} \to \text{Blackhole}$

• IPv4: DF gesetzt → ICMP Fragmentation Needed notwendig
• IPv6: Router fragmentieren nicht → ICMP Packet Too Big notwendig
• ICMP-Filtering ist die häufigste PMTUD-Ursache

Symptome: Woran du PMTUD-Probleme erkennst

PMTUD-Probleme sind selektiv: Ping funktioniert, aber große Antworten nicht. HTTP lädt „ohne Bilder“, TLS hängt, RDP/SSH ist ok, aber Dateiübertragungen brechen. Diese Muster sind sehr typisch.

• Kleine Pakete ok, große Pakete fail („small works, large fails“)
• Webseiten laden teilweise, Downloads brechen
• TLS/HTTPS Handshake hängt sporadisch
• VPN/Encapsulation: nur bestimmte Sites/Flows betroffen

MTU-Overhead: Wo PMTUD in der Praxis bricht

Die häufigsten MTU-Engstellen entstehen an WAN-Edges und Tunneln: PPPoE, MPLS Label Stack, GRE, IPsec, VXLAN. Auch wenn dein LAN 1500 kann, kann der Pfad kleiner sein. Daher ist die Overhead-Rechnung wichtig.

Overhead als grobe Formel

$\text{Path MTU}\le \text{Link MTU}–\text{Encapsulation Overhead}$

• PPPoE: reduziert effektive MTU häufig auf 1492
• MPLS: +4 Byte pro Label (L3VPN meist +8)
• GRE/IPsec: deutlich mehr Overhead (abhängig von Algorithmen)

Diagnose Schritt 1: Path MTU mit DF-Pings bestimmen (IPv4)

Der schnellste Praxis-Test ist ein Ping mit DF-Bit und variierender Größe. Damit findest du die maximale Paketgröße, die ohne Fragmentierung durchkommt. Für IPv4 gilt: 1472 ICMP Payload entspricht 1500 IP-MTU (1472 + 28 Header).

DF-Ping (Cisco Pattern)

ping <dst-ip> df-bit size 1472 repeat 5
ping <dst-ip> df-bit size 1464 repeat 5
ping <dst-ip> df-bit size 1400 repeat 5

Interpretation

• 1472 ok → Pfad kann 1500 IP-MTU
• 1472 fail, 1464 ok → Pfad ca. 1492 (typisch PPPoE)
• Nur kleine Werte ok → starke Overheads oder ICMP-Block

Diagnose Schritt 2: IPv6 „Packet Too Big“ – ohne ICMPv6 geht es nicht

In IPv6 ist PMTUD noch strikter: Router fragmentieren nicht. Wenn ICMPv6 „Packet Too Big“ blockiert ist, bleiben Sender bei zu großen Paketen hängen. Deshalb ist ICMPv6 Allow-List Pflicht.

• ICMPv6 Packet Too Big muss erlaubt sein
• Auch Time Exceeded und Destination Unreachable sind wichtig für Diagnose
• PMTUD-Probleme äußern sich oft bei TLS/HTTPS zuerst

ICMP Filtering richtig machen: Allow-List statt „block all“

Viele Security-Policies blocken ICMP pauschal. Das ist bei PMTUD fatal. Best Practice ist: ICMP selektiv erlauben, mindestens die PMTUD-relevanten Typen. Das gilt besonders auf WAN-Edges und Firewalls.

IPv4: relevante ICMP-Typen

• Type 3 Code 4: Fragmentation Needed
• Type 11: Time Exceeded (Traceroute)
• Type 3: Destination Unreachable (ausgewählte Codes)

IPv6: relevante ICMPv6-Typen

• Packet Too Big
• Neighbor Solicitation/Advertisement (ND)
• Router Solicitation/Advertisement (RA)
• Time Exceeded, Destination Unreachable

MSS Clamping: Der pragmatische Fix an der Edge

MSS Clamping löst viele PMTUD-Probleme, indem es TCP-Segmente kleiner macht, bevor sie in einen Pfad mit kleinerer MTU laufen. Damit werden große IP-Pakete vermieden, und PMTUD muss weniger „arbeiten“. Das ist besonders effektiv bei PPPoE, GRE/IPsec und MPLS+VPN Overhead.

MSS-Berechnung (TCP/IPv4)

$\text{MSS}=\text{Path MTU}–40$

• 40 Byte = 20 (IPv4) + 20 (TCP)
• Für IPv6: MSS = Path MTU – 60

IOS XE MSS Clamping (Pattern)

interface GigabitEthernet0/1
 ip tcp adjust-mss 1452

Typische Werte

• PPPoE (1492 MTU): MSS ≈ 1452
• IPsec/GRE: oft 1360–1400 (abhängig vom Overhead)

Edge-Cases: Warum MSS Clamping nicht alles löst

MSS Clamping wirkt nur für TCP. UDP-basierte Protokolle (VoIP, QUIC/HTTP3, Gaming) profitieren nicht direkt. Außerdem kann PMTUD trotz MSS Clamping scheitern, wenn ICMP komplett blockiert ist und andere Paketarten groß werden (z. B. ICMP, UDP, Fragment-Header in IPv6).

• UDP/QUIC: MSS Clamping greift nicht
• ICMP blockiert: Traceroute/Diagnose schwierig, MTU bleibt unklar
• Tunnel-Overhead variiert: ESP/AH, AES-GCM, Zusatzheader

PMTUD in MPLS/VPN: Label Stack und Tunnel-Overhead berücksichtigen

In MPLS L3VPN wächst der Paketkopf durch Labels. Wenn im Core die MPLS-MTU nicht größer als 1500 ist, droppen große Pakete. Bei SR-MPLS mit mehreren SIDs kann das noch stärker werden. Hier hilft entweder eine größere Core-MTU oder MSS Clamping am Edge.

• MPLS: +4 Byte pro Label
• L3VPN typisch: +8 Byte
• SR Policies: potenziell deutlich mehr

Checks

show interfaces | include MTU
show mpls forwarding-table
ping <dst> df-bit size 1472 repeat 5

Systematischer Workflow: PMTUD-Probleme sauber isolieren

Der schnellste Weg ist: erst Path MTU testen, dann ICMP-Filtering prüfen, dann MSS Clamping setzen (an der richtigen Stelle), und danach mit realen Flows verifizieren. Wichtig: MSS Clamping muss auf dem Interface sitzen, wo der Traffic in den „kleineren“ Pfad eintritt.

• 1) DF-Ping (IPv4) / große Tests (IPv6) → Path MTU abschätzen
• 2) ICMP-Policy prüfen (Router/Firewall)
• 3) MSS Clamping am Edge setzen
• 4) Re-Test: TLS/HTTP/Downloads, nicht nur Ping

Copy & Paste Command Pack

show interfaces | include MTU|drops|error
ping <dst-ip> df-bit size 1472 repeat 5
ping <dst-ip> df-bit size 1464 repeat 5
traceroute <dst-ip>
show running-config interface <wan-if> | include adjust-mss
show platform hardware qfp active statistics drop

Best Practices: PMTUD dauerhaft stabil halten

Langfristig ist die beste Lösung: MTU konsistent designen und ICMP korrekt erlauben. MSS Clamping ist ein sehr guter pragmatischer Fix, aber kein Ersatz für sauberes MTU- und Security-Design.

• MTU-Plan: WAN/Backbone MTU >= 1500 + Overhead
• ICMP Allow-Lists statt pauschalem Block
• MSS Clamping gezielt am WAN-Edge
• Monitoring: Drops, PMTUD-relevante ICMP Events, Ticket-Korrelation

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.