QinQ (802.1ad) auf Cisco: Provider Bridging in der Praxis

QinQ (802.1ad) ist in vielen Metro-Ethernet- und Provider-Umgebungen das pragmatische Werkzeug, um mehrere Kunden-VLANs transparent über eine Provider-Infrastruktur zu transportieren. In der Praxis spricht man häufig von „Provider Bridging“ oder „VLAN Stacking“: Ein Kunde nutzt weiterhin seine eigenen VLANs (C-VLANs), während der Provider außen ein zusätzliches Service-Tag (S-VLAN) ergänzt und damit Kundennetze sauber voneinander trennt. Genau dadurch wird QinQ (802.1ad) auf Cisco besonders interessant, wenn mehrere Kunden identische VLAN-IDs verwenden oder wenn Sie aus Betriebssicht die Anzahl der VLANs in der Provider-Domäne reduzieren möchten, ohne dem Kunden Flexibilität zu nehmen. Gleichzeitig ist QinQ kein „einfaches doppelt taggen“: Es hat Auswirkungen auf Trunk-Design, MTU, Spanning Tree, Layer-2-Protokolle, Security, Monitoring und vor allem auf Troubleshooting. Wer QinQ in Enterprise- oder Provider-Netzen sauber betreiben will, braucht klare Rollen für Ports (UNI/NNI), konsistente Tagging-Standards, eine restriktive VLAN-Policy und eine saubere Dokumentation der S-VLAN-Zuordnung. Dieser Artikel zeigt QinQ (802.1ad) auf Cisco in der Praxis: Architektur, Konfigurationsmuster (IOS XE und NX-OS), typische Fallstricke und bewährte Prüf- und Betriebsroutinen, damit Provider Bridging stabil skaliert und Änderungen kontrolliert bleiben.

Begriffe und Architektur: C-VLAN, S-VLAN, UNI und NNI

Damit QinQ im Alltag verständlich bleibt, lohnt sich eine klare Begriffswelt. Im Kern gibt es zwei Tags: das innere Kunden-Tag (C-VLAN) und das äußere Service-Tag (S-VLAN). Der Provider transportiert in seiner Domäne typischerweise nur anhand des S-VLANs, während das C-VLAN im Frame erhalten bleibt und am entfernten Ende wieder „sichtbar“ wird.

• C-VLAN: Kunden-VLAN, das der Kunde intern nutzt (inneres 802.1Q-Tag).
• S-VLAN: Service-VLAN des Providers (äußeres Tag), dient zur Separation von Kunden/Services.
• UNI-Port: „User Network Interface“ – Provider-Port Richtung Kunde, hier wird das S-Tag typischerweise hinzugefügt (Tag-Push).
• NNI-Port: „Network-to-Network Interface“ – Provider-Port Richtung Provider-Netz/Kern, transportiert die S-VLANs durch die Domäne.

Der Standardhintergrund für Provider Bridging ist im IEEE-Kontext beschrieben, beispielsweise über die Entwicklungs-/Übersichtsseite zu IEEE 802.1ad Provider Bridges sowie die Standards-Übersicht bei der IEEE Standards Association zu 802.1ad.

Was QinQ technisch macht: Tag Stack, EtherType und MTU

Bei QinQ wird ein zusätzlicher VLAN-Header in den Ethernet-Frame eingefügt. Der Frame wird „double-tagged“: außen S-Tag, innen C-Tag. Praktisch bedeutet das: Es kommen weitere Bytes hinzu, und genau daraus ergeben sich MTU-Fragen. Wenn Provider- oder Kundenseite die zusätzliche Header-Länge nicht einplant, entstehen schwer erkennbare Probleme (z. B. nur bestimmte Protokolle/Frames schlagen fehl).

• Tag-Push am UNI: Der Provider ergänzt das S-Tag, ohne das C-Tag zu verändern.
• Transport im Provider-Netz: Switching/Forwarding orientiert sich oft an S-VLAN und MAC-Learning im Provider-Kontext.
• Tag-Pop am entfernten UNI: Das äußere Tag wird entfernt, der Kunde sieht wieder seine ursprünglichen C-VLANs.
• MTU: Double-Tagging erhöht Frame-Größe; End-to-End muss die Pfad-MTU ausreichend sein.

In vielen Cisco-Dokumenten wird QinQ auch im Kontext „802.1Q tunneling“ bzw. „VLAN Tunneling“ beschrieben. Für IOS XE gibt es dazu konkrete Hinweise in der LAN/WAN-Konfigurationsdokumentation, z. B. unter LAN and WAN Configuration Guide (IOS XE 17.x) – Q-in-Q/802.1Q.

Einsatzfälle: Wann Provider Bridging sinnvoll ist

QinQ ist besonders dann stark, wenn Sie Layer-2-Transparenz anbieten müssen, aber nicht die vollständige VLAN-Komplexität des Kunden in Ihrer Provider-Domäne spiegeln wollen. Typische Szenarien sind Standortvernetzungen auf Layer 2, Metro-Ethernet-Dienste oder Carriernetze, in denen Kunden-VLANs über ein Provider-Backbone geführt werden.

• Mehrere Kundennetze mit gleichen VLAN-IDs: S-VLAN trennt Kunden, C-VLAN bleibt intern identisch.
• Reduktion der Provider-VLAN-Komplexität: Provider verwaltet primär S-VLANs, nicht jede Kunden-VLAN-ID.
• Transparente L2-Dienste: Kunden können VLANs über Standorte hinweg „wie im eigenen LAN“ betreiben.
• Übergangslösungen: QinQ kann Migrationen unterstützen, z. B. wenn Kunden später auf L3VPN/EVPN wechseln.

Designregeln: S-VLAN-Plan, Allowed Lists und klare Portrollen

Stabiler Betrieb beginnt beim Design. Die häufigsten QinQ-Probleme sind nicht „Feature-Bugs“, sondern Folge von unklaren Portrollen und unkontrollierten VLAN-Listen. Definieren Sie deshalb S-VLANs wie Produkt-IDs: eindeutig, dokumentiert, restriktiv geführt.

• S-VLAN-Katalog: Welche S-VLANs existieren, welcher Kunde/Service gehört dazu, welche UNI-Ports sind zugeordnet?
• UNI/NNI strikt trennen: UNI-Ports sind Tunnels/Access-ähnlich, NNI-Ports transportieren S-VLANs als Trunk.
• Allowed Lists: Auf NNI-Trunks nur die S-VLANs erlauben, die wirklich benötigt werden.
• Native VLAN vermeiden: In Provider-Kontexten sollte „untagged“ möglichst keine Rolle spielen; Konsistenz ist Pflicht.

IOS XE in der Praxis: Dot1Q Tunneling, L2 Protocol Tunneling und typische Patterns

Auf Catalyst- und IOS-XE-basierten Plattformen wird QinQ häufig über „802.1Q tunneling“ bzw. „dot1q tunneling“ umgesetzt. In der Praxis gehört dazu nicht nur das VLAN-Stacking, sondern häufig auch Layer-2-Protocol-Tunneling (L2PT), damit kundeninterne L2-Protokolle (z. B. STP BPDUs) nicht in der Provider-Domäne wirken oder dort geblockt werden.

• UNI-Port als Tunnel-Port: Der Provider-Port zum Kunden wird so konfiguriert, dass er Kunden-Tags kapselt.
• S-VLAN Zuordnung: Der UNI-Port wird einem S-VLAN zugeordnet, das den Kunden repräsentiert.
• L2PT je nach Bedarf: Bestimmte L2-Protokolle können getunnelt werden, um Transparenz zu gewährleisten.
• Prüfbarkeit: Konsistente Naming-Standards für S-VLANs, Interfaces und Policies erleichtern Betrieb und Audit.

Für konkrete Konfiguration, Verifikation und Troubleshooting auf IOS XE (Catalyst 9000) ist der Cisco-Supportartikel Configure and Troubleshoot QinQ and L2PT on Catalyst 9000 Switches besonders praxisnah.

NX-OS in der Praxis: Q-in-Q VLAN Tunnels und Grenzen im Datacenter-Design

In NX-OS-Umgebungen wird QinQ typischerweise als „Q-in-Q VLAN tunnel“ beschrieben. Der Grundgedanke ist identisch, aber die Betriebspraxis ist oft stärker von Data-Center-Designs geprägt: Port-Channels, vPC, konsistente VLAN-Listen und klare Feature-Aktivierung spielen eine größere Rolle. Auch die Verifikation unterscheidet sich: NX-OS liefert oft sehr spezifische Show-Ausgaben je Feature, was bei guter Standardisierung die Fehlersuche beschleunigt.

• Double Tagging: NX-OS unterstützt Q-in-Q-Tunnelkonzepte, die inneres Tag erhalten und äußeres Tag hinzufügen.
• Layer-2 Protocol Tunneling: Je nach Anforderungen können L2-Protokolle kontrolliert getunnelt werden.
• vPC/Port-Channel Konsistenz: VLAN-Listen und Tunnelparameter müssen an beiden vPC-Peers konsistent sein.
• Limitations: Bestimmte Plattform-/Feature-Kombinationen haben Einschränkungen; daher immer plattformbezogen prüfen.

Als Referenz sind die NX-OS-Kapitel zu QinQ sehr hilfreich, z. B. Nexus 9000 NX-OS Interfaces Configuration Guide – Configuring Q-in-Q VLAN Tunnels oder die neueren Varianten wie NX-OS 10.4.x – Q-in-Q VLAN Tunnels. Für PDF-Detailtiefe ist auch Configuring Q-in-Q VLAN Tunnels (NX-OS) – PDF nützlich.

Provider Bridging auf Routern: Wenn QinQ am Edge terminiert oder durchgereicht wird

Nicht jede QinQ-Topologie ist „nur Switching“. Häufig müssen Router am Provider-Edge QinQ-Frames terminieren (z. B. um Kunden in VRFs zu routen) oder QinQ encapsulierten Verkehr an andere Domänen übergeben. Das ist besonders relevant bei Aggregationsroutern, bei denen Kunden-UNI-Ports in L2-Services münden, die später in L3-Services überführt werden.

• UNI als Provider-Port: Der Router/Edge behandelt Kundenseite nach Provider-Bridge-Regeln.
• Service-Mapping: S-VLAN kann als Service-Identifier dienen, der später in VRF- oder Policy-Logik überführt wird.
• Migration: QinQ kann als Übergang dienen, bevor Segmentierung auf VLAN-to-VRF oder L3VPN/EVPN umgestellt wird.

Ein Cisco-Beispiel für Provider-Bridge- und 802.1ad-Kontext findet sich u. a. in Configuring IEEE 802.1ad (ASR900/ASR903) – Cisco.

Layer-2-Protokolle und QinQ: STP, CDP/LLDP und L2PT richtig einordnen

Ein Kernpunkt in Provider Bridging ist die Frage, welche Layer-2-Protokolle in der Provider-Domäne wirken dürfen. Ohne klare Steuerung können Kundentopologien die Provider-Topologie beeinflussen oder umgekehrt. Gleichzeitig gibt es Kundenanforderungen, bestimmte L2-Protokolle transparent zu transportieren. Genau dafür existiert Layer-2 Protocol Tunneling (L2PT) als Ergänzung zu QinQ.

• Spanning Tree: Provider will typischerweise nicht, dass Kunden-BPDUs das Provider-STP beeinflussen.
• Transparenzbedarf: Kunden wollen eventuell STP zwischen ihren Standorten nutzen, ohne Provider-Interferenzen.
• L2PT: Ermöglicht selektives Tunneling bestimmter L2-Protokolle über die Provider-Domäne.
• Standardisierung: L2PT-Entscheidungen gehören in ein Service-Template, nicht als Einzelfallkonfiguration.

Der praktische Cisco-Bezug für L2PT in Kombination mit QinQ wird im Catalyst-9000-Kontext im Supportartikel zur QinQ- und L2PT-Konfiguration erläutert: QinQ und L2PT auf Catalyst 9000 – Configure/Troubleshoot.

Security und Isolation: Was QinQ kann und was nicht

QinQ ist ein Isolationstool auf Layer 2 – aber keine vollständige Sicherheitslösung. Es trennt Kundenverkehr über S-VLANs, verhindert aber nicht automatisch Fehlkonfigurationen, Leaks durch zu offene Allowed Lists oder Risiken durch unkontrollierten untagged Verkehr. Ein professioneller Ansatz behandelt QinQ daher wie einen Service: definierte Inputs (UNI-Ports), definierte Outputs (NNI-Transporte), klare Policy-Grenzen.

• Allowed Lists als Schutz: Auf NNI nur die S-VLANs erlauben, die dem Link tatsächlich zugeordnet sind.
• UNI-Ports strikt definieren: UNI ist kein „normaler Trunk“. Portrolle muss eindeutig sein und geprüft werden.
• Native VLAN konsequent entschärfen: Untagged sollte im Provider-Kontext kein produktiver Pfad sein.
• Monitoring und Logging: QinQ-Probleme sind oft indirekt; ohne saubere Betriebsdaten wird Troubleshooting langsam.

Troubleshooting in der Praxis: Fehlerbilder schneller einfangen

QinQ-Fehler wirken häufig „komisch“: Ein Standort ist erreichbar, der andere nicht; DHCP geht, aber bestimmte Applikationen nicht; oder MAC-Adressen flappen. Ein effizientes Troubleshooting folgt einem festen Pfad: Tagging prüfen, VLAN-Pfade prüfen, MTU prüfen, dann L2-Protokolle/Policy prüfen.

• Tagging-Pfad: Wird am UNI wirklich ein S-Tag hinzugefügt und am entfernten Ende korrekt entfernt?
• S-VLAN Transport: Ist das S-VLAN über alle NNI-Trunks im Pfad erlaubt?
• MTU: Gibt es Drops oder Fragmentierungs-/PMTUD-Effekte durch zusätzliche Tags?
• MAC-Learning: Wo wird die Kunden-MAC gelernt? Gibt es Flapping zwischen Ports/Port-Channels?
• L2PT/STP: Werden Kunden-BPDUs korrekt getunnelt oder unerwartet gefiltert?

Für IOS XE (Catalyst 9000) bietet Cisco konkrete Verify- und Troubleshoot-Beispiele: Configure/Verify/Troubleshoot QinQ und L2PT. Für NX-OS finden Sie Verify-Abschnitte und Beispiele in Configuring Q-in-Q VLAN Tunnels (NX-OS Guide).

Operationalisierung: Templates, Naming und Compliance Checks für QinQ-Services

Provider Bridging skaliert nur, wenn es standardisiert wird. In der Praxis heißt das: ein QinQ-Service ist ein wiederholbarer Blueprint, der Portrollen, S-VLAN-Zuordnung, Allowed Lists, L2PT-Entscheidungen und Monitoring-Vorgaben umfasst. Ohne diese Standardisierung entsteht Drift: Ein Kunde läuft „anders“ als der nächste, und jede Änderung wird zur Einzelfallanalyse.

• Naming-Standard: S-VLAN-Namen und Service-IDs müssen Kunden/Service und Standort erkennen lassen (z. B. SVC-CUSTX-BER).
• UNI/NNI-Checklisten: Vor Inbetriebnahme und nach Änderungen feste Prüfblöcke (S-VLAN erlaubt, MTU ok, MAC-Learning plausibel).
• Änderungsdisziplin: Allowed Lists nur nach Change-Prozess; „quick fix“ führt zu VLAN-Leaks.
• Exception Register: Sonderfälle (z. B. besondere L2PT-Anforderungen) werden begründet und befristet dokumentiert.

Typische Fallstricke bei QinQ auf Cisco

• Unkontrollierte Allowed Lists: S-VLANs werden überall erlaubt, bis niemand mehr weiß, wo ein Service wirklich läuft.
• Native VLAN Inkonsistenz: Untagged-Verkehr oder Mismatches erzeugen schwer erklärbare Effekte.
• MTU übersehen: Double-Tagging führt zu Drops, die nur bestimmte Frame-Typen betreffen.
• Portrollen verwischt: UNI-Ports werden wie normale Trunks behandelt, wodurch Kunden-Tags ungewollt in die Provider-Domäne „auslaufen“.
• L2PT falsch eingeschätzt: Entweder zu viel tunneln (unnötige Komplexität) oder zu wenig (Kundenprotokolle brechen).
• vPC/Port-Channel Mismatch: In NX-OS/DC-Designs führen inkonsistente Parameter schnell zu instabilem Verhalten.

Weiterführende Referenzen für die Praxis

• IEEE 802.1ad Provider Bridges für den Standardkontext von Provider Bridging.
• IEEE Standards Association – 802.1ad als formale Standards-Referenz.
• Cisco: Configure and Troubleshoot QinQ und L2PT auf Catalyst 9000 für IOS XE-nahe Praxisbeispiele.
• Cisco NX-OS Guide: Configuring Q-in-Q VLAN Tunnels für NX-OS-Konfiguration und Verifikation.
• Cisco: Configuring IEEE 802.1ad (ASR900/ASR903) für Provider-Edge- und Router-nahe Perspektiven.

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.