MTU und Fragmentierung: Cisco Einstellungen richtig wählen

Ob ein Netzwerk „einfach funktioniert“ oder regelmäßig mit schwer erklärbaren Fehlern kämpft, entscheidet sich oft an Details, die im Alltag unterschätzt werden. Eines dieser Details ist die Kombination aus MTU und Fragmentierung. MTU (Maximum Transmission Unit) bestimmt, wie groß ein Layer-3-Paket auf einem Link maximal sein darf, ohne zerlegt zu werden. Wenn MTU-Werte im Pfad nicht zusammenpassen, entstehen typische Symptome: Webseiten laden nur teilweise, VPN-Verbindungen sind instabil, Dateiübertragungen brechen ab, VoIP/Video zeigt Aussetzer oder bestimmte Anwendungen funktionieren ausschließlich über einzelne Ports. Besonders in Cisco-Umgebungen ist es wichtig, MTU und Fragmentierung bewusst zu planen und die Cisco Einstellungen richtig wählen zu können, weil Switches, Router, Tunnel-Interfaces und Trunks teilweise unterschiedliche MTU-Mechanismen nutzen. Dazu kommt: IPv4 kann fragmentieren (wenn erlaubt), IPv6 fragmentiert im Router nicht mehr, und moderne Pfadmechanismen wie PMTUD (Path MTU Discovery) hängen von ICMP ab, das in vielen Netzen fälschlicherweise „zu hart“ geblockt wird. Dieser Leitfaden erklärt die Zusammenhänge praxisnah, zeigt typische Cisco-Befehle zur Überprüfung und Anpassung und hilft Ihnen, MTU-Probleme strukturiert zu beheben – ohne Trial-and-Error und ohne riskante Schnellschüsse.

MTU, MSS und Overhead: Begriffe sauber trennen

In Diskussionen über „MTU-Probleme“ werden oft mehrere Begriffe vermischt. Für eine stabile Konfiguration müssen Sie sie unterscheiden:

• MTU: Maximale Größe eines IP-Pakets (Layer 3) auf einem Link, typischerweise 1500 Bytes bei Ethernet.
• L2-Frame-Größe: Ethernet-Frame enthält zusätzlich L2-Header und Trailer (z. B. 14 Byte Ethernet-Header + 4 Byte FCS; VLAN-Tags kommen hinzu). Deshalb ist „Jumbo“ nicht nur IP, sondern auch L2 relevant.
• MSS (TCP Maximum Segment Size): Maximale TCP-Nutzlast pro Segment. MSS ist typischerweise MTU minus IP-Header minus TCP-Header. Bei Ethernet MTU 1500 ist MSS oft 1460 (1500 − 20 − 20) für IPv4 ohne Optionen.
• Overhead durch Encapsulation: VLAN (802.1Q), QinQ, GRE, IPsec, VXLAN, PPPoE und andere Kapselungen reduzieren die effektive Nutzlast.

Praxisregel: Viele Probleme sind eigentlich MSS-Probleme, ausgelöst durch eine zu kleine effektive MTU (z. B. durch VPN-Overhead). Das lässt sich oft eleganter über MSS-Clamping lösen als durch wildes MTU-Anpassen.

Warum MTU-Mismatches so tückisch sind

Ein klassischer Fehler ist ein „Hidden MTU Black Hole“: Kleine Pakete gehen durch, große Pakete nicht. Dann wirken Ping und DNS „okay“, aber HTTPS, VPN oder große Downloads brechen ab. Typische Ursachen:

• Ein Link im Pfad hat eine kleinere MTU als erwartet (z. B. Provider, Tunnel, Firewall-Policy).
• ICMP wird blockiert, sodass PMTUD nicht arbeiten kann (insbesondere ICMP Fragmentation Needed).
• DF-Bit (Don’t Fragment) ist gesetzt, und der Router darf nicht fragmentieren, sendet aber die nötigen ICMP-Hinweise nicht erfolgreich zurück.
• Bei IPv6 kann ein Router nicht fragmentieren, und fehlende ICMPv6 Packet Too Big-Meldungen verhindern Anpassung.

Die Folge: Anwendungen warten, retransmittieren, timeouten – und das Problem wirkt wie „Random Netzwerk“, obwohl es deterministisch ist.

Fragmentierung bei IPv4: Was passiert technisch?

Bei IPv4 kann ein Router ein Paket fragmentieren, wenn es größer ist als die MTU des nächsten Links – sofern das DF-Bit nicht gesetzt ist. Das Paket wird in mehrere Fragmente zerlegt, die jeweils eigene IP-Header tragen. Der Empfänger setzt die Fragmente wieder zusammen. Klingt praktisch, hat aber Nachteile:

• Mehr Overhead: Jedes Fragment hat einen IP-Header, das kostet Bandbreite und CPU.
• Höhere Fehleranfälligkeit: Geht ein Fragment verloren, muss das gesamte Originalpaket erneut übertragen werden.
• Security- und Performance-Aspekte: Fragmentierung kann Firewalls und IDS/IPS stärker belasten und ist in vielen Netzen unerwünscht.

In modernen Netzen ist deshalb das Ziel meist: Fragmentierung vermeiden, indem MTU konsistent geplant wird und PMTUD funktioniert.

IPv6: Warum Router nicht fragmentieren und ICMPv6 wichtig ist

Bei IPv6 dürfen Router Pakete nicht fragmentieren. Fragmentierung ist nur durch den Sender möglich (via Fragment Extension Header), und dafür muss der Sender die Path MTU kennen. Das macht PMTUD bei IPv6 noch wichtiger. Wenn ICMPv6 Packet Too Big blockiert wird, entstehen sehr ähnliche „Black Hole“-Symptome – oft schwerer zu diagnostizieren, weil IPv6-Fehlerbilder weniger „klassisch“ sind.

Best Practice: ICMPv6 nicht pauschal blocken. ICMPv6 ist funktionaler Bestandteil von IPv6 (Neighbor Discovery, PMTUD, Fehlermeldungen). Als Hintergrund ist der Anchor-Text RFC 8200 (IPv6) hilfreich.

PMTUD: Path MTU Discovery und die Rolle von ICMP

PMTUD sorgt dafür, dass Sender die maximale Paketgröße eines Pfads lernen. Bei IPv4 wird dafür häufig das DF-Bit gesetzt. Wenn ein Router ein zu großes Paket nicht weiterleiten kann, sendet er ICMP „Fragmentation Needed“ zurück (inklusive MTU-Hinweis, wenn verfügbar). Der Sender reduziert dann die Paketgröße. Wenn diese ICMP-Meldungen unterwegs geblockt werden, bleibt der Sender bei zu großen Paketen – das ist der typische MTU Black Hole.

• IPv4: ICMP Fragmentation Needed muss durchgelassen werden, sonst bricht PMTUD.
• IPv6: ICMPv6 Packet Too Big ist essenziell.

Ein praxisnaher Überblick zu PMTUD findet sich über den Anchor-Text RFC 1191 (Path MTU Discovery für IPv4).

MTU-Planung: 1500, Jumbo Frames und typische Overheads

Die Standard-Ethernet-MTU ist 1500. Das funktioniert in den meisten Campus- und Enterprise-Netzen zuverlässig. Jumbo Frames (z. B. 9000) können Vorteile bringen (weniger CPU, bessere Effizienz) – aber nur, wenn sie end-to-end konsequent umgesetzt sind.

• Standard (1500): Einfach, kompatibel, wenig Risiko.
• Jumbo (z. B. 9000): Sinnvoll in Storage-/DC-Szenarien (iSCSI/NFS), aber nur, wenn alle beteiligten Switches, NICs, Firewalls und L3-Hopps es unterstützen.
• Tunnel-/VPN-Overhead: IPsec, GRE oder PPPoE reduzieren effektive MTU. Häufig ist 1400–1472 ein relevanter Bereich, abhängig vom Overhead.

Praxisregel: In Campus-Netzen ist 1500 meist der richtige Standard. Wenn VPNs ins Spiel kommen, lösen Sie Probleme oft über MSS-Clamping oder Tunnel-MTU, nicht über globales „MTU überall ändern“.

Cisco Grundlagen: Wo stellt man MTU überhaupt ein?

Bei Cisco-Geräten gibt es mehrere Ebenen, auf denen MTU relevant ist. Je Plattform (IOS, IOS XE, NX-OS) unterscheidet sich die genaue Syntax. Typische Ebenen:

• Interface MTU (L3): MTU für IP auf einem Interface (Router-Interface, SVI, Tunnel).
• Switchport / System MTU (L2): MTU für Ethernet Frames bzw. Jumbo-Frame-Fähigkeit im Switching.
• Port-Channel MTU: EtherChannel muss konsistente MTU auf Member-Ports haben.
• Tunnel MTU: GRE/IPsec/VXLAN-Tunnel haben eigene effektive MTU-Überlegungen.

Für genaue, modellabhängige Befehle ist der Anchor-Text Cisco IOS Command Reference die beste Referenz.

MTU auf Cisco Router-Interfaces prüfen und setzen

Der erste Schritt ist fast immer: Ist die MTU so, wie Sie glauben? Prüfen Sie das pro Interface.

MTU anzeigen

show interfaces GigabitEthernet0/0

In der Ausgabe finden Sie typischerweise eine Zeile wie „MTU 1500 bytes“. Prüfen Sie dabei auch, ob es Hinweise auf Encapsulation oder Tunnel gibt.

MTU setzen (L3 Interface)

Je nach Plattform können Sie die MTU direkt am Interface setzen:

configure terminal
interface GigabitEthernet0/0
mtu 1500
end

Wichtig: MTU-Änderungen können Traffic beeinflussen. Setzen Sie MTU nicht „auf Verdacht“ hoch oder runter, sondern begründet. Bei manchen Plattformen erfordern MTU-Änderungen einen Interface-Reset oder sogar Reload (insbesondere bei System-MTU im Switching).

System MTU und Jumbo Frames auf Cisco Switches

Bei Catalyst-Switches ist Jumbo oft an eine globale oder systemweite MTU gekoppelt. Der genaue Mechanismus ist modellabhängig. Typisch ist, dass Sie eine „system mtu“-Konfiguration setzen und danach einen Reload benötigen, damit die Hardware-Pipelines die neue MTU übernehmen.

configure terminal
system mtu jumbo 9000
end

Ob dieser Befehl auf Ihrem Modell existiert und ob ein Reload nötig ist, hängt von der Plattform ab. Prüfen Sie vorab die Dokumentation Ihrer Switch-Serie. Ein hilfreicher Einstieg ist der Anchor-Text Cisco Catalyst Dokumentation.

SVI-MTU und Multilayer Switching: Besonderheiten

Bei L3-Switches (Multilayer Switching) können SVIs (interface VlanX) eine MTU haben, die mit der Switching-MTU zusammenspielt. Wenn Sie Jumbo Frames nutzen möchten, müssen Sie sicherstellen, dass:

• die systemweite Switching-MTU die Framegröße tragen kann,
• die L3-MTU auf den SVIs nicht kleiner ist als gewünscht,
• Trunks und Port-Channels konsistent sind.

Wenn ein SVI zwar konfiguriert ist, aber Pakete über 1500 nicht sauber laufen, liegt es häufig an einem Link im Pfad (Trunk/Port-Channel) oder an einem Device, das Jumbo nicht unterstützt.

Tunnel und VPN: Warum MTU hier besonders häufig Probleme macht

Viele MTU-Probleme treten auf, sobald Traffic gekapselt wird. Beispiele:

• GRE: zusätzlicher Overhead durch GRE-Header und ggf. Outer IP Header.
• IPsec: zusätzlicher Overhead durch ESP/AH und ggf. NAT-T.
• PPPoE: reduziert effektive MTU (klassisch 1492 statt 1500), relevant bei DSL/Provider-Edges.

Die Folge: Ein Client sendet 1500-Byte-Pakete, der Tunnel kann aber nur 1400–1472 effektiv transportieren. Wenn PMTUD nicht sauber arbeitet, entstehen Black Holes.

MSS Clamping: Oft der schnellste und sauberste Fix

Bei TCP-basierten Anwendungen lässt sich MTU-Problematik häufig elegant über MSS Clamping lösen. Dabei wird die TCP MSS in SYN-Paketen angepasst, sodass Endgeräte von vornherein kleinere Segmente verwenden. Das verhindert Fragmentierung und reduziert die Abhängigkeit von PMTUD (ohne ICMP völlig ignorieren zu dürfen).

Beispiel: TCP MSS auf einem Interface setzen

configure terminal
interface GigabitEthernet0/0
ip tcp adjust-mss 1360
end

Die richtige MSS hängt von Ihrer effektiven MTU ab. Als grobe Orientierung gilt:

• IPv4: $\mathrm{MSS}=\mathrm{MTU}-20-20$
• IPv6: $\mathrm{MSS}=\mathrm{MTU}-40-20$

Beispiel: Bei einer effektiven MTU von 1400 wäre MSS (IPv4) etwa 1360.

ICMP in Firewalls/ACLs: Was Sie erlauben sollten

Ein sehr häufiger Fehler ist, ICMP „aus Sicherheitsgründen“ pauschal zu blocken. Dadurch brechen wichtige Mechanismen (PMTUD, Fehlermeldungen, Diagnose). Eine sinnvolle Praxis ist, ICMP gezielt zu erlauben, mindestens für relevante Typen:

• IPv4: ICMP Destination Unreachable (insbesondere Fragmentation Needed), Time Exceeded (Traceroute), Echo/Echo Reply (Ping) nach Policy
• IPv6: ICMPv6 Packet Too Big, Neighbor Discovery relevante Typen, Time Exceeded

Wenn Sie ACLs für Betrieb und Diagnose strukturieren möchten, hilft als Hintergrund der Anchor-Text RFC 1191 (PMTUD) und für IPv6 der Anchor-Text RFC 8200.

Diagnose in der Praxis: MTU-Probleme sauber nachweisen

Bei MTU-Problemen ist das Ziel: die maximale Paketgröße im Pfad herausfinden und den „kleinsten“ Link identifizieren. Typische Schritte in Cisco-Umgebungen:

• Interface-MTU prüfen (Switch/Router, Tunnel, Port-Channel)
• Ping mit DF-Bit (IPv4) und steigender Größe testen
• Pfad abschnittsweise testen (z. B. zwischen Router und Firewall, Firewall und Provider)
• Logs/Counter auf Drops und Fragmentierung prüfen

Ping mit DF-Bit und Paketgröße (Cisco IOS, typisch)

ping 203.0.113.1 size 1472 df-bit repeat 5

Warum 1472? Bei IPv4 entspricht 1472 Bytes ICMP Payload ungefähr einer IP-Gesamtgröße von 1500 (1472 + 20 IP Header + 8 ICMP Header). Wenn 1472 mit DF klappt, ist 1500 auf dem Pfad sehr wahrscheinlich ok. Wenn es scheitert, reduzieren Sie schrittweise (z. B. 1464, 1452, 1400), bis es stabil ist.

Interface-Statistiken und Fragmentierung prüfen

show interfaces GigabitEthernet0/0
show ip traffic

Je nach Plattform sehen Sie Hinweise auf Fragmentierung, Drops oder ICMP-Meldungen.

Typische MTU-Fehlerbilder und ihre Ursachen

• Webseiten laden teilweise, HTTPS hängt: PMTUD blockiert (ICMP fehlt), MSS zu hoch bei Tunnel.
• VPN steht, aber große Transfers brechen ab: Tunnel-Overhead reduziert effektive MTU; MSS fehlt oder falsch.
• Nur bestimmte Ziele betroffen: Unterschiedliche Pfade (Provider/Peering) mit anderer MTU oder ICMP-Filterung.
• VoIP/Video stottert bei hoher Last: Fragmentierung erhöht Verlustanfälligkeit; QoS und MTU/MSS kombinieren sich ungünstig.
• Jumbo Frames „gehen manchmal“: Nicht end-to-end umgesetzt; ein Switch/Firewall/Serverport bleibt bei 1500.

Best Practices: Cisco MTU-Einstellungen richtig wählen

• Standardisieren: Im Campus möglichst überall 1500, solange kein klarer Jumbo-Use-Case besteht.
• Jumbo nur end-to-end: Wenn Jumbo, dann konsequent über alle beteiligten Geräte, inklusive Server-NICs, Firewalls und Port-Channels.
• Tunnel separat planen: Für GRE/IPsec/PPPoE effektive MTU bestimmen und ggf. MSS-Clamping einsetzen.
• ICMP gezielt erlauben: PMTUD muss funktionieren, sonst entstehen Black Holes.
• Port-Channel Konsistenz: Member-Ports identisch konfigurieren (MTU, Speed, Trunk-Parameter), sonst instabile Bundles.
• Dokumentation: MTU-Policy pro Zone (Campus, DC, WAN, VPN) dokumentieren, inklusive Overheads.
• Monitoring: Drops, Fragmentierung, ICMP-Errors und Tunnel-Health überwachen (Syslog, SNMP, NetFlow).

Outbound-Links zur Vertiefung

• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8200: IPv6
• Cisco IOS Command Reference

Praxis-Checkliste: MTU und Fragmentierung sauber beherrschen

• Ist die MTU-Policy im Netz klar (Standard 1500 vs. Jumbo in definierten Zonen)?
• Wurde bei Tunneln/VPNs der Overhead berücksichtigt (effektive MTU) und ist MSS-Clamping geplant?
• Sind ICMP/ICMPv6 so freigegeben, dass PMTUD zuverlässig funktioniert?
• Ist MTU auf Interfaces, SVIs und Port-Channels konsistent und wurde sie verifiziert (show interfaces)?
• Gibt es einen reproduzierbaren Ping-DF-Test, um die Path MTU nachzuweisen?
• Wurden typische Black-Hole-Symptome (teilweise Webseiten, große Transfers) mit MTU/MSS in Verbindung gebracht und systematisch getestet?
• Sind Monitoring und Logs so eingerichtet, dass Drops/Fragmentierung auffallen (Syslog, SNMP, NetFlow)?

copy running-config startup-config

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.