VLAN dual-tagging QinQ configuration FAQ: Expert Answers to Technical & Deployment Questions

Overview & Thematic Scope

This FAQ covers technical and deployment aspects of VLAN dual-tagging (IEEE 802.1ad QinQ) for service providers, data centers, and enterprise edge networks. Topics include configuration prerequisites, TPID compatibility, MTU planning, troubleshooting common errors, hardware support, and performance considerations.

Frequently Asked Questions

Q1: What is VLAN dual-tagging QinQ and when should I use it?

VLAN dual-tagging QinQ (IEEE 802.1ad) stacks an outer service VLAN tag on top of a customer inner tag, preserving customer VLAN IDs across a provider network. Use QinQ when you need to aggregate multiple customer VLANs over a single trunk, support overlapping customer VLAN IDs, or extend L2VPN services without rewriting tags.

Q2: How do I configure basic QinQ on a switch port?

Set the port as an 802.1ad tunnel port, define the outer Service VLAN (S-VLAN) ID, and enable QinQ encapsulation. Typical CLI commands: interface gigabitEthernet 0/1 → switchport mode dot1q-tunnel → switchport access vlan 100 (where VLAN 100 is the S-VLAN). Customer frames arriving untagged or single-tagged get wrapped with the outer S-VLAN tag.

Q3: What are the most common QinQ configuration mistakes and how do I fix them?

The top three errors are: mismatched TPID (0x8100 vs 0x88A8), insufficient MTU (needs at least 1504 bytes for standard QinQ, 1522+ for double-tagged VLANs with 4-byte CRC), and asymmetric VLAN pruning on intermediate switches. Fix by globally aligning TPID on all devices (set dot1q-tunnel tpid 0x88A8), raising all trunk MTU to 1522–1600 bytes, and verifying allowed VLAN lists include both inner and outer tags.

Q4: Which switch models and chipsets fully support hardware-accelerated QinQ?

Full hardware QinQ support exists on Broadcom Trident 3/4, Jericho 2+, and Marvell Prestera DX families. For enterprise gear: Cisco Catalyst 9300/9500 (with appropriate license), Juniper EX4400/QFX5120, Arista 7050X3, and Nokia 7250 IXR. Always verify that the specific SKU includes 802.1ad line-rate tagging; many low-end switches implement QinQ in CPU-based slow path, limiting throughput to

Q5: Does QinQ break STP, LACP, or CDP/LLDP traffic?

Yes, unless you configure tunnel protocol transparency. STP BPDUs, LACP PDUs, and CDP/LLDP are typically dropped or consumed by the service provider switch. Solution: enable BPDU tunneling (Cisco: l2protocol-tunnel stp) or L2PT (Juniper: protocol-tunnel) on QinQ edge ports. Alternatively, use VXLAN or MPLS for environments requiring full customer control plane transparency.

Q6: What is the maximum throughput and VLAN scale for QinQ deployments?

Line-rate throughput of 1G/10G/25G/100G ports is achievable on ASIC-accelerated switches with zero performance penalty. Maximum active S-VLANs per port typically ranges 4,000–8,000 (4K limit on legacy platforms). Inner C-VLANs support full 12-bit space (4,096 IDs per S-VLAN) but operational limit is usually 3,000–4,000 concurrent inner tags per S-VLAN due to MAC table size (typical 16K–128K entries).

Q7: How do I troubleshoot QinQ traffic that intermittently drops or fails to pass jumbo frames?

First, verify end-to-end MTU with ICMP do-not-fragment packets sized 1500, 1522, and 1600 bytes. Second, check TPID consistency: capture frames on intermediate trunk ports — outer tag TPID must match globally (default Cisco: 0x88A8, Juniper: 0x8100 for certain models). Third, inspect MAC learning: QinQ outer tag changes the MAC lookup key; ensure MAC aging timers align across all switches. Use embedded diagnostics like show dot1q-tunnel interface and debug platform packet (vendor-specific).

Q8: Does QinQ work with LACP link aggregation across multiple S-VLANs?

Yes, but with restrictions: LACP PDUs are encapsulated with the outer S-VLAN tag on tunnel ports, preventing direct LACP negotiation unless you disable QinQ on the LAG member ports or use provider bridge (PBB) with I-SID. Standard practice: place QinQ ports in static LAG (no LACP) or configure LACP on native VLAN only. Alternatively, run LACP on customer edge switches before they reach the QinQ encapsulation point.