Q-in-Q was introduced for the Juniper Networks EX Series Switches starting with Junos OS Release 9.3 for Legacy Switches. This article provides a summary of how it functions and a configuration example for both Legacy and switches with ELS support.
Note: Additional examples and information can be found in Understanding Q-in-Q Tunneling on EX-series Switches.
To find if your device supports Q-in-Q in standalone mode or virtual chassis, refer to Q-in-Q | Juniper Networks Pathfinder Feature Explorer.
Q-in-Q tunneling allows service providers on Ethernet access networks to extend a Layer 2 Ethernet connection between two customer sites. Using Q-in-Q tunneling, providers can also segregate or bundle customer traffic into fewer VLANs or different VLANs by adding another layer of 802.1Q tags.
Q-in-Q tunneling is useful when customers have overlapping VLAN IDs, because the customer’s 802.1Q (dot1Q) VLAN tags are prepended by the service VLAN (S-VLAN) tag. The Junos OS software implementation of Q-in-Q tunneling supports the IEEE 802.1ad standard.
The following example outlines a Q-in-Q topology and configuration.
Customer-tagged traffic comes in on ge-0/0/0 and is sent across ge-0/0/1 (cloud) preserved, and ge-0/0/0 on the other end gets the tagged traffic.
The switches on the left and right are considered Provider Edge, interfacing the customer at the server on the left and right. The servers can be replaced with a switch with the same result. For any device in the intermediate path, an MTU of at least 1522 is needed to accommodate the outer and inner tag if the default MTU is in use. Make sure the MTU in the intermediate path can accommodate the extra 4 bytes for the outer VLAN tag.
Interfaces ge-0/0/0 on both sides are trunk ports as shown below.
Switch configuration for devices with ELS support.
root@switch> show configuration interfaces ge-0/0/0 { flexible-vlan-tagging; encapsulation extended-vlan-bridge; unit 10 { <<<< Defines outer tag or Service VLAN tag. vlan-id-list [ 100 200 ]; <<<< Defines inner tags or customer VLAN tags. input-vlan-map push; <<<< Pushes tag 10 on top of 100 OR 200. output-vlan-map pop; <<<< Pops tag 10 leaving only tag 100 OR 200. } } ge-0/0/1 { flexible-vlan-tagging; mtu 1522; encapsulation flexible-ethernet-services; unit 10 { encapsulation vlan-bridge; vlan-id 10; } } root@switch> show configuration vlans QinQ-Tunnel { interface ge-0/0/0.10; interface ge-0/0/1.10; } Set commands: set interfaces ge-0/0/0 flexible-vlan-tagging set interfaces ge-0/0/0 encapsulation extended-vlan-bridge set interfaces ge-0/0/0 unit 10 vlan-id-list 100 set interfaces ge-0/0/0 unit 10 vlan-id-list 200 set interfaces ge-0/0/0 unit 10 input-vlan-map push set interfaces ge-0/0/0 unit 10 output-vlan-map pop set interfaces ge-0/0/1 mtu 1522 set interfaces ge-0/0/1 flexible-vlan-tagging set interfaces ge-0/0/1 encapsulation flexible-ethernet-services set interfaces ge-0/0/1 unit 10 encapsulation vlan-bridge set interfaces ge-0/0/1 unit 10 vlan-id 10 set vlans QinQ-Tunnel interface ge-0/0/0.10 set vlans QinQ-Tunnel interface ge-0/0/1.10
Because the other device uses the same interfaces, the configuration is the same. We can verify that the configuration works as follows:
root@switch> show interfaces ge-0/0/0.10 extensive Logical interface ge-0/0/0.10 (Index 560) (SNMP ifIndex 525) (Generation 146) Flags: Up SNMP-Traps Redundancy-Device 0x20004000 VLAN-Tag [ 100, 200 ] In(push .10) Out(pop) Encapsulation: Extended-VLAN-Bridge Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol eth-switch, MTU: 1522, Generation: 169, Route table: 7, Mesh Group: __all_ces__, Next-hop: 1715, vpls-status: up
Pinging from the host connected:
root@host> ping 192.168.100.1 source 192.168.100.2 rapid count 10 PING 192.168.100.1 (192.168.100.1): 56 data bytes !!!!!!!!!! --- 192.168.100.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.787/2.123/3.330/0.542 ms
The example above shows a one-to-many mapping, meaning many C-VLANs (100 and 200) are mapped to one S-VLAN (10). If you want to encapsulate all VLANs, use the following:
set interfaces ge-0/0/0 unit 10 vlan-id-list [ 1-4094]
And if only one is to be mapped, use:
set interfaces ge-0/0/0 unit 10 vlan-id-list 1
Legacy Configuration for EX4200/EX4500 switches:
The interface ge-0/0/0 points towards the customer devices and ge-0/0/1 towards the service provider. The following configuration is used:
set interfaces ge-0/0/0 unit 0 family ethernet-switching set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode trunk set interfaces ge-0/0/1 mtu 1522 set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 20 set ethernet-switching-options dot1q-tunneling ether-type 0x8100 set vlans QinQ-Tunnel vlan-id 20 set vlans QinQ-Tunnel interface ge-0/0/0.0 set vlans QinQ-Tunnel dot1q-tunneling customer-vlans 50 set vlans QinQ-Tunnel dot1q-tunneling customer-vlans 150 root@host> ping 192.168.150.1 source 192.168.50.2 count 10 rapid PING 192.168.150.1 (192.168.150.1): 56 data bytes !!!!!!!!!! --- 192.168.150.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.831/2.715/3.872/0.869 ms
Note that ge-0/0/0 pointing towards the server has no configuration other than "family ethernet-switching".
Along with Q-in-Q, the feature L2PT can be configured for supported devices. Refer to Layer 2 Protocol Tunneling for examples and feature supportability.
2020-01-21: Article checked for accuracy and validity and found up-to-date; topology diagram changed along with minor name changes.
2022-12-27: Article expanded to include devices with ELS support configuration examples and legacy, as well as links to find supportability for the standalone and VC feature.