Q in Q Tunneling
Q in Q Tunneling
Q in Q Tunneling
1Q Tunneling (Q-in-Q)
Configuration Example
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 simplethe
provider will put a 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 its easy to implement, you dont need
exotic hardware and we dont have to run any routing protocols between the service
provider and customer (unlike MPLS VPN). From the customers perspective, its just
like their sites are directly connected on layer 2.
In this tutorial Im going to show you how to configure 802.1Q tunneling and Ill
explain how it works. Ill 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 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.
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 well have to configure a number of items. First I will
configure 802.1Q trunks between SW1 SW3 and SW2 SW3:
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. Well configure
the interfaces towards the customer routers to tag everything for VLAN 123:
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, lets do a quick test to see if R1 and R2 can reach each
other:
R1#ping 192.168.12.2
Great! Our ping is working! Lets take a look at some commands to verify our work:
SW1#show dot1q-tunnel
The show dot1q-tunnel command doesnt 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
As you can see above the only VLAN that is active (besides VLAN 1) on these trunk
links is VLAN 123. You wont see VLAN 12 here because thats the customer traffic
and its encapsulated with VLAN 123. Another good way to prove this is by looking at
spanning-tree:
Our switches dont have a spanning-tree topology for VLAN 12, they dont care what
VLAN the customer is usingthey 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:
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:
Ill 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:
By tunneling CDP packets between R1 and R2 they see each other as directly
connected. Thats a great example of a transparent network.
The last thing we have to discuss are 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
Because of 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:
After configuring the MTU you have to reboot your switches. You can see the MTU
size like this:
There we go, problem solved! This is all I have for now on 802.1Q tunneling, I hope
this has been helpful to you. If you have any questions feel free to leave a comment!
R1
hostname R1
!
interface FastEthernet0/0.12
encapsulation dot1Q 12
ip address 192.168.12.1 255.255.255.0
!
end
R2
hostname R2
!
interface FastEthernet0/1.12
encapsulation dot1Q 12
ip address 192.168.12.2 255.255.255.0
!
end
sw1
hostname SW1
!
vlan 123
!
interface FastEthernet0/1
switchport access vlan 123
switchport mode dot1q-tunnel
no cdp enable
!
interface FastEthernet0/19
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
sw2
hostname SW2
!
interface FastEthernet0/2
switchport access vlan 123
switchport mode dot1q-tunnel
no cdp enable
!
interface FastEthernet0/21
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
sw3
hostname SW3
!
vlan 123
!
interface FastEthernet1/0/19
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet1/0/21
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
Jumbo frame - A frame that is larger than the standard MTU size of 1518 bytes. This definition is vendor
dependant and is not part of any IEEE standard. For Cisco, 1518 or 1522 in the case of Q in Q is the
standard MTU. Anything larger is considered a jumbo frame.
When encapsulation from Layer 2 to Layer 3 occurs, if you have a frame that is say, 1600 bytes in size, in
order for it to be encapsulated to layer 3, if there is an MTU setting of 1518, this frame will be fragmented
into two parts, and each part will be placed in a separate packet. So one frame can be fragmented into two
(or more) packets when encapsulated.
A network can be configured to accommodate jumbo frames, that is on layer 2, frames of sizes up to 9216
bytes for Gigabit Ethernet and faster interfaces can be used. 10/100Mbps ports are limited to 8092 bytes.
MTU is configured on interfaces, such as physical interfaces of a switch or router, or on SVIs. Some
platforms have a global MTU size configuration parameter. If all interfaces on all devices within a flat layer
2 network are configured to accommodate jumbo frames, this could be very useful especially when
configuring the core or backbone of a network. Large bulks of data can be sent in this manner with much
less overhead.
When using jumbo frames, it is important to be sure that the design you create is sound. If there is routing
involved, that is if these large frames are going up to layer 3, then fragmentation of these frames may occur
and this can easily slow down a network or even drop frames that cannot be fragmented.
SW2
Try this in all switch sw1 asw2 and sw3