While I haven’t covered 802.1Q yet, I wanted to look at “QinQ“, allowing service providers to tunnel 802.1Q over their own managed ethernet network, which is likely running 802.1Q for customer separation.

1. Describe the features and operation of 802.1Q Tunneling (802.1QinQ) within a service provider network
2. Describe the operation and purpose of managed VLAN services

Packet Magazine ran an article about ip tunneling, and as a good description of QinQ:

Some service providers want to offer transparent LAN services that preserve and extend customers’ virtual LAN (VLAN) groupings and associated access privileges across a metropolitan-area network (MAN) and, possibly, a WAN. To do this, they can use Cisco 802.1Q Tunneling (also called Cisco 802.1Q-in-Q).

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’s VLAN traffic segregated and private.

The tag also enables as many as 4094 customer VLANs to be backhauled across a single service provider VLAN through the use of a tunnel port that is assigned to each customer site. All of a single customer’s VLANs that are configured in the tunnel port on the service provider’s WAN edge switch are aggregated and backhauled over a single VLAN.

Service providers do not have to assign a unique VLAN ID number to each individual customer VLAN, which quickly consumes the 4094-ID VLAN space supported by Ethernet’s 802.1Q technology. In this way, encapsulating multiple customer 802.1Q VLANs into a single service provider 802.1Q VLAN (thus the name, “Q in Q”) affords service providers a scalable approach to offering Ethernet services. To transport not only customers’ data traffic but also customers’ Layer 2 control traffic (such as Spanning Tree, Cisco Discovery Protocol, and VLAN Trunking Protocol), service providers must configure on 802.1Q tunneling ports Cisco Layer 2 Protocol Tunneling, a separate feature that is available in the same Cisco IOS® Software release.

In a nutshell, QinQ allows a service provider to give the customer a port that is mapped to a VLAN in the service provider network, letting the customer run a .1Q tunnel over it without having to worry about VLANid collisions.

A port configured to support 802.1Q tunneling is called a tunnel port (this is on the provider end). The customer simply configures their end of the connection as a regular 802.1Q tunnel. Within the service provider cloud, the links are carried as regular .1Q ports.

A very simplified way to look at the packet is as follows:

On the left, the customer passes a regular 802.1Q tagged packet to the provider’s tunnel port. The provider appends its own customer specific VLAN id to it and passes it through the cloud. Upon egress, the provider VLAN tag is removed and the customer sees a packet just as if it came from the other customer switch.

Consider the following network:

Customer A and B both use VLANs 6 and 7, but it doesn’t matter, because the provider has given them their own tags, say 2 and 3 (or even 6 and 7 for all it matters).

Configuring 802.1Q tunneling in CatOS is fairly easy.

! enable the feature on the switch
set dot1q-all-tagged enable
! Set it up on the port
set port dot1qtunnel mod/port access

Verify with

show port dot1qtunnel mod/port

Likewise, Configuring 802.1Q tunneling in IOS is also easy:

! Native VLAN traffic from customer should be tagged
Router(config)# vlan dot1q tag native
Router(config-if)# spanning-tree portfast trunk
Router(config-if)# switchport
Router(config-if)# switchport mode dot1qtunnel

show dot1q-tunnel interface

is used to show the tunnels.

I’m not sure how much depth the CCNP exam will get into, but some of the restrictions mentioned on the top of both of the articles may come into play. For one, since the frame is an encapsulated 802.1Q packet, it can not be routed! The IP headers are part of the underlying packet, which can not be inspected. Thus, many of the other mechanisms like QoS and filtering can not be done within the cloud, I suspect they would have to be applied at the service provider edge.

References

1. Packet Magazine
2. ip tunneling
3. Configuring 802.1Q tunneling in CatOS
4. Configuring 802.1Q tunneling in IOS