Table Of Contents
802.1Q Tunneling Configuration Guidelines
802.1Q Tunneling and Other Features
Configuring an 802.1Q Tunneling Port
Monitoring and Maintaining Tunneling Status
Configuring 802.1Q Tunneling
Virtual private networks (VPNs) provide enterprise-scale connectivity on a shared infrastructure, often Ethernet-based, with the same security, prioritization, reliability, and manageability requirements of private networks. Tunneling is a feature designed for service providers who carry traffic of multiple customers across their networks and who are required to maintain the VLAN configurations of each customer without impacting the traffic of other customers. The Catalyst 4500 series switch supports IEEE 802.1Q tunneling.
Note
Be aware that 802.1Q requires WS-C4948, WS-C4948-10GE, ME-4924-10GE, WS-C4928-10GE, WS-C4900M, WS-X4013+10GE, WS-X4516, or WS-X4516-10GE.
This chapter contains these sections:
•
•
•
Note
http://www.cisco.com/en/US/products/hw/switches/ps4324/index.html
If the command is not found in the Catalyst 4500 Command Reference, it is located in the larger Cisco IOS library. Refer to the Catalyst 4500 Series Switch Cisco IOS Command Reference and related publications at this location:
http://www.cisco.com/en/US/products/ps6350/index.html
About 802.1Q Tunneling
The VLAN ranges required by different customers in the same Service Provider network might overlap, and customer traffic 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 802.1Q specification.
802.1Q tunneling enables Service Providers to use a single VLAN to support customers who have multiple VLANs, while preserving customer VLAN IDs and keeping traffic in different customer VLANs segregated.
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 ID that is dedicated to tunneling. Each customer requires a separate Service Provider VLAN ID, but that Service Provider VLAN ID supports VLANs of all the customers.
Customer traffic tagged in the normal way with appropriate VLAN IDs comes 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 asymmetric 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. See Figure 22-1.
Figure 22-1 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 802.1Q-tagged with the appropriate VLAN ID. When the tagged packets exit the trunk port into the Service Provider network, they are encapsulated with another layer of an 802.1Q tag (called the metro tag) that contains the VLAN ID that is unique to the customer. The original customer 802.1Q tag is preserved in the encapsulated packet. Therefore, packets entering the Service Provider network are double-tagged, with the 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 metro 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 22-2 shows the tag structures of the Ethernet packets starting with the original, or normal, frame.
Figure 22-2 Original (Normal), 802.1Q, and Double-Tagged Ethernet Packet Formats
When the packet enters the trunk port of the Service Provider egress switch, the metro tag is again stripped as the switch 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 802.1Q-tagged frame to preserve the original VLAN numbers in the customer network.
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 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 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.)
In Figure 22-1, Customer A was assigned VLAN 30, and Customer B was assigned VLAN 40. Packets entering the edge-switch tunnel ports with 802.1Q tags are double-tagged when they enter the Service Provider network, with the metro tag containing VLAN ID 30 or 40, appropriately, and the inner tag containing the original customer VLAN number, for example, VLAN 100. Even if Customers A and B both have VLAN 100 in their networks, the traffic remains segregated within the Service Provider network because the metro 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.
Configuring 802.1Q Tunneling
These sections describe 802.1Q tunneling configuration:
•
•
•
Note
802.1Q Tunneling Configuration Guidelines
When you configure 802.1Q tunneling, you should always use asymmetrical links for traffic going through a tunnel and should dedicate one VLAN for each tunnel. You should also be aware of configuration requirements for native VLANs and maximum transmission units (MTUs). For more information about MTUs, see the "System MTU" section.
Native VLANs
When configuring 802.1Q tunneling on an edge switch, you must use 802.1Q trunk ports for sending packets into the Service Provider network. However, packets going through the core of the Service Provider network can 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 nontrunking (tunneling) port on the same switch because traffic on the native VLAN would not be tagged on the 802.1Q sending trunk port.
See Figure 22-3. VLAN 40 is configured as the native VLAN for the 802.1Q trunk port from Customer A at the ingress edge switch in the Service Provider network (Switch 2). Switch 1 of Customer A sends a tagged packet on VLAN 30 to the ingress tunnel port of Switch 2 in the Service Provider network, which 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 metro tag is not added to tagged packets 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 3) and is misdirected through the egress switch tunnel port to Customer B.
These are some ways to solve this problem:
•
•
•
Figure 22-3 Potential Problem with 802.1Q Tunneling and Native VLANs
System MTU
The default system MTU for traffic on the Catalyst 4500 series switch is 1500 bytes. You can configure the switch to support larger frames by using the system mtu global configuration command. Because the 802.1Q tunneling feature increases the frame size by 4 bytes when the metro tag is added, you must configure all switches in the Service Provider network to be able to process larger frames by increasing the switch system MTU size to at least 1504 bytes. The maximum allowable system MTU for Catalyst 4500 Gigabit Ethernet switches is 9198 bytes; the maximum system MTU for Fast Ethernet switches is 1552 bytes.
802.1Q Tunneling and Other Features
Although 802.1Q tunneling works well for Layer 2 packet switching, there are incompatibilities between some Layer 2 features and Layer 3 switching.
•
•
•
•
•
•
•
•
•
Configuring an 802.1Q Tunneling Port
To configure a port as an 802.1Q tunnel port, perform this task:
Use the no vlan dot1q tag native global command and the no switchport mode dot1q-tunnel interface configuration command to return the port to the default state of dynamic auto. Use the no vlan dot1q tag native global configuration command to disable tagging of native VLAN packets.
This example shows how to configure an interface as a tunnel port, enable tagging of native VLAN packets, and verify the configuration. In this configuration, the VLAN ID for the customer connected to Gigabit Ethernet interface 2/7 is VLAN 22.
Switch(config)# interface gigabitethernet2/7Switch(config-if)# switchport access vlan 22% Access VLAN does not exist. Creating vlan 22Switch(config-if)# switchport mode dot1q-tunnelSwitch(config-if)# exitSwitch(config)# vlan dot1q tag nativeSwitch(config)# endSwitch# show dot1q-tunnel interface gigabitethernet2/7Port-----LAN Port(s)-----Gi2/7Switch# show vlan dot1q tag nativedot1q native vlan tagging is enabled globallyMonitoring and Maintaining Tunneling Status
Table 22-1 shows the commands for monitoring and maintaining 802.1Q and Layer 2 protocol tunneling.
Note
Switch# show spann int f6/1 detailPort 321 (FastEthernet6/1) of VLAN0001 is listeningPort path cost 19, Port priority 128, Port Identifier 128.321.Designated root has priority 32768, address 0008.e341.4600Designated bridge has priority 32768, address 0008.e341.4600Designated port id is 128.321, designated path cost 0Timers: message age 0, forward delay 2, hold 0Number of transitions to forwarding state: 0Link type is point-to-point by default** Bpdu filter is enabled internally **BPDU: sent 0, received 0