IEEE 802.1Q TUNNELING
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.
6.Port Aggregation Protocol (PAgP) and Unidirectional Link Detection (UDLD) Protocol are not supported on IEEE 802.1Q tunnel ports.
7.Dynamic Trunking Protocol (DTP) is not compatible with IEEE 802.1Q tunneling because you must manually configure asymmetric links with tunnel ports and trunk ports.
8.Loopback detection is supported on IEEE 802.1Q tunnel ports.
9.When a port is configured as an IEEE 802.1Q tunnel port, spanning tree bridge protocol data unit (BPDU) filtering is automatically disabled on the interface.
Configuration Example:
Switch1(config)# interface gigabitethernet0/4
Switch1(config-if)# switchport access vlan 40
Switch1(config-if)# switchport mode dot1q-tunnel
Switch1(config-if)# exit
Switch1(config)# vlan dot1q tag native
Switch1(config)# end
Verification:
Switch1# show vlan dot1q tag native
Switch1# show dot1q-tunnel interface gigabitethernet0/7
Layer 2 Protocol Tunneling
Points to remember.
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.
3.You cannot enable Layer 2 protocol tunneling on ports configured in either switchport mode dynamic auto (the default mode) or switchport mode dynamic desirable.
4.DTP is not compatible with layer 2 protocol tunneling.
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.
Configuration Example:
Switch1(config)# interface fastethernet0/5
Switch1(config-if)# l2protocol-tunnel cdp
Switch1(config-if)# l2protocol-tunnel stp
Switch1(config-if)# l2protocol-tunnel vtp
Switch1(config-if)# l2protocol-tunnel shutdown-threshold 1500
Switch1(config-if)# l2protocol-tunnel drop-threshold 1000
Switch1(config-if)# exit
Switch1(config)# l2protocol-tunnel cos 5
Verification:
Switch1# show l2protocol
Posts
You dont need this command
ReplyDeleteSwitch1(config)# vlan dot1q tag native
The reason is because you are using vlan 40 which is already tagged. That would be needed if you were using the native vlan like vlan 1.
Ether channel is supported if you use IEEE standar protocol like LACP.....you should also remember this.....please comment on this...
ReplyDeleteworksew
Remarks on
ReplyDeleteSwitch1(config)# vlan dot1q tag native
command.....
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.
This is my understanding of the feature Thanks....
Worksew N.
great work
ReplyDeletecontinue plz
after configuring the layer 2 tunnel I think it will tag all vlans even the native vlan ( the customer one ) without the command :
ReplyDeleteSwitch1(config)# vlan dot1q tag native
for your example all the traffic comes from this port f0/5 will tag with vlan 40 tag.
so no conflict.
Can you provide customer side configuration? How customer's interface would be configured if he is also using same kinda switch?
ReplyDeletethe 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.
ReplyDeleteYou 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):
ReplyDeleteswitchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
l2protocol-tunnel point-to-point lacp
l2protocol-tunnel point-to-point udld
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.
Respect and that i have a nifty proposal: How To Reno A House exterior house remodel
ReplyDelete