Site icon bintorosoft.com

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

Red Snapper

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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:

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

Exit mobile version