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 (4096) of the IEEE 802.1Q specification.
Using the IEEE 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 network, even
when they appear to be in the same VLAN. Using IEEE 802.1Q tunneling expands
VLAN space by using a VLAN-in-VLAN hierarchy and retagging the tagged packets.
A port configured to support IEEE 802.1Q tunneling is called a tunnel port.
When you configure tunneling, you assign a tunnel port to a VLAN ID that is
dedicated to tunneling. Each customer requires a separate service-provider VLAN
ID, but that VLAN ID supports all of the customer’s VLANs.
Customer traffic
tagged in the normal way with appropriate VLAN IDs comes from an IEEE 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 asymmetric because one end is configured as an IEEE 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. IEEE 802.1Q
Tunnel Ports in a Service-Provider Network
Packets coming from
the customer trunk port into the tunnel port on the service-provider edge
switch
are normally IEEE 802.1Q-tagged with the appropriate VLAN ID. The tagged
packets remain intact inside the
switch
and when they exit the trunk port into the service-provider network, they are
encapsulated with another layer of an IEEE 802.1Q tag (called the metro tag)
that contains the VLAN ID that is unique to the customer. The original customer
IEEE 802.1Q tag is preserved in the encapsulated packet. Therefore, packets
entering the service-provider network are double-tagged, with the outer (metro)
tag containing the customer’s access VLAN ID, and the inner VLAN ID being that
of the incoming traffic.
When the double-tagged
packet enters another trunk port in a service-provider core
switch,
the outer tag is stripped as the
switch
processes the packet. When the packet exits another trunk port on the same core
switch,
the same metro tag is again added to the packet.
Figure 2. Original
(Normal), IEEE 802.1Q, and Double-Tagged Ethernet Packet Formats. This figure shows
the tag structures of the double-tagged packets.
When the packet enters
the trunk port of the service-provider egress
switch,
the outer tag is again stripped as the
switch
internally processes the packet. However, the metro tag is not added when the
packet is sent out the tunnel port on the edge
switch
into the customer network. The packet is sent as a normal IEEE 802.1Q-tagged
frame to preserve the original VLAN numbers in the customer network.
In the above network
figure, Customer A was assigned VLAN 30, and Customer B was assigned VLAN 40.
Packets entering the edge
switch
tunnel ports with IEEE 802.1Q tags are double-tagged when they enter the
service-provider network, with the outer tag containing VLAN ID 30 or 40,
appropriately, and the inner tag containing the original VLAN number, for
example, VLAN 100. Even if both Customers A and B have VLAN 100 in their
networks, the traffic remains segregated within the service-provider network
because the outer tag is different. Each customer controls its own VLAN
numbering space, which is independent of the VLAN numbering space used by other
customers and the VLAN numbering space used by the service-provider network.
At the outbound tunnel
port, the original VLAN numbers on the customer’s network are recovered. It is
possible to have multiple levels of tunneling and tagging, but the
switch
supports only one level in this release.
If traffic coming from
a customer network is not tagged (native VLAN frames), these packets are
bridged or routed as normal packets. All packets entering the service-provider
network through a tunnel port on an edge
switch
are treated as untagged packets, whether they are untagged or already tagged
with IEEE 802.1Q headers. The packets are encapsulated with the metro tag VLAN
ID (set to the access VLAN of the tunnel port) when they are sent through the
service-provider network on an IEEE 802.1Q trunk port. The priority field on
the metro tag is set to the interface class of service (CoS) priority
configured on the tunnel port. (The default is zero if none is configured.)
On
switches,
because 802.1Q tunneling is configured on a per-port basis, it does not matter
whether the
switch
is a standalone
switch
or a stack member. All configuration is done on the stack master.