LAB
In this lab we are going to join 2 sites of a customer network using QinQ through our Service Provider (SP). The result will be that the two sites are logically trunked, meaning that they are able to send VLANs across to each other through the service providers dedicated QinQ VLAN. In this example, the provider is going to be using VLAN34 as the QinQ VLAN.
Lets start by configuring both customer & carrier switches
Cpe1.3560#
vlan 3
name vlan3
!
interface GigabitEthernet0/1
description Trunk to Virgin.Edge.Sw2
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/5
description Link to PC1
switchport access vlan 3
cpe2.3560#
interface GigabitEthernet0/1
description Trunk to BT.Sw2
switchport trunk encapsulation dot1q
switchport mode trunk
!
vlan 3
name vlan3
!
interface GigabitEthernet0/5
description PC2 is connected here
switchport access vlan 3
switchport mode access
Virgin.Edge.Sw2#
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
switchport trunk encapsulation dot1q
witchport mode trunk
BT.Sw2#
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
description Trunk to edge.sw2.3560
switchport trunk encapsulation dot1q
switchport mode trunk
Nothing fancy, we just trunk to the carrier, and make an access port to our PCs. On the carrier switches we just trunk both ends.
The config for our edge switches is shown below.
Edge.Sw1.3560#
vlan 34
name vlan34
!
interface FastEthernet0/1
description Trunk to Virgin.Edge.Sw2
switchport access vlan 34
switchport mode dot1q-tunnel
!
interface FastEthernet0/2
description link to QinQ.Sw1.3560
switchport trunk encapsulation dot1q
switchport mode trunk
Edge.Sw2.3560#
vlan 34
name vlan34
!
interface FastEthernet0/1
description feed to BT.Sw2
switchport access vlan 34
switchport mode dot1q-tunnel
!
interface FastEthernet0/2
description feed to QInQ.Sw2.3560
switchport trunk encapsulation dot1q
switchport mode trunk
When I put the configuration on the tunnel ports, the switch prompted me to change my MTU to 1504 & reload the switch. If your switch doesnt do that then I suggest you check your system MTU using #show system MTU, and ensure that its using 1504 bytes or more. If not, you should manually set it using #system mtu 1504. The reason for it is because QinQ adds 4 bytes when adding an extra Tag & EType field in the frame (for a more elaborated explanation see the bottom of this page under QinQ technical bits).
The config for the QinQ.sw1.3560 & QinQ.sw2.3560 are shown below. Remember, you must check the system MTU on them, as they will also need to be 1504 to be able to process double tagged frames in the QinQ ring.
QinQ.Sw1.3560#
vlan 34
name vlan34
!
interface FastEthernet0/1
description Trunk to QinQ.Sw2.3560
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/2
description Trunk to Edge.Sw1.3560
switchport trunk encapsulation dot1q
switchport mode trunk
!
vlan 34
name vlan34
QinQ.SW2.3560#
!
vlan 34
name vlan34
!
interface GigabitEthernet0/1
description Trunk to qinq.sw1.3560
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
description Trunk to edge.sw2.3560
switchport trunk encapsulation dot1q
switchport mode trunk
Lets shove some PCs on port 5 at both Cpe1.3560 and Cpe2.3560 to test this actually works!
And PC2
Notice that we can see the MAC of the PCs at either side of the tunnel by checking the arp table (arp -a). The reason we can see these MACs is because weve formed a layer 2 network between both sites.
Tips/Considerations
Use one dot1q tunnel interface/VLAN per customer
Be sure to tag your customers native VLAN traffic into the QinQ VLAN (I forgot to do that in my lab). If you dont, and the customer decides he wants to use VLAN 100 as his management vlan (as a native VLAN), when he trys to SSH or manage his switch at his other site, his packets could get dropped. This is because the native VLAN is left untagged, and when it hits the provider switchport in the dot1q-tunnel mode, it doesnt double tag the packet (as there is no original VLAN tag to start with). To avoid complications, just tag his native VLAN using #vlan dot1q tag native when inserting his traffic into the QinQ VLAN.
You cant detect the received CoS value from frames in different customer side VLANs because you added a 2 byte Tag & Etype field in front of his Tag & Etype fields when you received the frame on the tunnel port. So you cant prioritise his traffic according to his VLANs. You can, however, prioritise your QinQ VLAN if you needed to.
Encapsulating frames into a QinQ VLAN adds 4 bytes of overhead (from the Tag & Etype fields) to every frame. Switches sending/receiving QinQ frames must increase their system MTU to 1504 for VLAN tunneling work. You can check your MTU using #show system mtu. You can increase your MTU by issuing #system mtu 1504, however, this change requires a reboot.
You can also tunnel the customers CDP, STP, VTP, and CoS values by using the following commands:
#l2protocol-tunnel stp
#l2protocol-tunnel cdp
#l2protocol-tunnel vtp
#l2protocol-tunnel cos
QinQ Technical bits
When a frame arrives at a trunk port, it looks like the 802.1Q frame in the diagram below. As you can see, it adds a Etype & Tag field (compared to the Original Ethernet Frame). The Etype field (sometimes referred to as a Tag Protocol IDentifier: TPID) will have a value of 0x8100, indicating a VLAN-tagged frame (IEEE 802.1Q). The Tag field (sometimes referred to as the Tag Control Information :TCI) will identify a VLAN ID & and any 802.1p priority (i.e. QoS) attached to the frame.
IEEE 802.1Q Frame (Cisco, 2006)
The last frame in the image above is a QinQ frame. Now you can see why its double tagged! A tunnel interface adds another Tag (sometimes referred to as an outer tag) and Etype field.
References
Cisco (2006) IEEE 802.1q Frame [Online] Available from:
http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094665.shtml
[Accessed 08/02/2011]