IEEE 802.1ad Support on Provider Bridges
Available Languages
Table Of Contents
IEEE 802.1ad Support on Provider Bridges
Restrictions for IEEE 802.1ad Support on Provider Bridges
Information About IEEE 802.1ad Support on Provider Bridges
MAC Addresses for Layer 2 Protocols
IEEE 802.1ad Support on Provider Bridges Feature
Layer 2 PDU Destination MAC Addresses for Customer-Facing C-Bridge UNI Ports
Layer 2 PDU Destination MAC Addresses for Customer-Facing S-Bridge UNI Ports
How to Configure IEEE 802.1ad Support on Provider Bridges
Configuring a Switch Port to Process 802.1ad BPDUs
Configuring a Switch Port to Forward BPDUs
Configuring a Switch Port to Process BPDUs
Configuration Examples for IEEE 802.1ad Support on Provider Bridges
Example: Configuring an 802.1ad S-Bridge UNI
Example: Configuring an 802.1ad C-Bridge UNI
Feature Information for IEEE 802.1ad Support on Provider Bridges
IEEE 802.1ad Support on Provider Bridges
First Published: April 19, 2010Last Updated: May 26, 2011Service provider bridges (also called provider bridges) allow switches in a service provider network to transparently carry a customer's Layer 2 control frames, such as Spanning Tree Protocol (STP) bridge protocol data units (BPDUs) or Cisco Discovery Protocol frames, separate from the service provider's traffic and from other customer traffic in the service provider's network. User network interface (UNI) ports of a provider bridge interface with customer devices and have a specific set of requirements defined by the IEEE 802.1ad standard. These requirements enable provider bridges to have the same functionality as Layer 2 protocol tunneling (L2PT) and Q-in-Q (QnQ) bridges.
This document describes the IEEE 802.1ad implementation on Cisco switches using Layer 2 switch ports.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for IEEE 802.1ad Support on Provider Bridges" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Restrictions for IEEE 802.1ad Support on Provider Bridges
•
•
•
Restrictions for IEEE 802.1ad Support on Provider Bridges
•
Information About IEEE 802.1ad Support on Provider Bridges
•
•
Service Provider Bridges
Provider bridges pass the network traffic of many customers, and each customer's traffic flow must be isolated from one another. For Layer 2 protocols within customer domains to function properly, geographically separated customer sites must appear to be connected via a LAN, and the provider network must be transparent.
The IEEE has reserved 33 Layer 2 MAC addresses for customer devices operating Layer 2 protocols. If a provider bridge uses these standard MAC addresses for its Layer 2 protocols, the customers' and service provider's Layer 2 traffic will be mixed together. Provider bridges solve this traffic-mixing issue by providing Layer 2 protocol data unit (PDU) tunneling for customers using a provider bridge (S-bridge) component and a provider edge bridge (C-bridge) component. Figure 1 shows the topology.
Figure 1 Layer 2 PDU Tunneling
S-Bridge Component
The S-bridge component is capable of inserting or removing a service provider VLAN (S-VLAN) for all traffic on a particular port. IEEE 802.1ad adds a new tag called a Service tag (S-tag) to all ingress frames from the customer to the service provider.
The VLAN in the S-tag is used for forwarding the traffic in the service provider network. Different customers use different S-VLANs, which results in each customer's traffic being isolated. In the S-tag, provider bridges use an Ethertype value different than the standard 802.1Q Ethertype value, and they do not understand the standard Ethertype. This difference makes customer traffic tagged with the standard Ethertype appear as untagged in the provider network so customer traffic is tunneled in the port VLAN of the provider port. 802.1ad service provider user network interfaces (S-UNIs) and network-network interfaces (NNIs) implement the S-bridge component.
For example, a VLAN tag has a VLAN ID of 1, the C-tag Ethertype value is 8100 0001, the S-tag Ethertype value is 88A8 0001, and the class of service (CoS) is zero.
C-tag S-tag
------------------------------------------------------- --------------------------------------------------
0x8100 | Priority bits | CFI | C-VLAN-ID 0x88A8 | Priority bits | 0 | S-VLAN-ID
------------------------------------------------------- --------------------------------------------------
C-Bridge Component
All C-VLANs entering on a UNI port in an S-bridge component are provided the same service (marked with the same S-VLAN). C-VLAN components are not supported, but a customer may want to tag a particular C-VLAN packet separately to differentiate between services. Provider bridges allow C-VLAN packet tagging with a provider edge bridge, called the C-bridge component of the provider bridge. C-bridge components are C-VLAN aware and can insert or remove a C-VLAN 802.1Q tag. The C-bridge UNI port is capable of identifying the customer 802.1Q tag and inserting or removing an S-tag on the packet on a per service instance or C-VLAN basis. A C-VLAN tagged service instance allows service instance selection and identification by C-VLAN. 801.1ad customer user network interfaces (C-UNIs) implement the C-component.
MAC Addresses for Layer 2 Protocols
Customers' Layer 2 PDUs received by a provider bridge are not forwarded, so Layer 2 protocols running in customer sites do not know the complete network topology. By using a different set of addresses for the Layer 2 protocols running in provider bridges, IEEE 802.1ad causes customers' Layer 2 PDUs entering the provider bridge to appear as unknown multicast traffic and forwards it on customer ports (on the same S-VLAN). Customers' Layer 2 protocols can then run transparently.
Table 1 shows the Layer 2 MAC addresses reserved for the C-VLAN component.
Table 2 shows the Layer 2 MAC addresses reserved for the S-VLAN component. These addresses are a subset of the C-VLAN component addresses, and the C-bridge does not forward the provider's BPDUs to a customer network.
IEEE 802.1ad Support on Provider Bridges Feature
The IEEE 802.1ad Support on Provider Bridges feature is implemented on switch ports and supports the following IEEE 802.1ad specified functions:
•
•
•
In Cisco IOS Release 12.2(54)SE, the Cisco ME 3400E and Catalyst 3750 Metro switch platforms support this feature. The Cisco ME3400 switch platform does not support this feature.
Layer 2 PDU Destination MAC Addresses for Customer-Facing C-Bridge UNI Ports
Table 3 shows the Layer 2 PDU destination MAC addresses for customer-facing C-bridge UNI ports and how frames are processed.
Layer 2 PDU Destination MAC Addresses for Customer-Facing S-Bridge UNI Ports
If a port is operating as a customer-facing S-bridge UNI, the destination MAC addresses shown in Table 4 are used for defining the Layer 2 protocol PDU processing at the S-bridge UNI.
Table 4 shows the Layer 2 PDU destination MAC addresses for customer-facing S-bridge ports and how frames are processed.
How to Configure IEEE 802.1ad Support on Provider Bridges
•
Configuring a Switch Port to Process 802.1ad BPDUs
In an 802.1ad network, the default behavior for Layer 2 PDUs on an interface depends on the 802.1ad interface type. If the interface type is an S-bridge UNI, all Layer 2 PDUs are tunneled. If the interface type is a C-bridge UNI, all Layer 2 PDUs are processed (peered)
PDU processing on the S-bridge UNI is the same as on an 802.1ad NNI. Both interface types have the same scope of MAC addresses. Perform the tasks in this section to configure one switch port to forward 802.1ad BPDUs end to end and another switch port to peer (process) BPDUs:
•
•
Configuring a Switch Port to Forward BPDUs
Perform this task to configure a switch port to forward BPDUs.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring a Switch Port to Process BPDUs
Perform this task to configure a switch port to process BPDUs.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuration Examples for IEEE 802.1ad Support on Provider Bridges
•
•
Example: Configuring an 802.1ad S-Bridge UNI
The following example shows how to configure GigabitEthernet interface 0/2 of a PE as an 802.1ad S-bridge UNI. In this example, only Cisco Discovery Protocol PDUs will be forwarded (tunneled). Cisco Discovery Protocol PDUs will be forwarded between the PE and a customer device.
Switch# configure terminalSwitch(config)# interface GigabitEthernet 0/2Switch(config-if)# switchport access vlan 500Switch(config-if)# ethernet dot1ad uni s-portSwitch(config-if)# l2protocol forward cdpExample: Configuring an 802.1ad C-Bridge UNI
The following example shows how to configure interface GigabitEthernet 0/3 of a PE as an 802.1ad C-bridge UNI. In this example, only Cisco Discovery Protocol PDUs will be processed.
Switch# configure terminalSwitch(config)# interface GigabitEthernet 0/3Switch(config-if)# switchport mode trunkSwitch(config-if)# ethernet dot1ad uni c-portSwitch(config-if)# l2protocol peer cdpAdditional References
Related Documents
Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Configuring Carrier Ethernet
Cisco IOS Carrier Ethernet Configuration Guide, Release 12.2SR
Standards
MIBs
None
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Feature Information for IEEE 802.1ad Support on Provider Bridges
Table 5 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Glossary
DTP—Dynamic Trunking Protocol
GARP—Generic Attribute Registration Protocol
GMRP—GARP Multicast Registration Protocol
GVRP—Generic VLAN Registration Protocol
LLDP—Link Layer Discovery Protocol
OAM—Operations, Administration, and Maintenance
PagP—Port Aggregation Protocol
PVST—Per-VLAN Spanning Tree
UDLD—UniDirectional Link Detection
VTP—VLAN Trunk Protocol
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2010-2011 Cisco Systems, Inc. All rights reserved.
Feedback