Das Hauptkeyword „QinQ-Troubleshooting“ beschreibt eine sehr konkrete, immer wiederkehrende Betriebsrealität in Provider- und Metro-Ethernet-Netzen: Kunden-VLANs (C-Tags) „gehen verloren“, sobald sie das Aggregation-Netz erreichen. Der Link ist dabei häufig stabil, OAM wirkt teilweise unauffällig, und dennoch kommen einzelne VLANs nicht am Ziel an oder funktionieren nur sporadisch. Typisch sind Symptome wie „einige VLANs gehen, andere nicht“, „Ping klappt nur mit kleinen Paketen“, „nach einem Change sind bestimmte Services tot“ oder „Broadcast läuft, aber Unicast nicht“. Ursache ist selten ein einzelner Fehler, sondern oft ein Zusammenspiel aus Tagging-Regeln, Allowed-VLAN-Listen, MTU-Overhead durch doppelte Tags, inkonsistentem TPID/Tag-Parsing, MAC-Learning-Policy, Storm-Control oder unerwarteten Rewrite-/Translation-Regeln. In großen Aggregationsdomänen verschärft sich das Problem, weil dieselben Trunks viele Services tragen: Ein kleiner Konfigurationsunterschied an einer Stelle kann tausende Kunden-VLANs beeinflussen. Dieser Artikel liefert ein operatives Framework, um QinQ-Probleme reproduzierbar zu isolieren: vom mentalen Modell (C-Tag, S-Tag, Mapping) über typische Failure Modes bis zu einer praxistauglichen Schrittfolge im NOC, die „Trial-and-Error“ ersetzt und die Fault Domain sauber eingrenzt.
Das mentale Modell: Wo VLANs „verschwinden“ können
Bevor Sie messen oder „blind“ konfigurieren, lohnt sich eine klare Vorstellung, an welchen Punkten Kunden-VLANs im QinQ-Design verschwinden können. QinQ transportiert C-Tags innerhalb eines Provider-Service-Tags (S-Tag). Operativ gibt es drei kritische Übergänge:
- UNI (Customer Edge ↔ Provider Edge): hier entsteht das S-Tag (Push), oder C-Tags werden gemappt/übersetzt.
- Aggregation/Metro-Trunk: hier muss das Netzwerk doppelte Tags korrekt weiterleiten (Tag-Preservation, MTU, Policies).
- NNI/Remote-UNI (Provider Edge ↔ Ziel): hier wird das S-Tag entfernt (Pop) oder erneut gemappt, und C-Tags müssen in der erwarteten Form ausgeleitet werden.
„Verloren“ heißt in der Praxis fast immer: Frames werden gedroppt, falsch klassifiziert (landen im falschen Service), oder sie werden so verändert, dass das Ziel sie nicht mehr akzeptiert. Die zugrunde liegenden Bridging- und VLAN-Mechanismen sind in IEEE 802.1Q beschrieben; für Dienstmodelle und Provider-Operabilität ist der MEF-Kontext hilfreich, z. B. über MEF Resources.
Symptome richtig lesen: Was „VLAN verloren“ konkret bedeuten kann
Ein häufiger Fehler ist, alle QinQ-Probleme unter einem Symptom zusammenzufassen. Für schnelles Troubleshooting sollten Sie das Fehlerbild präzisieren:
- Einzelne VLANs betroffen: deutet auf Allowed-VLAN, Mapping/Translation, Policy oder eine falsche C-VLAN-Range hin.
- Alle VLANs betroffen, Link up: deutet auf falsches UNI-Profil (tagged/untagged), falsches S-VLAN, falsche Service-Zuordnung oder Pop/Push an der falschen Stelle hin.
- Nur große Pakete betroffen: klassisches MTU-/Overhead-Problem durch zusätzliche Tags oder zusätzliche Encapsulation.
- Intermittierend, flappend: häufig MAC-Learning/Flapping, Loop/Storm-Control oder Control-Plane-Policing (stille Drops).
- Broadcast ok, Unicast schlecht: häufig MAC-Lernen blockiert, MAC-Limits erreicht, oder Flooding-Policy greift unerwartet.
Diese Einordnung spart Zeit, weil sie die ersten Hypothesen fokussiert und verhindert, dass Sie zu früh „im Core“ suchen, obwohl die Ursache am UNI liegt.
Die häufigsten Root Causes in QinQ-Aggregationsnetzen
In der Praxis lassen sich die meisten QinQ-Outages auf wenige Klassen von Ursachen zurückführen. Die folgenden Punkte sind besonders häufig, weil sie bei Changes und Migrationen „leicht“ passieren:
- Allowed-VLAN-Listen inkonsistent: Trunks transportieren nicht alle C-VLANs oder S-VLANs, obwohl der Service es erwartet.
- Falsches UNI-Tagging-Profil: Provider erwartet C-tagged, Kunde sendet untagged (oder umgekehrt); Frames werden gedroppt oder in ein Default-VLAN gelegt.
- S-VLAN-Kollisionen oder falsches Service-Tag: ein C-VLAN wird im falschen S-VLAN transportiert und landet im falschen Dienst.
- VLAN-Translation/Rewrite greift unerwartet: C-VLAN wird umgeschrieben oder gepusht/popped an einer falschen Stelle.
- MTU zu klein: doppelte Tags überschreiten die zulässige Framegröße; große Frames verschwinden „still“.
- TPID-/Tag-Parsing-Mismatch: die Hardware erkennt das äußere Tag nicht als S-Tag (oder interpretiert es falsch).
- MAC-Scale/Policy: MAC-Limits, Aging, oder Anti-Spoofing führen zu Drops oder Flooding.
Schritt 1 im NOC: Service-Identität und Tagging-Vertrag prüfen
QinQ-Troubleshooting scheitert oft daran, dass Teams „technisch messen“, bevor sie sicher sind, welche Tagging-Form überhaupt erwartet wird. Beginnen Sie daher immer mit Service-Identität und Vertrag:
- Welche UNI-Variante? Port-based (untagged) oder VLAN-based (C-tagged)?
- Welche C-VLANs sind vereinbart? einzelne VLAN-ID, Range, oder „transparent“?
- Welche S-VLAN-ID ist zugeordnet? pro Service oder gebündelt für mehrere C-VLANs?
- Gibt es VLAN-Translation? C-VLAN-Umsetzung ja/nein, und wenn ja: Mapping-Tabelle korrekt?
Ohne diese Basis kann jeder Test irreführend sein, weil Sie möglicherweise genau das „falsche“ VLAN testen.
Schritt 2: Tagging-Pfade verifizieren – nicht raten
„VLAN geht verloren“ ist häufig ein Tagging-Problem. Deshalb ist es entscheidend, Tags tatsächlich zu verifizieren. Operativ gibt es drei robuste Methoden:
- Switch/Router-Zähler pro VLAN: prüfen, ob Frames für das betroffene C-VLAN/S-VLAN überhaupt gezählt werden (Ingress/Egress).
- Gezielte Testframes: Testtraffic mit definiertem C-Tag erzeugen und nachvollziehen, ob er im S-Tag landet.
- Packet Capture / Mirror (wo möglich): Sicht auf tatsächliche Tags am UNI und an der Aggregation (besonders bei schwer reproduzierbaren Fällen).
Wichtig ist, beide Richtungen zu prüfen. Einseitige Probleme entstehen z. B. durch asymmetrische Allowed-VLAN-Listen oder unterschiedliche Rewrite-Policies.
MTU und Overhead: Der stille Killer bei QinQ
QinQ fügt zusätzliche VLAN-Tags hinzu. Jeder VLAN-Tag ist 4 Byte. Bei doppeltem Tagging kommt zum bestehenden 802.1Q-Tag ein weiteres Tag hinzu. Viele Geräte können „baby giant frames“ oder Jumbo Frames, aber nur, wenn es end-to-end konsistent ist. Eine vereinfachte Overhead-Rechnung (ohne Präambel/IFG) sieht so aus:
Dabei ist
- Discards ohne Link-Down: Drops steigen bei hoher Last oder großen Frames.
- Nur bestimmte Anwendungen betroffen: Applikationen mit großen Segmenten/Encapsulation brechen zuerst.
- Asymmetrie: nur eine Richtung hat MTU-Probleme, wenn Policies oder Hardware-Pfade unterschiedlich sind.
TPID und Tag-Parsing: Wenn das S-Tag nicht als S-Tag erkannt wird
Ein unterschätzter Fallstrick ist die Interpretation des äußeren Tags. Provider-Designs nutzen häufig ein „Service Tag“ mit definiertem TPID (Tag Protocol Identifier). Wenn ein Gerät oder ein Zwischenprovider dieses Tag nicht korrekt interpretiert, kann es Frames droppen oder falsch behandeln. Operativ äußert sich das oft so:
- Alle C-VLANs betroffen, aber nur über bestimmte Trunks: deutet auf Tag-Parsing-Inkompatibilität in einem Segment hin.
- VLANs „leaken“ oder werden falsch zugeordnet: das äußere Tag wird nicht als Service-Klasse erkannt.
- OAM wirkt inkonsistent: weil OAM-Frames ggf. anders behandelt werden als Nutzframes.
Wenn mehrere Domänen beteiligt sind, sollten Sie den Tagging-Standard an der NNI explizit prüfen: Welche TPID-Werte sind erlaubt, und welche Erwartung hat der Transit?
Allowed-VLAN und Bundling: Warum „ein VLAN fehlt“ meist ein Listenproblem ist
Wenn einzelne Kunden-VLANs nicht ankommen, ist die häufigste Ursache eine fehlende VLAN-Freigabe auf einem Trunk oder eine inkonsistente Bundling-Konfiguration. Das passiert oft nach:
- Hardwaretausch: Default-Konfigurationen unterscheiden sich, Allowed-Listen werden nicht vollständig migriert.
- Neuem Uplink/Redundanzpfad: ein alternativer Pfad hat nicht dieselben VLANs freigegeben.
- Service-Erweiterung: neue C-VLANs werden am UNI ergänzt, aber nicht durchgängig bis zum NNI propagiert.
Operative Gegenmaßnahme: pro Dienstklasse eine standardisierte „VLAN-Propagation“-Validierung, die nicht nur das „Haupt-VLAN“ testet, sondern bewusst mehrere VLANs aus dem vereinbarten Spektrum.
VLAN-Translation und Rewrite: Der Fallstrick, der wie „zufällig“ wirkt
VLAN-Translation ist nützlich, aber im Betrieb riskant, wenn sie nicht streng standardisiert wird. Häufige Fehlerbilder:
- Nur bestimmte VLANs betroffen: Mapping-Tabelle ist lückenhaft oder überschneidet sich.
- VLAN funktioniert an Standort A, nicht an Standort B: Translation ist nicht symmetrisch konfiguriert.
- „Falscher“ Dienst bekommt Traffic: C-VLAN wird in eine ID übersetzt, die zu einem anderen Service gehört.
Ein einfaches Mapping lässt sich als Funktion ausdrücken, die einem Kunden-VLAN eine Ziel-VLAN-ID zuweist:
Operativ ist weniger die Formel relevant, sondern die Konsequenz: Translation muss vollständig, konfliktfrei und bidirektional nachvollziehbar sein. Sobald „Sonderfälle“ entstehen, steigt die Fehlerquote im Change dramatisch.
MAC-Learning, MAC-Limits und Unknown-Unicast: Wenn Unicast „verschwindet“
Ein QinQ-Dienst kann auf Layer 2 völlig „an“ wirken, aber Unicast-Traffic geht trotzdem verloren, wenn MAC-Learning nicht wie erwartet funktioniert. Typische Ursachen:
- MAC-Limit pro UNI erreicht: neue MACs werden nicht mehr gelernt, Frames werden gedroppt oder gefloodet.
- MAC-Flapping: dieselbe MAC taucht auf unterschiedlichen Ports auf (Loop, falsche Patchung, Multihoming ohne saubere Policy).
- Aging inkonsistent: MACs altern zu schnell oder zu langsam, was zu unvorhersehbarem Flooding führt.
- Security/Anti-Spoofing: Frames werden verworfen, weil sie nicht zum erwarteten Profil passen.
Operativ sollten Sie bei „Broadcast ok, Unicast nicht“ immer prüfen: Wird die Kunden-MAC auf beiden Enden gelernt? Gibt es Flap-Events? Und ist ein MAC-Limit der „stille Dropper“?
Storm-Control und Loop-Szenarien: Wenn Schutzmechanismen VLANs „abschneiden“
Aggregation-Netze schützen sich häufig mit Storm-Control gegen Broadcast/Multicast/Unknown-Unicast. Das ist sinnvoll, kann aber VLAN-spezifisch oder service-spezifisch zu Drops führen, die wie „VLAN verloren“ wirken. Typische Muster:
- Probleme nur bei bestimmten Lastprofilen: z. B. ARP/ND-Stürme oder Multicast-Discovery lösen Drops aus.
- Nur Multipoint-Dienste betroffen: große Broadcast-Domains erhöhen das Risiko.
- Nach Kundenänderung plötzlich instabil: neue Applikation erzeugt mehr Broadcast/Multicast, Policy greift.
Wenn Loops möglich sind, wird das Problem schnell kritisch. Transparenz von Kunden-STP oder unkontrollierte L2-Topologien sind ein klassischer Carrier-Fallstrick. Hier hilft nur eine klare Provider-Policy: welche Control-Frames werden transportiert, welche werden gefiltert, und welche Guardrails sind verpflichtend.
Ethernet OAM richtig nutzen: CFM und Performance-Messungen als Abkürzung
Ohne OAM ist QinQ-Troubleshooting oft Ratespiel. Zwei Bausteine sind im Provider-Alltag besonders wertvoll:
- Connectivity Fault Management (CFM): ermöglicht Segment- und End-to-End-Konnektivitätstests auf Layer 2.
- Performance OAM: Messungen von Delay, Jitter und Loss helfen, „geht nicht“ von „geht schlecht“ zu unterscheiden.
Für CFM ist IEEE 802.1ag (historisch) eine gängige Referenz, und für Performance-Messungen ist ITU-T Y.1731 zentral. Operativ sinnvoll ist eine Fault-Domain-Struktur:
- UNI-Domain: prüft lokale Kundenanbindung.
- Aggregation-Domain: prüft Metro-Segment (Trunks, Ring, Aggregationsswitches).
- E2E-Domain: prüft den Dienst über alle Domains hinweg.
Wenn ein VLAN „verloren“ geht, kann OAM helfen, exakt zu zeigen, bis wohin es funktioniert, und ob es ein Connectivity- oder ein Performance-Problem ist.
Multi-Provider- und NNI-Szenarien: Wenn QinQ unterwegs verändert wird
Besonders schwierig wird QinQ-Troubleshooting, wenn ein Dienst über mehrere Betreiber läuft oder wenn NNI-Übergaben im Spiel sind. Typische Risiken:
- S-VLAN-Kollisionen: zwei Domänen nutzen dieselbe S-VLAN-ID, Traffic landet im falschen Service.
- Filter auf Control-/OAM-Frames: CFM/Y.1731 wird unterwegs gefiltert, Diagnosen werden „blind“.
- MTU-Policy bricht im Transit: ein Segment akzeptiert die zusätzlichen Tags nicht, große Frames verschwinden.
- Unterschiedliche Transparenzregeln: bestimmte Ethertypes oder VLAN-Ranges werden unterwegs verworfen.
In solchen Szenarien ist es essenziell, technische Übergabeparameter vertraglich zu fixieren: Tagging-Form, MTU, OAM-Transparenz und SRLG/Fault-Domain-Definitionen. Ohne diese Vereinbarungen wird das NOC zum Eskalations-Hub statt zur Diagnoseinstanz.
Change-Window-Fallen: Warum QinQ-Probleme oft nach „kleinen“ Änderungen auftreten
Viele QinQ-Outages passieren nach vermeintlich harmlosen Changes, weil QinQ in Aggregationsnetzen stark von Konsistenz lebt. Häufige Change-Fallen:
- Neuer Uplink mit Default-MTU: der alte Pfad konnte größere Frames, der neue nicht.
- Neue Template-Version: Allowed-VLAN-Listen, CoPP oder OAM-Policies unterscheiden sich unbemerkt.
- Service-Erweiterung ohne End-to-End-Propagation: C-VLAN wird am UNI ergänzt, aber nicht bis zum NNI.
- Umbau im ODF/Panel: falsche Patchung oder Portprofil verändert Tagging-Verhalten.
Eine wirksame Gegenmaßnahme ist eine standardisierte Validierung, die Tagging, MTU und MAC-Learning explizit prüft – nicht nur „Interface up“ oder „ein Ping“.
Praxis-Runbook: QinQ-Troubleshooting in 12 reproduzierbaren Schritten
- Service identifizieren: Dienst-ID, UNI/NNI, S-VLAN, vereinbarte C-VLANs, Translation-Regeln.
- Scope eingrenzen: betroffenes einzelnes VLAN oder mehrere? nur groß/klein? nur eine Richtung?
- Letzte Changes prüfen: Patch, Portprofil, Template, Uplink, Hardwaretausch, NNI-Änderungen.
- Ingress-Zähler am UNI prüfen: sieht der Provider Frames des betroffenen C-VLANs?
- Tagging am UNI verifizieren: untagged/tagged, C-VLAN korrekt, keine unerwarteten Rewrite-Regeln.
- S-VLAN-Klassifizierung prüfen: landet der Traffic im erwarteten Service-Tag?
- Allowed-VLANs am Trunk: S-VLAN/C-VLAN-Range durchgängig erlaubt?
- MTU testen: große Frames mit definiertem VLAN, beide Richtungen, Drops/Discards beobachten.
- MAC-Learning prüfen: wird die Kunden-MAC gelernt? Flapping? MAC-Limit erreicht?
- Storm-Control/Loop-Indikatoren: Broadcast/Unknown-Unicast, Policers, CPU-Spikes, Drop-Counter.
- OAM einsetzen: CFM-Tests pro Fault Domain, bei Bedarf Y.1731 Loss/Delay.
- Nachweis sichern: Vorher/Nachher Counter, OAM-Ergebnisse, Tagging-Validierung, Change-Verknüpfung.
Outbound-Referenzen für Standards und operative Vertiefung
- IEEE 802.1Q: VLAN- und Bridging-Grundlagen, inklusive Provider-Bridging-Konzepte
- IEEE 802.1ag: Connectivity Fault Management (CFM)
- ITU-T Y.1731: Ethernet OAM Performance-Messungen (Loss/Delay/Jitter)
- MEF Resources: Metro-Ethernet-Dienstmodelle und Best Practices
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.
