MTU-Probleme sind eine der häufigsten Ursachen für „mysteriöse“ Performance-Probleme im LAN: Ping geht, aber Dateiübertragungen hängen; bestimmte Anwendungen funktionieren nur sporadisch; VoIP/Videokonferenzen frieren ein; oder nur große Downloads brechen ab. Der Grund ist meist Fragmentierung oder – noch tückischer – Path-MTU-Blackholing, wenn große Pakete im Pfad verworfen werden und ICMP-Meldungen nicht zurückkommen. Dieser Leitfaden erklärt MTU, Fragmentierung und PMTUD praxisnah und zeigt, wie du im LAN die Ursache sauber nachweist und behebst.
MTU, MSS und Fragmentierung: Begriffe sauber trennen
Damit du Performance-Probleme richtig einordnest, musst du MTU (IP-Paketgröße), MSS (TCP-Nutzdaten pro Segment) und Fragmentierung unterscheiden. Oft ist nicht „MTU zu klein“, sondern „MTU inkonsistent“.
- MTU: maximale IP-Paketgröße auf einem Link (typisch 1500, Jumbo z. B. 9000)
- MSS: maximale TCP-Nutzlast pro Segment (typisch MTU minus IP/TCP-Header)
- Fragmentierung: IPv4 kann Pakete zerlegen; das kostet Performance und ist fehleranfällig
- PMTUD: Path MTU Discovery findet die größte MTU im Pfad ohne Fragmentierung
MSS grob verstehen (ohne Overhead-Details zu verlieren)
Für IPv4 gilt im Standardfall: MSS ≈ MTU − 20 (IP) − 20 (TCP). Bei MTU 1500 ergibt sich typischerweise eine MSS von ca. 1460 Byte.
Typische Symptome: So sieht ein MTU-Problem in der Praxis aus
MTU-Fehler sind oft „größenabhängig“: kleine Pakete funktionieren, große nicht. Genau dieses Muster ist der wichtigste Hinweis.
- Ping/kleine HTTP-Requests funktionieren, große Transfers hängen
- SMB/Dateikopien brechen ab oder sind extrem langsam
- VPN-Tunnel oder Overlay-Netze funktionieren nur teilweise
- „Sporadisch“: weil Traffic mal klein, mal groß ist
Warnsignal
Wenn ein Problem nur bei „großen Paketen“ auftritt, ist MTU/Fragmentierung ein Top-Verdacht.
Warum Fragmentierung Performance kostet
Fragmentierung erhöht Overhead, belastet CPU und ist anfällig: Geht ein Fragment verloren, ist das gesamte Originalpaket unbrauchbar. Viele moderne Netzdesigns versuchen Fragmentierung aktiv zu vermeiden.
- Mehr Pakete pro Datenmenge (Overhead steigt)
- Mehr CPU/Buffer-Bedarf auf Endgeräten und Geräten im Pfad
- Verlust eines Fragments = Retransmit des ganzen Pakets (TCP)
Path-MTU-Blackholing: Der tückischste MTU-Fehler
PMTUD basiert auf ICMP-Meldungen („Fragmentation Needed“). Wenn Firewalls/ACLs ICMP blockieren, erfahren Sender nicht, dass die MTU kleiner ist. Ergebnis: große Pakete werden verworfen, Verbindung wirkt „kaputt“, aber ohne klare Fehlermeldung.
- Große Pakete werden gedroppt, kleine gehen durch
- Keine ICMP-Antwort → Sender reduziert MTU nicht → „Blackhole“
- Besonders häufig bei VPN/Overlays/Firewalls im Pfad
MTU im LAN testen: DF-Ping und Größenstufen
Der zuverlässigste Nachweis ist ein Ping mit DF-Bit (Don’t Fragment) und definierter Größe. Du erhöhst die Größe schrittweise, bis der Ping fehlschlägt. So findest du die tatsächliche Path MTU.
DF-Ping (Konzept, Syntax plattformabhängig)
ping 10.1.10.50 df-bit size 1472
ping 10.1.10.50 df-bit size 8972
Warum 1472 oft ein Startwert ist
Bei MTU 1500 bleiben nach IP/ICMP-Overhead typischerweise 1472 Byte Payload übrig. Wenn 1472 mit DF funktioniert, ist Standard-MTU im Pfad wahrscheinlich okay.
MTU-Checks auf Cisco Switches: Wo du nachsehen kannst
Die MTU-Konfiguration ist plattformabhängig: Manche Switches haben eine System-MTU, andere Interface-MTU, und L3-SVIs können eigene Werte haben. Prüfe daher zuerst, was dein Gerät überhaupt unterstützt.
MTU anzeigen (plattformabhängig)
show system mtu
show system mtu jumbo
show interfaces gigabitEthernet 1/0/48 | include MTU
show ip interface vlan 10
Trunk/Port-Channel Kontext prüfen
show interfaces trunk
show etherchannel summary
Die häufigsten LAN-Ursachen für MTU-Probleme
Im Campus entstehen MTU-Probleme meist durch inkonsistente Jumbo-Frame-Settings, durch Zwischenkomponenten mit Standard-MTU oder durch Security-Geräte, die ICMP blockieren.
- Jumbo Frames nur auf Teilen des Pfads (Server ja, Zwischen-Switch nein)
- Port-Channel: ein Member oder ein Pfadabschnitt hat andere MTU
- Firewall/Router/VPN: kleinere effektive MTU durch Encapsulation
- ICMP „Fragmentation Needed“ blockiert (PMTUD Blackhole)
Fix-Strategien: Wie du MTU-Probleme sauber löst
Es gibt zwei grundsätzliche Wege: MTU überall konsistent erhöhen (nur in kontrollierten Segmenten) oder MTU/MSS an den Übergängen so begrenzen, dass keine Fragmentierung entsteht. Im Campus ist Konsistenz wichtiger als „maximal groß“.
Fix 1: Pfad konsistent auf Standard MTU halten
- Jumbo nur in dedizierten VLANs einsetzen
- Client-/Office-VLANs bei 1500 belassen
- Zwischenkomponenten vereinheitlichen (Switches/Firewalls)
Fix 2: Jumbo end-to-end korrekt einführen (kontrolliert)
- Nur dedizierte Storage/Backup/VMotion VLANs
- Alle Switches im Pfad müssen Jumbo unterstützen
- Port-Channel Member identisch, Trunks sauber
Fix 3: PMTUD ermöglichen (ICMP nicht blind blocken)
- ICMP „Fragmentation Needed“ zulassen, mindestens im internen Pfad
- Firewall-Policies so gestalten, dass PMTUD funktioniert
Verifikation: Nach dem Fix messen und belegen
Nach der Anpassung musst du nachweisen, dass große Pakete durchgehen und dass keine Drops/Errors steigen. Nutze DF-Ping, Applikationstests und Interface-Counter.
Nachweis-Checks
show interfaces counters errors
show interfaces gigabitEthernet 1/0/48 | include drops|discard|MTU|rate
show logging | include MTU|DROP|FRAG|ICMP
Best Practices: MTU-Performance-Probleme im LAN vermeiden
MTU ist kein „Tuning-Knopf“, sondern ein End-to-End-Designparameter. Wenn du Jumbo Frames brauchst, kapsle sie in dedizierte Segmente. Wenn du Standard-MTU nutzt, verhindere Blackholing durch sinnvolle ICMP-Policies.
- Jumbo nur in dedizierten VLANs/Use-Cases, nicht campusweit
- MTU entlang des gesamten Pfads konsistent halten (inkl. Firewalls)
- PMTUD unterstützen: ICMP „Fragmentation Needed“ nicht blocken
- Bei Port-Channels: Member identisch, keine „schwache“ MTU im Bundle
- Dokumentation: MTU pro Segment, klare Rollout- und Testpläne
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.
