MTU bei QinQ und VXLAN: Warum Subnetting allein nicht reicht

Bei MTU bei QinQ und VXLAN zeigt sich im Telco- und Provider-Alltag ein wiederkehrendes Muster: Das IP-Design ist sauber, Subnetting stimmt, Routing ist korrekt – und trotzdem „funktioniert es irgendwie nicht“. Typische Symptome sind besonders tückisch: Kleine Pings gehen, große Pakete brechen ab, bestimmte Anwendungen sind langsam oder timeouten, TCP-Verbindungen wirken instabil, oder nur einzelne Services (z. B. VoIP, VPN, bestimmte Webportale) sind betroffen. In solchen Fällen ist Subnetting nicht das Problem, sondern die MTU (Maximum Transmission Unit) und damit die Frage, wie viel Nutzlast ein Frame oder Paket auf dem kompletten Pfad wirklich tragen kann. Gerade bei Technologien wie QinQ (802.1ad) und VXLAN kommt zusätzlicher Overhead hinzu: VLAN Stacking fügt einen weiteren Tag hinzu, VXLAN kapselt Ethernet in UDP/IP. Jeder zusätzliche Header reduziert die effektive Nutzlast oder erfordert eine größere Transport-MTU. Wenn diese End-to-End nicht konsistent ist – oder wenn Path MTU Discovery (PMTUD) durch Filterregeln gebrochen wird – entstehen genau die „Geisterprobleme“, die in großen Provider-Netzen Zeit und Nerven kosten. Dieser Artikel erklärt praxisnah, warum Subnetting allein nicht reicht, wie Sie MTU bei QinQ und VXLAN korrekt planen, welche Overheads realistisch sind, welche Best Practices in Telco-Topologien funktionieren und wie Sie MTU-Probleme schnell und strukturiert eingrenzen.

MTU-Grundlagen: Was bedeutet MTU in Ethernet- und IP-Netzen?

MTU ist die maximale Größe einer Daten-Einheit, die ohne Fragmentierung über eine Schnittstelle übertragen werden kann. In Ethernet-Umgebungen beziehen sich viele Diskussionen auf zwei Ebenen:

• L2 (Ethernet MTU): maximale Frame-Nutzlast (typisch 1500 Byte Payload bei „Standard Ethernet“, Jumbo z. B. 9000 Byte).
• L3 (IP MTU): maximale IP-Paketgröße, die auf dem Pfad ohne Fragmentierung transportiert wird.

Wichtig: Eine größere MTU ist nur dann nützlich, wenn sie end-to-end funktioniert. Ein einzelner Link mit 1500 Byte in einem ansonsten Jumbo-fähigen Pfad reicht, um Probleme zu erzeugen. Und genau das passiert in Telco-Netzen häufig: QinQ oder VXLAN wird eingeführt, einzelne Zwischenknoten bleiben auf Standard-MTU, und plötzlich brechen große Pakete.

Warum Subnetting allein nicht reicht: MTU ist eine Pfad-Eigenschaft, nicht eine Adress-Eigenschaft

Subnetting und CIDR lösen Adress- und Routingfragen. MTU betrifft dagegen die Paketverpackung. Selbst wenn ein Subnetz perfekt geplant ist, kann ein einzelnes zu kleines MTU-Glied im Pfad verhindern, dass Anwendungen stabil funktionieren. Subnetting kann Ihnen nicht „sagen“, ob ein Paket von 1500 Byte plus Overhead noch passt.

• Subnetting: definiert, welche IPs zusammengehören und wie geroutet wird.
• MTU: definiert, wie viel Nutzlast auf dem Pfad transportiert werden kann.
• Overhead durch Encapsulation: QinQ/VXLAN erhöhen Header-Anteile, Nutzlast schrumpft oder Transport-MTU muss wachsen.

Overhead verstehen: Was QinQ am Frame ändert

Bei QinQ wird zu einem bestehenden 802.1Q-Tag ein weiterer VLAN-Tag hinzugefügt. Das ist „nur“ ein kleiner Overhead, aber er kann ausreichen, um an einer 1500er Grenze zu scheitern, wenn irgendwo strikt gefiltert wird oder wenn weitere Encapsulations im Spiel sind.

• Single Tag (802.1Q): zusätzliches VLAN-Tag (4 Byte) im Ethernet-Frame.
• QinQ (Double Tag): zwei VLAN-Tags, also 8 Byte Tag-Overhead.

In vielen Netzen ist der praktische Effekt: Ein Kunde sendet 1500 Byte IP-MTU, der Provider kapselt und transportiert – und wenn die Transportstrecke keine zusätzlichen Bytes zulässt, entstehen Drops oder Fragmentierung an ungünstigen Stellen.

Overhead verstehen: Was VXLAN am Paket ändert

VXLAN kapselt Ethernet in UDP/IP (Overlay über Underlay). Dadurch entsteht ein deutlich größerer Overhead als bei QinQ. Für Telcos ist das entscheidend, weil VXLAN oft in PoP-Fabrics, Edge-Clouds oder DC-nahem Telco-Design eingesetzt wird. Wenn Underlay-MTU nicht angepasst ist, brechen große Frames im Overlay.

• VXLAN Encapsulation: zusätzliche Header für Outer Ethernet, Outer IP, UDP und VXLAN.
• Praktische Folge: Bei Standard 1500er Underlay-MTU muss die Overlay-Nutzlast kleiner sein, oder das Underlay muss Jumbo können.
• EVPN/VXLAN: Control Plane löst keine MTU-Probleme; sie sorgt nur für Learning/Reachability.

Faustregel für VXLAN im Betrieb

Wenn Sie im Overlay „Ethernet-MTU 1500“ anbieten wollen, brauchen Sie im Underlay in der Regel eine deutlich höhere MTU (Jumbo). Andernfalls müssen Sie im Overlay die MTU reduzieren und sicherstellen, dass Endgeräte/Server damit klarkommen.

Das typische Fehlerbild: „Ping geht, aber die Anwendung nicht“

MTU-Probleme sind berüchtigt, weil ein Standard-Ping mit kleiner Payload oft durchgeht. Erst bei größeren Payloads oder bei Protokollen mit größeren Segmenten treten Drops auf. Besonders typisch ist das bei TCP: Verbindungen kommen zustande, aber Datenübertragung ist langsam oder bricht.

• Symptom 1: kleine ICMP-Pings ok, große Pings failen.
• Symptom 2: TCP-Handshake ok, Datenübertragung stockt (Retransmits).
• Symptom 3: bestimmte Anwendungen betroffen (VPN, VoIP, bestimmte Webdienste, File Transfers).
• Symptom 4: „Nur bei QinQ/VXLAN Services“ – klassische Indikation für Overhead/MTU.

PMTUD: Warum ICMP-Filter MTU-Probleme unsichtbar machen

Path MTU Discovery (PMTUD) sorgt dafür, dass Sender die maximale Paketgröße auf dem Pfad herausfinden. Wenn PMTUD nicht funktioniert, bleibt der Sender bei zu großen Paketen hängen. In Provider-Netzen wird PMTUD häufig unabsichtlich gebrochen – etwa durch zu aggressive Firewall-Policies oder falsch gesetzte Filter.

• IPv4: PMTUD hängt an ICMP-Meldungen („Fragmentation Needed“). Wenn diese geblockt werden, entsteht ein Blackhole.
• IPv6: Fragmentierung im Transit ist anders; ICMPv6 ist funktional wichtiger. Blindes Blocken führt zu schwer erklärbaren Problemen.
• Telco-Realität: Security-Defaults müssen funktional korrekt sein, sonst „heilen“ Sie nichts, sondern verstecken Fehler.

MTU-Planung im Telco-Design: End-to-End statt Link-für-Link

Eine robuste MTU-Strategie ist nicht „jeder Link 9000“, sondern ein bewusstes End-to-End-Modell, das Overheads berücksichtigt: Access/UNI, Aggregation, Metro, PoP-Fabric, Firewall-Interconnect, Core und ggf. DC/Cloud-Edges müssen zusammenpassen.

• Pfad definieren: Wo beginnt die Service-MTU (Kunde/Server) und wo endet sie (Service-Endpunkt)?
• Encapsulation-Kette kennen: QinQ allein? QinQ + MPLS? VXLAN über IP/MPLS? Jede Schicht addiert Overhead.
• Einheitliche Standards: pro Domäne definierte MTUs (z. B. Access 1500, Transport X, Underlay Jumbo).
• Grenzknoten beachten: Firewalls, Load Balancer, PE/BNG und bestimmte Optik-/Transportplattformen sind häufig MTU-Flaschenhälse.

Praktische Best Practices für QinQ-MTU

QinQ wird oft im Access- und Wholesale-Transport genutzt. Hier ist die wichtigste Frage: Soll der Kunde 1500 Byte IP-MTU behalten? Wenn ja, muss der Providertransport den zusätzlichen Tag-Overhead verkraften. Wenn nicht, muss die Kunden-MTU klar kommuniziert und konsistent umgesetzt werden.

• Provider-MTU auf NNI/Transport erhöhen: damit Double-Tagging nicht an 1500er Grenzen scheitert.
• UNI klar definieren: Kunde tagged selbst (C-TAG) oder Provider setzt C-TAG; beide Varianten müssen MTU-seitig konsistent sein.
• QoS/Policer prüfen: manche Policers rechnen Frames anders; Overhead kann zu unerwarteten Drops führen.
• Scope minimieren: je größer die L2-Domäne, desto schwerer die Fehlersuche bei MTU/Drop-Anomalien.

Praktische Best Practices für VXLAN-MTU

VXLAN ist im Underlay/Overlay-Design besonders MTU-sensibel. Der häufigste Fehler ist, VXLAN „einzuschalten“, ohne das Underlay auf Jumbo-MTU zu bringen oder ohne die Overlay-MTU bewusst zu reduzieren.

• Underlay-Jumbo als Standard: wenn Sie im Overlay 1500 anbieten wollen, braucht das Underlay ausreichend Reserve.
• Overlay-MTU bewusst setzen: wenn Underlay nicht Jumbo kann, muss Overlay kleiner sein – und das muss in Server-/CPE-Profilen berücksichtigt werden.
• PMTUD sicherstellen: ICMP/ICMPv6 funktional korrekt zulassen, damit Blackholes vermieden werden.
• VTEP/Interconnect prüfen: MTU-Mismatches an VTEP-Links oder Firewall-Edges sind häufig.

Warum Kombinationen besonders kritisch sind: QinQ + VXLAN + weitere Encapsulations

In Telco-Umgebungen ist selten „nur QinQ“ oder „nur VXLAN“. Häufig kommen mehrere Schichten zusammen: QinQ im Access, MPLS im Core, VXLAN in der PoP-Fabric oder zur Cloud-Anbindung. Jede Schicht addiert Overhead, und die kleinste MTU im Pfad gewinnt.

• Mehrschichtige Overheads: jeder zusätzliche Header reduziert Nutzlast oder erfordert höhere Transport-MTU.
• Grenzgeräte sind kritisch: Firewalls, CGNAT, PE/BNG, bestimmte Optikplattformen limitieren oft MTU.
• Fehlersuche wird komplexer: Symptome ähneln sich; deshalb ist ein standardisiertes MTU-Testset wichtig.

Troubleshooting: MTU-Probleme schnell nachweisen

MTU-Troubleshooting sollte immer beweisorientiert sein: nicht „gefühlt“, sondern mit klaren Tests. Ziel ist: die maximale funktionierende Payload zu finden und den Flaschenhals zu lokalisieren.

• Große ICMP-Tests: Payload schrittweise erhöhen, um die Grenze zu finden (unter Beachtung von DF/Fragmentation-Mechanismen).
• Hop-by-Hop eingrenzen: Tests von verschiedenen Punkten (UNI, Aggregation, PoP, Core, DC) durchführen.
• Drop-Counter prüfen: Interface Drops, QoS Drops, Policer Drops, MTU-Errors auf Zwischenknoten.
• PMTUD prüfen: ob ICMP/ICMPv6-Meldungen ankommen oder gefiltert werden.

Operationalisierung: MTU-Standards als Teil des Service- und IP-Designs

MTU ist kein „Detail“, das man später fixen kann. In großen Provider-Netzen gehört MTU in die gleiche Kategorie wie IP-Container und VLAN-Scope: Sie muss standardisiert, dokumentiert und automatisiert validiert werden. Sonst entstehen wiederkehrende Incidents bei jedem Ausbau.

• Serviceprofile: pro Service (QinQ Transport, VXLAN Fabric, L2VPN, Internet Access) definierte MTU.
• Templates: MTU-Werte in Konfigtemplates, keine manuellen Einzelanpassungen.
• Monitoring: KPIs für MTU-Errors, Fragmentation-Events, ICMP-Rate-Limits, Drops in Queues.
• Dokumentation: MTU pro Domäne und Übergabepunkt (UNI/NNI, PoP-Interconnects, Firewalls) festhalten.

Typische Stolperfallen in Telco-Netzen

• „Nur ein Link blieb auf 1500“: der klassische Hidden Bottleneck, der sporadische Drops erzeugt.
• ICMP geblockt: PMTUD-Blackholes, besonders schmerzhaft bei IPv6.
• QoS/Policer rechnen anders: Drops bei großen Frames oder bei Burst-Verhalten, obwohl Bandbreite ausreichend scheint.
• Grenzgeräte limitieren MTU: Firewalls/Load Balancer/Transportplattformen sind häufig die tatsächliche Grenze.
• Keine einheitlichen Standards: jedes Team setzt andere MTU-Werte; Fehlersuche wird zur Detektivarbeit.

Praxis-Checkliste: MTU bei QinQ und VXLAN richtig planen

• End-to-End Pfad definieren: vom UNI/Server bis zum Service-Endpunkt, inklusive aller Encapsulations.
• Overhead einkalkulieren: QinQ (Double Tag), VXLAN (Overlay), ggf. weitere Schichten – kleinste MTU gewinnt.
• Underlay/Transport-MTU erhöhen: wenn Sie im Overlay/Service 1500 anbieten wollen, braucht der Transport Reserve.
• PMTUD funktional halten: ICMP/ICMPv6 nicht blind blocken; Rate-Limits sinnvoll statt Total-Block.
• Grenzknoten priorisieren: Firewalls, PE/BNG, VTEPs und Transportplattformen als erste MTU-Checkpunkte.
• Serviceprofile und Templates: MTU in Standards und Automatisierung verankern, nicht als Einzelfall lösen.
• Beweisorientiertes Troubleshooting: große Payload-Tests, Counter, Hop-by-Hop Eingrenzung, Drop-Ursachen trennen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.