Configuring IEEE 802.1Q Tunneling

The IEEE 802.1Q Tunneling feature is designed for service providers who carry traffic of multiple customers across their networks and are required to maintain the VLAN and Layer 2 protocol configurations of each customer without impacting the traffic of other customers.

IEEE 802.1Q Tunnel Ports in a Service Provider Network

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 device. The link between the customer device and the edge device 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 device are normally IEEE 802.1Q-tagged with the appropriate VLAN ID. The tagged packets remain intact inside the device 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 device, the outer tag is stripped as the device processes the packet. When the packet exits another trunk port on the same core device, 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 device, the outer tag is again stripped as the device internally processes the packet. However, the metro tag is not added when the packet is sent out the tunnel port on the edge device 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 device 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 device 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 device 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.)

Restrictions for Tunneling

  • IEEE 802.1Q tunneling and Layer 2 protocol tunneling are supported on the following platforms:

    • Cisco 1000 Series Integrated Services Routers

    • Cisco 4000 Series Integrated Services Routers with the NIM-ES module

  • The vlan dot1q tag native command is not supported.

  • Since the Ethernet virtual connection (EVC) of the WAN port is used as the 802.1Q-in-802.1Q (QinQ) port, the encapsulation of the Ethernet flow point (EFP) of the Switch Virtual Interface (SVI) and WAN port only supports default EFP and 802.1Q EFP. The 802.1AD TPID (0x88a8) is not supported. You cannot use the switchport as the QinQ port towards the service provider.

  • An SVI or Bridge Domain Interface (BDI) cannot route IEEE 802.1Q tunneling traffic.

  • EtherChannels are not supported.

  • The default DMAC of layer protocol tunneling is 01-00-0c-cd-cd-d0 and cannot be customized.

IEEE 802.1Q Tunneling and Other Features

Although IEEE 802.1Q tunneling works well for Layer 2 packet switching, there are incompatibilities between some Layer 2 features and Layer 3 switching.

  • A tunnel port cannot be a routed port.

  • IP routing is not supported on a VLAN that includes IEEE 802.1Q tunnel ports. Packets received from a tunnel port are forwarded based only on Layer 2 information. If routing is enabled on a switch virtual interface (SVI) that includes tunnel ports, untagged IP packets received from the tunnel port are recognized and routed by the switch. Customers can access the Internet through its native VLAN. If this access is not needed, you should not configure SVIs on VLANs that include tunnel ports.

  • Fallback bridging is not supported on tunnel ports. Because all IEEE 802.1Q-tagged packets received from a tunnel port are treated as non-IP packets, if fallback bridging is enabled on VLANs that have tunnel ports configured, IP packets would be improperly bridged across VLANs. Therefore, you must not enable fallback bridging on VLANs with tunnel ports.

  • Tunnel ports do not support IP access control lists (ACLs).

  • 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.

  • EtherChannel port groups are compatible with tunnel ports as long as the IEEE 802.1Q configuration is consistent within an EtherChannel port group.

  • Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP), and UniDirectional Link Detection (UDLD) are supported on IEEE 802.1Q tunnel ports.

  • 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.

  • VLAN Trunking Protocol (VTP) does not work between devices that are connected by an asymmetrical link or devices that communicate through a tunnel.

  • Loopback detection is supported on IEEE 802.1Q tunnel ports.

  • When a port is configured as an IEEE 802.1Q tunnel port, spanning-tree bridge protocol data unit (BPDU) filtering is automatically enabled on the interface. Cisco Discovery Protocol (CDP) and the Layer Link Discovery Protocol (LLDP) are automatically disabled on the interface.

  • When an IEEE 802.1Q tunnel port is configured as SPAN source, span filter must be applied for SVLAN to avoid packet loss.

  • IGMP/MLD packet forwarding can be enabled on IEEE 802.1Q tunnels. This can be done by disabling IGMP/MLD snooping on the service provider network.

Default IEEE 802.1Q Tunneling Configuration

By default, IEEE 802.1Q tunneling is disabled because the default switchport mode is dynamic auto. Tagging of IEEE 802.1Q native VLAN packets on all IEEE 802.1Q trunk ports is also disabled.

How to Configure IEEE 802.1Q Tunneling

Follow these steps to configure a port as an IEEE 802.1Q tunnel port:

Before you begin

  • Always use an asymmetrical link between the customer device and the edge device, with the customer device port configured as an IEEE 802.1Q trunk port and the edge device port configured as a tunnel port.

  • Assign tunnel ports only to VLANs that are used for tunneling.

  • Observe configuration requirements for native VLANs and for and maximum transmission units (MTUs).

Procedure

  Command or Action Purpose
Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/1

Enters interface configuration mode for the interface to be configured as a tunnel port. This should be the edge port in the service-provider network that connects to the customer device. Valid interfaces include physical interfaces and port-channel logical interfaces (port channels 1 to 48).

Step 4

switchport access vlan vlan-id

Example:

Device(config-if)# switchport access vlan 2

Specifies the default VLAN, which is used if the interface stops trunking. This VLAN ID is specific to the particular customer.

Step 5

switchport mode dot1q-tunnel

Example:

Device(config-if)# switchport mode dot1q-tunnel

Sets the interface as an IEEE 802.1Q tunnel port.

Note 

Use the no switchport mode dot1q-tunnel interface configuration command to return the port to the default state of dynamic desirable.

Step 6

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 8

Use one of the following:

  • show dot1q-tunnel
  • show running-config interface

Example:

Device# show dot1q-tunnel

or 

Device# show running-config interface

Displays the ports configured for IEEE 802.1Q tunneling.

Displays the ports that are in tunnel mode.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Example: Configuring an IEEE 802.1Q Tunneling Port

The following example shows how to configure a switch port as a tunnel port and verify the configuration. In this example, traffic received from the LAN switch port Gigabit Ethernet interface 0/1/3 is tagged with tunnel VLAN 2000 and service VLAN 3000 and then transmitted to WAN port Gigabit Ethernet interface 0/0/1. 

Device(config)# interface GigabitEthernet0/1/3
Device(config-if)# switchport access vlan 2000
% Access VLAN does not exist. Creating vlan 2000
Device(config-if)# switchport mode dot1q-tunnel
Device(config-if)# exit
Device(config)# interface Vlan2000
Device(config-if)# service instance 10 ethernet evc1
Device(config-if)# encapsulation dot1q 2000
Device(config-if)# rewrite ingress tag pop 1 symmetric
Device(config-if)# exit
Device(config)# interface GigabitEthernet0/0/1
Device(config-if)# service instance 10 ethernet
Device(config-if)# encapsulation dot1q 3000
Device(config-if)# rewrite ingress tag pop 1 symmetric
Device(config-if)# exit
Device(config)# bridge-domain 10
Device(config-if)# member GigabitEthernet0/0/1 service-instance 10
Device(config-if)# member Vlan2000 service-instance 10
Device(config-if)# exit
Device(config)# end

Monitoring Tunneling Status

The following table describes the commands used to monitor tunneling status.

Table 1. Commands for Monitoring Tunneling

Command

Purpose

show dot1q-tunnel

Displays IEEE 802.1Q tunnel ports on the device.

show dot1q-tunnel interface interface-id

Verifies if a specific interface is a tunnel port.

Feature History and Information for IEEE 802.1Q Tunneling

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Release

Modification

Cisco IOS XE Gibraltar 16.12.1

This feature was introduced