Wednesday, December 17, 2008

It’s been a bit since I last updated the blog.( 2 days only ): ). Today I was reviewing some switching topics with my 3560 configuration guide . The bad news with switching is that we may forget key features of some of the technologies if we are not reviewing it frequently . QinQ is such a topic for me .

QinQ tunneling is a feature that is asked occassionaly in CCIE LAB . Though the chances of getting this task in CCIE lab is rare , you are supposed to be familiar with this one also.

Cisco 802.1Q Tunneling enables service providers to use a single VLAN to securely transport most or all of a single customer’s VLANs across their MAN or WAN backbone. In this case, the software adds an extra 802.1Q tag to customer traffic in the switch at the edge of the service provider’s network. This tag assigns a unique VLAN ID number to each customer to keep each customer’sVLAN traffic segregated and private.

Points to remember.

1. Use the vlan dot1q tag native global configuration command to configure the edge switch so that all packets going out an IEEE 802.1Q trunk, including the native VLAN, are tagged.

2.A tunnel port cannot be a routed port.

3.Tunnel ports do not support IP access control lists (ACLs).

4.Layer 3 quality of service (QoS) ACLs and other QoS features related to Layer 3 information are not supported on tunnel ports. MAC-based QoS is supported on tunnel ports.

5.EtherChannel port groups are compatible with tunnel ports as long as the IEEE 802.1Q configuration is consistent within an EtherChannel port group.

1.Layer 2 protocol tunneling can be used independently or can enhance IEEE 802.1Q tunneling.

2.If protocol tunneling is not enabled on IEEE 802.1Q tunneling ports, remote switches at the receiving end of the service-provider network do not receive the PDUs and cannot properly run STP, CDP, and VTP. It also supports PAgP, LACP, and UDLD protocols.

5.Loopback detection is not supported on Layer 2 protocol tunneling of PAgP, LACP, or UDLD packets.

6.When protocol tunneling is enabled on an interface, you can set a per-protocol, per-port, drop threshold for the PDUs generated by the customer network. If the limit is exceeded, the port drops PDUs until the rate at which it receives them is below the drop threshold.

The reason to use this command is to tell the service provider(SP) switches(the switches that will be tunneling the customer switch vlan information) to tag all vlans including the native vlan of the customer that is untagged vlan, when it is traversing through the tunnel of the SP network.

Otherwise it will create a conflict in the SP network, in cases the customer and SP network native vlans are Identical by chance.

In other words the meaning of the command is :

"Tag all VLANs including the native vlan of the customer"

And don't forget that the native vlan of the customer can be any vlan including VLAN 1, thus the service provider avoid the conflict by using this command on its tunneling switches.

after configuring the layer 2 tunnel I think it will tag all vlans even the native vlan ( the customer one ) without the command :Switch1(config)# vlan dot1q tag nativefor your example all the traffic comes from this port f0/5 will tag with vlan 40 tag.so no conflict.

the vlan dot1q tag native command needs to be on the customer edge switches and not the provider switches. It sets an egress rule to tag all traffic going out trunk links. This prevents the situation where the native VLAN of the trunk link is the same as the Access VLAN used for the tunnel port, in which case the tag wouldn't be added, the frame would be accepted as untagged, and the frame would then go through the provider network and not go to the correct customer destination.

You can support protocols like UDLD, DTP, CDP, etc over QinQ tunnels as well as allowing "customer" spanning tree to run and operate properly. You simply need to enable support for the desired protocol with the following commands (on the tunnel interfaces):

It's important to note that to support LACP and UDLD, you will need to map EACH of the customers connnections (presumably 2 on each side) to a DIFFERENT provider VLAN. Essentially you're mapping Link 1 on customer A side all the way through the provider network (via a unique provider VLAN assignment) to Link 1 on customer B side. Same for Link 2. This allows the two links to appear solid all the way through the provide and support things like LACP and UDLD.