802.1Q Tunneling (Q-in-Q) Configuration (2024)

802.1Q tunneling (aka Q-in-Q) is often used by Metro Ethernet providers as a layer 2 VPN for customers. 802.1Q (or dot1q) tunneling is pretty simple…the provider will put an 802.1Q tag on all the frames that it receives from a customer with a unique VLAN tag. By using a different VLAN tag for each customer, we can separate the traffic from different customers and also transparently transfer it throughout the service provider network.

One of the advantages of this solution is that it’s easy to implement, you don’t need exotic hardware, and you don’t have to run any routing protocols between the service provider and customer (unlike MPLS VPN). From the customer’s perspective, it’s just like their sites are directly connected on layer 2.

In this lesson, I’m going to show you how to configure 802.1Q tunneling and I’ll explain how it works. I’ll be using the following topology for this:

Above you see two routers called R1 and R2, imagine these routers are the customer sites that we want to connect through the service provider network which consists of SW1, SW2, and SW3. Our customer wants to use VLAN 12 between the two sites and expects our service provider to transport this from one site to another.

In my example, our customer will be using VLAN 12 for traffic between their sites. The service provider has decided to use VLAN 123 to transport everything for this customer. Basically, this is what will happen when we send frames between R1 and R2:

Whenever R1 sends traffic it will tag its frames for VLAN 12. Once it arrives at the service provider, SW1 will add an additional VLAN tag (123). Once SW2 forwards the frame towards R2, it will remove the second VLAN tag and forwards the original tagged frame from R1.

Here is another way to visualize this:

Enough talk…let’s take a look at the configuration.

Here’s what the router configs look like:

R1(config)#interface fastEthernet 0/0R1(config-if)#no shutdownR1(config-if)#interface fastEthernet 0/0.12R1(config-subif)#encapsulation dot1Q 12R1(config-subif)#ip address 192.168.12.1 255.255.255.0

R2(config)#interface fastEthernet 0/0R2(config-if)#no shutdownR2(config-if)#interface fastEthernet 0/0.12R2(config-subif)#encapsulation dot1Q 12R2(config-subif)#ip address 192.168.12.2 255.255.255.0

R1 and R2 are both configured with sub-interfaces and use subnet 192.168.12.0 /24. All their frames are tagged as VLAN 12.

On the service provider network, we’ll have to configure a number of items. First I will configure 802.1Q trunks between SW1 – SW3 and SW2 – SW3:

SW1(config)#interface fastEthernet 0/19SW1(config-if)#switchport trunk encapsulation dot1q SW1(config-if)#switchport mode trunk

SW2(config)#interface fastEthernet 0/21SW2(config-if)#switchport trunk encapsulation dot1q SW2(config-if)#switchport mode trunk 

SW3(config)#interface fastEthernet 0/19 SW3(config-if)#switchport trunk encapsulation dot1q SW3(config-if)#switchport mode trunkSW3(config)#interface fastEthernet 0/21SW3(config-if)#switchport trunk encapsulation dot1q SW3(config-if)#switchport mode trunk

The next part is where we configure the actual “Q-in-Q” tunneling. The service provider will use VLAN 123 to transfer everything from our customer. We’ll configure the interfaces toward the customer routers to tag everything for VLAN 123:

SW1(config)#interface fastEthernet 0/1SW1(config-if)#switchport access vlan 123SW1(config-if)#switchport mode dot1q-tunnel

SW2(config)#interface fastEthernet 0/2SW2(config-if)#switchport access vlan 123SW2(config-if)#switchport mode dot1q-tunnel

The switchport mode dot1q-tunnel command tells the switch to tag the traffic and switchport access vlan command is required to specify the Q-in-Q VLAN of 123. Make sure that VLAN 123 is available on SW1, SW2, and SW3. By assigning the interfaces above to this VLAN, it was automatically created on SW1 and SW2, but I also have to make sure that SW3 has VLAN 123 in its database:

SW3(config)#vlan 123

Everything is now in place. Let’s do a quick test to see if R1 and R2 can reach each other:

R1#ping 192.168.12.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Great! Our ping is working! Let’s take a look at some commands to verify our work:

SW1#show dot1q-tunnel dot1q-tunnel mode LAN Port(s)-----------------------------Fa0/1

SW2#show dot1q-tunnel dot1q-tunnel mode LAN Port(s)-----------------------------Fa0/2

The show dot1q-tunnel command doesn’t give me a lot of information. The only thing we see are the interfaces that are configured for dot1q tunneling. A good way to prove that the service provider switches are really tunneling the frames from the customer is by looking at the trunks between SW1, SW2, and SW3:

SW1#show interfaces fa0/19 trunkPort Mode Encapsulation Status Native vlanFa0/19 on 802.1q trunking 1Port Vlans allowed on trunkFa0/19 1-4094Port Vlans allowed and active in management domainFa0/19 1,123Port Vlans in spanning tree forwarding state and not prunedFa0/19 1,123

SW2#show interfaces trunk Port Mode Encapsulation Status Native vlanFa0/21 on 802.1q trunking 1Port Vlans allowed on trunkFa0/21 1-4094Port Vlans allowed and active in management domainFa0/21 1,123Port Vlans in spanning tree forwarding state and not prunedFa0/21 1,123

SW3#show interfaces trunk Port Mode Encapsulation Status Native vlanFa1/0/19 on 802.1q trunking 1Fa1/0/21 auto n-802.1q trunking 1Port Vlans allowed on trunkFa1/0/19 1-4094Fa1/0/21 1-4094Port Vlans allowed and active in management domainFa1/0/19 1,123Fa1/0/21 1,123Port Vlans in spanning tree forwarding state and not prunedFa1/0/19 1,123Fa1/0/21 1,123

As you can see above, the only VLAN that is active (besides VLAN 1) on these trunk links is VLAN 123. You won’t see VLAN 12 here because that’s the customer traffic and it’s encapsulated with VLAN 123. Another good way to prove this is by looking at spanning tree:

SW1#show spanning-tree vlan 12 Spanning tree instance(s) for vlan 12 does not exist.

SW2#show spanning-tree vlan 12 Spanning tree instance(s) for vlan 12 does not exist.

SW3#show spanning-tree vlan 12 Spanning tree instance(s) for vlan 12 does not exist.

Our switches don’t have a spanning tree topology for VLAN 12. They don’t care what VLAN the customer is using…they only care about VLAN 123.

So far, so good! 802.1Q tunneling has some more tricks up its sleeve. One of the things it can do is tunnel some layer two protocols. Take a look below:

SW1(config)interface fastEthernet 0/1SW1(config-if)#l2protocol-tunnel ? cdp Cisco Discovery Protocol drop-threshold Set drop threshold for protocol packets point-to-point point-to-point L2 Protocol shutdown-threshold Set shutdown threshold for protocol packets stp Spanning Tree Protocol vtp Vlan Trunking Protocol <cr>

If you want, it can tunnel CDP, VTP, STP, and even point-to-point protocols like PAgP or LACP (Etherchannel). Let me show you what happens when you tunnel CDP traffic: