QinQ (802.1ad) erklärt: VLAN Stacking für Provider und Wholesale

QinQ (802.1ad) – oft auch „VLAN Stacking“ genannt – ist eine Schlüsseltechnologie, wenn Provider und Wholesale-Partner Ethernet-Services skalierbar, sauber trennbar und betrieblich beherrschbar transportieren müssen. In klassischen VLAN-Designs mit 802.1Q stößt man im Telco-Umfeld schnell an Grenzen: Einerseits ist die Anzahl der VLAN-IDs begrenzt, andererseits explodiert die Komplexität, wenn jedes Kunden-VLAN (C-VLAN) durch das gesamte Provider-Netz durchgeschleift werden soll. Genau hier setzt QinQ an: Der Provider kapselt das Kunden-VLAN in ein Service-VLAN (S-VLAN) und erhält damit eine klare Demarkation, bessere Skalierung und ein sauberes Betriebsmodell – besonders relevant für Wholesale, Carrier Ethernet, Business-Anbindungen, Multi-Tenant-Access und regionale Aggregationsnetze. In diesem Artikel erfahren Sie verständlich und praxisnah, wie QinQ funktioniert, welche Topologien sich bewährt haben, welche Stolperfallen (MTU, Tagging, QoS, Security) häufig auftreten und wie Sie VLAN Stacking so implementieren, dass es langfristig stabil bleibt.

Was ist QinQ (802.1ad) – und was bedeutet „VLAN Stacking“?

QinQ erweitert das klassische VLAN-Tagging nach 802.1Q, indem es zwei VLAN-Tags in einem Ethernet-Frame ermöglicht: einen inneren Tag (Kunden-Tag) und einen äußeren Tag (Provider-Tag). Das Prinzip ist simpel: Der Kunde oder Wholesale-Partner nutzt seine eigenen VLANs (C-VLANs). Der Provider fügt am Übergabepunkt einen zusätzlichen Tag hinzu (S-VLAN) und transportiert den Verkehr im eigenen Netz primär anhand des äußeren S-Tags. Dadurch kann der Provider:

• Kunden-VLANs transparent transportieren: ohne jedes C-VLAN im Provider-Netz einzeln zu verwalten.
• Services sauber bündeln: mehrere C-VLANs können unter einem S-VLAN zusammengefasst werden.
• Skalierung erreichen: weniger VLAN-Komplexität im Provider-Core und in der Metro/Aggregation.
• Übergaben klar definieren: S-VLAN ist die Provider-Domäne, C-VLAN bleibt Kunden-/Partnerdomäne.

Begriffe im QinQ-Umfeld: C-VLAN, S-VLAN, UNI und NNI

Damit QinQ in der Praxis verständlich bleibt, lohnt sich eine klare Begriffsbasis. Im Provider- und Wholesale-Kontext werden häufig Begriffe aus Carrier Ethernet verwendet.

• C-VLAN (Customer VLAN): inneres VLAN-Tag, vom Kunden oder Wholesale-Partner vorgegeben.
• S-VLAN (Service VLAN): äußeres VLAN-Tag, vom Provider vergeben und im Netz transportiert.
• UNI (User Network Interface): Übergabepunkt zwischen Kunde/Partner und Provider (Demarkation).
• NNI (Network-to-Network Interface): Übergabe zwischen Netzen (z. B. Provider zu Provider oder Metro zu Core).

Wichtig für die Praxis: Wer „owned“ welches Tag?

Ein sauberes Betriebsmodell trennt Verantwortlichkeiten: Der Kunde/Partner verantwortet C-VLAN-Design und ggf. interne Trennung. Der Provider verantwortet S-VLAN-Zuordnung, Transport, QoS-Policies im Provider-Netz sowie die Dokumentation der Demarkationspunkte.

Warum QinQ für Provider und Wholesale so wertvoll ist

Die zentrale Herausforderung in Wholesale- und Carrier-Ethernet-Szenarien ist Skalierung mit klarer Trennung. Ohne QinQ müsste der Provider entweder extrem viele VLANs im eigenen Netz führen oder auf komplexe Sonderkonstrukte ausweichen. QinQ reduziert diesen Druck, ohne die Flexibilität der Kunden einzuschränken.

• Skalierbarkeit in Metro und Aggregation: viele Kundensegmente über wenige Provider-Services transportieren.
• Einfachere Provisionierung: neue Kunden/Partner oft „nur“ neues S-VLAN oder neues Mapping.
• Saubere Demarkation: klare Grenzlinie für SLA, Monitoring, Verantwortung und Entstörung.
• Reduzierte VLAN-Explosion: weniger Allowed-VLAN-Listen, weniger Trunk-Komplexität, weniger Fehlerrisiko.
• Flexibilität für Kunden: Kunden können mehrere C-VLANs für verschiedene Dienste nutzen (z. B. Voice, Daten, Video).

Wie QinQ technisch funktioniert: Tag-Struktur und Frame-Overhead

Bei klassischem 802.1Q trägt ein Frame einen VLAN-Tag. Bei QinQ werden zwei Tags eingefügt: der äußere S-Tag und der innere C-Tag. Für den Transport im Provider-Netz ist meist der äußere Tag entscheidend. Dadurch verändert sich die Frame-Größe, was in der Praxis unmittelbar die MTU-Planung betrifft.

Warum MTU bei QinQ eine der häufigsten Fehlerquellen ist

Jeder VLAN-Tag erhöht den Overhead. QinQ bedeutet also mindestens einen zusätzlichen Tag. Kommen weitere Encapsulations hinzu (z. B. PPPoE, MPLS, VXLAN), steigt der Overhead weiter. Wenn die End-to-End-MTU nicht konsistent geplant und umgesetzt ist, entstehen schwer zu diagnostizierende Probleme wie Fragmentierung, Drops oder unerklärliche Performance-Einbrüche.

• Best Practice: End-to-End-MTU für den Service definieren, inklusive aller Overheads.
• Konsequenz: MTU konsistent auf Access, Aggregation, Metro, NNI und Termination setzen.
• Runbook: MTU-Tests als Standard (z. B. PMTU-Prüfungen und gezielte Paketgrößen-Checks).

QinQ-Topologien in der Praxis: Transparent, Selective und Mapping

QinQ ist kein „Einheitsmodus“. Je nach Geschäft und Technik wählen Provider unterschiedliche Varianten. Entscheidend ist, ob C-VLANs transparent durchgereicht werden oder ob der Provider selektiert und mappt.

• Transparent QinQ: alle (oder viele) C-VLANs werden akzeptiert, S-Tag wird hinzugefügt, Transport erfolgt ohne inhaltliche Veränderung.
• Selective QinQ: nur definierte C-VLANs oder VLAN-Ranges sind erlaubt; alles andere wird verworfen.
• C-VLAN-to-S-VLAN Mapping: mehrere C-VLANs können in ein S-VLAN gebündelt werden, um S-VLANs zu sparen.
• Service-VLAN pro Partner: häufiges Wholesale-Modell: Partner bekommt ein oder wenige S-VLANs, darunter viele C-VLANs.

Welche Variante ist „richtig“?

Für Wholesale ist Selective QinQ oft betrieblich stabiler, weil Sie erlaubte C-VLAN-Ranges definieren und unerwünschtes Tagging vermeiden. Transparent QinQ ist komfortabel, kann aber schneller zu unerwarteten Effekten führen, wenn Kunden C-VLANs unkontrolliert erweitern.

QinQ als Skalierungswerkzeug: Wie viele C-VLANs passen unter ein S-VLAN?

QinQ kann die Komplexität im Provider-Netz stark reduzieren, aber es hebt nicht alle Limits auf. In der Praxis bestimmen Plattformlimits (MAC-Learning, ARP/ND in L3-Termination-Szenarien, TCAM/ACL-Kapazitäten) sowie Betriebsprozesse, wie „groß“ ein QinQ-Service werden darf.

• MAC-Tabellen: viele Endpunkte unter einem S-VLAN können MAC-Learning und Memory belasten.
• Broadcast/Unknown-Unicast: große L2-Domänen können Störanfälligkeit erhöhen.
• Trunk-Design: auch S-VLANs sollten restriktiv freigegeben und regelmäßig auditiert werden.
• Fehlerdomänen: zu große QinQ-Domänen erschweren Troubleshooting – Segmentierung bleibt wichtig.

QoS im QinQ-Umfeld: CoS/DSCP, Trust Boundaries und Priorisierung

Wholesale- und Provider-Services erfordern häufig klare QoS-Regeln. QinQ bringt dabei eine zusätzliche Dimension: Welcher Tag trägt die Priorität? In Ethernet-Umgebungen kann die Priorität über CoS (802.1p) im VLAN-Tag abgebildet werden. Im QinQ-Fall existieren zwei Tags, und Provider müssen festlegen, ob sie die Priorität am äußeren Tag, inneren Tag oder über eine Policy-Übersetzung steuern.

• Trust Boundary definieren: Welche Markierungen werden vom Partner akzeptiert?
• Marking-Policy: CoS am S-Tag ist oft Provider-geführt, um SLAs zu kontrollieren.
• Policing an der UNI: verhindert, dass Partner unkontrolliert hohe Prioritäten „einfordern“.
• End-to-End-Konsistenz: QoS muss von UNI über Aggregation/Metro bis zur Termination konsistent sein.

Praxisregel für Wholesale

Definieren Sie vertraglich und technisch, welche Klassen zulässig sind. Implementieren Sie an der UNI eine klare Klassifizierung und Policer-Logik. So bleibt QoS fair, vorhersehbar und auditierbar.

Sicherheit: QinQ schützt nicht automatisch – es braucht Kontrollen

QinQ ist primär ein Transport- und Skalierungsmechanismus, keine vollständige Sicherheitslösung. Ohne Kontrollen können Fehlkonfigurationen oder Missbrauch zu VLAN-Leaks, unerwünschtem Tagging oder großen Fehlerdomänen führen. Besonders wichtig sind klare Regeln an der UNI.

• Selective QinQ bevorzugen: erlaubte C-VLAN-Ranges und explizite Policies reduzieren Risiken.
• Trunks restriktiv halten: nur benötigte S-VLANs auf NNIs erlauben.
• Storm Control: begrenzt Broadcast-/Multicast-/Unknown-Unicast-Stürme.
• BPDU Guard/Filter: verhindert STP-Einflüsse aus Kundennetzen (sofern Architektur und Plattform es unterstützen).
• Monitoring auf Segmentebene: MAC-Flapping, ungewöhnliche Broadcast-Raten, Link-Fehler früh erkennen.

Betrieb und Provisionierung: QinQ sauber dokumentieren und standardisieren

QinQ kann Betrieb massiv vereinfachen – wenn es standardisiert ist. Ohne klare Regeln wird QinQ schnell zu einem „Mapping-Labyrinth“. Der Schlüssel liegt in Templates, Namenskonventionen und einer verlässlichen Dokumentation (idealerweise in IPAM/CMDB in Verbindung mit Service-Inventar).

• S-VLAN-Plan: reservierte Bereiche pro Region/PoP/Partner, damit es keine Kollisionen gibt.
• Naming: S-VLAN-Namen enthalten Partner/Service/PoP, damit NOC-Teams schnell erkennen, was betroffen ist.
• Mapping-Regeln: C-VLAN-Ranges, erlaubte VLANs, Übersetzungen – alles schriftlich und operational nutzbar.
• Lifecycle: geplant, aktiv, deprecated – alte Services geordnet abbauen.
• Change-Disziplin: QinQ-Changes sind servicekritisch, daher mit Review, Tests und Rollback.

Allowed VLAN Lists auch bei QinQ nicht vergessen

Auch wenn QinQ die Anzahl der „sichtbaren“ VLANs reduziert, bleibt Trunk-Hygiene essenziell. S-VLANs sollten auf NNIs nur dort erlaubt sein, wo sie gebraucht werden. Das reduziert Ausbreitung, Fehlersuche und Sicherheitsrisiken.

Typische Stolperfallen bei QinQ – und wie Sie sie vermeiden

In der Praxis sind QinQ-Probleme selten exotisch. Meist sind es wiederkehrende Basics, die bei konsequenter Standardisierung vermeidbar sind.

• MTU nicht end-to-end geplant: führt zu Drops und Performanceproblemen – MTU-Policy definieren und testen.
• Tagging-Mismatch: UNI/NNI unterschiedlich konfiguriert – „alles explizit“ und Templates nutzen.
• Zu große L2-Domänen: QinQ nicht als Einladung verstehen, alles zu bündeln – Fehlerdomänen klein halten.
• Unklare C-VLAN-Regeln: Partner erweitert VLANs unkontrolliert – Selective QinQ und VLAN-Ranges festlegen.
• QoS-Vertrauen ohne Kontrolle: Partner markiert alles hoch – Policer/Trust Boundary an der UNI.
• VLAN-Leaks durch offene Trunks: S-VLANs „wandern“ – Allowed VLAN Lists und Audits.

Praxis-Checkliste: QinQ (802.1ad) für Provider und Wholesale sauber umsetzen

• Service- und Verantwortungsgrenzen definieren: C-VLAN gehört dem Kunden/Partner, S-VLAN dem Provider.
• S-VLAN-Strategie festlegen: pro Partner/PoP/Service klare Zuordnung, reservierte ID-Bereiche.
• Selective QinQ bevorzugen: erlaubte C-VLAN-Ranges und Mapping-Regeln explizit definieren.
• MTU end-to-end planen: Overheads berücksichtigen, konsistente Konfiguration, standardisierte Tests.
• QoS sauber regeln: Trust Boundary, Marking-Policy, Policing an der UNI, SLA-konforme Klassen.
• Trunks restriktiv: Allowed VLAN Lists für S-VLANs auf NNIs, regelmäßige Audits.
• Security-Controls aktivieren: Storm Control, Schutz vor L2-Ereignissen, Monitoring auf Segmentebene.
• Dokumentation operationalisieren: S-VLAN ↔ Partner ↔ C-VLAN-Regeln ↔ Übergabepunkt in IPAM/CMDB/Service-Inventar.
• Change-Prozess standardisieren: Review, Rollback, Tests, klare Verantwortlichkeiten zwischen Teams und Partnern.

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.