Cisco-Router-Performance-Tuning: MTU, TCP MSS und Pfadoptimierung

Performance-Tuning auf Cisco-Routern scheitert in der Praxis selten an „zu wenig Bandbreite“, sondern an unsichtbaren Effekten entlang des Pfads: falsche MTU, Fragmentierung, geblockte ICMP-Fragmentation-Needed-Meldungen (PMTUD bricht), und ein TCP MSS, der nicht zum effektiven Overhead passt (z. B. bei VPN). Das Ergebnis sind Symptome wie „SaaS langsam“, „VPN funktioniert, aber Downloads brechen“, „Teams/Zoom ruckelt“ oder „nur bestimmte Seiten laden nicht“. Dieses Tutorial zeigt, wie Sie MTU und TCP MSS korrekt planen, Path-Probleme nachweisen und den Traffic-Pfad so optimieren, dass Latenz und Packet Loss sinken.

Grundlagen: MTU, MSS und warum PMTUD kritisch ist

MTU ist die maximale Frame-/Paketgröße auf einem Link. MSS ist die maximale TCP-Payload pro Segment. TCP MSS muss zur kleinsten MTU im Pfad passen, sonst kommt es zu Fragmentierung oder Drops. Path MTU Discovery (PMTUD) funktioniert nur, wenn ICMP-Meldungen nicht blockiert werden.

• MTU: maximale IP-Paketgröße pro Link (ohne L2-Details)
• MSS: TCP-Payload-Größe (abhängig von IP/TCP Headern)
• PMTUD: verhindert Fragmentierung durch automatische MTU-Anpassung
• Risiko: ICMP „Fragmentation needed“ blockiert → Blackholes bei großen Paketen

Rechenregel: MSS aus MTU ableiten (IPv4/IPv6)

Für TCP gilt: MSS ist die MTU minus Header. Für IPv4 sind es typischerweise 20 Byte IP + 20 Byte TCP. Für IPv6 ist der IP-Header 40 Byte.

$\mathrm{MSS}=\mathrm{MTU}–\mathrm{IP\_Header}–\mathrm{TCP\_Header}$

Orientierungswerte

• IPv4: $\mathrm{MSS}=\mathrm{MTU}–40$
• IPv6: $\mathrm{MSS}=\mathrm{MTU}–60$

Typische Enterprise-Szenarien: Wo MTU/MSS Probleme verursachen

MTU-Probleme treten besonders häufig auf, wenn zusätzliche Header dazukommen: VPN (IPsec/GRE), PPPoE, Provider-VLAN-Tags oder Tunnel-Overlays. In diesen Fällen ist die effektive MTU kleiner als „1500“.

• IPsec VPN: Overhead reduziert effektive MTU → Fragmentierung möglich
• GRE/IPsec oder DMVPN: zusätzlicher Tunnel-Overhead → MSS-Clamp sinnvoll
• PPPoE: kleinere MTU auf WAN → große TCP-Segmente droppen
• Dual-ISP: unterschiedliche MTU je ISP → sporadische Probleme nach Failover

Designprinzip: Fragmentierung vermeiden, MSS gezielt clampen

In Enterprise-Setups ist das Ziel: keine Fragmentierung auf dem WAN und keine PMTUD-Blackholes. Wenn der Pfad oder Tunnel die MTU reduziert, clampen Sie TCP MSS am Router (typisch inbound am LAN, outbound Richtung Tunnel/WAN je Design).

• Primärziel: End-to-End PMTUD muss funktionieren
• Wenn PMTUD unsicher: MSS-Clamp reduziert Risiko erheblich
• Richtwert: MSS so wählen, dass es auch bei VPN-Overhead passt
• Wichtig: MSS-Clamp betrifft TCP, nicht UDP (VoIP/Video bleibt MTU-sensitiv)

Pfadvalidierung: MTU-Tests (PMTUD nachweisen)

Bevor Sie Werte ändern, messen Sie. Nutzen Sie „Don’t Fragment“ (DF) Tests, um die maximal funktionierende Paketgröße zu finden. So erkennen Sie echte Path-MTU-Engpässe.

CLI: PMTUD/MTU Test (IPv4, DF gesetzt)

ping 1.1.1.1 size 1472 df-bit repeat 5
ping 1.1.1.1 size 1464 df-bit repeat 5
ping 1.1.1.1 size 1400 df-bit repeat 5

Interpretation

• Erfolg bei 1472: MTU 1500 im Pfad wahrscheinlich (1472 + 28 Byte ICMP/IP)
• Fehlschlag bei 1472, Erfolg bei kleiner: Path-MTU kleiner als 1500
• Fehlschlag ohne ICMP-Hinweis: mögliches PMTUD-Blackhole durch ICMP-Filter

MTU auf Interfaces: Wo Sie ansetzen sollten

MTU-Probleme entstehen häufig auf WAN-/Tunnel-Interfaces. Prüfen Sie die MTU dort zuerst. In vielen Fällen ist das LAN korrekt, aber das WAN/Tunnel hat eine kleinere effektive MTU.

• WAN-Interface: Provider-MTU/PPPoE/VLAN-Tags berücksichtigen
• Tunnel-Interface: Overhead für GRE/IPsec einplanen
• Inhomogene Pfade: wenn mehrere WANs, MTU je Pfad prüfen

CLI: MTU prüfen

show interfaces GigabitEthernet0/0 | include MTU
show interfaces Tunnel0 | include MTU

TCP MSS Clamping: Praxis-Template (konzeptionell)

MSS-Clamping wird häufig über eine Policy am Interface umgesetzt, die TCP SYN-Pakete anpasst. Ziel ist ein MSS-Wert, der sicher unter der effektiven MTU liegt, insbesondere bei VPN.

CLI: MSS am Interface setzen (Beispiel)

interface GigabitEthernet0/1
 description LAN-INSIDE
 ip tcp adjust-mss 1360

Hinweis zur Wahl des MSS-Werts

• Der Wert muss zum kleinsten Pfad passen (z. B. VPN/PPPoE)
• Zu niedrig: unnötiger Overhead (mehr Pakete), Performance kann sinken
• Zu hoch: Fragmentierung/Blackholes bleiben

VPN-Spezialfall: Warum „VPN langsam“ oft MTU/MSS ist

VPN fügt Overhead hinzu und verschiebt die effektive MTU. Wenn zusätzlich ICMP blockiert ist, entstehen „stille“ Drops. Typische Symptome sind: große Downloads brechen, bestimmte Webseiten laden nicht, RDP/SSH ok, aber Filesharing nicht.

• Prüfen: PMTUD über den Tunnel (DF-Pings zu Zielen hinter dem VPN)
• Prüfen: IPsec SA up, aber Packet Counters steigen? (Traffic vs. Policy)
• Mitigation: MSS clamp, ggf. Tunnel-MTU anpassen, ICMP erlauben

CLI: VPN-Traffic Evidence

show crypto ikev2 sa
show crypto ipsec sa
ping <REMOTE_HOST> size 1360 df-bit repeat 5

ICMP-Policy: PMTUD nicht „totfiltern“

Ein häufiger Security-Fehler ist „ICMP komplett blocken“. Für PMTUD und Troubleshooting müssen bestimmte ICMP-Typen erlaubt sein. In Enterprise-Policies sollten diese Typen explizit berücksichtigt werden.

• Erforderlich: ICMP „fragmentation needed“ (IPv4) bzw. „Packet Too Big“ (IPv6)
• Diagnostik: time-exceeded (traceroute) und echo-reply (kontrolliert)
• Best Practice: ICMP selektiv erlauben, nicht pauschal öffnen

Pfadoptimierung: Wo Latenz und Loss wirklich entstehen

MTU/MSS ist nur ein Teil. Pfadoptimierung bedeutet: Congestion (Drops/Queues) reduzieren, Routing stabil halten und Asymmetrien vermeiden. Viele Performanceprobleme sind Queue Drops, nicht „Routing“.

• Congestion: Output Drops/Queue Drops → QoS/Shaping prüfen
• Layer1/2: CRC/Input Errors → Kabel/SFP/Provider-CPE
• Routing: Flaps/Loops/Blackholes → Neighbor/Policy prüfen
• Asymmetrie: Dual-ISP/Policy kann stateful Apps brechen

CLI: Pfad- und Congestion-Checks

show interfaces counters errors
show interfaces | include output drops|queue
show policy-map interface
show ip route 0.0.0.0
show ip cef summary

Post-Change-Verifikation: Wie Sie Erfolg nachweisen

Nach MTU/MSS-Änderungen müssen Sie beweisen, dass das Problem weg ist: DF-Pings funktionieren, Fehler/Drops steigen nicht, und User-Tests (Downloads/SaaS) sind stabil. Dokumentieren Sie die Baseline vor und nach dem Change.

• PMTUD: DF-Pings mit größeren Sizes erfolgreich
• Stabilität: keine neuen Drops/Errors-Spikes
• VPN: keine SA-Flaps, Traffic-Counter plausibel
• KPIs: RTT/Loss unverändert oder besser

CLI: Evidence-Set (Copy/Paste)

show interfaces GigabitEthernet0/0 | include MTU
show interfaces Tunnel0 | include MTU
ping 1.1.1.1 size 1472 df-bit repeat 5
show interfaces counters errors
show interfaces | include output drops|queue
show crypto ipsec sa
show logging | last 50

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.