QinQ: IEEE 802.1Q Tunneling

by Tony Mattke on April 19, 2012



In situations where service providers want to offer transparent LAN services that preserve a customers VLAN tags across your Layer-2 network, This amendment to the IEEE 802.1q standard allows us to use a single VLAN to transport multiple VLANS across the MAN or WAN. In doing so, we stack on an extra 802.1q tag to the customer’s traffic at the provider’s edge (PE). The original 802.1Q specification allows a single VLAN header to be inserted into an Ethernet frame. QinQ allows multiple VLAN headers to be inserted into a single frame, this is essential when implementing Metro Ethernet networks.

QinQ Configuration

First we need to ensure our transport switches can support the baby giant frames. To check the current MTU on the switch you can issue the command show system mtu and in global configuration mode, you can use system mtu 1504 to change the switches MTU to the recommended 1504 bytes..

SW1# show system mtu
System MTU size is 1500 bytes
SW1# configure terminal
SW1(config)# system mtu 1504
Changes to the System MTU will not take effect until the next reload is done.

The actual QinQ configuration takes place entirely on the transport switches, no modifications are required on the customer equipment. The first step is to configure the trunk between our two backbone switches. We’ll be using VLAN 101 for Customer-A, and 201 for Customer-B. As you will see, the configuration is rather quick and simple.

SW1(config)# interface fa1/0/48
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 101,201

SW2(config)# interface fa1/0/48
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 101,201


Now, on the provider edge (PE) ports, we need to assign the port to the appropriate VLAN, and configure the dot1q-tunnel. This tunnel is what allows us to transport a customer’s VLANtrunk across our network. The command l2protocol-tunnel allows transportation of Layer-2 protocols such as CDP, LLDP, STP, and VTP. I’m also turning off CDP here for sanity’s sake.

SW1(config)# interface fa1/0/10
SW1(config-if)# desc Customer-A
SW1(config-if)# switchport access vlan 101
SW1(config-if)# switchport mode dot1q-tunnel
SW1(config-if)# l2protocol-tunnel
SW1(config-if)# no cdp enable
SW1(config-if)# interface fa1/0/20
SW1(config-if)# desc Customer-B
SW1(config-if)# switchport access vlan 201
SW1(config-if)# switchport mode dot1q-tunnel
SW1(config-if)# l2protocol-tunnel
SW1(config-if)# no cdp enable

SW2(config)# interface fa1/0/10
SW2(config-if)# desc Customer-A
SW2(config-if)# switchport access vlan 101
SW2(config-if)# switchport mode dot1q-tunnel
SW2(config-if)# l2protocol-tunnel
SW2(config-if)# no cdp enable
SW2(config-if)# interface fa1/0/20
SW2(config-if)# desc Customer-B
SW2(config-if)# switchport access vlan 201
SW2(config-if)# switchport mode dot1q-tunnel
SW2(config-if)# l2protocol-tunnel
SW2(config-if)# no cdp enable

And that’s it. Each customer has tunneled connectivity between their sites using their own VLAN numbering all encapsulated within their own VLAN on the providers Layer-2 network. In the near future I plan on writting a bit on 802.1Q tunnel termination in regards to the Cisco 10000, aka the BFR. It’s been a few years since I’ve done it, but I can still remember the basics.

About the author:

Tony Mattke is a network engineer for a financial institution in Indiana. In the past he has worked for ISPs, data centers, networking manufacturers, and the occasional enterprise. For feedback, please leave a comment on the article in question. For everything else including fan mail or death threats, contact him via twitter.

{ 4 comments… read them below or add one }

Brian October 2, 2012 at 8:22 pm

Thanks for the QinQ configuration lines. I think that this is a proper workaround for optimizing the DAG IP data cabling brisbane in our operations.

Reply

schaef November 15, 2012 at 4:40 pm

I was having some MTU issues when experimenting with this the other day… Your article help clear it up for me! Thanks!

Reply

@eemhints November 23, 2012 at 2:08 pm

You should keep in mind that QinQ is not full encapsulation of the incoming frame.. Just the vlan tag. If you have customers that do something stupid like split an HA firewall pair or router pair running VRRP or HSRP (or the enterprise you work for made this bad decision in the past), you have this situation where duplicate MAC addresses can be placed into the same broadcast domain when they are encapsulated in the provider vlan where QinQ is deployed. This occurs because VRRP and HSRP choose the MAC address based on the VRID or Standby group number.

If a customer was running HSRP on different Vlans using the same standby group number (0 or 1 or 100) that then was encapsulated in the same provider vlan, you get this great flapping behavior which is quite time consuming to troubleshoot.

The full solution is MACinMAC or PBB or 802.1ah. A better solution is not splitting HA pairs geographically, but YMMV on getting that changed.

Reply

imanetworkengineer December 28, 2013 at 12:47 pm

looking forward to learn about 802.1Q tunnel termination from you.. thanks for this infos. it somewhat, kind of inspired me alot

Reply

Leave a Comment

Previous post:

Next post: