802.1q tunnelling and l2 prtocol tunnels (QINQ)

802.1q Tunnelling QINQ

•  Was addded to allow for layer 2 tunnelling over service provider a scalable way of deciphering your traffic from the service providers + other customers
• Service provider assigns a unique vlan tag to each customer with all traffic coming from customer getting this new dot1q tag. The customers existing dot1q tag remains the service provider switches the traffic with it added dot1q tag then removes this tag on egress revealing the original customer tag
• Layer 2 traffic appears transparent accross service provider network
• Things to watch are to avoid native vlan matches as of no dot1q tag on customer side + service provider side to deal with this we could use isl (no native vlan) or dot1q tag or native vlan
• Service provider will need to support the added over head the dot1q tag so we will need to increase mtu mtu max for gi 9000 bytes for fa0/0 1988. To facilty one tag needs to be increased 1504
• Tunnel ports do not support layer 3 acl and other layer 3 features layer 3 qos 
• Fall back bridging is not supported
• DTP is not compatiable
• There are 2 types of qinq 

            1)basic qinq-qinq tag added no matter if there is existing dot1q tag or not   
            2)selective qinq- adds a specfied vlan tag according to the recieved vlan tag if none a default  
               tag is added

SP SIDE
            int fa0/0
            switchport mode-dot1q tunnel.
            switchport access vlan 'metro/sp vlan id'

There is design issues with qinq

There is firstly scalability issues for the service provider. The service provider vlan needs to know the arp address of customer clients this could thousands

It is complete layer 2 flat design relaying on mac and switching no layer 3

Most service providers now will opt for MPLS which willl allow layer 2 vpns across the a layer 3  backbone

.

Layer 2 Tunnel Protocol
There are some features that you can run over QinQ but they do need advanced configuration

• Spanning-tree traffic can now be carried between each site to allow for properly building the spanning-tree topology between both sites.
• CDP packets can now be carried between devices to properly recognize the “Pseudo” connected device.
• VTP can be carried between both sites
• LACP PAGP and UDLD traffic can be shared between two point-to-point interfaces.

Basically the isssue is that qinq is adding an additional doq1tag in the frame so it can go safely across the service provider and then it removes this tag one egress.  That is essentially all it does.

Control Plane protocols have nothing to do with tagging etc these tend to multicast to specific  well known mac address etc on the native vlan untagged.  The issue being if i send it to the well known mac address the service provider switches are going to process it,

Now rather than the service providers switches processing this tag the ingress switch will be aware for particular address to do a mac address rewrite of the frame destination so it is not processed by any switches in the path and then on egreess the service provider will rewrite well known mac so it can be recieved and processed on the other end.

This requires the addition of another protocol known as the l2 tunelling protocol

To enable this. On the pe routers under the interface that dot1q tunnelling is configured. Issue the following command
l2protocol-tunnel {cdp/vtp/stp)
or
l2protocol-tunnel point-to-point (lacp/Pagp/UDLD)

to troubleshoot 
  sh l2protocol-tunnel
   sh l2protocol-tunnel summary

Tunneling, note that LACP and UDLD are only support in a point-to-point operation.  This is the reason we used two different VLAN’s, 114 and 124, for the two ports connected to the customer.