QinQ Troubleshooting: S-TAG/C-TAG Fehlerbilder und Fixes

QinQ Troubleshooting ist im Telco- und Wholesale-Umfeld eine der häufigsten – und gleichzeitig frustrierendsten – Aufgaben im Betrieb. Der Grund: Wenn ein Service über VLAN Stacking (802.1ad) läuft, können Fehler auf mehreren Ebenen entstehen, die sich in sehr ähnlichen Symptomen äußern: „Kunde hat keinen Traffic“, „nur Broadcast geht“, „ARP flappt“, „nur bestimmte VLANs funktionieren“, „MTU-Probleme bei großen Paketen“ oder „Service läuft nur in eine Richtung“. Ursache ist oft nicht ein „großer“ Defekt, sondern ein Detail im Tagging: falsches S-TAG (Service-VLAN), falsches C-TAG (Customer-VLAN), ein Port ist versehentlich als Access statt QinQ konfiguriert, die Allowed-VLAN-Liste ist zu offen oder zu restriktiv, oder ein Zwischenknoten behandelt den Outer-Tag anders als erwartet (Drop, Rewrite, Pop/Push). Dazu kommen Telco-spezifische Stolpersteine wie gemischte Hersteller, unterschiedliche Begriffe (S-VLAN, Provider VLAN, Outer Tag, UNI/NNI), unerwartete Filter (STP/BPDU, MAC-Limits), sowie Overheads durch Double-Tagging, die MTU- und QoS-Probleme triggern können. Dieses Troubleshooting-How-to zeigt praxisnah die typischen S-TAG/C-TAG Fehlerbilder, eine schnelle Diagnose-Methodik und die häufigsten Fixes, die in Provider-Netzen wirklich wirken – so strukturiert, dass Sie auch unter Incident-Druck den Überblick behalten.

QinQ in 60 Sekunden: Was ist S-TAG, was ist C-TAG?

QinQ (802.1ad) kapselt ein Kunden-VLAN (C-TAG) in ein Service-VLAN (S-TAG). Der Provider transportiert im Kern hauptsächlich den S-TAG (oder S-TAG-Gruppen), während Kunden unterschiedliche C-TAGs innerhalb dieses Service-Tunnels nutzen können. Am UNI (Customer Facing Port) wird typischerweise der S-TAG hinzugefügt (Push), am Übergabepunkt oder am anderen Ende wird er wieder entfernt (Pop) oder in einen anderen S-TAG gemappt.

• C-TAG (Customer VLAN): inneres 802.1Q-Tag, vom Kunden vorgegeben oder vom Provider am UNI gesetzt.
• S-TAG (Service VLAN): äußeres Tag, das der Provider zur Skalierung und zur Trennung im Transport nutzt.
• UNI: Port zum Kunden (User Network Interface).
• NNI: Port zwischen Provider-Domänen oder Provider-Knoten (Network-to-Network Interface).

Merksatz für die Fehlersuche

Wenn der S-TAG falsch ist, „verschwindet“ der gesamte Service im Provider-Netz. Wenn der C-TAG falsch ist, funktioniert der Transport ggf. grundsätzlich, aber die kundenspezifischen VLANs oder Teilservices brechen.

Die häufigsten Symptome im QinQ-Betrieb – und was sie typischerweise bedeuten

Viele QinQ-Probleme sehen oberflächlich identisch aus („kein Traffic“). Deshalb ist es wichtig, Symptome zu clustern: L2 komplett tot, L2 teilweise, nur bestimmte VLANs, nur große Pakete, nur eine Richtung. Daraus ergibt sich die schnellste Hypothese.

• Komplett kein Traffic: S-TAG fehlt/falsch, Portmode falsch (Access statt QinQ), Trunk/Allowed S-VLAN blockt.
• Nur einzelne C-VLANs gehen nicht: C-TAG-Range nicht erlaubt/konfiguriert, Mapping/Translation falsch, Filter auf innerem Tag.
• Nur ARP/Broadcast geht, Unicast nicht stabil: MAC-Learning/Flapping, Loop, falsche STP-Behandlung, asymmetrische Pfade, Storm-Control.
• Nur in eine Richtung: asymmetrisches Tagging (Push/Pop nicht spiegelbildlich), falsche NNI-Konfiguration, ACL/Filter nur auf einem Pfad.
• Kleine Pakete gehen, große nicht: MTU/Overhead durch Double-Tagging, PMTUD/Fragmentierung, QoS-Policer.

Standardisierte Diagnose-Methodik: In 7 Schritten zum Fehler

QinQ ist beherrschbar, wenn Sie die Diagnose immer gleich strukturieren. Das Ziel ist, schnell zu klären: Ist der Fehler am UNI, im Provider-Transport oder am entfernten Ende/NNI? Und betrifft er S-TAG, C-TAG oder beides?

• Schritt 1: Service-Definition prüfen: erwarteter S-TAG, erwartete C-TAGs (Range), UNI/NNI-Endpunkte, Mapping-Regeln.
• Schritt 2: Link-/Portzustand prüfen: LACP, Fehlerzähler, Drops, MTU, Speed/Duplex.
• Schritt 3: UNI-Portmode prüfen: QinQ/Provider-Bridge korrekt? Wird S-TAG gepusht?
• Schritt 4: NNI/Transport prüfen: Allowed S-VLANs, Trunks, Provider-Bridge/Transportpfad, keine „Access“-Stellen im Pfad.
• Schritt 5: C-TAG Handling prüfen: C-VLAN Range/Filter, Translation/Rewrite, Customer-Frames tagged/untagged?
• Schritt 6: MAC/ARP prüfen: MAC-Learning, Flapping, Flooding, STP/BPDU-Handling, Storm-Control.
• Schritt 7: MTU/QoS prüfen: Double-Tag Overhead, Policer, Queue Drops, Jumbo/Provider-MTU.

S-TAG Fehlerbilder: Ursachen und Fixes

S-TAG-Probleme betreffen den „Transporttunnel“. Wenn der äußere Tag nicht stimmt, sieht der Providerkern den Traffic nicht im richtigen Service. Diese Fehler sind besonders häufig bei Änderungen an Trunks oder bei Migrationen zwischen Aggregationsknoten.

• Fehlerbild: Service komplett tot (alle C-VLANs betroffen).
• Typische Ursache: falsches S-VLAN konfiguriert, S-VLAN nicht auf Trunk erlaubt, S-VLAN am falschen Port gepusht/gepopt.
• Fix: S-VLAN auf allen NNI-Trunks erlauben (minimal nötig), Push/Pop konsistent an UNI/NNI definieren, Service-Objekte in der Doku abgleichen.

• Fehlerbild: Service läuft nur in eine Richtung.
• Typische Ursache: auf einer Seite S-TAG Push aktiv, auf der anderen Seite wird S-TAG nicht erwartet (oder bereits entfernt).
• Fix: Tagging-Richtung festlegen: UNI pusht, entfernte UNI poppt; NNI transportiert nur S-TAG; keine „doppelten Pops“ im Pfad.

• Fehlerbild: sporadische Drops, vor allem bei Last.
• Typische Ursache: S-VLAN läuft in eine zu große L2-Domäne, Storm-Control/Policer greifen, oder es gibt L2-Schleifen.
• Fix: Scope des S-VLAN begrenzen, Allowed S-VLANs pro Link minimieren, L2-Schutz (BPDU/Loop Guard) prüfen, Storm-Control mit sinnvollen Limits konfigurieren.

C-TAG Fehlerbilder: Ursachen und Fixes

C-TAG-Probleme sind „feingranularer“. Oft funktioniert der S-TAG-Transport grundsätzlich, aber einzelne Kunden-VLANs oder Teilservices sind gestört. Das passiert typischerweise durch C-VLAN-Filter, falsche Ranges oder VLAN-Translation-Fehler.

• Fehlerbild: nur bestimmte C-VLANs funktionieren (z. B. 10 und 20 gehen, 30 nicht).
• Typische Ursache: C-VLAN Range am UNI/NNI falsch (nicht erlaubt), Mapping-Regel unvollständig, kundenseitige VLANs anders als dokumentiert.
• Fix: C-VLAN Range explizit konfigurieren, Mapping/Translation-Regeln für alle benötigten VLANs ergänzen, Abgleich mit Kunden-Konfiguration (tagged/untagged) durchführen.

• Fehlerbild: untagged Traffic geht nicht, tagged geht (oder umgekehrt).
• Typische Ursache: UNI erwartet untagged und setzt C-TAG selbst, Kunde sendet tagged; oder UNI ist als Access konfiguriert und droppt Double-Tagged Frames.
• Fix: UNI-Modus eindeutig festlegen: „C-Tag vom Kunden“ vs. „Provider setzt C-Tag“; Native/untagged Handling dokumentieren und konsistent umsetzen.

• Fehlerbild: ARP/ND instabil, MACs flappen nur in einem C-VLAN.
• Typische Ursache: VLAN Translation führt zu ungewollten Zusammenlegungen (z. B. zwei C-VLANs mappen auf gleiche interne ID), oder es existiert ein Loop im Kundennetz nur für dieses VLAN.
• Fix: Translation-Matrix prüfen (1:1 und ohne Kollision), MAC-Flap-Logs auswerten, Kunden-VLAN isoliert testen, ggf. BPDU-Handling/Storm-Control gezielt prüfen.

Das klassische Missverständnis: QinQ-Port ist nicht einfach „Trunk“

In vielen Incidents steckt ein Portmode-Problem: Ein Gerät ist als klassischer 802.1Q-Trunk konfiguriert, soll aber QinQ sprechen. Dann passieren typische Dinge: Double-Tagged Frames werden gedroppt, Outer-Tags werden nicht akzeptiert, oder der Switch interpretiert den inneren Tag als „eigentliches VLAN“ und lernt MACs im falschen Kontext.

• Symptom: Double-Tagged Frames verschwinden oder landen im falschen VLAN.
• Ursache: Port nicht als Provider-Edge/Provider-Bridge/QinQ-Port konfiguriert.
• Fix: Portrolle eindeutig setzen (UNI/NNI), QinQ/Service-Tagging aktivieren, C-VLAN Handling (untagged/tagged) definieren.

MTU und Overhead: Wenn Double-Tagging große Pakete killt

QinQ fügt einen zusätzlichen VLAN-Header hinzu. Das ist nicht viel, aber im Providertransport mit weiteren Encapsulations (z. B. MPLS, GRE, VXLAN) summiert sich Overhead. Die Folge: Kleine Pakete gehen, große brechen – ein typisches „Geisterproblem“, wenn PMTUD oder Fragmentierung nicht sauber funktioniert.

• Symptom: Ping klein ok, große Pakete oder bestimmte Anwendungen brechen.
• Ursachen: MTU zu klein, Jumbo nicht end-to-end, Policer droppen größere Frames, PMTUD/ICMP blockiert.
• Fix: End-to-end MTU planen (inkl. Overheads), Provider-MTU auf NNI/Transport erhöhen, QoS/Policer prüfen, relevante ICMP/PMTUD-Mechanismen nicht blind blocken.

MAC-Learning, Flooding und Flapping: QinQ macht Fehler sichtbar

Viele QinQ-Störungen sind eigentlich klassische L2-Probleme: Loops, falsche STP-Topologien, MAC-Table-Limits oder Flooding. QinQ kann diese Effekte verstärken, weil große Kunden- oder Transportdomänen entstehen, wenn S-VLANs zu weit ausgedehnt werden.

• Symptom: MAC-Flapping zwischen Ports, ARP instabil, sporadische Unicast-Drops.
• Ursachen: L2-Loop, falsche STP-Filterung/Weiterleitung, zu große Broadcast-Domäne im S-VLAN, MAC-Limits.
• Fix: S-VLAN-Scope begrenzen, Allowed S-VLANs minimieren, STP/BPDU-Policy sauber definieren, Loop-Guards aktivieren, MAC-Limit-Policy prüfen.

STP/BPDU Handling: Wann BPDUs durch QinQ dürfen und wann nicht

Ein spezieller Telco-Aspekt ist BPDU-Handling. Je nach Servicemodell kann es gewünscht sein, dass Kunden-L2-Protokolle nicht in den Providerkern gelangen. Gleichzeitig kann hartes BPDU-Blocking im falschen Segment zu L2-Loops führen. Hier ist Klarheit über die Service-Definition entscheidend.

• Wenn der Service „L2 transparent“ ist: bestimmte L2-Protokolle könnten durchgereicht werden müssen (abhängig von Vertrag/Design).
• Wenn der Service „L2 isoliert“ sein soll: BPDUs und bestimmte L2-Protokolle sollten gefiltert werden, um Provider-Stabilität zu schützen.
• Fix-Ansatz: BPDU-Policy explizit pro Service definieren und nicht als globalen Default „irgendwie“ anwenden.

Allowed VLANs und Mapping-Matrizen: Die häufigste Root Cause in der Praxis

QinQ lebt von Konsistenz entlang des Pfads. In großen Netzen sind es meist nicht „zwei Geräte“, sondern 10+ Knoten, die den Service transportieren. Deshalb sind Allowed-Listen (S-VLANs) und Mapping-Matrizen (C↔S, Translation) die häufigste Fehlerquelle.

• Symptom: Service geht nach Change nicht mehr, obwohl Link up ist.
• Ursache: S-VLAN nicht auf einem Zwischenlink erlaubt, oder Mapping/Translation nur teilweise ausgerollt.
• Fix: Pfadbasierte Validierung: S-VLAN auf jedem Link prüfen, Konfig-Templates erzwingen, Mapping zentral verwalten und automatisiert ausrollen.

Dokumentation als Troubleshooting-Tool: Ohne Source of Truth wird QinQ teuer

Bei QinQ ist Dokumentation nicht „nice to have“, sondern Teil der Betriebsfähigkeit. Sie müssen jederzeit wissen: Welche S-VLANs existieren? Welche C-VLAN Ranges sind pro Kunde erlaubt? Wo wird gepusht/gepopt? Welche Zwischenknoten transportieren den Service? Ohne diese Daten wird Troubleshooting zu Ratearbeit.

• Pflichtdaten pro Service: UNI/NNI-Endpunkte, S-VLAN, C-VLAN Range, Tagging-Richtung (Push/Pop), MTU/QoS-Profil.
• Pflichtdaten pro Trunk: Allowed S-VLANs, Rolle (Transport/PoP), Scope (Metro/Region), Native-VLAN-Policy.
• Lifecycle: deprecated Services/VLANs sauber entfernen, damit alte Konfig nicht „im Weg“ steht.

Schnelle Fix-Liste: Häufige Ursachen und sofortige Maßnahmen

• Service komplett down: S-VLAN entlang des Pfads prüfen (Allowed, existiert, gleiche ID), UNI/NNI-Portmode prüfen.
• Nur einzelne VLANs down: C-VLAN Range/Mappings prüfen, Kunden-Tagging (tagged/untagged) abgleichen.
• Einseitiger Traffic: Push/Pop-Richtung spiegeln, NNI-Handling und Translation auf beiden Seiten vergleichen.
• Große Pakete brechen: MTU end-to-end prüfen, Overhead berücksichtigen, Policer/Queues und PMTUD betrachten.
• MAC/ARP instabil: Scope des S-VLAN begrenzen, Loops/STP/BPDU-Policy prüfen, Storm-Control und MAC-Limits prüfen.

Praxis-Checkliste: QinQ Troubleshooting für S-TAG/C-TAG Fehlerbilder

• Serviceparameter zuerst: erwartetes S-VLAN, erlaubte C-VLANs, UNI/NNI-Endpunkte, Push/Pop-Definition.
• S-TAG Pfadprüfung: S-VLAN auf jedem Zwischenlink erlaubt und korrekt konfiguriert? Kein „Access“-Loch im Pfad?
• C-TAG Prüfung: Range/Translation korrekt? Kunde tagged wie vereinbart? Untagged Handling eindeutig?
• Portrollen prüfen: UNI/NNI korrekt? QinQ/Provider-Bridge aktiviert? Native VLAN nicht produktiv?
• MTU/QoS prüfen: Double-Tag Overhead einkalkulieren, Drops/Policer/Queues prüfen.
• MAC/STP/Loop prüfen: MAC-Flaps, BPDU-Policy, Storm-Control, Loop-Guards.
• Dokumentation aktualisieren: alle Mappings und Allowed S-VLANs in Source of Truth pflegen, Drift vermeiden.

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.