Site icon bintorosoft.com

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

Red Snapper

Fiber Optic cables connected to an optic ports in data center, close up of network cables connected to an internet hub, shallow depth of field --ar 3:2 --v 5.2 Job ID: 32c5681d-0d88-464b-98dd-de93af4257d7

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

Typische Fallstricke bei QinQ auf Cisco

Weiterführende Referenzen für die Praxis

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:

Lieferumfang:

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.

 

Exit mobile version