Q-in-Q (Dot1q) Tunnelling

Stacking VLANs

Separating traffic by VLAN is nothing new. It may be separate departments, to provide boundaries, for security, or for a thousand other reasons.

The Tagged, Untagged, and Native VLANs article introduces how VLAN tags work. As shown below, a frame has a VLAN tag inserted to identify the VLAN is belongs to.

VLAN   Ethernet Frame 2  

Service Providers also need to separate traffic, but they usually have an another reason. They need to keep customer traffic separate. There are different ways to achieve this, depending on the provider link type. At layer 3, it may be MPLS with VRF's. To achieve this at layer 2, the frame has an extra VLAN tag inserted. This results in VLAN tags being 'stacked' in the frame.

The result is a frame with two tags; the customer tag and the provider tag:

Qinq Tag


This method is called VLAN stacking, Q-in-Q tunnels, or dot1q tunnels. The 'Q-in-Q' comes from the 802.1Q VLAN specification. This is like using MPLS tags and route-targets/VRF's at layer-3, but simpler to use.

Q-in-Q also helps providers to save money. When a provider gets a new customer, they have to provide a port into their core or aggregation network. These ports are likely to be 1Gbps, but the provider may be selling only 10Mbps services. The result is a waste of bandwidth. Instead, the provider could have an edge switch connected to the core port. Then, 100 10M customers could connect to the core port, separated by VLANs.

Another use for Q-in-Q is for a provider to pass traffic over an upstream provider's network. For example, a small provider may have networks on the east and west coasts of a country. An upstream provider can bridge these two networks. Q-in-Q allows the smaller provider to pass layer-2 traffic over the intermediate provider.

Although usually associated with providers, enterprises may have a use for tunnels as well. Some examples include mergers between different companies with overlapping VLANs, or converging separate offices. The important thing to remember here, is to make sure that the switches in use support this tunneling.





 Q-in-Q in VIRL

Currently (December 2016) VIRL does not support Q-in-Q tunnels


The service provider needs to allow for a larger MTU, as each frame has an extra 4 byte VLAN tag added.

On the customer facing ports, assign a top-level VLAN. This is the VLAN that the service provider inserts into the frame. Finally, the ports need to be Q-in-Q tunnel aware. Without this config, they will strip out existing tags on the frame.

There is no special configuration required between service provider switches. They do need to allow the top-level VLANs between them. In the example below, customer A uses vlan 100, and Customer B uses VLAN 200.



system mtu 1504

vlan 100
  name Customer-A

vlan 200
  name Customer-B

interface gi0/1
  mtu 1504
  switchport trunk encapsulation dot1q
  switchport mode trunk
  switchport trunk allowed vlan 100,200

interface gi 0/2
  description Customer-A
  switchport access vlan 100
  switchport mode dot1q-tunnel

interface gi 0/3
  description Customer-B
  switchport access vlan 200
  switchport mode dot1q-tunnel



The configuration can be verified with show interfaces int switchport. This shows which ports are Q-in-Q aware.


ISP-West#show interfaces gi 0/2 switchport | include Mode
  Administrative Mode: tunnel
  Operational Mode: tunnel
  Access Mode VLAN: 100 (Customer-A)
  Trunking Native Mode VLAN: 1 (default)
  Capture Mode Disabled


The customer switches (or routers) are unaware that there are any provider switches.

There is a small problem with the configuration shown so far. Some protocols, such as CDP or spanning-tree, are sent from switch-to-switch. They are not usually forwarded across switches. 

So what happens if a customer switch in one office needs to send CDP traffic to a switch in another office? This traffic has to be identified. To do this, use the l2protocol-tunnel command.



interface gi0/1
  l2protocol-tunnel cdp
  l2protocol-tunnel stp
  l2protocol-tunnel vtp
  l2protocol-tunnel point-to-point pagp
  l2protocol-tunnel point-to-point lacp
  l2protocol-tunnel point-to-point udld



This can be verified with show l2protocol-tunnel:


show l2protocol-tunnel


Twitter: @NetwrkDirection


Suggested Articles





Network Lessons - 802.1Q Tunneling (Q-in-Q) Configuration Example

Darren's Blog - Fun with QinQ

Packet Life - IEEE 802.1Q Tunneling

Packet Life - Layer two protocol tunneling



Last update 2017-08-29 08:57