QinQ: IEEE 802.1Q Tunneling

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, often referred to as QinQ, 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.