802.1Q Tunneling (Q-in-Q) Configuration

802.1Q tunneling (also called Q-in-Q) creates a Layer 2 VPN by adding a second VLAN tag to an Ethernet frame. This is often used by service providers or Metro Ethernet providers to tunnel the traffic from their customers. The provider will put an 802.1Q tag on all frames that is 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 forward 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 as if their sites are directly connected at Layer 2.

In this lesson, I’ll explain how 802.1Q tunneling works, and I’ll explain how to configure this.

Key Takeaways

• Q-in-Q adds a second 802.1Q tag to customer frames. The customer’s original VLAN tag remains intact while the provider adds their own tag
• Each customer gets a unique provider VLAN to isolate traffic across the service provider network
• Configure with switchport mode dot1q-tunnel on customer-facing interfaces and assign a provider VLAN using switchport access vlan
• MTU must be increased to 1504 bytes on all provider switches to accommodate the extra 4-byte VLAN tag
• Layer 2 protocols can be tunneled, including CDP, VTP, STP, and EtherChannel protocols
• Customers see their sites as directly connected at Layer 2

Prerequisites

To follow this lesson, you should understand basic switching, VLANs, and 802.1Q trunking.

Explanation

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:

Configuration

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 192.168.12.1 255.255.255.0

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 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/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 toward 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:

R1#ping 192.168.12.2

Type 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 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.

Layer Two Protocols Tunneling

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/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
  <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:

SW1(config)#interface fastEthernet 0/1
SW1(config-if)#l2protocol-tunnel cdp 

SW2(config)#interface fastEthernet 0/2
SW2(config-if)#l2protocol-tunnel cdp 

I’ll tell SW1 and SW2 to tunnel all CDP traffic between the interfaces that are connected to R1 and R2. Take a look below for the result:

R1#show cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2               Fas 0/0            171         R S I     2811      Fas 0/1

By tunneling CDP packets between R1 and R2, they see each other as directly connected. That’s a great example of a “transparent” network. Here’s what it looks like in wireshark:

Frame 2: Packet, 369 bytes on wire (2952 bits), 369 bytes captured (2952 bits) on interface -, id 0
Ethernet II, Src: fa:16:3e:0c:c9:4f (fa:16:3e:0c:c9:4f), Dst: GBPT (01:00:0c:cd:cd:d0)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 123
Logical-Link Control
Cisco Discovery Protocol
    Version: 2
    TTL: 180 seconds
    Checksum: 0xde8a [correct]
    [Checksum Status: Good]
    Device ID: R2
    Software Version
    Platform: Cisco 
    Addresses
    Port ID: GigabitEthernet0/1
    Capabilities
    IP Prefixes: 1
    Management Addresses

Packet Capture: 802.1Q Tunneling CDP

Maximum Transmission Unit (MTU)

The last thing we have to discuss is MTU (Maximum Transmission Unit) problems.

The Ethernet frame of the customer with the 802.1Q tag will have a MTU of 1500 bytes, but since we are adding another 802.1Q tag, the total MTU will be 1504 bytes in the service provider network. By default, most switches will only allow a maximum MTU of 1500 bytes, so you will run into problems with large packets. Below you can see the actual problem:

R1#ping 192.168.12.2 size 1500 df-bit 

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

Because of the second tag, this ping will be dropped because the MTU is too small. To solve this, you should increase the maximum MTU size of your switches: