802.1Q Tunneling (Q-in-Q) Configuration

802.1Q tunneling (aka Q-in-Q) is a technique 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 we 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:

Cisco Q In Q Lab Physical Topology

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:

Cisco Q In Q Lab Vlan Tags

Whenever R1 sends trafffic 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:

Ethernet Frame Q In Q

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

Here’s what the router configs look like:

R1(config)#interface fastEthernet 0/0
R1(config-if)#no shutdown
R1(config-if)#interface fastEthernet 0/0.12
R1(config-subif)#encapsulation dot1Q 12
R1(config-subif)#ip address
R2(config)#interface fastEthernet 0/0
R2(config-if)#no shutdown
R2(config-if)#interface fastEthernet 0/0.12
R2(config-subif)#encapsulation dot1Q 12
R2(config-subif)#ip address

R1 and R2 are both configured with sub-interfaces and use subnet /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/19
SW1(config-if)#switchport trunk encapsulation dot1q 
SW1(config-if)#switchport mode trunk
SW2(config)#interface fastEthernet 0/21
SW2(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 trunk

SW3(config)#interface fastEthernet 0/21
SW3(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 towards the customer routers to tag everything for VLAN 123:

SW1(config)#interface fastEthernet 0/1
SW1(config-if)#switchport access vlan 123
SW1(config-if)#switchport mode dot1q-tunnel
SW2(config)#interface fastEthernet 0/2
SW2(config-if)#switchport access vlan 123
SW2(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:


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, 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)
SW2#show dot1q-tunnel 

dot1q-tunnel mode LAN Port(s)

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 trunk

Port        Mode             Encapsulation  Status        Native vlan
Fa0/19      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/19      1-4094

Port        Vlans allowed and active in management domain
Fa0/19      1,123

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/19      1,123
SW2#show interfaces trunk 

Port        Mode             Encapsulation  Status        Native vlan
Fa0/21      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/21      1-4094

Port        Vlans allowed and active in management domain
Fa0/21      1,123

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/21      1,123
SW3#show interfaces trunk 

Port        Mode             Encapsulation  Status        Native vlan
Fa1/0/19    on               802.1q         trunking      1
Fa1/0/21    auto             n-802.1q       trunking      1

Port        Vlans allowed on trunk
Fa1/0/19    1-4094
Fa1/0/21    1-4094

Port        Vlans allowed and active in management domain
Fa1/0/19    1,123
Fa1/0/21    1,123

Port        Vlans in spanning tree forwarding state and not pruned
Fa1/0/19    1,123
Fa1/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 2 protocols. Take a look below:

SW1(config)interface fastEthernet 0/1
SW1(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

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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 739 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

542 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,

Forum Replies

  1. Hi Srini,

    I used routers just to have some “customer” device that could do tagging for me in this example. In a real network, you would use customer switches instead.

    The tag on the left side is the tag from the ISP, I should probably have used the same color for the customer tag.


  2. Hi Rene

    My question is : does the actual RSP720-3C-10GE also support the Q-in-Q feature ?

    We have a client that might want to shift away from the 7200/NPE-G2 and start using the 7600 series router and asked me if it does support the feature without use of the ES+ line cards.

    I find this Cisco 7600 series router config document regards to QinQ (802.1ad) :


    And i find this one for the ES+ line cards :


    ... Continue reading in our forum

  3. Hi Rene,

    Could you please explain Jumbo Frame in plain English :slight_smile:

    who uses it and why someone will use it ? Is it configurable ? Where this has to be configured ?


  4. Hello Abhishek

    In order to clearly answer your question, you’ll have to understand the following terminology:

    MTU - Maximum transmission unit - this is the largest physical packet size measured in bytes that a network can transmit. Any packet larger than this MTU is divided or fragmented into smaller packets before transmission. The standard MTU on an Ethernet network is 1500 bytes plus the size of the L2 header and frame check sequence which is an additional 18 bytes. So standard MTU size for Ethernet is 1518.

    Jumbo frame - A frame that is larger than the s

    ... Continue reading in our forum

  5. What happen if we have two customers, customer X and Y and use the same SVLAN (outer vlan) 123 and we segregate traffic using different cvlans (cvlan 12 for customer x and cvlan 13 for customer y). So, we have customer x site 1 and site 2, both sites using lan switches connected to the metro ethernet service provider lan switch and the same for customer y.
    If customer X Lan Switch sends a BPDU towards the ISP, this BPDU will be carried on the inner vlan ? or should I have to configure the “l2protocol stp” on the interface configuration mode on the ISP edge inte

    ... Continue reading in our forum

122 more replies! Ask a question or join the discussion by visiting our Community Forum