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 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 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 tutorial 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:
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.
Here is another way to visualize this:
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.0R2(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 trunkSW2(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-tunnelSW2(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/1SW2#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,123SW2#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,123SW3#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
<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:
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
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 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:
SW1(config)#system mtu 1504SW2(config)#system mtu 1504SW3(config)#system mtu 1504
After configuring the MTU you have to reboot your switches. You can see the MTU size like this:
SW1#show system mtu
System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1504 bytes
Our ping should now work:
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 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
There we go, problem solved! Here’s what this ping looks like in wireshark:
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!
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
!
endhostname SW2
!
vlan 123
!
interface FastEthernet0/2
switchport access vlan 123
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable
!
interface FastEthernet0/21
switchport trunk encapsulation dot1q
switchport mode trunk
!
endhostname R1
!
interface FastEthernet0/0.12
encapsulation dot1Q 12
ip address 192.168.12.1 255.255.255.0
!
endhostname R2 ! interface FastEthernet0/1.12 encapsulation dot1Q 12 ip address 192.168.12.2 255.255.255.0 ! end
hostname SW1 ! vlan 123 ! interface FastEthernet0/1 switchport access vlan 123 switchport mode dot1q-tunnel l2protocol-tunnel cdp no cdp enable ! interface FastEthernet0/19 switchport trunk encapsulation dot1q switchport mode trunk ! end
No comments:
Post a Comment