QinQ Debugging: C-Tag/S-Tag Fehlerbilder und MTU-Fallen

QinQ Debugging ist eine Spezialdisziplin im VLAN/Trunk Troubleshooting – und genau deshalb in der Praxis oft ein Zeitfresser. Sobald ein Provider- oder Campus-Backbone doppelt getaggte Frames transportiert (C-Tag/S-Tag), entstehen Fehlerbilder, die auf den ersten Blick wie Routing-, Firewall- oder Applikationsprobleme wirken: einzelne Kunden-VLANs sind „tot“, ARP/MAC-Tabellen flappen, DHCP funktioniert nur sporadisch, oder große Transfers hängen – obwohl Links physikalisch stabil sind. Der Grund ist, dass QinQ (auch VLAN Stacking genannt) mehrere Fehlerklassen gleichzeitig ermöglicht: Tagging- und TPID-Mismatches, falsche Service-VLAN-Zuordnung, unerwartetes Tag-Stripping, MAC-Learning an der falschen Stelle, und besonders tückisch: MTU-Fallen durch zusätzlichen 802.1Q-Overhead. Wer QinQ Debugging professionell angehen will, braucht ein klares Modell: Wo wird der äußere S-Tag gesetzt, wo wird er entfernt, welche VLANs/Interfaces sind Customer Edge (CE) und Provider Edge (PE), welche Frames sollen untagged, single-tagged oder double-tagged laufen – und wie wird sichergestellt, dass alle beteiligten Links die tatsächliche Framegröße tragen können. Dieser Artikel zeigt Ihnen ein systematisches Vorgehen, um C-Tag/S-Tag Fehlerbilder sauber zu beweisen und QinQ-typische MTU-Fallen zuverlässig zu finden.

QinQ in einem Satz: Warum überhaupt zwei VLAN-Tags?

QinQ erlaubt es, Kunden-VLANs (C-Tags) transparent durch ein Provider- oder Backbone-Netz zu transportieren, indem ein zusätzlicher äußerer VLAN-Tag (S-Tag, Service Tag) hinzugefügt wird. So kann ein Provider viele Kunden mit identischen VLAN-IDs isoliert transportieren, weil die eigentliche Trennung im Backbone über das Service VLAN erfolgt – nicht über die Kunden-VLAN-ID.

• C-Tag (Customer Tag): innerer VLAN-Tag des Kunden, typischerweise 802.1Q mit TPID 0x8100
• S-Tag (Service Tag): äußerer VLAN-Tag des Providers/Backbones, oft 802.1ad/802.1Q-in-Q mit TPID 0x88A8
• CE (Customer Edge): Kundenseite/Access-Seite, die C-Tags liefert oder erwartet
• PE (Provider Edge): Provider-/Backbone-Kante, die S-Tag setzt (push) und entfernt (pop)

Für den Standards-Kontext rund um VLAN Bridging, Tagging und Provider Bridges ist die IEEE 802.1Q Standardseite die zentrale Referenz.

Frame-Aufbau verstehen: Was am Draht wirklich passiert

Die häufigsten QinQ-Fehler entstehen, weil Teams „VLAN“ als abstrakten Schalter betrachten, aber nicht den tatsächlichen Frame-Aufbau. Ein Ethernet-Frame mit einem VLAN-Tag enthält zusätzlich 4 Byte (TPID + TCI). QinQ fügt diese 4 Byte ein zweites Mal hinzu. Dazu können weitere Overheads kommen (z. B. LACP, MPLS, GRE/IPsec darüber, oder Provider-spezifische Header).

Einfaches Modell: Overhead durch Tags

• Untagged Ethernet: Payload bis 1500 Byte (klassisches Ethernet MTU-Modell)
• Single-Tagged (802.1Q): +4 Byte Tag-Overhead
• Double-Tagged (QinQ): +8 Byte Tag-Overhead

Warum das für MTU wichtig ist

Wenn ein Link nur „klassische“ 1500-Byte-Frames sauber durchlässt, können doppelt getaggte Frames (oder große IP-Pakete plus Tag-Overhead) verworfen werden – oft ohne klaren Alarm. Das erzeugt genau die Fehlerbilder, die im Betrieb so schwer zu greifen sind: kleine Requests funktionieren, große Transfers hängen, TCP Retransmissions steigen, und niemand findet „den“ kaputten Link.

Typische Fehlerbilder bei QinQ: Was Teams in Tickets wirklich sehen

QinQ-Probleme treten meist nicht als kompletter Ausfall auf, sondern als Teil- oder Last-/Größen-abhängige Störung. Diese Muster sind besonders häufig:

• Nur ein Kunden-VLAN betroffen: z. B. VLAN 20 des Kunden funktioniert nicht, VLAN 10 schon → häufig S-Tag-Mapping oder Allowed VLAN/Policy-Fehler am PE
• Nur bestimmte Standorte/PEs betroffen: Problem nur bei einem Übergang, nicht global → häufig MTU- oder TPID-Mismatch auf einem Segment
• ARP/DHCP instabil: Broadcast/ARP geht nicht sauber durch oder landet im falschen S-VLAN → Mapping/Tag-Stripping
• „Große Transfers hängen“: PMTUD/MTU-Falle durch Tag-Overhead → Blackhole-Verhalten
• MAC-Flapping im Backbone: MACs des Kunden werden an mehreren Provider-Ports gelernt → Loop, falsches QinQ-Handling oder Bridge-Domänen-Fehler

Die häufigsten Ursachen: C-Tag/S-Tag Fehlerklassen

TPID-Mismatch: 0x8100 vs. 0x88A8

Ein klassischer QinQ-Fallstrick ist die Tag-Identifikation (TPID). Viele Geräte erwarten für den äußeren Tag 0x88A8 (S-Tag). Manche Umgebungen nutzen jedoch 0x8100 auch für den äußeren Tag (vendor-/designabhängig). Wenn die Gegenstelle eine andere Erwartung hat, wird der äußere Tag nicht als solcher erkannt – und Frames werden entweder falsch einsortiert oder verworfen.

• Symptom: QinQ-Frames kommen an, aber landen im falschen VLAN oder werden gedroppt
• Evidence: PCAP zeigt Double-Tag, aber Gerät „sieht“ nur Single-Tag oder Unknown Tag
• Fix-Richtung: TPID-Einstellungen am Provider-Edge konsistent machen

Falsches S-VLAN-Mapping (Service VLAN Zuordnung)

Im Provider-/Backbone-Kontext ist der äußere S-Tag die zentrale Isolation. Wenn die Zuordnung „Kunde/Port → S-VLAN“ falsch ist, wird Kundenverkehr in das falsche Service VLAN gesteckt. Das ist ein Sicherheits- und Stabilitätsproblem.

• Symptom: Kunden-VLANs „leaken“ oder sind unidirektional, DHCP kommt aus falscher Domäne
• Evidence: MACs des Kunden tauchen im falschen S-VLAN auf, ARP antwortet „falsch“
• Fix-Richtung: Service-Instanz/Service-VLAN korrekt zuordnen, Templates/Validation nutzen

Tag-Stripping oder Tag-Push/Pop an der falschen Stelle

QinQ lebt davon, dass der äußere Tag am PE gesetzt und am korrekten Austritt wieder entfernt wird. Wenn ein Zwischenknoten Tags entfernt oder zusätzliche Tags setzt, entstehen schwer erklärbare Mischzustände.

• Symptom: C-Tag verschwindet (Kunde sieht plötzlich untagged), oder Frames kommen mit „zu vielen“ Tags
• Evidence: Captures vor/nach dem Segment zeigen unterschiedliche Tag-Tiefe
• Fix-Richtung: klare Tagging-Rollen (CE/PE) definieren, Zwischenbridges vermeiden

MAC-Learning an der falschen Stelle (Transparenz vs. Skalierung)

In manchen Designs soll der Provider Kunden-MACs transparent lernen (Layer-2-Transit), in anderen Designs soll MAC-Learning begrenzt werden (z. B. per EVPN/VPWS/Bridge-Domain-Design). Wenn die falsche Erwartung besteht, führen MAC-Move-Limits, Flooding oder Flapping zu Störungen.

• Symptom: MAC-Flapping, Unknown Unicast Flooding, sporadische Erreichbarkeit
• Evidence: MAC-Table zeigt häufige Moves; Logs melden „MAC move“ oder Limit-Events
• Fix-Richtung: Bridge-Domain sauber designen, MAC-Limits bewusst setzen und dokumentieren

MTU-Fallen bei QinQ: Die häufigste versteckte Root Cause

QinQ erhöht die Framegröße. Wenn auch nur ein Link im Pfad diese größere Framegröße nicht unterstützt, entstehen Drops, die wie „random“ wirken. Besonders gemein ist: Viele Monitoring-Setups messen nur IP-MTU (1500) und übersehen L2-Overhead (Tags). Für TCP-Verkehr führen Drops dann zu Retransmissions und Throughput-Einbrüchen. Für PMTUD gilt: Wenn ICMP-Feedback geblockt ist, entstehen PMTUD Blackholes, bei denen große Transfers hängen. Für PMTUD-Grundlagen sind RFC 1191 (IPv4) und RFC 8201 (IPv6) relevante Referenzen.

Pragmatische MTU-Rechnung für QinQ

Ein nützliches Modell ist, die effektive maximale Nutzlast zu berechnen, wenn ein Link nur eine bestimmte Framegröße zulässt. Wenn Ihr Link z. B. maximal 1522 Byte für 802.1Q akzeptiert (klassischer „Jumbo Light“-Grenzfall), kann QinQ schon zu groß sein.

$\mathrm{Overhead}\left(\mathrm{QinQ}\right)=8 \mathrm{Byte}$
$\mathrm{MaxPayload}=\mathrm{MaxFrame}–\mathrm{EthernetHeader}–\mathrm{Tags}–\mathrm{FCS}$

Die exakten Werte hängen von Ihrer Definition (Frame inkl./exkl. FCS, zusätzlich VLAN PCP/DSCP Mapping, ggf. zusätzliche Encapsulation) ab. Entscheidend ist: QinQ verlangt häufig eine höhere L2-MTU als klassische VLANs.

Typische MTU-Fehlerbilder im QinQ-Kontext

• Nur große Transfers betroffen: kleine Pakete (z. B. ARP, DNS) ok, große TCP Segmente hängen
• VPN/Overlay + QinQ: zusätzlicher Overhead stapelt sich; effektive Nutzlast sinkt drastisch
• Nur ein Segment betroffen: ein einzelner Provider-Link oder Medienkonverter akzeptiert keine größeren Frames
• Spurious Retransmissions: Delay/Queueing durch Fragmentation oder Drops, TCP verhält sich „komisch“ (siehe RFC 9293)

Evidence-first: Welche Daten Sie für QinQ Debugging wirklich brauchen

QinQ-Probleme lassen sich schnell lösen, wenn Sie von Anfang an die richtigen Beweise sammeln. Das Ziel ist, Tagging- und MTU-Hypothesen mit harten Daten zu bestätigen oder zu verwerfen.

• MAC Address Tables (VLAN-Kontext): Wo werden Kunden-MACs gelernt? In welchem S-VLAN?
• ARP-Tabellen und ARP-Traffic: ARP-Replies kommen aus der richtigen Domäne? Wechselnde Zuordnungen?
• Interface Counter: Drops/Discards (Queue/MTU) vs. CRC/Symbol Errors (Physik)
• STP/Loop-Indikatoren: Topology Changes, MAC-Flapping-Logs, Broadcast-Anomalien
• PCAP mit VLAN-Tags: Sichtbarer Nachweis von C-Tag/S-Tag, TPID, VLAN-IDs
• MTU-Sicht entlang des Pfads: L2 MTU auf allen beteiligten Links, nicht nur IP MTU

PCAP: Der schnellste Beweis für Tagging-Fehler

Ein kurzer Mitschnitt an PE-Ports (Ingress/Egress) beantwortet oft in Minuten die zentrale Frage: Kommen Frames mit dem erwarteten C-Tag an? Wird der S-Tag korrekt gepusht? Wird er am Ausgang korrekt gepoppt? Für Capture- und Analysepraxis sind die Wireshark-Dokumentation und die tcpdump-Manpage zuverlässige Referenzen.

• Sehen Sie zwei Tags (inner/outer) mit den erwarteten VLAN-IDs?
• Ist der TPID für S-Tag so, wie die Gegenstelle ihn erwartet?
• Kommt Traffic untagged an, obwohl er tagged sein sollte (oder umgekehrt)?

Systematisches Vorgehen: QinQ Debugging Schritt für Schritt

Das folgende Vorgehen ist so aufgebaut, dass Sie in kurzer Zeit die häufigsten Fehlerklassen trennen: Mapping/Tagging vs. MTU vs. L2-Loop/MAC-Themen.

Schritt 1: Scope präzisieren und Service-VLAN identifizieren

• Welche Kunden-Services/VLANs sind betroffen (C-VLANs)?
• Welches Service-VLAN (S-VLAN) ist zugeordnet?
• Ist es standort-/PE-spezifisch oder global (alle PEs)?

Schritt 2: Tagging-Rollen festnageln (CE/PE)

• Wer liefert den C-Tag? (Kunde, Hypervisor, AP, Access-Switch?)
• Wo wird der S-Tag gesetzt und entfernt (Provider Edge)?
• Gibt es Zwischenkomponenten, die Tags verändern könnten (Bridges, Medienkonverter, Firewalls im Transparent Mode)?

Schritt 3: Allowed VLANs und Service-Policies prüfen

• Ist das betroffene C-VLAN überhaupt erlaubt/erwartet auf der CE→PE Schnittstelle?
• Ist das S-VLAN im Backbone überall erlaubt/korrekt provisioniert?
• Bei Port-Channels: sind alle Members konsistent (Allowed VLANs, MTU, Tagging-Modus)?

Schritt 4: TPID und Tag-Tiefe verifizieren

• TPID-Einstellungen für äußeren Tag konsistent?
• Werden Frames korrekt als QinQ erkannt?
• Gibt es Fälle, in denen der äußere Tag als „normaler“ 802.1Q-Tag fehlinterpretiert wird?

Schritt 5: MTU-Falle ausschließen oder beweisen

• L2-MTU auf allen Links im QinQ-Pfad prüfen (besonders Provider-Übergänge, Medienkonverter, alte Switches)
• Symptomtrennmessung: funktionieren kleine Pakete zuverlässig, große Transfers nicht?
• Counter: steigen Drops/Discards bei großen Transfers? (nicht CRC, sondern Drops)
• Wenn PMTUD im Spiel: ICMP-„Packet Too Big“/„Fragmentation Needed“ nicht blockieren (gezielt erlauben)

C-Tag/S-Tag Fehlerbilder konkret zuordnen: Musterkatalog

Nur ein C-VLAN „verschwindet“

• Wahrscheinliche Ursache: C-VLAN nicht gemappt oder nicht erlaubt am PE; falsches Service-VLAN Mapping
• Nachweis: PCAP zeigt C-VLAN kommt an, aber S-Tag wird nicht gesetzt oder falsches S-VLAN
• Fix: Mapping/Policy korrigieren, Allowed VLANs end-to-end konsistent

Traffic landet im falschen Kundenkontext

• Wahrscheinliche Ursache: falsches S-VLAN, Native/untagged Leakage, TPID-Mismatch
• Nachweis: Kunden-MACs tauchen in falschem S-VLAN auf; ARP/DHCP kommt aus falscher Domäne
• Fix: Service-Instanz korrekt, untagged minimieren, TPID konsistent

„Groß hängt, klein geht“

• Wahrscheinliche Ursache: L2-MTU zu klein für QinQ (oder zusätzliches Overlay), PMTUD Blackhole
• Nachweis: Drops/Discards steigen bei großen Transfers; PCAP zeigt Retransmits; ICMP-Feedback fehlt
• Fix: L2-MTU erhöhen, MSS-Clamping (für TCP) an Kanten, ICMP gezielt erlauben

MAC-Flapping im Backbone

• Wahrscheinliche Ursache: Loop, Bridge-Domain-Fehler, falsches QinQ Handling an einem Zwischenknoten
• Nachweis: MAC-Moves zwischen Ports, STP TCNs, Broadcast-Anstieg
• Fix: Loop isolieren, QinQ-Konfiguration konsistent, Bridge-Domänen sauber trennen

Best Practices: QinQ stabil und debug-freundlich betreiben

• Design klar dokumentieren: CE/PE Rollen, S-VLAN pro Kunde/Service, erwartete C-VLANs
• TPID standardisieren: Outer Tag (S-Tag) konsistent, Interop mit Gegenstellen testen
• MTU von Anfang an planen: L2-MTU im Backbone und an Edges passend dimensionieren; Overhead-Kette (QinQ + Overlay) berücksichtigen
• Allowed VLANs bewusst pflegen: keine „alles erlauben“-Defaults, aber konsistente Templates und Validierung
• Telemetry auf Drops pro Interface: Drops/Discards sind Ihr Signal für MTU/Queueing; CRC/Symbol eher Physik
• Change-Markierung: QinQ-/VLAN-Änderungen als Events in Monitoring, damit Incidents schnell korrelierbar sind

Runbook-Baustein: QinQ Debugging in 15 Minuten

• Minute 0–3: Betroffenen Service identifizieren (C-VLANs, S-VLAN, Standorte/PEs), Symptomtyp (nur ein VLAN? groß hängt? MAC flaps?).
• Minute 3–6: Rollen klären (CE/PE), Allowed VLANs/Policies auf CE→PE Schnittstelle prüfen (inkl. Port-Channel Members).
• Minute 6–9: Tagging verifizieren: kurzer PCAP oder Interface-Insights (C-Tag/S-Tag, TPID, VLAN-IDs).
• Minute 9–12: MTU-Falle prüfen: L2-MTU entlang des Pfads, Drops/Discards bei großen Transfers, PMTUD/ICMP-Policy checken.
• Minute 12–15: Low-Risk Fix anwenden (Mapping/Allowed VLAN korrigieren oder MTU/MSS/ICMP sauber setzen) und sofort verifizieren (ARP/DHCP/Traffic-Test + Counter).

Weiterführende Quellen für Standards und Praxis

• IEEE 802.1Q Standardseite für VLAN Bridging, Tagging und Provider-Bridge-Kontext
• RFC 1191 für Path MTU Discovery unter IPv4 (relevant bei MTU-Blackholes durch QinQ-Overhead)
• RFC 8201 für Path MTU Discovery unter IPv6
• RFC 826 (ARP) für ARP als häufiges Symptom-/Evidence-Feld bei VLAN-/QinQ-Fehlern
• Wireshark Dokumentation für 802.1Q/QinQ-Analyse, ARP/DHCP-Inspection und Timing-Korrelation
• tcpdump Manpage für effiziente Captures und Filter (inkl. VLAN-Tagging)

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.