Juniper Q-in-Q VLAN Stacking Configuration Guide

Q-in-Q lets a service provider carry many customers whose VLAN IDs overlap by pushing an outer service VLAN tag in front of the customer tag - the IEEE 802.1ad model that Junos implements as dot1q-tunneling. It solves a genuinely awkward problem: two tenants who both use VLAN 41 on their own equipment, both handed to you on one physical handoff. This guide covers the two bundling models, the exact configuration for EX and QFX switches, and the verification commands that prove the outer tag is being pushed and popped correctly.

How Q-in-Q Tagging Works

A frame arrives at the provider edge with a single customer (C-VLAN) tag. The provider adds an outer service (S-VLAN) tag in front of it, so the frame leaves with two tags. Inside the provider network the S-VLAN is the only tag that matters for forwarding; the customer tag is carried transparently. At the far end the outer tag is removed and the frame is delivered with the original customer tag intact, which is why customer VLAN plans can be completely private.

Junos implements this with the dot1q-tunneling statement under the VLAN, referenced by the customer VLAN IDs it should accept. Class-of-service values carried in the customer tag are retained, so customer QoS markings survive the tunnel.

Choose the Bundling Model

All-in-one bundling maps every frame received on the access interface - tagged or untagged - to one S-VLAN. Use it when the whole port belongs to a single customer and you do not care which customer VLANs appear.

set vlans SVID100 vlan-id 100
set vlans SVID100 dot1q-tunneling layer2-protocol-tunneling all
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members SVID100

Many-to-one bundling maps a specified set of customer VLANs into the S-VLAN, which is what you need when several customers share a handoff or when only some C-VLANs should be tunnelled.

set vlans SVID4 vlan-id 4
set vlans SVID4 dot1q-tunneling customer-vlans 41-42
set vlans SVID4 dot1q-tunneling layer2-protocol-tunneling all
set vlans SVID5 vlan-id 5
set vlans SVID5 dot1q-tunneling customer-vlans 51-52
set vlans SVID5 dot1q-tunneling layer2-protocol-tunneling all

set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members SVID4
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members SVID5

With that configuration, C-VLAN 41 and 42 arriving on ge-0/0/0 are pushed into S-VLAN 4, and 51 to 52 into S-VLAN 5 - the mapping the customer expects from a service handoff.

Provider Core Interfaces

Interfaces facing the provider core are ordinary trunks carrying the S-VLANs. Do not configure dot1q-tunneling there; the core just needs the service VLANs allowed.

set interfaces xe-0/0/10 unit 0 family ethernet-switching port-mode trunk
set interfaces xe-0/0/10 unit 0 family ethernet-switching vlan members SVID4
set interfaces xe-0/0/10 unit 0 family ethernet-switching vlan members SVID5

Rules and Restrictions Worth Knowing

• You cannot enable Q-in-Q tunneling on an Ethernet port that has multiple logical subinterfaces - the port must be a plain access port.
• VLAN translation and Q-in-Q tunneling cannot be configured on the same access port. Pick one per interface.
• Only one VLAN translation is allowed per VLAN per interface.
• layer2-protocol-tunneling keeps L2 control protocols (STP BPDUs and others) from the customer from being processed by the provider switch, which is what makes the customer's topology appear point-to-point.

Verification

show vlans
show vlans SVID4 detail
show ethernet-switching table
show interfaces ge-0/0/0 extensive | match "VLAN"
show ethernet-switching interface ge-0/0/0

Send a tagged frame from the customer side and confirm the MAC appears in the S-VLAN's forwarding table rather than in the C-VLAN's. If customer frames are being dropped, the usual causes are a port mode that is not access, the C-VLAN missing from the customer-vlans list, or the S-VLAN not being allowed on the core trunk. For the same feature on other platforms see Arista EOS VLAN translation and dot1q-tunnel, and for the Huawei equivalent Huawei QinQ dot1q-tunnel configuration.

On EVPN-VXLAN fabrics there is a further wrinkle: single- and double-tagged Q-in-Q packets can be tunnelled inside the overlay, but the VTEP must be configured to retain the inner C-VLAN tag while de-encapsulating. Platforms that only support service-provider style interface configuration have restrictions here, so check the specific switch family before designing Q-in-Q into an EVPN fabric.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/topic-map/q-in-q.html