MTU End-to-End ist im Telco- und Provider-Umfeld ein wiederkehrender „unsichtbarer“ Erfolgsfaktor: Wenn die Maximum Transmission Unit entlang eines Pfads nicht konsistent ist, entstehen Fehlerbilder, die in der Praxis zu den teuersten gehören. Verbindungen funktionieren scheinbar, aber nur „manchmal“. Große Transfers brechen ab, VPNs sind instabil, EVPN/DCI zeigt sporadische Drops, SRv6-Policies wirken plötzlich „buggy“, oder ein Failover löst unerklärlichen Paketverlust aus. Die Ursache ist häufig nicht ein einzelnes Gerät, sondern ein MTU-Mismatch über mehrere Domänen hinweg – verstärkt durch Overlays, Encapsulation und Jumbo Frames. Besonders kritisch wird es, wenn ICMP-Meldungen für Path MTU Discovery (PMTUD) gefiltert werden: Dann entstehen Blackholes, bei denen Pakete zu groß sind und still verworfen werden, ohne dass Sender ihre Paketgröße anpassen können. Ein professionelles MTU-Design ist deshalb kein Randthema, sondern ein Architektur- und Betriebsstandard: klare MTU-Profile pro Layer, saubere Overhead-Budgets, Validierung auf Normal- und Failoverpfaden sowie konkrete Blackhole-Prevention-Mechanismen. Dieser Artikel zeigt, wie Sie MTU end-to-end planen, Jumbo Frames sinnvoll einsetzen, Overlays sicher integrieren und Blackholes systematisch verhindern.
MTU-Grundlagen: Was genau ist „End-to-End“?
Die MTU ist die maximale Paketgröße, die ein Link oder eine Schnittstelle ohne Fragmentierung oder Drop transportieren kann. „End-to-End“ bedeutet: Die effektive MTU eines Pfads ist immer die kleinste MTU aller beteiligten Segmente (der sogenannte Bottleneck). Sobald ein Paket größer als die Bottleneck-MTU ist, gibt es zwei Möglichkeiten: Fragmentierung (wenn erlaubt) oder Drop. Im Provider-Betrieb ist Drop häufig der Standard – und genau hier entstehen Blackholes, wenn die Gegenstelle nicht über die zu kleine MTU informiert wird.
- Link-MTU: MTU auf der physischen/Layer-2-Schnittstelle (z. B. Ethernet MTU).
- IP-MTU: MTU für IP-Pakete; relevant für Router, Tunnels und PMTUD.
- Service-MTU: „Kunden-MTU“ bei L2VPN/EVPN/E-Line, die der Provider garantiert.
- Path-MTU: die kleinste MTU entlang des gesamten Pfads (maßgeblich für End-to-End).
Warum MTU-Probleme so schwer zu finden sind
Viele Anwendungen senden zunächst kleine Pakete (DNS, Handshakes, kurze HTTP-Requests). Erst bei größeren Payloads (Downloads, Replikation, bestimmte TLS-Records, Tunnels) wird die MTU relevant. Das führt zu dem typischen Symptom: „Ping geht, aber die Anwendung nicht“ oder „kleine Transfers gehen, große brechen ab“.
Jumbo Frames: Nutzen, Risiken und realistische Einsatzmuster
Jumbo Frames (typisch > 1500 Bytes, häufig ~9000 Bytes im Ethernet-Umfeld) werden eingesetzt, um Protokoll-Overhead zu reduzieren und Effizienz bei großen Transfers zu erhöhen. In Data-Centern und DCI-Szenarien können Jumbo Frames Performance verbessern, insbesondere bei Storage, Replikation oder großen East-West-Workloads. Im Telco-Backbone sind Jumbo Frames dann sinnvoll, wenn sie konsequent end-to-end umgesetzt werden können. Genau hier liegt das Risiko: Ein einzelner Link oder Provider-Übergang mit kleiner MTU zerstört den Nutzen und erzeugt schwer erkennbare Drops.
- Vorteile: weniger Header-Overhead, weniger Interrupts/CPU-Last auf Hosts, höhere Effizienz bei großen Payloads.
- Typische Use Cases: DCI, Storage, Cloud-Backbones, Service-Chains mit Encapsulation, SRv6-Overheadpuffer.
- Risiken: inkonsistente MTU-Profile, Blackholes bei PMTUD-Problemen, Mischbetrieb mit 1500.
- Betrieb: höhere Anforderungen an Tests, Telemetry und dokumentierte MTU-Standards.
Jumbo Frames sind ein Netzstandard oder gar nichts
Im Provider-Umfeld funktionieren Jumbo Frames zuverlässig nur dann, wenn sie als Standard über alle relevanten Domänen hinweg durchgesetzt werden: Core, Metro, DCI, Border, ggf. Peering-Übergänge. „Jumbo nur im DC“ kann funktionieren, erfordert dann aber klare MTU-Grenzen und saubere Übergänge zwischen Jumbo- und 1500-Welt.
Overlays und Encapsulation: Warum MTU-Budgets heute Pflicht sind
Moderne Telco-Netze nutzen Overlays: EVPN, VXLAN-artige Kapselungen, MPLS/SR-Labelstacks, SRv6 mit SRH, GRE/IPsec oder Service-Chaining. Jede Encapsulation fügt Header hinzu und reduziert die effektive Nutzdaten-MTU. Wenn dieses Overhead-Budget nicht eingeplant wird, entsteht genau der Klassiker: Der Underlay-Link kann 1500, aber das Overlay braucht 1500 Nutzdaten plus Encapsulation – Ergebnis: Drops oder Fragmentierung.
- MPLS/SR: Labelstacks erhöhen Overhead; bei mehreren Labels kann das relevant werden.
- EVPN/Overlay: Encapsulation reduziert Nutzdaten-MTU; DCI/Spine-Leaf besonders betroffen.
- SRv6: SRH kann signifikanten Overhead erzeugen, besonders bei langen Segmentlisten.
- IPsec/GRE: Security- und Tunnelheader reduzieren effektive MTU deutlich.
Ein praktisches MTU-Budget-Denken
Statt „wir nehmen 9000“ sollte ein Design sagen: „Wir garantieren X Byte Nutzdaten für Serviceklasse Y, und der Underlay-MTU-Wert ist so gewählt, dass Encapsulation-Overhead Z Byte immer passt.“ Vereinfacht:
Das Overhead-Budget muss für Normal- und Failoverpfade gelten, nicht nur für den „besten“ Pfad.
MTU-Profile als Blueprint: Core, Metro, Access, DC, DCI
Ein robustes End-to-End MTU-Design arbeitet mit wenigen, klar definierten Profilen statt mit individuellen MTU-Werten je Segment. Diese Profile sind Teil der Netzarchitektur: Sie definieren, welche MTU in welcher Domäne gilt, welche Service-MTU Kunden bekommen und wie Übergänge (z. B. DC zu WAN) gestaltet sind. Der Schlüssel ist Konsistenz: Je weniger Varianten, desto weniger Blackhole-Risiko.
- Backbone-Profil: Einheitliche Underlay-MTU im Core, mit Reserve für Encapsulation und zukünftige Features.
- Metro-Profil: Konsistente MTU bis zur Service-Edge, keine „kleinen Inseln“.
- Access-Profil: Klarer Service-Handover (z. B. 1500 oder definierte höhere MTU) und dokumentierte Grenzen.
- DC/DCI-Profil: Jumbo-fähig, mit festen Regeln für Overlays und Übergänge ins WAN.
- Border/Peering-Profil: Explizite MTU-Grenzen zu externen Partnern, da dort selten Jumbo garantiert ist.
Wenige Profile sind ein OPEX-Hebel
MTU-Probleme sind teuer, weil sie schwer zu reproduzieren sind. Wenn Sie statt zehn Varianten nur zwei oder drei Profile haben, werden Tests und Troubleshooting deutlich einfacher – und Automatisierung wird realistischer.
Blackhole Prevention: PMTUD, ICMP und realistische Schutzmaßnahmen
Blackholes entstehen typischerweise, wenn ein Gerät Pakete verwirft, die größer als seine MTU sind, und der Sender keine brauchbare Rückmeldung bekommt. Das passiert besonders häufig, wenn ICMP-Meldungen (z. B. „Fragmentation Needed“ bzw. „Packet Too Big“) gefiltert werden. In Provider-Umgebungen ist ICMP oft restriktiv behandelt – manchmal zu restriktiv. Blackhole Prevention bedeutet: PMTUD muss funktionieren oder es muss eine alternative Strategie existieren, die Drops verhindert.
- PMTUD ermöglichen: ICMP-Meldungen, die für MTU nötig sind, müssen kontrolliert erlaubt sein.
- PLPMTUD berücksichtigen: Wo vorhanden, kann Packetization Layer PMTUD helfen, ist aber nicht überall verlässlich.
- Konservative MSS: TCP MSS Clamping kann in bestimmten Übergängen Blackholes reduzieren, ist aber ein Workaround.
- MTU-Standards: Der beste Blackhole-Schutz ist ein konsistenter End-to-End MTU-Standard.
ICMP ist nicht „böse“, sondern ein Steuerungsinstrument
In Carrier-Designs ist es sinnvoll, ICMP kontrolliert zu filtern – aber nicht blind zu blockieren. Für MTU-Funktionalität müssen bestimmte ICMP-Typen/Codepfade erlaubt und überwacht werden. Ohne diese kontrollierte Offenheit wird PMTUD unzuverlässig, und Blackholes werden wahrscheinlicher.
Failover als MTU-Falle: Warum Ersatzpfade oft die wahre Ursache sind
Viele MTU-Probleme treten nicht im Normalbetrieb auf, sondern erst im Failover: Traffic nimmt einen anderen Pfad, der durch einen Provider-Übergang, eine andere Trasse oder ein anderes Transportmedium führt – und plötzlich ist die MTU kleiner. Das Ergebnis sind Drops, die wie „Konvergenzprobleme“ wirken, tatsächlich aber reine MTU-Mismatches sind. Deshalb ist es entscheidend, MTU nicht nur „auf dem Hauptpfad“ zu verifizieren, sondern auf allen relevanten Ersatzpfaden.
- Backup-Links prüfen: Haben Ersatzpfade die gleiche MTU wie der Normalpfad?
- Cross-Domain Pfade: DCI/WAN-Übergänge sind besonders kritisch.
- FRR/TI-LFA Effekte: Schnelle Umschaltung kann schnell in einen MTU-limitierten Pfad führen.
- Maintenance-Playbooks: Drain-Prozesse sollten MTU-Checks einschließen.
Designregel: MTU muss N-1-fähig sein
Wenn Sie N-1 Resilienz versprechen, muss die MTU auch im N-1-Szenario funktionieren – sonst ist die Resilienz nur „online Degradation“.
MTU und Services: L2VPN, EVPN, L3VPN, SRv6 und DCI sauber abbilden
In Provider-Netzen hängt MTU stark vom Service ab. Ein L2-Service (E-Line/E-LAN/EVPN) hat eine andere MTU-Logik als ein L3VPN oder ein Internet-Service. Ein SRv6-TE-Pfad hat andere Overhead-Anforderungen als ein reines IP-Underlay. Deshalb sollten MTU-Werte als Bestandteil von Service-Blueprints definiert werden: Welche Kunden-MTU wird garantiert, wie viel Overhead ist eingeplant, und welche Validierung gehört zur Abnahme?
- L2VPN/EVPN: Service-MTU muss VLAN/Tagging und Overlay-Overhead berücksichtigen.
- L3VPN: IP-MTU und ggf. MSS-Clamping an definierten Übergängen; klare Handover-Standards.
- SRv6: SRH-Overhead kann groß sein; Underlay-MTU muss Reserve enthalten.
- DCI: Jumbo-Profile sind häufig sinnvoll, aber Übergänge ins WAN müssen klar begrenzt sein.
MTU ist ein Produktmerkmal
Für viele Kunden ist MTU nicht nur „technisch“, sondern funktional: VPNs, Cloud-Verbindungen, Storage-Replikation und bestimmte Anwendungen hängen davon ab. Ein Provider-Blueprint sollte MTU daher klar dokumentieren und als messbares SLA-Element behandeln.
Operationalisierung: Tests, Telemetry und Guardrails
Ein End-to-End MTU-Design ist nur dann robust, wenn es operationalisiert ist. Das heißt: standardisierte Tests bei Inbetriebnahme, regelmäßige Regressionstests nach Changes, Telemetry für Drops/Fragmentierung und klare Guardrails, die verhindern, dass einzelne Links „aus der Reihe tanzen“.
- Abnahmetests: MTU-Tests pro Service und pro Pfadklasse (Normal/Failover), inklusive Overhead.
- Telemetry: Interface-Drops, MTU-bezogene Error-Counter, Fragmentierungsindikatoren, ICMP-Events.
- Change-Governance: Optikwechsel, Provider-Übergänge und DCI-Änderungen als MTU-Risiko behandeln.
- Automatisierte Checks: Pre-Checks vor Rollouts, die MTU-Konsistenz validieren.
Evidence-by-Design: MTU-Probleme prophylaktisch verhindern
Wenn Sie MTU-Standards versionieren, Tests protokollieren und Telemetry historisieren, wird MTU nicht mehr zur „mystischen“ Fehlerquelle. Stattdessen wird sie zu einem kontrollierten, auditierbaren Architekturparameter.
Praktische Leitlinien für MTU End-to-End in Telco-Netzen
- Wenige MTU-Profile: Core/Metro/DC als standardisierte Profile, statt individueller Werte je Link.
- Overhead budgetieren: Underlay-MTU so wählen, dass Overlay-/Encapsulation-Overhead sicher passt.
- PMTUD sicherstellen: ICMP für „Packet Too Big“ kontrolliert erlauben und überwachen.
- Failover testen: MTU auf Ersatzpfaden verifizieren, nicht nur auf dem Hauptpfad.
- Jumbo gezielt: Jumbo Frames dort, wo sie end-to-end garantiert sind; Übergänge zur 1500-Welt klar definieren.
- Service-Blueprints nutzen: MTU als Bestandteil von L2VPN/L3VPN/EVPN/SRv6/DCI-Produkten dokumentieren.
- Telemetry verpflichtend: Drops, Fragmentierungshinweise, ICMP-Events, Member-Link-Sicht bei Bundles.
- Guardrails einbauen: Pre-Checks, Change-Policies und klare Rollback-Kriterien bei MTU-relevanten Änderungen.
