Metro Ethernet QinQ: Kunden-VLANs troubleshooten (Step-by-Step)

Metro Ethernet QinQ ist in Provider-Netzen ein Standardmechanismus, um Kunden-VLANs transparent über ein Provider-Backbone zu transportieren: Das Kunden-VLAN (C-Tag) bleibt erhalten, während der Provider ein zusätzliches Service-VLAN (S-Tag) „außen“ ergänzt. Genau diese Doppel-Tagging-Logik macht Troubleshooting anspruchsvoll, weil Fehler an mehreren Stellen auftreten können: falsches Tagging am UNI, falsche S-Tag-Zuordnung im Aggregationsnetz, MTU-Probleme durch zusätzlichen Overhead, falsche Class-of-Service-Markierung, MAC-Learning in unerwarteten Domänen oder Filter/Rewrite-Regeln, die nur bestimmte VLANs betreffen. Für NOCs und Field-Teams ist daher ein reproduzierbares Step-by-Step-Vorgehen entscheidend, damit „Kunde VLAN 120 geht nicht“ nicht in endlosen Ping-Tests endet, sondern in einer klaren Fault Domain: UNI/CE, Provider Edge (PE), Aggregation (NID/Access/Metro), Core (P/Transport) oder Übergang zu weiteren Services (EVPN/VPLS/Bridge-Domain). Dieser Leitfaden zeigt ein praxisnahes Vorgehen, um Kunden-VLANs in Metro Ethernet QinQ sauber zu troubleshooten: von der schnellen Basiseinordnung über Tagging- und MTU-Verifikation bis zu MAC-/ARP-Checks, Loop- und Filtering-Fallen, sowie konkreten Post-Checks, damit der Fix nachhaltig ist.

Grundlagen: Was bei QinQ technisch passiert

Bei QinQ werden Ethernet-Frames mit zwei VLAN-Tags transportiert. Das innere Tag (C-Tag) trägt die Kunden-VLAN-ID (C-VID). Das äußere Tag (S-Tag) trägt die Service-VLAN-ID (S-VID) des Providers. Entscheidend ist, dass die Grenzen klar sind:

• UNI (User Network Interface): Kundenübergabe. Kunde sendet typischerweise C-Tagged oder untagged Frames, abhängig vom Vertrag.
• Provider Edge / NID: setzt S-Tag auf (Push) oder entfernt S-Tag (Pop) und mappt Service/CoS.
• Metro/Core: transportiert S-Tags über das Provider-Netz (Bridging/Transport-Mechanismus je nach Architektur).

Normativer Kontext: VLAN-Tagging und Bridging basieren auf IEEE 802.1Q. Für eine präzise Begriffs- und Funktionsbasis sind IEEE 802.1Q und die Service-Definitionen der Metro Ethernet Forum (MEF) hilfreich, z. B. MEF Specifications.

Typische Fehlerbilder bei QinQ: Schnellklassifikation vor dem Deep Dive

Bevor Sie in Detailprüfungen gehen, lohnt sich eine schnelle Klassifikation. Viele QinQ-Tickets lassen sich bereits über das Muster eingrenzen.

• Nur ein Kunden-VLAN betroffen: häufig Mapping-/Filter-Regel, falsche VLAN-Liste am UNI, oder „VLAN Translation“ nur teilweise.
• Mehrere VLANs betroffen, aber nicht alle: häufig MTU/Fragmentierungs- oder CoS/Policing-Effekt bei bestimmten Pakettypen.
• Alles tot (kein Traffic): häufig S-VID falsch, UNI falsch provisioniert, Port im falschen Mode, oder physische/Link-Down-Probleme.
• Intermittierend / Flapping: häufig Loop/Storm-Control, MAC-Flapping, LACP/Port-Channel-Inkonsistenz, oder fehlerhafte OAM/CFM-Konfiguration.
• Nur Broadcast/ARP geht nicht (oder nur ARP geht): häufig MAC-Learning/Filtering, unbekannte Unicast-Policies, oder Split-Horizon/Bridge-Domain-Regeln.

Step-by-Step: QinQ Troubleshooting von außen nach innen

Das Ziel ist, jede Stufe mit einem klaren „Pass/Fail“ zu prüfen und die Fault Domain zu isolieren. Der Ablauf ist bewusst so gestaltet, dass er ohne PCAP funktioniert, aber optional PCAP/OAM nutzen kann, wenn verfügbar.

Schritt: Ticketdaten und Service-Intent verifizieren

Viele QinQ-Probleme sind schlicht ein Missverständnis über den Service-Intent. Prüfen Sie zuerst, was vertraglich und technisch vereinbart ist:

• UNI-Mode: untagged (Port-based), single-tagged (C-Tag), oder QinQ (C-Tags transparent).
• C-VID-Liste: welche Kunden-VLANs sind erlaubt? Gibt es eine Range (z. B. 100–199) oder eine explizite Liste?
• S-VID: welche Service-VLAN-ID wird im Provider-Netz verwendet?
• VLAN Translation: wird C-VID übersetzt (C-VID remapping) oder transparent übertragen?
• CoS/PCP/DEI-Regeln: wird 802.1p (PCP) übernommen, neu gesetzt oder gemappt?
• MTU-Vereinbarung: Standard (1500) oder Jumbo (z. B. 9000) – und gilt sie End-to-End?

Schritt: Layer-1/Link-Health am UNI sicherstellen

Auch wenn das Problem „VLAN“ heißt: QinQ-Troubleshooting ohne saubere Link-Health ist Zeitverschwendung. Prüfen Sie am Provider-UNI (PE/NID-Port):

• Link State: up, keine Flaps, korrekte Speed/Duplex/Autoneg.
• Errors: CRC/Alignment, Drops, Pause-Frames, ggf. FEC/PCS (bei optischen Interfaces).
• Optik (wenn relevant): Rx/Tx dBm und Drift, um Mikro-/Makrobend oder Steckerprobleme auszuschließen.

Schritt: Tagging am UNI prüfen

Der häufigste QinQ-Fehler ist falsches Tagging am Übergabepunkt. Wichtig ist, dass Sie zwischen „Kunde sendet falsch“ und „Provider verarbeitet falsch“ unterscheiden.

UNI-Tagging-Fragen

• Sendet der Kunde C-Tagged oder untagged? Wenn untagged erwartet wird, darf kein C-Tag ankommen (und umgekehrt).
• Ist das C-Tag in der Allow-Liste? Viele Geräte droppen VLANs, die nicht explizit erlaubt sind.
• Ist die Native VLAN Logik konsistent? Native VLAN Mismatch kann dazu führen, dass untagged Frames falsch zugeordnet werden.

Wenn Sie Remote Hands oder NID-Tools haben, sind einfache „VLAN-Tag presence“-Checks (ohne Payload) oft ausreichend: Sie müssen nicht den Inhalt sehen, sondern nur, ob Frames mit C-VID X überhaupt ankommen.

Schritt: S-Tag Push/Pop und S-VID-Zuordnung verifizieren

Wenn der UNI korrekt ist, muss der Provider Edge/NID korrekt QinQ anwenden. Typische Fehler: falsche S-VID, falsche Richtung (Pop auf falscher Seite), oder inkonsistente Zuordnung bei redundanten PEs.

• S-VID korrekt? Ein falsches Service VLAN kann den Traffic in eine falsche Bridge-Domain schicken oder komplett droppen.
• Symmetrisch? Beide Richtungen müssen konsistent sein: C→S (Push) am ingress und S→C (Pop) am egress.
• Redundanzfall: Bei dual-homed Setups müssen beide PEs die gleiche Service-Definition haben, sonst entsteht MAC-Flapping oder Blackholing.

Schritt: MTU und Overhead – der stille Killer bei QinQ

QinQ fügt zusätzlichen Overhead hinzu: Zwei VLAN-Tags bedeuten typischerweise 8 Bytes zusätzlich gegenüber untagged Ethernet. In der Praxis scheitern Services nicht, weil VLAN „falsch“ ist, sondern weil einzelne Pakettypen (z. B. größere TCP-Segmente, bestimmte Encapsulations) über die effektive MTU laufen und dann gedroppt werden. Das wirkt wie „manchmal geht’s, manchmal nicht“.

VLAN-Overhead und effektive Nutzlast (MathML)

$\mathrm{EffectivePayload}=\mathrm{L2\_MTU}-\mathrm{EthernetHeader}-\mathrm{VLANOverhead}$
$\mathrm{VLANOverhead}=4\times \mathrm{TagCount}$

• TagCount: 2 bei QinQ (C-Tag + S-Tag)
• Praktische Konsequenz: Wenn Geräte strikt 1500 Bytes L2-MTU erwarten, kann QinQ zu Drops führen, wenn nicht korrekt konfiguriert.

MTU-Checks (praxisnah)

• UNI-MTU: ist am UNI-Port eine erhöhte MTU konfiguriert, die QinQ-Frames erlaubt?
• End-to-End-MTU: ist die MTU durchgehend im Metro/Core vorhanden oder gibt es einen „kleinen“ Knoten?
• Symptom-Muster: kleine Pings gehen, große Payloads scheitern; TCP zeigt Retransmissions; bestimmte Applikationen brechen ab.

Schritt: MAC Learning, Flooding-Policies und unbekannte Unicast-Fallen

QinQ ist meist ein Bridging-Service. Damit sind MAC-Learning und Flooding-Policies zentral. Viele „VLAN geht nicht“-Tickets sind in Wirklichkeit MAC-Learning-Probleme: MAC wird nicht gelernt, wird in falscher Domain gelernt oder flapped zwischen Ports.

• MAC wird gelernt? Prüfen Sie, ob die CE-MAC auf dem erwarteten UNI-Port in der richtigen Service-Domain auftaucht.
• MAC-Flapping? Wenn dieselbe MAC zwischen Ports wechselt, droppen Systeme häufig oder aktivieren Schutzmechanismen.
• Unknown Unicast Handling: Einige Provider-Designs flooden unbekannten Unicast nicht (Security/Scale). Dann sieht der Kunde „ARP geht, aber Unicast nicht“ oder umgekehrt.
• MAC Limits/Storm Control: Wenn ein Kunde zu viele MACs sendet, kann der Port limitiert und Traffic teilweise gedroppt werden.

Schritt: ARP, Broadcast und Control-Plane-Symptome richtig lesen

Viele Kunden melden „VLAN tot“, aber das eigentliche Problem ist, dass ARP nicht funktioniert oder Broadcast gefiltert wird. QinQ-Services müssen definieren, wie Broadcast/Multicast/Unknown-Unicast behandelt werden. Ein typisches Muster:

• ARP Requests gehen raus, keine Replies: Rückweg blockiert (S-Tag Pop, ACL, MAC-Learning, MTU).
• ARP Reply kommt, aber Unicast bricht ab: unknown-unicast-policy oder MAC wird nicht stabil gelernt.
• Broadcast Storm: Loop im Kunden-LAN oder in der Provider-Bridge-Domain; dann greifen Storm-Control und wirken wie „teilweise tot“.

Schritt: VLAN-Liste, Rewrite-Regeln und „Teilweise erlaubt“-Konfigurationen prüfen

Wenn nur bestimmte C-VLANs betroffen sind, ist die Wahrscheinlichkeit hoch, dass eine VLAN-Liste, eine Rewrite-Regel oder eine Translation-Tabelle nicht vollständig ist. Häufige Ursachen:

• Allow-List unvollständig: z. B. VLAN 120 fehlt, VLAN 121–130 sind erlaubt.
• Translation-Kollision: zwei C-VIDs werden auf dieselbe interne ID gemappt.
• QinQ-Selective: nur ein Subset wird „getunnelt“, andere VLANs werden wie normaler Access behandelt.
• Range vs. Liste: ein Range wurde falsch interpretiert (z. B. inklusiv/exklusiv).

Schritt: QoS/PCP/DEI- und Policing-Fallen

QinQ bringt zwei PCP-Felder (im inneren und äußeren Tag). Je nach Design übernimmt der Provider das Kunden-PCP, mappt es auf S-Tag-PCP oder überschreibt es. Fehler hier führen zu schwer erklärbaren Performance-Problemen: bestimmte VLANs oder Traffic-Klassen werden gedroppt oder hart policed.

• PCP-Mapping prüfen: wird Kunden-PCP übernommen oder ignoriert?
• Policer per S-VID: wenn Policing am Service-VLAN hängt, können alle Kunden-VLANs gemeinsam limitiert sein.
• Policer per C-VID: wenn Policing pro Kunden-VLAN gilt, können einzelne VLANs auffällig sein.
• Symptom: Connectivity ok, aber Durchsatz/Latency schlecht, besonders bei Last.

Schritt: OAM/CFM als Troubleshooting-Beschleuniger (wenn vorhanden)

In vielen Metro-Ethernet-Designs wird Ethernet OAM (CFM/Y.1731) genutzt, um Services ohne PCAP zu prüfen. Wenn Ihr Netz OAM bereitstellt, ist es ein extrem effizientes Mittel zur Fault-Domain-Isolierung. Ein Standardspezifikationsanker ist IEEE 802.1Q für CFM-Grundlagen; für Provider-Service-Definitionen sind MEF-Dokumente hilfreich (siehe MEF Specifications).

• Continuity Check: zeigt, ob die Service-Domain End-to-End erreichbar ist.
• Loopback/Linktrace: hilft, die Stelle zu finden, an der Frames nicht weiterkommen.
• Delay/Loss Measurements: verifizieren Servicequalität und zeigen, ob ein Problem „nur“ VLAN ist oder bereits Performance betrifft.

Schritt: Redundanz, Dual-Homing und Split-Brain-Fallen

Viele Metro-Ethernet-Services sind redundant: zwei UNIs, zwei PEs, LAGs, Ring-Protection oder EVPN/VPLS-Backends. Hier entstehen QinQ-Probleme oft durch inkonsistente Konfiguration zwischen den Pfaden.

• Symmetrie: Beide PEs müssen identische VLAN-/Service-Definitionen haben (S-VID, C-VID-Liste, Rewrite, QoS).
• MAC Mobility: Wenn MACs zwischen Pfaden wechseln, müssen die Control-Plane-Mechanismen korrekt arbeiten, sonst Blackholing.
• LAG-Konsistenz: VLAN-Liste, MTU, QoS müssen auf allen Member-Ports identisch sein.
• Protection Events: wenn ein Ring/Span switched, prüfen Sie, ob der Service auf dem Schutzpfad dieselben MTU- und VLAN-Policies hat.

Step-by-Step Runbook: In 15 Minuten zur Fault Domain

• Minute 0–2: Service-Intent verifizieren (UNI-Mode, C-VID-Liste, S-VID, MTU, QoS).
• Minute 2–5: Link/Errors am UNI prüfen, optische Werte bei Bedarf, Flaps/CRC ausschließen.
• Minute 5–7: Tagging prüfen: kommt das erwartete C-Tag an? Ist VLAN erlaubt? Native VLAN konsistent?
• Minute 7–9: S-Tag Mapping prüfen: korrektes S-VID, Push/Pop, redundante PEs konsistent?
• Minute 9–11: MTU testen: große Pakete, QinQ-Overhead, Drops/Policer-Indizien.
• Minute 11–13: MAC/ARP prüfen: wird MAC gelernt? Flapping? Unknown Unicast Policy?
• Minute 13–15: QoS/Policing und OAM prüfen; Entscheidung: UNI/CE, PE/NID, Metro/Core oder Redundanzproblem.

Post-Fix-Validation: Pflichtchecks, damit der Fehler nicht zurückkommt

Nach dem Fix ist das wichtigste Ziel, Stabilität nachzuweisen und „Second Incidents“ zu verhindern. Prüfen Sie nicht nur Connectivity, sondern auch Qualität und Konsistenz.

• Stabilitätsfenster: mindestens 10–30 Minuten ohne Flaps/Errors, je nach Kritikalität länger.
• MTU bestätigt: große Payloads funktionieren, keine Drops/Policer-Spikes.
• MAC stabil: kein Flapping, MAC-Limits nicht erreicht.
• QoS konsistent: gewünschte Klassen werden korrekt bedient, keine unerwarteten Drops.
• Dokumentation: aktualisierte C-VID-Liste, S-VID, Port-Mode und MTU in Inventory/Ticket.

Evidence Pack: Welche Daten Sie bei QinQ-Tickets immer sichern sollten

• Service-Intent: UNI-Mode, C-VID-Liste, S-VID, QoS/PCP-Regeln, MTU.
• Zeitfenster (UTC): Beginn, Peak, Fix-Zeitpunkt, Stabilitätsfenster.
• UNI-Telemetrie: Link-State, CRC/Errors/Drops, ggf. optische DOM-Werte.
• MAC/ARP-Sicht: learned MACs, MAC-Flapping-Indizien, ARP-Resolution-Status.
• MTU-Tests: Testergebnisse für kleine vs. große Payloads, ggf. OAM-Delay/Loss.
• Konfigurationsdiff: welche Allow-List/Rewrite/Translation wurde geändert.

Outbound-Ressourcen

• IEEE 802.1Q (VLAN Bridging, CFM/OAM-Kontext)
• MEF Specifications (Metro Ethernet Services, E-Line/E-LAN, OAM-Kontext)
• RFC 2685 (VLAN Bridging: Architektur- und Terminologie-Kontext)
• RFC 7432 (EVPN: relevant, wenn QinQ in EVPN-Backends terminiert)

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.