A Q-in-Q VLAN tunnel
enables a service provider to segregate the traffic of different customers in
their infrastructure, while still giving the customer a full range of VLANs for
their internal use by adding a second 802.1Q tag to an already tagged frame.
Business customers of
service providers often have specific requirements for VLAN IDs and the number
of VLANs to be supported. The VLAN ranges required by different customers in
the same service-provider network might overlap, and traffic of customers
through the infrastructure might be mixed. Assigning a unique range of VLAN IDs
to each customer would restrict customer configurations and could easily exceed
the VLAN limit of 4096 of the 802.1Q specification.
Q-in-Q is supported
on port channels. To configure a port channel as an asymmetrical link, all
ports in the port channel must have the same tunneling configuration.
Using the 802.1Q
tunneling feature, service providers can use a single VLAN to support customers
who have multiple VLANs. Customer VLAN IDs are preserved and traffic from
different customers is segregated within the service-provider infrastructure
even when they appear to be on the same VLAN. The 802.1Q tunneling expands VLAN
space by using a VLAN-in-VLAN hierarchy and tagging the tagged packets. A port
configured to support 802.1Q tunneling is called a tunnel port. When you
configure tunneling, you assign a tunnel port to a VLAN that is dedicated to
tunneling. Each customer requires a separate VLAN, but that VLAN supports all
of the customer’s VLANs.
tagged in the normal way with appropriate VLAN IDs come from an 802.1Q trunk
port on the customer device and into a tunnel port on the service-provider edge
switch. The link between the customer device and the edge switch is an
asymmetric link because one end is configured as an 802.1Q trunk port and the
other end is configured as a tunnel port. You assign the tunnel port interface
to an access VLAN ID that is unique to each customer.
Figure 1. 802.1Q-in-Q
tunneling is not supported. All frames entering the tunnel port are subjected
to Q-in-Q tagging.
Packets that enter the
tunnel port on the service-provider edge switch, which are already
802.1Q-tagged with the appropriate VLAN IDs, are encapsulated with another
layer of an 802.1Q tag that contains a VLAN ID that is unique to the customer.
The original 802.1Q tag from the customer is preserved in the encapsulated
packet. Therefore, packets that enter the service-provider infrastructure are
The outer tag contains
the customer’s access VLAN ID (as assigned by the service provider), and the
inner VLAN ID is the VLAN of the incoming traffic (as assigned by the
customer). This double tagging is called tag stacking, Double-Q, or Q-in-Q.
The following figure
shows the differences between the untagged, tagged and double-tagged ethernet
Figure 2. Untagged,
802.1Q-Tagged, and Double-Tagged Ethernet Frames
By using this method,
the VLAN ID space of the outer tag is independent of the VLAN ID space of the
inner tag. A single outer VLAN ID can represent the entire VLAN ID space for an
individual customer. This technique allows the customer’s Layer 2 network to
extend across the service provider network, potentially creating a virtual LAN
infrastructure over multiple sites.
tagging, that is multi-level dot1q tagging Q-in-Q, is not supported.
802.1Q tunneling on an edge switch, you must use 802.1Q trunk ports for sending
out packets into the service-provider network. However, packets that go through
the core of the service-provider network might be carried through 802.1Q
trunks, ISL trunks, or nontrunking links. When 802.1Q trunks are used in these
core switches, the native VLANs of the 802.1Q trunks must not match any native
VLAN of the dot1q-tunnel port on the same switch because traffic on the native
VLAN is not tagged on the 802.1Q transmitting trunk port.
VLAN 40 is configured
as the native VLAN for the 802.1Q trunk port from Customer X at the ingress
edge switch in the service-provider network (Switch B). Switch A of Customer X
sends a tagged packet on VLAN 30 to the ingress tunnel port of Switch B in the
service-provider network that belongs to access VLAN 40. Because the access
VLAN of the tunnel port (VLAN 40) is the same as the native VLAN of the
edge-switch trunk port (VLAN 40), the 802.1Q tag is not added to the tagged
packets that are received from the tunnel port. The packet carries only the
VLAN 30 tag through the service-provider network to the trunk port of the
egress-edge switch (Switch C) and is misdirected through the egress switch
tunnel port to Customer Y.
The following figure
shows the native VLAN hazard.
Figure 3. Native VLAN
A couple of ways to
solve the native VLAN problem, are as follows:
Configure the edge
switch so that all packets going out an 802.1Q trunk, including the native
VLAN, are tagged by using the
tag native command. If the switch is configured to tag native VLAN
packets on all 802.1Q trunks, the switch accepts untagged packets but sends
only tagged packets.
dot1q tag native command is a global command that affects the tagging
behavior on all trunk ports.
Ensure that the
native VLAN ID on the edge switch trunk port is not within the customer VLAN
range. For example, if the trunk port carries traffic of VLANs 100 to 200,
assign the native VLAN a number outside that range.