- Preface
- Product Overview
- Basic Configurations
- Configuring the OC-3c/STM-1, OC-12c/STM-4, and OC-48c/STM-16 SONET/SDH Optical
- Configuring the 4-Port Gigabit Ethernet WAN Optical Services Modules
- Configuring the Channelized OC-12/T3 SONET/SDH Optical Services Modules
- Configuring the Channelized OC-12/T1 Optical Services Modules
- Configuring the Channelized 12-port CT3/T1 Optical Services Modules
- Configuring the OC-12 ATM Optical Services Modules
- Configuring QoS on the Optical Services Modules
- Configuring Multiprotocol Label Switching on the Optical Services Modules
OSM Configuration Note, 12.2SR
Chapter: Configuring Multiprotocol Label Switching on the Optical Services Modules
- Configuring MPLS
- Configuring MPLS QoS
- Configuring MPLS VPN
- Configuring MPLS VPN QoS
- Any Transport over MPLS
- Supervisor Engine 720-Based EoMPLS
- Supported OSMs
- Configuring EoMPLS VLAN Mode for OSM-Based System
- Configuring EoMPLS VLAN Mode for Supervisor Engine 720-Based System
- Ethernet over MPLS VLAN Mode Configuration Guidelines
- Configuring EoMPLS Port Mode for OSM-Based System
- Configuring EoMPLS Port Mode for Supervisor Engine 720-Based System
- Prerequisites for the HQoS for EoMPLS VCs Feature
- Restrictions for the HQoS for EoMPLS VCs Feature
- Supported Features
- Related Commands
- Configuring the HQoS for EoMPLS VCs Feature
- Creating and Assigning a Policy Map to Mark the QoS Group at the Incoming Interface
- Configuring the Class Map to Match on a QoS Group
- Creating the Child Policy Map for the Egress Interface
- Configuring the Class Maps for Matching on an Input VLAN
- Creating the Parent Policy Map and Attaching It to the Egress Interface
- Configuration Examples for the HQoS for EoMPLS VCs Feature
Configuring Multiprotocol Label Switching on the Optical Services Modules
This chapter describes how to configure Multiprotocol Label Switching (MPLS) and Any Transport over Multiprotocol Label Switching (AToM) on the Optical Services Modules (OSMs).
This chapter consists of these sections:
•
How to Configure QoS with AToM
•HQoS for EoMPLS Virtual Circuits
•Virtual Private LAN Services on the Optical Services Modules
Configuring MPLS
These sections describe MPLS and provides configuration information:
•MPLS Limitations and Restrictions
Understanding MPLS
MPLS uses label switching to forward packets over various link-level technologies such as Packet-over-SONET, Frame Relay, ATM, and Ethernet. Labels are assigned to packets based on groupings or forwarding equivalence classes (FECs). Packets belonging to the same FEC get similar treatment. The label is added between the Layer 2 and the Layer 3 header (in a packet environment) or in the virtual path identifier/virtual channel identifier (VPI/VCI) field (in ATM networks).
In an MPLS network, the edge router performs a label lookup of the incoming label, swaps the incoming label with an outgoing label, and sends the packet to the next hop. Labels are imposed on packets only at the ingress edge of the MPLS network and are removed at the egress edge. The core network reads the labels, applies the appropriate services, and forwards the packets based on the labels.
MPLS Support on OSMs
MPLS is supported on the following Cisco 7600 series OSMs:
•OC-3 POS:
–OSM-4OC3-POS-SI+
–OSM-8OC3-POS-SI+, SL+
•OC-12 POS:
–OSM-2OC12-POS-MM+, SI+, SL+
–OSM-4OC12-POS-MM+, SI+, SL+
•OC-12 ATM:
–OSM-2OC12-ATM-MM+
–OSM-2OC12-ATM-SI+
•OC-48 POS:
–OSM-1OC48-POS-SS+, SI+, SL+
–OSM-2OC48/1DPT-SS, SI, SL
•Gigabit Ethernet
–OSM-2+4GE-WAN+
•WS-X6582-2PA Enhanced FlexWAN
Supported Features
The following features are supported with SUP720-3BXL and SUP720-3CXL supervisor engines:
Note Features in the Cisco IOS 12.2SR releases that are also supported in the Cisco IOS 12.2 mainline, 12.2T and 12.2S releases are documented in the corresponding publications for those releases. When applicable, this section refers to those publications for platform-independent features supported in the Cisco IOS 12.2SR releases. The Cisco IOS 12.2S releases do not support software images for the Cisco 7600 series routers, and the Cisco IOS 12.2S publications do not list support for the Cisco 7600 series routers.
•Multi-VRF for CE Routers (VRF Lite)—VRF-lite is a feature that enables a service provider to support two or more VPNs, where IP addresses can be overlapped among the VPNs. See http://www.cisco.com/en/US/products/hw/routers/ps259/prod_bulletin09186a00800921d7.html.
Note Multi-VRF for CE Routers (VRF Lite) is supported with the following features: IPv4 forwarding between VRFs interfaces, IPv4 ACLs, and IPv4 HSRP. Starting with Cisco IOS Release 12.2(18)SXE, Multi-VRF for CE Routers (VRF Lite) is supported with IPv4 multicast..
Note Multi-VRF for CE Routers (VRF Lite) is also supported with the Supervisor Engine 720 with PFC3A.
•MPLS Label Distribution Protocol (LDP)—MPLS label distribution protocol (LDP), as standardized by the Internet Engineering Task Force (IETF) and as enabled by Cisco IOS software, allows the construction of highly scalable and flexible IP Virtual Private Networks (VPNs) that support multiple levels of services. See http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs2sldp.html.
•Multiprotocol Label Switching (MPLS) on Cisco Routers—This feature provides basic MPLS support for imposing and removing labels on IP packets at label edge routers (LERs) and switching labels at label switch routers (LSR). See http://www.cisco.com/en/US/docs/ios/12_0st/12_0st21/feature/guide/fs_rtr.html.
•MPLS Traffic Engineering-DiffServ Aware (DS-TE)—This feature provides extensions made to Multiprotocol Label Switching Traffic Engineering (MPLS TE) to make it DiffServ aware, allowing constraint-based routing of guaranteed traffic. See http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsdserv3.html.
•MPLS Traffic Engineering Forwarding Adjacency—This feature allows a network administrator to handle a traffic engineering, label-switched path (LSP) tunnel as a link in an Interior Gateway Protocol (IGP) network based on the Shortest Path First (SPF) algorithm. For information on forwarding adjacency with Intermediate System-to-Intermediate System (IS-IS) routing, see http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fstefa_3.html.
For information on forwarding adjacency with Open Shortest Path First (OSPF) routing, see http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospffa.html.
•MPLS Traffic Engineering (TE) Interarea Tunnels—This feature allows the router to establish MPLS TE tunnels that span multiple Interior Gateway Protocol (IGP) areas and levels, removing the restriction that had required the tunnel head-end and tail-end routers to be in the same area. See http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsiarea3.html.
•MPLS Virtual Private Networks (VPNs)—This feature allows you to deploy scalable IPv4 Layer 3 VPN backbone services over a Cisco IOS network. See http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st21/fs_vpn.htm.
•MPLS VPN Carrier Supporting Carrier (CSC)—The feature enables one MPLS VPN-based service provider to allow other service providers to use a segment of its backbone network. See http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftcsc8.html.
•MPLS VPN—Carrier Supporting Carrier—IPv4 BGP Label Distribution—This feature enables you to configure your carrier supporting carrier network to enable Border Gateway Protocol (BGP) to transport routes and Multiprotocol Label Switching (MPLS) labels between the backbone carrier provider edge (PE) routers and the customer carrier customer edge (CE) routers. See http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftcscl13.html.
•MPLS VPN—Interautonomous System Support—This feature allows an MPLS VPN to span service providers and autonomous systems. See http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsias24.html.
•MPLS VPN—Inter-AS—IPv4 BGP Label Distribution: This feature enables you to set up a Virtual Private Network (VPN) service provider network so that the autonomous system boundary routers (ASBRs) exchange IPv4 routes with Multiprotocol Label Switching (MPLS) labels of the provider edge (PE) routers.See http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftiasl13.html.
•Hot Standby Router Protocol (HSRP) Support for Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs)—This feature ensures that the HSRP virtual IP address is added to the correct IP routing table and not to the default routing table. See http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dt_hsmp.html.
•OSPF Sham Link: OSPF Sham-Link Support for MPLS VPN—This feature allows you to use a sham-link to connect Virtual Private Network (VPN) client sites that run the Open Shortest Path First (OSPF) protocol and share backdoor OSPF links in a Multiprotocol Label Switching (MPLS) VPN configuration. See http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ospfshmk.html.
•BGP Multipath Load Sharing for eBGP and iBGP—This feature allows you to configure multipath load balancing with both external BGP (eBGP) and internal BGP (iBGP) paths in Border Gateway Protocol (BGP) networks that are configured to use Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). See http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fseibmpl.html.
•Any Transport over MPLS (AToM). Transports Layer 2 packets over a Multiprotocol Label Switching (MPLS) backbone. See the "Any Transport over MPLS" section.
MPLS Limitations and Restrictions
The following platform-specific limitations and restrictions apply to the MPLS support on the OSM modules:
•MPLS Traffic Engineering with Fast ReRoute (FRR) protection—this feature is not yet supported.
MPLS Limitations
The following MPLS limitations apply:
•MTU checking and fragmentation is not supported on the OSMs except that checking is supported on the OSM-2+4GE-WAN+ on the receive path.
Note For information on other limitations and restrictions, see "MPLS VPN Limitations and Restrictions" section, "Ethernet over MPLS Restrictions" section, and "Restrictions for VPLS" section.
Configuring MPLS
For information on configuring MPLS, refer to the Multiprotocol Label Switching on Cisco Routers feature module at the following URLs:
http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/mpls4t.html
Configuring MPLS QoS
This section provides configuration information for MPLS QoS.
Supported MPLS QoS Features
The OSMs support the following MPLS QoS features:
•OSM QoS features using MPLS EXP classification. See "Configuring QoS on the OSMs" section.
•MPLS EXP policing and marking done by PFC3BXL when the OSMs are used with a SUP720-3BXL. For PFC3BXL policing and marking, refer to http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/qos.html.
Note For AToM QoS features, see "How to Configure QoS with AToM" section.
Configuring MPLS VPN
These sections describe how to configure MPLS VPN:
•MPLS VPN Limitations and Restrictions
•MPLS VPN Memory Requirements and Recommendations
•MPLS Per-Label Load Balancing
MPLS VPN Support on OSMs
MPLS VPN is supported on the following OSMs:
•OC-3 POS:
–OSM-4OC3-POS-SI+
–OSM-8OC3-POS-SI+, SL+
•OC-12 POS:
–OSM-2OC12-POS-MM+, SI+, SL+
–OSM-4OC12-POS-MM+, SI+, SL+
•OC-12 ATM:
–OSM-2OC12-ATM-MM+
–OSM-2OC12-ATM-SI+
•OC-48 POS:
–OSM-1OC48-POS-SS+, SI+, SL+
–OSM-2OC48/1DPT-SS, SI, SL
•Gigabit Ethernet:
–OSM-2+4GE-WAN+
•WS-X6582-2PA Enhanced FlexWAN
MPLS VPN Limitations and Restrictions
The following MPLS VPN limitations apply:
•With SUP720-3BXL- or SUP720-3CXL-based systems, load sharing is supported.
•With SUP720-3BXL- or SUP720-3CXL-based systems, MTU checking and fragmentation is supported.
•For SUP720-3BXL- or SUP720-3CXL-based systems, a total of 1000 VRFs per chassis are supported with enhanced OSMs; using a non-enhanced OSM causes the system to default to 511 VRFs.
•With SUP720-3BXL- or SUP720-3CXL-based systems, MPLS Provider (P) functionality is supported.
MPLS VPN Memory Requirements and Recommendations
When a Cisco 7600 series router functions as a PE router in an MPLS VPN environment, the memory requirements that are listed in Table 9-1apply:
If the number of Internet routes, eBGP sessions, and VPNv4 routes exceed those listed in Table 9-1, upgrade to the next memory option. If you have an Enhanced FlexWAN module installed in the system, the number of Internet routes, eBGP sessions, and VPNv4 routes in the configuration file must not exceed the requirement listed in the table for FlexWAN.
MPLS Per-Label Load Balancing
The Supervisor Engine 720 handles MPLS labeled packets without commands. If the packet has three labels or less and the underlying packet is IPv4 then the Supervisor Engine 720 uses the source and destination IPv4 address. If the underlying packet is not IPv4 or more then three labels are present, then the Supervisor Engine 720 parses down as deep as the fifth or lowest label and uses it for hashing.
For information on configuring MPLS VPN, refer to the MPLS Virtual Private Networks feature module at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/vpn_en.htm.
Configuring MPLS VPN QoS
The OSMs support the following MPLS VPN QoS features:
•OSM QoS features using MPLS EXP classification. See "Configuring QoS on the OSMs" section.
•MPLS EXP policing and marking done by PFC3BXL when the OSMs are used with a SUP720-3BXL. For PFC3BXL policing and marking, refer to http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/qos.html.
The following restrictions apply to the support for MPLS VPN QoS on the OSMs:
•PFC2 QoS features are not supported with MPLS VPN.
•MPLS VPN QoS is supported on the VPN interfaces only.
Match IP precedence and SET IP precedence and MPLS Experimental values are supported on the input interface only.
Configuration Example
The following example shows how to configure QoS on an MPLS VPN:
Router# configure terminal
Router(config)# class-map match-any vpn-class
Router(config-cmap)# match ip precedence 3
Router(config-cmap)# exit
Router(config)# policy-map VPN-MARKING
Router(config-pmap)# class vpn-class
Router(config-pmap-c)# set ip precedence 5
Router(config-pmap-c)# set mpls exp 5
Router(config-pmap-c)# ^Z
Router# configure terminal
Router(config)# interface ge-WAN 5/4
Router(config-if)# service-policy input VPN-MARKING
Router(config-if)# ^Z
Router# show running-config interface g5/4
Building configuration...
Current configuration :175 bytes
!
interface GE-WAN5/4
ip vrf forwarding TEST
ip address 194.3.1.3 255.255.255.0
negotiation auto
service-policy input VPN-MARKING
mls qos trust dscp
end
Router#
Any Transport over MPLS
Any Transport over MPLS (AToM) transports Layer 2 packets over a Multiprotocol Label Switching (MPLS) backbone. AToM uses a directed Label Distribution Protocol (LDP) session between edge routers for setting up and maintaining connections. Forwarding occurs through the use of two level labels, switching between the edge routers. The external label (tunnel label) routes the packet over the MPLS backbone to the egress Provider Edge (PE) at the ingress PE. The VC label is a demuxing label that determines the connection at the tunnel endpoint (the particular egress interface on the egress PE as well as the VPI/VCI value for the AAL5 PDU, the DLCI value for Frame Relay PDU, or the VLAN identifier for an Ethernet frame).
AToM supports the following like-to-like transport types for Supervisor Engine 720-based systems:
•Ethernet over MPLS (VLAN mode and port mode)
Note Supervisor Engine 720-based systems support both hardware-based WAN as well as OSM- or Enhanced FlexWAN-based WAN.
Note Supervisor Engine 720-based systems require that the core-facing cards must be WAN cards (enhanced OSMs, Enhanced FlexWAN modules, and Shared Port Adapter [SPA] Interface Processors [SIPs]). This applies to Ethernet over MPLS.
Also, the specific MPLS core-facing line card may not be supported for a specific AToM technology; view specific AToM configurations in this chapter, in the FlexWAN and Enhanced FlexWAN Modules Configuration Guide, and in the Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide for more details.
Restrictions for Any Transport over MPLS
The following general restrictions pertain to all transport types under AToM:
•Sequencing: AToM does not support detecting of out-of-order packets.
•Address format: Configure the LDP router ID on all PE routers to be a loopback address with a /32 mask. Otherwise, some configurations might not properly function.
•Fragmentation and Reassembly: Ensure that the maximum transmission unit (MTU) of all intermediate links between endpoints is sufficient to carry the largest Layer 2 packet received.
•Control word: You cannot use CLI to enable or disable control word.
Ethernet over MPLS Restrictions
The following restrictions pertain to the Ethernet over MPLS feature:
•Fragmentation and Reassembly: Ensure that the maximum transmission unit (MTU) of all intermediate links between endpoints is sufficient to carry the largest Layer 2 packet received.
•Packet Format: EoMPLS supports VLAN packets that conform to the IEEE's 802.1Q standard. The 802.1Q specification establishes a standard method for inserting VLAN membership information into Ethernet frames.
•Preserving 802.1 P bits and IP precedence bits: If QoS is disabled globally, both the 802.1p and IP precedence bits are preserved. When the QoS is enabled on a Layer 2 port, either 802.1q P bits or IP precedence bits can be preserved with the trusted configuration. However, by default the unpreserved bits are overwritten by the value of preserved bits. For instance, if you preserve the P bits, the IP precedence bits are overwritten with the value of the P bits. PFC3BXL provides a new command that allows you to trust the P bits while preserving the IP precedence bits. To preserve the IP precedence bits, use the no mls qos rewrite ip dscp command.
Note The no mls qos rewrite ip dscp command is not compatible with the MPLS and MPLS VPN features. See http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/qos.html.
•Private VLANs: EoMPLS is not supported with private VLANs.
•Layer 2 Connections: The following restrictions apply to using Layer 2 connection with Ethernet over MPLS:
–You cannot have a direct Layer 2 connection between PEs with Ethernet over MPLS.
–You cannot have more than one Layer 2 connection between routers if those routers are configured to transport Ethernet VLAN packets over the MPLS backbone. Adding a second Layer 2 connection causes the spanning tree state to constantly toggle if you disable spanning tree on the peer router.
•Ethernet over MPLS and Trunks: The following restrictions apply to using trunks with Ethernet over MPLS. For more information, see theCisco 7600 Series Router software documentation.
–Spanning Tree: To support Ethernet spanning tree bridge protocol data units (BPDUs) across an EoMPLS cloud, you must disable the supervisor engine spanning tree for the Ethernet over MPLS VLAN. This ensures that the EoMPLS VLANs are carried only on the trunk to the customer switch. Otherwise, the BPDUs are directed to the supervisor engine and not to the EoMPLS cloud.
–Native VLAN: The native VLAN of a trunk must not be configured as an EoMPLS VLAN.
• Layer 2 Protocol Tunneling: With PFC3BXL-based systems, there is a configuration choice for user to decide which specific protocols (for example, CDP, VTP, BPDUs). get tunneled across the MPLS cloud and which ones terminate locally. This is supported in software switching path.
• ISL encapsulation is not supported for the interface that receives EoMPLS packets.
• Unique VLANs are required across interfaces. You cannot use the same VLAN ID on different interfaces.
• EoMPLS tunnel destination route in routing and CEF table must be with a /32 mask to insure that there is an LSP from PE to PE.
•For a particular EoMPLS connection, both the ingress EoMPLS interface on the ingress PE and the egress EoMPLS interface on the egress PE have to be sub-interfaces with dot1Q encapsulation or neither is a sub-interface.
• 802.1Q in 802.1Q over EoMPLS is supported if outgoing interface connecting to MPLS network is a port on an Layer 2 card.
•Shaping of EoMPLS traffic is not supported if egress interface connecting to MPLS network is Layer 2 card.
•EoMPLS based on PFC3BXL does not perform any Layer 2 look up to determine if the destination MAC address resides on the local or remote segment and does not perform any Layer 2 address learning (as traditional LAN bridging does). This functionality (local switching or hair pinning) is available only when using OSM/FlexWAN-based modules as uplinks.
Information About Any Transport over MPLS
To configure AToM, you must understand the following concepts:
•How AToM Transports Layer 2 Packets
•Compatibility with Previous Releases of AToM
How AToM Transports Layer 2 Packets
AToM encapsulates Layer 2 frames at the ingress PE and sends them to a corresponding PE at the other end of a pseudowire, which is a connection between the two PE routers. The egress PE removes the encapsulation and sends out the Layer 2 frame.
The successful transmission of the Layer 2 frames between PE routers is due to the configuration of the PE routers. You set up the connection, called a pseudowire, between the routers. You specify the following information on each PE router:
•The type of Layer 2 data that will be transported across the pseudowire, such as Ethernet, Frame Relay, or ATM
•The IP address of the loopback interface of the peer PE router, which enables the PE routers to communicate
•A VC ID that uniquely identifies the pseudowire
The following example shows the basic configuration steps on a PE router that enable the transport of Layer 2 packets.
First define the interface or subinterface on the PE router.
Router# interface interface-type interface-number
Then specify the encapsulation type for the interface, such as dot1q.
Router(config-if)# encapsulation encapsulation-type
The last step does the following:
•Makes a connection to the peer PE router by specifying the LDP router ID of the peer PE router.
•Identifies a unique identifier that is shared between the two PE routers. The vcid is a 32-bit identifier.
The combination of the peer-router-id and the VC ID must be a unique combination on the router. Two circuits cannot use the same combination of peer-router-id and VC ID.
•Specifies the tunneling method used to encapsulate data in the pseudowire. For AToM, the tunneling method used to encapsulate data is mpls.
Router(config-if)# xconnect peer-router-id vcid encapsulation mpls
Compatibility with Previous Releases of AToM
In previous releases of AToM, the command used to configure AToM circuits was mpls l2 transport route. This command has been replaced with the xconnect command. You can use the xconnect command to configure EoMPLS circuits.
Benefits of AToM
The following list explains some of the benefits of enabling Layer 2 packets to be sent in the MPLS network:
•The AToM product set accommodates many types of Layer 2 packets, including Ethernet and Frame Relay, across multiple Cisco router platforms, including the Cisco 7600 series routers. This enables the service provider to transport all types of traffic over the backbone and accommodate all types of customers.
•AToM adheres to the standards developed for transporting Layer 2 packets over MPLS. (See the "Ethernet over MPLS" section for the specific standards that AToM follows.) This benefits the service provider who wants to incorporate industry-standard methodologies in the network. Other Layer 2 solutions are proprietary, which can limit the service provider's ability to expand the network and can force the service provider to use only one vendor's equipment.
•Upgrading to AToM is transparent to the customer. Because the service provider network is separate from the customer network, the service provider can upgrade to AToM without disruption of service to the customer. The customers assume that they are using a traditional Layer 2 backbone.
Prerequisites
Before configuring AToM, ensure that the network is configured as follows:
•Configure IP routing in the core so that the PE routers can reach each other via IP.
•Configure MPLS in the core so that a label switched path (LSP) exists between the PE routers.
AToM and QoS
MPLS AToM uses the three experimental bits in a label to determine the queue of packets. You statically set the experimental bits in both the VC label and the LSP tunnel label, because the LSP tunnel label might be removed at the penultimate router. See "How to Configure QoS with AToM" section and "HQoS for EoMPLS Virtual Circuits" section for more information.
Ethernet over MPLS
Ethernet over MPLS works by encapsulating Ethernet PDUs in MPLS packets and forwarding them across the MPLS network. Each PDU is transported as a single packet. There are two ways to configure Ethernet over MPLS:
•VLAN mode—transports Ethernet traffic from a source 802.1Q VLAN to a destination 802.1Q VLAN through a single VC over an MPLS network.
•Port mode—allows all traffic on a port to share a single VC across an MPLS network.
Supervisor Engine 720-Based EoMPLS
With Supervisor Engine 720-based systems, the supervisor engine 720 supports the MPLS functionality. The supervisor engine 720 can receive Layer 2 traffic, impose labels, and switch the frames into the MPLS core without using an OSM or FlexWAN module.
You can also equip a Supervisor Engine 720-based system with an OSM or a Flexwan module facing the core of MPLS network. In this case, you can use either OSM/FlexWAN-based configuration or the SUP720-3BXL-based configuration.
Note A system can have both an OSM/FlexWAN-based configuration and a SUP720-3BXL-based configuration enabled at the same time. Cisco supports this configuration but does not recommend it. Unless the uplinks to the MPLS core are through OSM/FlexWAN-enabled interfaces then OSM/FlexWAN-based EoMPLS connections are not active; this causes packets for OSM/FlexWAN-based EoMPLS arriving on non-WAN interfaces to be dropped.
Supported OSMs
EoMPLS is supported on the OSM-2+4GE-WAN+.
Configuring EoMPLS VLAN Mode for OSM-Based System
To configure MPLS to transport Layer 2 VLAN packets between two endpoints in an OSM-based system, perform the following steps on the provider edge (PE) routers.
Note When OSPF is used as the IGP, all loopback addresses on PE routers must be configured with 32-bit masks to ensure proper operation of MPLS forwarding between PE routers.
SUMMARY STEPS
1. enable
2. configure terminal
3. vlan
4. interface gigabitEthernet
5. switchport
6. switchport trunk encapsulation dot1q
7. switchport trunk allowed vlan list
8. switchport mode trunk
9. exit
10. interface vlan
11. xconnect peer-router-id vcid encapsulation mpls
DETAILED STEPS
The following configuration shows a mode trunk configuration.
CE1 Configuration
!
interface GigabitEthernet1/0
no ip address
no ip mroute-cache
negotiation auto
no cdp enable
no shut
!
interface GigabitEthernet1/0.2
encapsulation dot1Q 2
ip address 180.8.0.1 255.255.0.0
no cdp enable
no shut
!
interface GigabitEthernet1/0.3
encapsulation dot1Q 3
ip address 180.9.0.1 255.255.0.0
no cdp enable
no shut
!
CE2 Configuration
!
interface GigabitEthernet4/0
no ip address
no ip directed-broadcast
negotiation auto
tag-switching ip
no cdp enable
no shut
!
interface GigabitEthernet4/0.2
encapsulation dot1Q 2
ip address 180.8.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
interface GigabitEthernet4/0.3
encapsulation dot1Q 3
ip address 180.9.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
PE1 Configuration
!
vlan 2-3
!
interface GigabitEthernet1/4
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 2-3
switchport mode trunk
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 11.11.11.11 2 encapsulstion mpls
no shut
!
interface Vlan3
no ip address
no ip mroute-cache
xconnect 11.11.11.11 3 encapsulation mpls
no shut
!
PE2 Configuration
!
vlan 2-3
!
interface GigabitEthernet7/4
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 2-3
switchport mode trunk
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 13.13.13.13 2 encapsulation mpls
no shut
!
interface Vlan3
no ip address
no ip mroute-cache
xconnect 13.13.13.13 3 encapsulation mpls
no shut
!
Configuring EoMPLS VLAN Mode for Supervisor Engine 720-Based System
To configure MPLS to transport Layer 2 VLAN packets between two endpoints in a supervisor engine 720-based system, perform the following steps on the provider edge (PE) routers.
Note You must configure Ethernet over MPLS (VLAN mode) on the subinterfaces.
SUMMARY STEPS
1. enable
2. configure terminal
3. vtp mode transparent
4. interface gigabitethernetslot/interface.subinterface
5. encapsulation dot1q vlan-id
6. xconnect peer-router-id vcid encapsulation mpls
DETAILED STEPS
The following shows an example of a EoMPLS VLAN mode configuration:
Note The IP address is configured on subinterfaces of the CE devices.
CE1 Configuration
!
interface GigabitEthernet1/0
no ip address
no ip mroute-cache
negotiation auto
no cdp enable
no shut
!
interface GigabitEthernet1/0.2
encapsulation dot1Q 2
ip address 180.8.0.1 255.255.0.0
no cdp enable
no shut
!
interface GigabitEthernet1/0.3
encapsulation dot1Q 3
ip address 180.9.0.1 255.255.0.0
no cdp enable
no shut
!
CE2 Configuration
!
interface GigabitEthernet4/0
no ip address
no ip directed-broadcast
negotiation auto
tag-switching ip
no cdp enable
no shut
!
interface GigabitEthernet4/0.2
encapsulation dot1Q 2
ip address 180.8.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
interface GigabitEthernet4/0.3
encapsulation dot1Q 3
ip address 180.9.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
PE1 Configuration (OSM based)
!
vlan 2-3
!
interface GigabitEthernet1/4
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 2-3
switchport mode trunk
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 11.11.11.11 2 encapsulation mpls
no shut
!
interface Vlan3
no ip address
no ip mroute-cache
xconnect 11.11.11.11 3 encapsulation mpls
no shut
!
PE2 Configuration (supervisor engine 720)
!
vtp mode transparent
!
interface GigabitEthernet7/4
no ip address
no shut
!
interface GigabitEthernet7/4.1
encapsulation dot1Q 2
xconnect 13.13.13.13 2 encapsulation mpls
no shut
!
interface GigabitEthernet7/4.2
encapsulation dot1Q 3
xconnect 13.13.13.13 3 encapsulation mpls
no shut
!
Ethernet over MPLS VLAN Mode Configuration Guidelines
When configuring Ethernet over MPLS in VLAN mode, use the following guidelines:
•The AToM control word is supported. However, if the peer PE does not support a control word, the control word is disabled. This negotiation is done by LDP label binding.
•Ethernet packets with hardware level cyclic redundancy check (CRC) errors, framing errors, and runt packets are discarded on input.
Verifying the Configuration
To verify and display the configuration of Layer 2 VLAN transport over MPLS tunnels, perform the following steps:
Step 1 To display a brief summary of IP status and configuration for all interfaces, issue the show vlan brief command. If the interface can provide two-way communication, the Protocol field is marked "up." If the interface hardware is usable, the Status field is marked "up."
Router# show vlan brief
osr1#sh vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------
1 default active
2 VLAN0002 active
3 VLAN0003 active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Step 2 To make sure the PE router endpoints have discovered each other, issue the show mpls ldp discovery command. When an PE router receives an LDP Hello message from another PE router, it considers that router and the specified label space to be "discovered."
Router# show mpls ldp discovery
osr1#show mpls ldp discovery
Local LDP Identifier:
13.13.13.13:0
Discovery Sources:
Interfaces:
GE-WAN3/3 (ldp): xmit/recv
LDP Id: 12.12.12.12:0
Targeted Hellos:
13.13.13.13 -> 11.11.11.11 (ldp): active/passive, xmit/recv
LDP Id: 11.11.11.11:0
Step 3 To make sure the label distribution session has been established, issue the show mpls ldp neighbor command. The third line of the output shows that the state of the LDP session is operational and shows that messages are being sent and received.
Router# show mpls ldp neighbor
osr1#show mpls ldp neighbor
Peer LDP Ident: 12.12.12.12:0; Local LDP Ident 13.13.13.13:0
TCP connection: 12.12.12.12.646 - 13.13.13.13.11010
State: Oper; Msgs sent/rcvd: 1649/1640; Downstream
Up time: 23:42:45
LDP discovery sources:
GE-WAN3/3, Src IP addr: 34.0.0.2
Addresses bound to peer LDP Ident:
23.2.1.14 37.0.0.2 12.12.12.12 34.0.0.2
99.0.0.1
Peer LDP Ident: 11.11.11.11:0; Local LDP Ident 13.13.13.13:0
TCP connection: 11.11.11.11.646 - 13.13.13.13.11013
State: Oper; Msgs sent/rcvd: 1650/1653; Downstream
Up time: 23:42:29
LDP discovery sources:
Targeted Hello 13.13.13.13 -> 11.11.11.11, active, passive
Addresses bound to peer LDP Ident:
11.11.11.11 37.0.0.1 23.2.1.13
Step 4 To make sure the label forwarding table is built correctly, issue the show mpls forwarding-table command. The output shows the following data:
•Local tag—Label assigned by this router.
•Outgoing tag or VC—Label assigned by next hop.
•Prefix or Tunnel Id—Address or tunnel to which packets with this label are going.
•Bytes tag switched— Number of bytes switched out with this incoming label.
•Outgoing interface—Interface through which packets with this label are sent.
•Next Hop—IP address of neighbor that assigned the outgoing label.
Router# show mpls forwarding-table
osr1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 223.255.254.254/32 \
0 Gi2/1 23.2.0.1
20 Untagged l2ckt(2) 133093 Vl2 point2point
21 Untagged l2ckt(3) 185497 Vl3 point2point
24 Pop tag 37.0.0.0/8 0 GE3/3 34.0.0.2
25 17 11.11.11.11/32 0 GE3/3 34.0.0.2
26 Pop tag 12.12.12.12/32 0 GE3/3 34.0.0.2
osr1#
Step 5 To view the state of the currently routed VCs issue the show mpls l2transport vc command.
Router# show mpls l2transport vc
osr1#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------- --------------- ---------- ----------
Vl2 Eth VLAN 2 11.11.11.11 2 UP
Vl3 Eth VLAN 3 11.11.11.11 3 UP
Step 6 Add the keyword detail to see detailed information about each VC.
Router# show mpls l2transport vc detail
osr1#show mpls l2transport vc detail
Local interface: Vl2 up, line protocol up, Eth VLAN 2 up
Destination address: 11.11.11.11, VC ID: 2, VC status: up
Tunnel label: 17, next hop 34.0.0.2
Output interface: GE3/3, imposed label stack {17 18}
Create time: 01:24:44, last status change time: 00:10:55
Signaling protocol: LDP, peer 11.11.11.11:0 up
MPLS VC labels: local 20, remote 18
Group ID: local 71, remote 89
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 1009, send 1019
byte totals: receive 133093, send 138089
packet drops: receive 0, send 0
Local interface: Vl3 up, line protocol up, Eth VLAN 3 up
Destination address: 11.11.11.11, VC ID: 3, VC status: up
Tunnel label: 17, next hop 34.0.0.2
Output interface: GE3/3, imposed label stack {17 19}
Create time: 01:24:38, last status change time: 00:10:55
Signaling protocol: LDP, peer 11.11.11.11:0 up
MPLS VC labels: local 21, remote 19
Group ID: local 72, remote 90
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 1406, send 1414
byte totals: receive 185497, send 191917
packet drops: receive 0, send 0
Configuring EoMPLS Port Mode for OSM-Based System
To support 802.1Q-in-802.1Q traffic and native Ethernet traffic over EoMPLS in an OSM-based system, configure port-based EoMPLS by performing these tasks:
SUMMARY STEPS
1. enable
2. configure terminal
3. vlan
4. vlan dot1q tag native
5. interface gigabitEthernet
6. switchport
7. switchport mode dot1qtunnel
8. switchport access vlan
9. exit
10. interface vlan
11. xconnect peer-router-id vcid encapsulation mpls
DETAILED STEPS
This example shows a port mode access configuration for untagged packets. It requires configuring the IP addresses on the main interface of the CE devices.
CE1 Configuration
!
interface GigabitEthernet1/0
ip address 180.8.0.1 255.255.0.0
no ip mroute-cache
negotiation auto
no cdp enable
no shut
!
CE 2 Configuration
!
interface GigabitEthernet4/0
ip address 180.8.0.2 255.255.0.0
no ip directed-broadcast
negotiation auto
tag-switching ip
no cdp enable
no shut
!
PE1 Configuration
!
vlan 2
!
interface GigabitEthernet1/4
no ip address
switchport
switchport access vlan 2
switchport mode access
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 11.11.11.11 2 encapsulation mpls
no shut
!
PE2 Configuration
!
vlan 2
!
interface GigabitEthernet7/4
no ip address
switchport
switchport access vlan 2
switchport mode access
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 13.13.13.13 2 encapsulation mpls
no shut
!
This configuration shows a port mode dot1Q-tunneling configuration. You must configure subinterfaces on the CE devices for this configuration. There is a specific access VLAN for the packets.
CE1 Configuration
!
interface GigabitEthernet1/0
no ip address
no ip mroute-cache
negotiation auto
no cdp enable
no shut
!
interface GigabitEthernet1/0.2
encapsulation dot1Q 2
ip address 180.8.0.1 255.255.0.0
no cdp enable
no shut
!
interface GigabitEthernet1/0.3
encapsulation dot1Q 3
ip address 180.9.0.1 255.255.0.0
no cdp enable
no shut
!
CE2 Configuration
!
interface GigabitEthernet4/0
no ip address
no ip directed-broadcast
negotiation auto
tag-switching ip
no cdp enable
no shut
!
interface GigabitEthernet4/0.2
encapsulation dot1Q 2
ip address 180.8.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
interface GigabitEthernet4/0.3
encapsulation dot1Q 3
ip address 180.9.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
PE1 Configuration
Note This configuration requires vlan dot1q tag native.
!
vlan 2
!
vlan dot1q tag native
!
interface GigabitEthernet1/4
no ip address
switchport
switchport access vlan 2
switchport trunk encapsulation dot1q
switchport mode dot1q-tunnel
no cdp enable
spanning-tree bpdufilter enable
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 11.11.11.11 2 encapsulation mpls
no shut
!
PE2 Configuration
Note This configuration requires vlan dot1q tag native.
!
vlan 2
!
vlan dot1q tag native
!
interface GigabitEthernet7/4
no ip address
switchport
switchport access vlan 2
switchport trunk encapsulation dot1q
switchport mode dot1q-tunnel
no cdp enable
spanning-tree bpdufilter enable
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 13.13.13.13 2 encapsulation mpls
no shut
!
Configuring EoMPLS Port Mode for Supervisor Engine 720-Based System
To support 802.1Q-in-802.1Q traffic and native Ethernet traffic over EoMPLS in a supervisor engine 720-based system, configure port-based EoMPLS by performing these tasks:
SUMMARY STEPS
1. enable
2. configure terminal
3. interface gigabitethernetx/x
4. xconnect peer-router-id vcid encapsulation mpls
DETAILED STEPS
Note When the underlying port of the VLAN is an access port or .1q in .1q tunnel, then you must use an OSM or Enhanced FlexWAN module to access the MPLS core similarly to the OSM configuration in the example below.
The following example provides provides two configurations for the CE devices: one where the IP address is configured on the main interface and another where the IP address is configured on the subinterface.
CE1 Configuration (main interface)
!
interface GigabitEthernet1/0
ip address 180.8.0.1 255.255.0.0
no ip mroute-cache
negotiation auto
no cdp enable
no shut
!
CE1 Configuration (subinterface)
!
interface GigabitEthernet1/0
no ip address
no ip mroute-cache
negotiation auto
no cdp enable
no shut
!
interface GigabitEthernet1/0.2
encapsulation dot1Q 2
ip address 180.8.0.1 255.255.0.0
no cdp enable
no shut
!
interface GigabitEthernet1/0.3
encapsulation dot1Q 3
ip address 180.9.0.1 255.255.0.0
no cdp enable
no shut
!
!
CE2 Configuration (main interface)
!
interface GigabitEthernet4/0
ip address 180.8.0.2 255.255.0.0
no ip directed-broadcast
negotiation auto
tag-switching ip
no cdp enable
no shut
!
CE2 Configuration (subinterface)
!
interface GigabitEthernet4/0
no ip address
no ip directed-broadcast
negotiation auto
tag-switching ip
no cdp enable
no shut
!
interface GigabitEthernet4/0.2
encapsulation dot1Q 2
ip address 180.8.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
interface GigabitEthernet4/0.3
encapsulation dot1Q 3
ip address 180.9.0.2 255.255.0.0
no ip directed-broadcast
no cdp enable
no shut
!
PE1 Configuration (OSM based)
!
vlan 2
!
interface GigabitEthernet1/4
no ip address
switchport
switchport access vlan 2
switchport trunk encapsulation dot1q
switchport mode dot1q-tunnel
no cdp enable
spanning-tree bpdufilter enable
no shut
!
interface Vlan2
no ip address
no ip mroute-cache
xconnect 11.11.11.11 2 encapsulation mpls
no shut
!
PE2 Configuration (SUP720-3BXL)
!
interface GigabitEthernet7/4
no ip address
xconnect 13.13.13.13 2 encapsulation mpls
no shut
!
Ethernet over MPLS Port Mode Configuration Guidelines
When configuring Ethernet over MPLS in port mode, use the following guidelines:
•The AToM control word is supported. However, if the peer PE does not support a control word, the control word is disabled. This negotiation is done by LDP label binding.
•Ethernet packets with hardware level cyclic redundancy check (CRC) errors, framing errors, and runt packets are discarded on input.
•Port mode and Ethernet VLAN mode are mutually exclusive. If you enable a main interface for port-to-port transport, you cannot also enter commands on a subinterface.
Verifying the Configuration
To verify and display the configuration of Layer 2 VLAN transport over MPLS tunnels, perform the following steps:
Step 1 To display a brief summary of IP status and configuration for all interfaces, issue the show vlan brief command. If the interface can provide two-way communication, the Protocol field is marked "up." If the interface hardware is usable, the Status field is marked "up."
Router# show vlan brief
osr1#sh vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
2 VLAN0002 active Gi1/4
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Step 2 To make sure the PE router endpoints have discovered each other, issue the show mpls ldp discovery command. When an PE router receives an LDP Hello message from another PE router, it considers that router and the specified label space to be "discovered."
Router# show mpls ldp discovery
osr1#show mpls ldp discovery
Local LDP Identifier:
13.13.13.13:0
Discovery Sources:
Interfaces:
GE-WAN3/3 (ldp): xmit/recv
LDP Id: 12.12.12.12:0
Targeted Hellos:
13.13.13.13 -> 11.11.11.11 (ldp): active/passive, xmit/recv
LDP Id: 11.11.11.11:0
Step 3 To make sure the label distribution session has been established, issue the show mpls ldp neighbor command. The third line of the output shows that the state of the LDP session is operational and shows that messages are being sent and received.
Router# show mpls ldp neighbor
osr1#show mpls ldp neighbor
Peer LDP Ident: 12.12.12.12:0; Local LDP Ident 13.13.13.13:0
TCP connection: 12.12.12.12.646 - 13.13.13.13.11010
State: Oper; Msgs sent/rcvd: 1715/1706; Downstream
Up time: 1d00h
LDP discovery sources:
GE-WAN3/3, Src IP addr: 34.0.0.2
Addresses bound to peer LDP Ident:
23.2.1.14 37.0.0.2 12.12.12.12 34.0.0.2
99.0.0.1
Peer LDP Ident: 11.11.11.11:0; Local LDP Ident 13.13.13.13:0
TCP connection: 11.11.11.11.646 - 13.13.13.13.11013
State: Oper; Msgs sent/rcvd: 1724/1730; Downstream
Up time: 1d00h
LDP discovery sources:
Targeted Hello 13.13.13.13 -> 11.11.11.11, active, passive
Addresses bound to peer LDP Ident:
11.11.11.11 37.0.0.1 23.2.1.13
Step 4 To make sure the label forwarding table is built correctly, issue the show mpls forwarding-table command. The output shows the following data:
•Local tag—Label assigned by this router.
•Outgoing tag or VC—Label assigned by next hop.
•Prefix or Tunnel Id—Address or tunnel to which packets with this label are going.
•Bytes tag switched— Number of bytes switched out with this incoming label.
•Outgoing interface—Interface through which packets with this label are sent.
•Next Hop—IP address of neighbor that assigned the outgoing label.
Router# show mpls forwarding-table
osr1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 223.255.254.254/32 \
0 Gi2/1 23.2.0.1
20 Untagged l2ckt(2) 55146580 Vl2 point2point
24 Pop tag 37.0.0.0/8 0 GE3/3 34.0.0.2
25 17 11.11.11.11/32 0 GE3/3 34.0.0.2
26 Pop tag 12.12.12.12/32 0 GE3/3 34.0.0.2
Step 5 To view the state of the currently routed VCs issue the show mpls l2transport vc command.
Router# show mpls l2transport vc
osr1#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------- --------------- ---------- ----------
Vl2 Eth VLAN 2 11.11.11.11 2 UP
osr3#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------- --------------- ---------- ----------
Gi7/4 Ethernet 13.13.13.13 2 UP
Step 6 Add the keyword detail to see detailed information about each VC.
Router# show mpls l2transport vc detail
osr1#show mpls l2transport vc detail
Local interface: Vl2 up, line protocol up, Eth VLAN 2 up
Destination address: 11.11.11.11, VC ID: 2, VC status: up
Tunnel label: 17, next hop 34.0.0.2
Output interface: GE3/3, imposed label stack {17 18}
Create time: 00:15:13, last status change time: 00:11:46
Signaling protocol: LDP, peer 11.11.11.11:0 up
MPLS VC labels: local 20, remote 18
Group ID: local 71, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 407857, send 407684
byte totals: receive 53827205, send 55444697
packet drops: receive 0, send 0
How to Configure QoS with AToM
The following QoS features are supported on AToM:
•Marking on CE facing card—(imposition packets) with match criteria, match-dlci, match-any, or class-default.
Note For Marking on CE facing card, match-dcli applies to the Enhanced FlexWAN module only.
•Shaping on the core-facing card, with match exp, and match-any.
•Shaping on the CE-facing card - (disposition packets) with match-any.
•WRED on the core-facing card with match criteria, match-exp, or match-any
This section explains how to configure QoS with AToM and includes the following procedures:
•How to Set Experimental Bits with AToM
•Setting the Priority of Packets with EXP Bits
How to Set Experimental Bits with AToM
MPLS AToM uses the three experimental bits in a label to determine the queue of packets. You statically set the experimental bits in both the VC label and the LSP tunnel label, because the LSP tunnel label might be removed at the penultimate router. The following sections explain the transport-specific implementations of the EXP bits.
Ethernet over MPLS and EXP Bits
Note The information in this section is for OSM-based EoMPLS only. For information on PFC3BXL QoS, see http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/qos.html.
OSM-based EoMPLS supports the following QoS implementations:
•VLAN interface policies
•Core-facing interface policy
You apply a VLAN interface policy to an individual VLAN. You may configure a unique policy for each individual VLAN. Within a policy, you can classify on 802.1q P bits to set the MPLS experimental bits. You can also implement a single traffic shaper that applies to all traffic within the VLAN.
Note Within a VLAN interface policy, only the shape average and set mpls experimental commands are supported. Within the shape average command, only the cir argument is valid for EoMPLS.
You apply a core-facing interface policy to the EoMPLS uplink interface. This policy applies to traffic from all VLANs. It does not distinguish between different VLANs. Within a policy, you can classify on MPLS experimental bits and configure the following features:
•Class-based traffic shaping
•Class-based weighted fair queuing (CBWFQ)
•Low latency queuing (LLQ)
•Weighted random early detection (WRED)
Note You cannot use both VLAN interface policies and core-facing interface policies at the same time. If you configure QoS for OSM-based EoMPLS, you must select either VLAN interface policies or a core-facing interface policy.
For more information on VLAN interface policies, see "Setting the Priority of Packets with the Experimental Bits" section and "Enabling Traffic Shaping" section.
For more information on core-facing policies, see "Configuring MPLS QoS" section.
For more information on the commands used to enable Quality of Service, see the following documents:
•Modular Quality of Service Command-Line Interface
•Cisco IOS Quality of Service Solutions Command Reference, Release 12.2
Setting the Priority of Packets with the Experimental Bits
Ethernet over MPLS provides Quality of Service (QoS) using the three experimental bits in a label to determine the priority of packets. To support QoS between LERs, set the experimental bits in both the VC and tunnel labels. If you do not assign values to the experimental bits, the priority bits in the 802.1q header's "tag control information" field and are written into the experimental bit fields.
Perform the following steps to set the experimental bits:
Note You can enable traffic shaping and set experimental bits in the same policy-map.
Note You can configure the service-policy for either the input or the output direction. However, the policy is always implemented on the core-facing OSM port and is applied only to the traffic leaving the core-facing OSM port.
Enabling Traffic Shaping
Traffic shaping limits the rate of transmission of data. Average rate shaping limits the transmission rate to the committed information rate (CIR). To add traffic shaping, issue the following commands:
|
|
|
|
|---|---|---|
Step 1 |
Router(config)# class-map
class-name
|
Specifies the user-defined name of the traffic class. |
Step 2 |
Router(config-cmap)# match any |
Specifies that all packets will be matched. (Using the class-default in the policy-map would have the same effect.) |
Step 3 |
Router(config-cmap)#
policy-map policy-name
|
Specifies the name of the traffic policy to configure. |
Step 4 |
Router(config-pmap)# class
class-name
|
Specifies the name of a predefined traffic class, which was configured with the class-map command, used to classify traffic to the traffic policy. |
Step 5 |
Router (config-pmap-c)# shape average cir 1 2 |
Shapes traffic according to the bit rate you specify. |
Step 6 |
Router(config)# interface
vlanvlan-number
|
Enters the VLAN interface. |
Step 7 |
Router(config-if)# service-policy [input | output] policy-name |
Assigns a traffic policy to an interface. |
1 Only supported parameters are shown. 2 See Table 10-1. |
The shape average rate is rounded to the nearest multiple of the link rate divided by 255. If the shape value is lower than the link rate divided by 255, it is rounded up to link rate divided by 255.
This example shows how the shape value is rounded:
Router# show pol p2
Policy Map p2
class any-pkt
shape average 2000000 8000 8000
Router# show pol int
Vlan101
service-policy input:p2
class-map:any-pkt (match-all)
2018169 packets, 4575195376 bytes
30 second offered rate 295768000 bps, drop rate 0 bps
match:any
queue size 0, queue limit 0
packets input 40492, packet drops 1977677
tail/random drops 0, no buffer drops 0, other drops 1977677
shape:cir 2000000, Bc 8000, Be 8000
(shape parameter is rounded to 2439000 due to granularity)
input bytes 40847436, shape rate 1874000 bps
class-map:class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:any
0 packets, 0 bytes
30 second rate 0 bps
To display the traffic policy attached to an interface, issue the following command:
Router# show policy-map vlan50
service-policy input: badger
class-map: blue (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match: any
queue size 0, queue limit 2
packets input 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
shape: cir 2000000, Bc 8000, Be 8000
output bytes 0, shape rate 0 bps
class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match: any
0 packets, 0 bytes
30 second rate 0 bps
Setting the Priority of Packets with EXP Bits
Set the experimental bits in both the VC label and the LSP tunnel label. You set the experimental bits in the VC label, because the LSP tunnel label might be removed at the penultimate router.
Perform the following steps to set the experimental bits.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map class-name
4. match any
5. policy-map policy-name
6. class class-name
7. set mpls experimental value
8. interfaceslot/port
9. service-policy input policy-name
DETAILED STEPS
Enabling Traffic Shaping
Traffic shaping limits the rate of transmission of data. Average rate shaping limits the transmission rate to the committed information rate (CIR). To add traffic shaping, issue the following commands:
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map class-name
4. match any
5. policy-map policy-name
6. class class-name
7. shape average bit rate
8. interfaceslot/port
9. service-policy input policy-name
DETAILED STEPS
Note You can enable traffic shaping and set experimental bits in the same policy-map.
Note EoMPLS VLAN Policing Exclusion—traffic on the EoMPLS uplink port is excluded from a VLAN-based ingress policer.
To display the traffic policy attached to an interface, use the show policy-map interface command.
EoMPLS QoS Example
If the egress MPLS tunnel is carried on an OSM WAN interface configured for fair queuing, the shape value is rounded to the nearest multiple of the link rate divided by 255. If the shape value is lower than the link rate divided by 255, it is rounded up to link rate divided by 255.
This example shows how the shape value is rounded:
Router# show pol p2
Policy Map p2
class any-pkt
shape average 2000000 8000 8000
Router# show pol int
Vlan101
service-policy input:p2
class-map:any-pkt (match-all)
2018169 packets, 4575195376 bytes
30 second offered rate 295768000 bps, drop rate 0 bps
match:any
queue size 0, queue limit 0
packets input 40492, packet drops 1977677
tail/random drops 0, no buffer drops 0, other drops 1977677
shape:cir 2000000, Bc 8000, Be 8000
(shape parameter is rounded to 2439000 due to granularity)
input bytes 40847436, shape rate 1874000 bps
class-map:class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:any
0 packets, 0 bytes
30 second rate 0 bps
EoMPLS QoS Example—Displaying the Traffic Policy Assigned to an Interface
To display the traffic policy attached to an interface, issue the following command:
Router# show policy-map vlan50
service-policy input: badger
class-map: blue (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match: any
queue size 0, queue limit 2
packets input 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
shape: cir 2000000, Bc 8000, Be 8000
output bytes 0, shape rate 0 bps
class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match: any
0 packets, 0 bytes
30 second rate 0 bps
EoMPLS QoS Example— Configuring QoS on VLAN
The following example show how to configure QoS on the VLAN.
class-map blue
match cos 1 2 3
!
policy-map badger
class blue
set mpls experimental 1
class class-default
shape average 2000000 8000 8000
!
interface vlan50
no ip address
no ip mroute-cache
load-interval 30
mpls l2transport route 192.168.255.255 50
service-policy input badger
no cdp enable
HQoS for EoMPLS Virtual Circuits
The Hierarchical Quality of Service (HQoS) for Ethernet over MPLS (EoMPLS) Virtual Circuits (VCs) feature enables hierarchical QoS services on WAN-based interfaces, allowing service providers to classify the traffic in customer EoMPLS networks before it is forwarded into the core network. This gives users of Cisco 7600 series routers greater flexibility in providing QoS services to specific customers in their EoMPLS networks.
The HQoS for EoMPLS VCs feature allows you to classify EoMPLS networks in the following ways:
•Match on the VLAN ID that the packet contained when it was originally received at the input interface. You can match a single VLAN ID, a range of VLAN IDs, or a combination of the two, allowing you to match all or part of an EoMPLS network.
•Match on a QoS group value that is set to the same value of the IP precedence or CoS bits that are received with the packet at the input interface.
The use of hierarchical policy maps can simplify the configuration of the router, because the same child policy map can be used in multiple parent maps. You can also match multiple VLANs with one class map, as opposed to having separate class maps for each VLAN.
The HQoS for EoMPLS VCs feature does not require any upgrades to the customer-facing interfaces, because the HQoS policy map is applied to the WAN interface, allowing the customer-facing interfaces to be standard Ethernet interfaces.
Prerequisites for the HQoS for EoMPLS VCs Feature
•You must enable QoS on the router before using HQoS. To enable QoS globally on the router, use the mls qos command in global configuration mode. To enable QoS on an individual interface, use the mls qos interface configuration command. In addition, the mls trust command must be configured on the CE facing PE interfaces.
Restrictions for the HQoS for EoMPLS VCs Feature
The following section lists restrictions for the HQoS for EoMPLS VCs feature. Other restrictions may also apply to QoS services in general, depending on the supervisor module and line cards being used.
Note The HQoS for EoMPLS VCs feature is supported only on PXF- based QoS configured on switched virtual interfaces (SVIs).
•If a policy contains a class map with a match input vlan command, you cannot attach that policy map to an interface if you have already attached a service policy to a VLAN interface (a logical interface that has been created with the interface vlan command).
Note This restriction means that match input vlan configurations and interface vlan configurations are mutually exclusive.
•The HQoS for EoMPLS VCs feature is supported only for output (egress) interfaces (policy maps must be attached to the interface using the service-policy output command).
•The HQoS for EoMPLS VCs feature supports only point-to-point VCs, not point-to-multipoint VCs.
•If the parent class contains a class map with a match input vlan command, you cannot use a match exp command in a child policy map.
•You cannot attach a child policy map to the parent class default.
•Child and parent policy maps do not support any marking, such as the match ip dscp and set commands.
•The HQoS for EoMPLS VCs feature does not support multiple levels of parent and child policy map nesting. Each parent policy map supports only one level of nesting. In other words, a traffic class in a parent policy map can have a maximum of one child policy map, and child policy maps cannot have their own child policy maps.
Note You can mix flat traffic classes (that do not refer to child policy maps) and hierarchical traffic classes (that do refer to child policy maps) in the same HQoS parent policy maps.
•You cannot apply both HQoS output policy on a main interface (using the service-policy output command) and an output policy (service-policy output command) on a subinterface of that same interface. If you attempt to do so, then attaching the HQoS output policy fails with the following error message:
Attaching service policy to main and sub-interface concurrently is not allowed
•Policy maps can contain a maximum of 255 class maps.
•Child policy maps support only strict priority (the priority command without any options). Parent policy maps do not support any form of the priority command.
•When using both the priority and police commands in more than one class in a child priority map, you must configure the commands in the following order:
–In the first class to be configured on the priority map, specify the priority command first, and then the police command.
–In the second and any additional classes to be configured on the priority map, specify the police command first, and then the priority command.
–The police cir command is supported only on OSM interfaces.
Note The priority command can be configured only with the police command. You cannot use priority together with any forms of the bandwidth or shape commands.
•Class maps that use the match input vlan command support only the match-any option. You cannot use the match-all option in class maps that use the match input vlan command.
•Classes using the the match input vlan command should always be placed first in the policy maps, before any classes that use flat policies.
•Parent policy maps do not support the fair-queue command. Also, the fair-queue command is not supported for OSM interfaces.
•You must use class-default for the input service policy on a CE-PE interface that uses the qos-group command to set CoS or IP-Precedence.
•Service policies cannot be attached to subinterfaces for OSM interfaces.
•OSM interfaces support only the shape average command. Other forms of the shape command are not supported on OSM interfaces.
•The bandwidth remaining precent command is not supported on any OSM interfaces. However, the following OSMs support the bandwidth command in a parent class under a hierarchical policy map:
–OSM-2+4GE-WAN-GBIC+
Note For the bandwidth command, the minimum rate and the granularity are 1/255 of the bandwidth.
Note For additional prerequisites and restrictions for HQoS in general, see the section "Configuring Hierarchical Traffic Shaping" at "Configuring Hierarchical Traffic Shaping" section.
Supported Features
The HQoS for EoMPLS VCs feature supports the following commands on the class maps and policy maps for output interfaces.
The following are supported on parent policy maps:
•bandwidth—Egress class-based weighted fair queuing (CBWFQ) supported on parent policy maps on OSM-2+4GE-WAN-GBIC+ interfaces.
•shape average—Egress shaping
The following are supported on child policy maps:
•bandwidth—Egress class-based weighted fair queuing (CBWFQ)
•priority—Egress low latency queuing (LLQ) (Only strict priority is supported on child maps and on OSMs.)
Note Strict priority is supported for OSM-2+4GE-WAN-GBIC+ interfaces only.
•queue-limit—Queue throttling
•random-detect—Egress weighted random early detection (WRED)
•shape average—Egress shaping
Related Commands
Do not confuse the match input vlan command with the match vlan command, which is also a class-map configuration command.
•The match vlan command matches the VLAN ID on packets for the particular interface at which the policy map is applied. Policy maps using the match vlan command can be applied to either ingress or egress interfaces on the router, using the service-policy {input | output} command.
•The match input vlan command matches the VLAN ID that was on packets when they were received on the ingress interface on the router. Policy maps using the match input vlan command must be applied to egress interfaces on the router, using the service-policy output command.
The match input vlan command can also be confused with the match input-interface vlan command, which matches packets being received on a logical VLAN interface that is used for inter-VLAN routing.
Tip Because class maps also support the match input-interface command, you cannot abbreviate the input keyword when giving the match input vlan command.
Configuring the HQoS for EoMPLS VCs Feature
To use a hierarchical QoS policy map for EoMPLS traffic, you must perform the following tasks. (All tasks are required.)
•Apply a policy map to the input interface to set the QoS group value on incoming packets. See the "Creating and Assigning a Policy Map to Mark the QoS Group at the Incoming Interface" section.
•Create class maps that match packets on the basis of their QoS group values. See the "Configuring the Class Map to Match on a QoS Group" section.
•Create a child policy map that uses these class maps. See the "Creating the Child Policy Map for the Egress Interface" section.
•Create class maps that match packets on the basis of their input VLAN IDs. See the "Configuring the Class Maps for Matching on an Input VLAN" section.
•Create a parent policy map and apply it to the output interface. See the "Creating the Parent Policy Map and Attaching It to the Egress Interface" section.
Note For more information about hierarchical traffic shaping, see the section "Configuring Hierarchical Traffic Shaping" at "Configuring Hierarchical Traffic Shaping" section.
Creating and Assigning a Policy Map to Mark the QoS Group at the Incoming Interface
To be able to classify traffic on a QoS group, you must first create a policy map that marks incoming packets with the desired QoS group value. You can set the QoS group value to the value of either the IP precedence bits or 802.1P CoS bits of the incoming packets. You then must assign that policy map to the incoming interface (which must be a Layer 2 LAN interface). To perform these tasks, use the following procedure.
SUMMARY STEPS
1. enable
2. configure terminal
3. policy-map policy-map-name
4. description string
5. class class-default
6. set qos-group {cos | ip-precedence}
7. interface if-type {slot/port | slot/subslot/port}
8. service-policy input policy-map-name
9. end
10. show policy-map
show policy-map policy-map-name [class class-map]
DETAILED STEPS
|
|
|
|
|---|---|---|
Step 1 |
enable Router> enable |
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 |
configure terminal Router# configure terminal |
Enters global configuration mode. |
Step 3 |
policy-map policy-map-name Router(config)# policy-map cos-to-qosgrp-pmap |
Creates a policy map with the specified name and enters policy-map configuration mode. • |
Step 4 |
description string Router(config-pmap)# description Sets QoS group to 802.1P CoS of incoming packets |
(Optional) Arbitrary string, up to 200 characters long, that describes this policy map. |
Step 5 |
class class-default Router(config-pmap)# class class-default |
Specifies the default class to be used for traffic with this policy, and enters policy-map class configuration mode. |
Step 6 |
set qos-group {cos | ip-precedence} Router(config-pmap-c)# set qos-group cos
|
Sets a quality of service (QoS) group identifier (ID) that can be used later to classify packets. • • Note |
Step 7 |
interface if-type {slot/port | slot/subslot/port} Router(config-pmap-c)# interface GigabitEthernet 5/2 |
Enters interface configuration mode for the incoming interface. Note |
Step 8 |
service-policy input policy-map-name Router(config-if)# service-policy input cos-to-qosgrp-pmap |
Attaches the specified policy map to the interface for input (ingress) traffic. • |
Note |
||
Step 9 |
show policy-map show policy-map policy-map-name [class class-map] Router# show policy-map cos-to-qosgrp-pmap |
(Optional) Displays the configured class map to verify the configuration. To display all policy maps, enter the command without any options. To display a specific policy map, specify its name on the command line. You can also display a specific class that is part of a specific policy map by adding the class option. |
The following policy map sets the QoS group value to match the CoS value of the incoming packets. The policy map is then assigned to two interfaces:
policy-map cos-to-qosgroup-pmap
class class-default
set qos-group cos
...
!
interface GE 6/0
service-policy input cos-to-qosgroup-pmap
...
!
interface GE 6/1
service-policy input cos-to-qosgroup-pmap
...
What to Do Next
After attaching the policy map to the input interface, create the class map to match on the QoS group value at the egress (outgoing) interface. See the "Configuring the Class Map to Match on a QoS Group" section for details.
Configuring the Class Map to Match on a QoS Group
To be able to match EoMPLS traffic using QoS groups, you must create class maps to match traffic on the basis of the QoS group value at the egress (outgoing) interface. To create these class maps, use the following procedure.
Prerequisites
•You must create policy maps that contain class maps that use the set qos-group command to mark incoming packets with the desired QoS group values. Then attach those policy maps to the input interfaces that are receiving the incoming traffic. See the "Creating and Assigning a Policy Map to Mark the QoS Group at the Incoming Interface" section.
•Input interfaces must also be configured with mls trust.
Restrictions
•A policy map that refers to a class map that uses the match qos-group command cannot have other class maps that match on the following commands:
–match ip prec match
–match mpls exp
•The allowable range of values for QoS groups is from 0 to 99. The only valid values for EoMPLS traffic are from 0 to 7. This is because the QoS group value is set to the IP precedence or CoS fields in the incoming packets, and both of these fields are only 3-bit values that can range from 0 to 7.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map [match-all | match-any] class-map-name
4. match qos-group qos-group-value
5. end
6. show class-map class-map-name
DETAILED STEPS
The following example configuration shows all of the class maps that are allowed for matching on QoS groups for EoMPLS traffic.
class-map match-all group0
match qos-group 0
class-map match-all group1
match qos-group 1
class-map match-all group2
match qos-group 2
class-map match-all group3
match qos-group 3
class-map match-all group4
match qos-group 4
class-map match-all group5
match qos-group 5
class-map match-all group6
match qos-group 6
class-map match-all group7
match qos-group 7
What to Do Next
After creating all of the desired class maps, you must include them in a child policy map. See the next section, "Creating the Child Policy Map for the Egress Interface," for more information.
Creating the Child Policy Map for the Egress Interface
A hierarchical policy map is identical to the flat policy maps that were supported in earlier Cisco IOS software releases, except that at least one of the traffic class maps in the parent policy map refers to a child policy map. You must create the child policy maps before creating the parent policy maps.
To create a child policy map, use the following procedure. Repeat as needed to create the desired number of child policy maps.
Tip Different parent policy maps can use the same child policy maps, if desired.
Prerequisites
•You must first create the class maps to be used by this policy map. See the "Configuring the Class Map to Match on a QoS Group" section.
Restrictions
Child policy maps for EoMPLS traffic have the following restrictions:
•The set command is not supported on the child policy map.
•Child policy maps support only strict priority (the priority command without any options). Parent policy maps do not support any form of the priority command.
•When using both the priority and police commands in more than one class in a priority map, you must configure the commands in the following order:
–In the first class to be configured on the priority map, specify the priority command first, and then the police command.
–In the second and any additional classes to be configured on the priority map, specify the police command first, and then the priority command.
•You cannot use the service-policy child-pmap-name command in child policy maps, because multi-level nesting is not supported for HQoS for EoMPLS VCs policy maps.
SUMMARY STEPS
1. enable
2. configure terminal
3. policy-map child-pmap-name
4. description string
5. class {class-map-name | class-default}
Note Each class action below must be preceded by a class command.
6. shape {average} mean-rate
7. class {class-map-name | class-default}
8. priority
9. police bps [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action]
10. class {class-map-name | class-default}
11. bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}
12. end
13. show policy-map child-pmap-name
DETAILED STEPS
|
|
|
|
|---|---|---|
Step 1 |
enable Router> enable |
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 |
configure terminal Router# configure terminal |
Enters global configuration mode. |
Step 3 |
policy-map child-pmap-name Router(config)# policy-map child-pmap-name |
Creates a policy map with the specified name, for use as a child policy map, and enters policy-map configuration mode. • |
Step 4 |
description string Router(config-pmap)# description Child policy map for input VLAN parent class |
(Optional) Arbitrary string, up to 200 characters long, that describes this policy map. |
Step 5 |
class {class-map-name | class-default} Router(config-pmap)# class qosgroup4 Router(config-pmap-c)# or Router(config-pmap)# class class-default |
Specifies the name of a class map that should be used with this policy, and enters policy-map class configuration mode. • • |
Step 6 |
shape {average} mean-rate Router(config-pmap-c)# shape average 10000000 |
(Optional) Shapes the traffic in this class by the limits specified. • • |
Step 7 |
class {class-map-name | class-default} Router(config-pmap)# class qosgroup5 or Router(config-pmap)# class class-default |
Specifies the name of a class map that should be used with this policy, and enters policy-map class configuration mode. • • |
Step 8 |
priority Router(config-pmap-c)# priority |
(Optional) Specifies that traffic in this class is priority traffic. Note |
Note |
||
Step 9 |
police bps [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action] Router(config-pmap-c)# police 8000 1000 conform-action transmit exceed-action drop
|
(Optional) Specifies the policing policy that should be used for traffic in this class. • • • • • • • |
Step 10 |
class {class-map-name | class-default} Router(config-pmap)# class qosgroup6 or Router(config-pmap)# class class-default |
Specifies the name of a class map that should be used with this policy, and enters policy-map class configuration mode. • • |
Step 11 |
bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage} Router(config-pmap-c)# bandwidth percent 50 |
(Optional) Specifies the bandwidth that is allowed for traffic in this class. • • • |
Note |
||
Step 12 |
end Router(config-pmap-c)# end |
Exits policy-map class configuration mode and returns to privileged EXEC mode. |
Step 13 |
show policy-map show policy-map child-pmap-name [class class-map] Router# show policy-map child-policy1 (command output) |
(Optional) Displays the configured policy map to verify the configuration. To display all policy maps, enter the command without any options. To display a specific policy map, specify its name on the command line. You can also display a specific class that is part of a specific policy map by adding the class option. |
The following sample configuration shows a typical child policy map that refers to two of the QoS group class maps that were defined in the "Configuring the Class Map to Match on a QoS Group" section.
policy-map child
! Class for QoS Group 3 performs LLQ
class group3
priority
police 20000000 625000 625000 conform-action transmit exceed-action drop
! Class for QoS Group 4 performs CBWFQ when bandwidth usage is at 30 percent
class group4
bandwidth percent 30
Note When using both the priority and police commands in a class, you must configure them in the following order: In the first class to be configured on the priority map, specify the priority command first, and then the police command. In the second and any additional classes to be configured on the priority map, specify the police command first, and then the priority command.
What to Do Next
After creating the child policy map, you must create the parent policy map. See the "Creating the Parent Policy Map and Attaching It to the Egress Interface" section for details.
Configuring the Class Maps for Matching on an Input VLAN
To match EoMPLS packets that are tagged with one or more specific VLAN IDs, you must create a class map that matches on those VLAN IDs. To do this, use the following procedure.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map match-any class-map-name
4. match input vlan input-vlan-list
5. end
6. show class-map class-map-name
DETAILED STEPS
|
|
|
|
|---|---|---|
Step 1 |
enable Router> enable |
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 |
configure terminal Router# configure terminal |
Enters global configuration mode. |
Step 3 |
class-map match-any class-map-name Router(config)# class-map vlan-map |
Creates a class map and enters class-map configuration mode. • Note |
Step 4 |
match input vlan input-vlan-list Router(config-cmap)# match input vlan 10 20 30 100-1999 |
Matches packets that are tagged with a VLAN ID specified in the input-vlan-list, which can be one or both of the following: • • Note |
Step 5 |
end Router(config-cmap)# end |
Exits class-map configuration mode and returns to privileged EXEC mode. |
Step 6 |
show class-map class-map-name Router# show class-map vlan-map |
(Optional) Displays the configured class map to verify the configuration. |
The following configuration example shows a number of class maps that match either one specific VLAN ID, or a range of VLAN IDs. The last class map matches all valid VLAN IDs.
class-map match-any vlan1
match input vlan 1
class-map match-any vlan2
match input vlan 2
class-map match-any vlan3
match input vlan 3
class-map match-any vlan4
match input vlan 4
class-map match-any vlans1-4
match input vlan 1-4
class-map match-any vlans-all
match input vlan 1-4094
The following sample configuration shows multiple match input vlan commands being used in the traffic class map.
class-map match-any vlans-even
match input vlan 2 4 6 8
match input vlan 102 104 106 108
match input vlan 202 204 206 208
What to Do Next
After creating all desired class maps, you must then create the parent policy map and assign it to the egress interface. See the next section, ""Creating the Parent Policy Map and Attaching It to the Egress Interface" section," for details.
Creating the Parent Policy Map and Attaching It to the Egress Interface
After creating the class maps and child policy maps, you must create a parent policy map and attach it to the appropriate egress (output) interface. To create and attach a parent policy map, use the following procedure. Repeat as needed to create the desired number of parent policy maps.
Prerequisites
Create at least one child policy map to be used in this parent policy map. See the "Creating the Child Policy Map for the Egress Interface" section for details. (Different parent policies can use the same child policy maps, if desired.)
Restrictions
Parent policy maps have the following restrictions:
•You cannot attach a policy with the match input vlan command to an interface if you have already attached a service policy to its VLAN interface (a logical interface that has been created with the interface vlan command). If you attempt to do so, you must then remove both types of policy maps from all interfaces, and then reattach only one type of policy map to the interfaces.
•The priority and fair-queue commands are not supported in parent policy maps.
•Only the shape command and the bandwidth command are supported in parent classes; other actions are not supported.
•The bandwidth command is supported on parent policy maps only on OC-3 and OC-12 POS OSM interfaces, and on OSM-2+4GE-WAN-GBIC+ interfaces.
SUMMARY STEPS
1. enable
2. configure terminal
3. policy-map parent-pmap-name
4. description string
5. class {class-map-name}
6. shape {average | peak} mean-rate [Bc [Be]]
7. bandwidth {bandwidth-kbps | percent percentage}
8. service-policy child-pmap-name
9. interface if-type {slot/port | slot/subslot/port}
10. service-policy output parent-pmap-name
11. end
12. show policy-map parent-pmap-name
DETAILED STEPS
|
|
|
|
|---|---|---|
Step 1 |
enable Router> enable |
Enables privileged EXEC mode. Enter your password if prompted. |
Step 2 |
configure terminal Router# configure terminal |
Enters global configuration mode. |
Step 3 |
policy-map parent-pmap-name Router(config)# policy-map parent-policy1 |
Creates a policy map with the specified name, for use as a parent policy map, and enters policy-map configuration mode. • |
Step 4 |
description string Router(config-pmap)# description Parent Policy Map |
(Optional) Arbitrary string, up to 200 characters long, that describes this policy map. |
Step 5 |
class {class-map-name} Router(config-pmap)# class vlan100 or Router(config-pmap)# class class-default |
Specifies the name of a class-map that should be used with this policy, and enters policy-map class configuration mode. • |
Step 6 |
shape {average} mean-rate] Router(config-pmap-c)# shape average 10000000 |
(Optional) Shapes the traffic in this class by the limits specified. • • |
Step 7 |
bandwidth {bandwidth-kbps | percent percentage} Router(config-pmap-c)# bandwidth percent 50 |
(Optional) Specifies the bandwidth that is allowed for traffic in this class. • • |
Step 8 |
service-policy child-pmap-name Router(config-pmap-c)# service-policy child-pmap-name |
Specifies a child policy map that should be applied to the traffic in this class: • |
Note |
||
Step 9 |
interface if-type {slot/port | slot/subslot/port}] Router(config)# interface ge-wan 5/2 |
Enters interface configuration mode for the specified interface. |
Step 10 |
service-policy output parent-pmap-name Router(config-pmap)# service-policy output parent-policy1 |
Attaches the specified parent policy map to the interface for outgoing traffic. • |
Step 11 |
end Router(config-pmap-c)# end |
Exits policy-map class configuration mode and returns to privileged EXEC mode. |
Step 12 |
show policy-map show policy-map parent-pmap-name [class class-map] Router# show policy-map vlan-map |
(Optional) Displays the configured policy map to verify the configuration. To display all policy maps, enter the command without any options. To display a specific policy map, specify its name on the command line. You can also display a specific class that is part of a specific policy map by adding the class option. |
The following sample configuration shows a parent policy map that shapes all of the traffic for three VLANs to specific maximum values. Each class in the parent policy map also specifies a child policy map that further shapes the VLAN traffic on the basis of each packet's QoS group value.
!
! Class maps to match on QoS groups (to be used in child policy map)
class-map match-all qosgroup0
match qos-group 0
class-map match-all qosgroup1
match qos-group 1
class-map match-all qosgroup2
match qos-group 2
class-map match-all qosgroup3
match qos-group 3
class-map match-all qosgroup4
match qos-group 4
class-map match-all qosgroup5
match qos-group 5
class-map match-all qosgroup6
match qos-group 6
class-map match-all qosgroup7
match qos-group 7
!
! Class maps to match on input vlan IDs (to be used in parent policy map)
class-map match-all vlan101
match input vlan 101
class-map match-all vlan102
match input vlan 102
class-map match-all vlan103
match input vlan 103
!
policy-map child-pmap
description Child policy map to shape on the basis of the QoS group values
class qosgroup1
shape average 10000000
class qosgroup2
shape average 20000000
class qosgroup5
shape average 40000000
class class-default
shape average 10000000
!
policy-map parent-pmap
description Parent pmap that shapes traffic for individual VLANs
class vlan101
shape average 70000000
service-policy child-pmap
class vlan102
shape average 80000000
service-policy child-pmap
class vlan103
shape average 90000000
service-policy child-pmap
class class-default
shape average 10000000
Configuration Examples for the HQoS for EoMPLS VCs Feature
This section contains the following sample configurations for the HQoS for EoMPLS VCs feature:
•Simple Hierarchical Configuration Example
•Complete Hierarchical QoS Example
•Multiple Parent Policies Using the Same Child Policy Example
•Common Class-Map Templates Example
Simple Hierarchical Configuration Example
The following example shows a simple hierarchical QoS configuration with one parent policy and one child policy. This configuration performs the following:
•The parent policy shapes all outgoing traffic for VLAN 101 on the GE7/1 interface to a total maximum of 90 Mbps.
•The child policy performs LLQ on the VLAN 101 traffic that has the QoS group set to 1, giving it 10 percent of the bandwidth.
•The child policy allocates 10 percent of the bandwidth of the VLAN 101 traffic that has the QoS group set to 2.
•The child policy performs WRED on the remaining VLAN 101 traffic.
class-map match-any vlan101
match input vlan 101
class-map match-all qos1
match qos-group1
class-map match-all qos-group2
match mpls experimental topmost 2
!
policy-map child-pmap
class qos1
priority
police percent 10
class qos-group2
bandwidth percent 10
class class-default
random-detect
policy-map vlan101-pmap
class vlan101
shape average 90000000 360000 360000
service-policy child-pmap
interface GigabitEthernet 7/1
service-policy output vlan101-pmap
...
Complete Hierarchical QoS Example
The following example shows a hierarchical QoS configuration with one parent policy map and two child policy maps. This configuration performs the following:
•The input interface (Gigabit Ethernet 2/2) uses the cos-to-qosgroup-pmap policy map to set the QoS group value of incoming packets to match the packets' original 802.1P CoS values.
•The parent policy map shapes traffic for VLAN 101 and 102 to different bandwidths, and applies separate child policy maps to each. The rest of the traffic on the interface is shaped and made subject to the random-detect method.
•The child policy map for VLAN 101 allocates different bandwidth to traffic for QoS groups 1 and 2, and transmits all other traffic on that VLAN unchanged (subject to the parent policy map's bandwidth limitations).
•The child policy map for VLAN 102 marks traffic with QoS group set to 2 as priority traffic, and limits all other traffic to 40 percent of the bandwidth (subject to the parent policy map's bandwidth limitations).
•The outgoing interface (POS 8/7) attaches the parent policy map (vlan-parent) for outgoing traffic.
class-map match-any vlan101
match input vlan 101
class-map match-any vlan102
match input vlan 102
class-map match-all group1
match qos-group 1
class-map match-all group2
match qos-group 2
!
policy-map cos-to-qosgroup-pmap
class class-default
set qos-group cos
!
policy-map vlan-parent
description top-level parent policy map
class vlan101
shape average 50000000 200000 200000
service-policy 101qos
class vlan102
shape average 100000000 400000 400000
service-policy 102qos
class class-default
shape average 50000000 200000 200000
random-detect
!
policy-map 101qos
description child-level policy map for VLAN 101
class group1
bandwidth percent 10
class group2
bandwidth percent 30
policy-map 102qos
description child-level policy map for VLAN 102
class group2
police percent 10
priority
class class-default
bandwidth percent 40
!
! Customer-facing interface - the cos-to-qosgroup-pmap policy map sets the
! packet's QoS group value to match the customer's original CoS values.
interface GigabitEthernet2/2
description Customer-facing interface
ip address 192.168.100.13 255.255.255.0
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 101-1000,1002-1005
switchport mode trunk
mls qos trust
no cdp enable
service-policy input cos-to-qosgroup-pmap
...
!
interface POS8/7
description Network-Facing OSM POS
ip address 10.11.0.5 255.255.255.0
encapsulation ppp
tag-switching ip
mls qos trust dscp
service-policy output vlan-parent
...
Multiple Parent Policies Using the Same Child Policy Example
This excerpt from a sample configuration file shows several parent policy maps using the same child map.
! You can enable QoS globally or per-interface
mls qos
!
class-map match-all group1
match qos-group 1
class-map match-all group2
match qos-group 2
class-map match-any vlan101
match input vlan 101
class-map match-any vlan102
match input vlan 102
class-map match-any vlan103
match input vlan 103
class-map match-all exp-3
match mpls experimental topmost 3
!
policy-map child-pmap
class group1
shape average 10000000
class group2
shape average 20000000
!
policy-map parent1-pmap
class vlan101
shape average 60000000
service-policy child-pmap
class vlan102
shape average 80000000
service-policy child-pmap
class class-default
shape average 100000000
!
policy-map parent2-pmap
class vlan103
shape average 55000000
service-policy child-pmap
class exp-3
shape average 60000000
...
Common Class-Map Templates Example
This excerpt from a configuration file gives some common templates for class maps that can be used with your own policy maps.
! You can enable QoS globally or per-interface
mls qos
...
! Class Maps to Match on IP Precedence Bits
class-map match-any prec0
match ip precedence 0
class-map match-any prec1
match ip precedence 1
class-map match-any prec2
match ip precedence 2
class-map match-any prec3
match ip precedence 3
class-map match-any prec4
match ip precedence 4
class-map match-any prec5
match ip precedence 5
class-map match-any prec6
match ip precedence 6
class-map match-any prec7
match ip precedence 7
! Matches all non-priority precedence values
class-map match-any prec0-4
match ip precedence 0 1 2 3 4
!
! Class-Maps to Match on QoS Groups
class-map match-all group0
match qos-group 0
class-map match-all group1
match qos-group 1
class-map match-all group2
match qos-group 2
class-map match-all group3
match qos-group 3
class-map match-all group4
match qos-group 4
class-map match-all group5
match qos-group 5
class-map match-all group6
match qos-group 6
class-map match-all group7
match qos-group 7
!
! Class Maps to Match on MPLS EXP Bits
class-map match-all exp0
match mpls experimental topmost 0
class-map match-all exp1
match mpls experimental topmost 1
class-map match-all exp2
match mpls experimental topmost 2
class-map match-all exp3
match mpls experimental topmost 3
class-map match-all exp4
match mpls experimental topmost 4
class-map match-all exp5
match mpls experimental topmost 5
class-map match-all exp6
match mpls experimental topmost 6
class-map match-all exp7
match mpls experimental topmost 7
class-map match-all exp1-4
match mpls experimental topmost 1 2 3 4
!
! Sample Class-MapS to Match on VLAN
! Copy and Change the VLAN Number as Desired
class-map match-any vlan101
match input vlan 101
class-map match-any vlan102
match input vlan 102
class-map match-any vlan103
match input vlan 103
class-map match-any vlan104
match input vlan 104
class-map match-any vlans101-104
match input vlan 101-104
!
AToM Load Balancing
Load-balancing allows a router to take advantage of multiple best paths to a given destination. By default most AToM modes (except Supervisor Engine 720-based EoMPLS) use a similar load balancing mechanism to determine the tunnel label for the core facing interface: the router distributes AToM VCs across all available paths, irrespective of each link's load. The router hashes the VC label into an index value that is used to select a tunnel label. The selected tunnel label is placed on the top of the label stack of a particular VC.
The Cisco 7600 series router provides another way to load balance by selecting the path with the lowest use across all available paths based on the following order:
•Different ports on the same packet processor complex
•Different interfaces on a chosen port on the same packet processor complex.
Load Balancing Guidelines
Enable lowest use mode by entering configuration commands (one command per line) and pressing Ctrl-Z after each command.
PE-7600B#conf t
PE-7600B(config)#mpls load-balance per-l2transport-circuit
Disable lowest use mode by entering configuration commands (one command per line) and pressing Crtl-Z after each command.
PE-7600B#conf t
PE-7600B(config)#no mpls load-balance per-l2transport-circuit
Display the current load balancing mode using the show cwan atom load-balance-mode command.
PE-7600B#sh cwan atom load-balance-mode
Current load balancing mode : per-l2transport-circuit
Note When the lowest use load balancing mode is enabled on a system that is already up, it only affects newer AToM VCs. Existing AToM VCs are not affected. To apply the lowest use load balancing mode to all the existing VCs, you can flap the VCs.
Lowest Use Mode Limitations
If the interfaces facing the MPLS core are a mix of WAN and LAN interfaces, then the AToM VCs remain active as long as there is a minimum of one usable WAN interface. However, this is not a recommended setup and the AToM VC may be dropping disposition packets that arrive on the LAN interface.
If you ignore the warning message that indicates this type of configuration, you risk losing disposition packets because the AToM VC may not be fully functioning.
Virtual Private LAN Services on the Optical Services Modules
This section describes how to configure Virtual Private LAN Services (VPLS) on the Optical Services Modules (OSMs) and covers the topics below.
•Full-Mesh Configuration Example
•H-VPLS with MPLS Edge Configuration Example
•Configuring Dot1q Transparency for EoMPLS
VPLS Overview
Virtual Private LAN Services (VPLS) uses the provider core to join multiple attachment circuits together to simulate a virtual bridge that connects the multiple attachment circuits together. From a customer point of view, there is no topology for VPLS. All of the CE devices appear to connect to a logical bridge emulated by the provider core. See Figure 9-1.
Figure 9-1 VPLS
Full-mesh, hub and spoke, and Hierarchical VPLS (H-VPLS) with MPLS edge configurations are available.
Full-Mesh Configuration
The full-mesh configuration requires a full mesh of tunnel label switched paths (LSPs) between all the PEs that participate in the VPLS. With full-mesh, signaling overhead and packet replication requirements for each provisioned VC on a PE can be high.
You set up a VPLS by first creating a virtual forwarding instance (VFI) on each participating PE router. The VFI specifies the VPN ID of a VPLS domain, the addresses of other PE routers in the domain, and the type of tunnel signaling and encapsulation mechanism for each peer PE router.
The set of VFIs formed by the interconnection of the emulated VCs is called a VPLS instance; it is the VPLS instance that forms the logic bridge over a packet switched network. The VPLS instance is assigned a unique VPN ID.
The PE routers use the VFI to establish a full-mesh LSP of emulated VCs to all the other PE routers in the VPLS instance. PE routers obtain the membership of a VPLS instance through static configuration using the Cisco IOS CLI.
The full-mesh configuration allows the PE router to maintain a single broadcast domain. Thus, when the PE router receives a broadcast, multicast, or unknown unicast packet on an attachment circuit, it sends the packet out on all other attachment circuits and emulated circuits to all other CE devices participating in that VPLS instance. The CE devices see the VPLS instance as an emulated LAN.
To avoid the problem of a packet looping in the provider core, the PE devices enforce a "split-horizon" principle for the emulated VCs. That means if a packet is received on an emulated VC, it is not forwarded on any other emulated VC.
After the VFI has been defined, it needs to be bound to an attachment circuit to the CE device.
The packet forwarding decision is made by looking up the Layer 2 virtual forwarding instance (VFI) of a particular VPLS domain.
A VPLS instance on a particular PE router receives Ethernet frames that enter on specific physical or logical ports and populates a MAC table similarly to how an Ethernet switch works. The PE router can use the MAC address to switch those frames into the appropriate LSP for delivery to the another PE router at a remote site.
If the MAC address is not in the MAC address table, the PE router replicates the Ethernet frame and floods it to all logical ports associated with that VPLS instance, except the ingress port where it just entered. The PE router updates the MAC table as it receives packets on specific ports and removes addresses not used for specific periods.
Hub and Spoke
In a hub-and-spoke model, the PE router that acts as the hub establishes a point-to-multipoint forwarding relationship with all PE routers at the spoke sites. An Ethernet or VLAN packet received from the customer network on the hub PE can be forwarded to one or more emulated VCs.
The PE routers that act as the spoke establish a point-to-point connection to the PE at the hub site. Ethernet or VLAN packets received from the customer network on the spoke PE are forwarded to the VFI or VPLS instance at the hub. If there are a number of customer sites connecting to the spoke, you can terminate mutiple VCs per spoke into the same VFI or VPLS instance at the hub.
H-VPLS
Hierarchical VPLS (H-VPLS) reduces both signaling and replication overhead by using both full-mesh as well as hub and spoke configurations. Hub and spoke configurations operate with split horizon to allow packets to be switched between pseudo-wires (PWs), effectively reducing the number of PWs between PEs.
Note Split horizon is the default configuration to avoid broadcast packet looping. To avoid looping when using the no-split-horizon keyword, be very mindful of your network configuration.
Restrictions for VPLS
The following general restrictions pertain to all transport types under VPLS:
•Split horizon is the default configuration to avoid broadcast packet looping and to isolate Layer 2 traffic. With split horizon, a packet coming from a WAN interface never goes back to another WAN interface (it always get switched to a Layer 2 interface). Split horizon prevents packets received from an emulated VC from being forwarded into another emulated VC. This technique is important for creating loop-free paths in a full-meshed network.
•The Cisco 7600 series routers support a maximum of 60 peer PEs and a maximum of 15,000 VCs. For example, you can configure 15,000 VCs as 1,000 VFIs with 15 VPLS peers per VFI.
Note The 60 peer PEs are distributed between the MPLS edge and the core; do not assume there are 60 peer PEs on each side.
•No software-based data plane is supported.
•No auto-discovery mechanism is supported.
•Load sharing and failover on redundant CE-PE links are not supported.
•The addition or removal of MAC addresses with Label Distribution Protocol (LDP) is not supported.
•On the Cisco 7600 series router, the virtual forwarding instance (VFI) is supported only with the interface vlan command.
Supported Features
Multipoint-to-Multipoint Support
Two or more devices are associated over the core network. No one device is designated as the Root node, but all devices are treated as Root nodes. All frames can be exchanged directly between nodes.
Non-Transparent Operation
A virtual Ethernet connection (VEC) can be transparent or non-transparent with respect to Ethernet PDUs (that is, BPDUs). The purpose of VEC non-transparency is to allow the end user to have a Frame Relay-type service between Layer 3 devices.
Circuit Multiplexing
Circuit Multiplexing allows a node to participate in multiple services over a single Ethernet connection. By participating in multiple services, the Ethernet connection is attached to multiple logical networks. Some examples of possible service offerings are VPN services between sites, Internet services, and third-party connectivity for intercompany communications.
MAC-Address Learning Forwarding and Aging
PEs must learn remote MAC addresses and directly attached MAC addresses on customer facing ports. MAC address learning accomplishes this by deriving topology and forwarding information from packets originating at customer sites. A timer is associated with stored MAC addresses. After the timer expires, the entry is removed from the table.
Jumbo Frame Support
Jumbo frame support provides support for frame sizes between 1548 through 9216 bytes. You use the CLI to establish the jumbo frame size for any value specified in the above range. The default value is 1500 bytes in any Layer 2/VLAN interface. You can configure jumbo frame support on a per-interface basis.
Q-in-Q Support and Q-in-Q to EoMPLS Support
With 802.1Q tunneling (Q-in-Q), the CE issues VLAN-tagged packets and the VPLS forwards the packets to a far-end CE. Q-in-Q refers to the fact that one or more 802.1Q tags may be located in a packet within the interior of the network. As packets are received from a CE device, an additional VLAN tag is added to incoming Ethernet packets to segregate traffic from different CE devices. Untagged packets originating from the CE use a single tag within the interior of the VLAN switched network, while previously tagged packets originating from the CE use two or more tags.
VPLS Services
Transparent LAN Service (TLS) and Ethernet Virtual Connection Service (EVCS) are available for service provider and enterprise use.
•Transparent LAN Service (TLS)—Use when you need transparency of bridging protocols (for example, bridge protocol data units [BPDUs]) and VLAN values. Bridges see this service as an Ethernet segment.
Note You must enable Layer 2 protocol tunneling to run the Cisco Discovery Protocol (CDP), the VLAN Trunking Protocol (VTP), and the Spanning-Tree Protocol (STP). See Chapter 18, "Configuring IEEE 802.1Q Tunneling" in the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR.
•Ethernet Virtual Connection Service (EVCS)—Use when you need routers to reach multiple intranet and extranet locations from a single physical port. Routers see subinterfaces through which they access other routers.
Transparent LAN Service
TLS is an extension to the point-to-point port-based EoMPLS. With TLS, the PE router forwards all Ethernet packets received from the customer-facing interface (including tagged, untagged, and BPDUs) as follows:
•To a local Ethernet interface or an emulated VC if the destination MAC address is found in the Layer 2 forwarding table.
•To all other local Ethernet interfaces and emulated VCs belonging to the same VPLS domain if the destination MAC address is a multicast or broadcast address or if the destination MAC address is not found in the Layer 2 forwarding table.
Ethernet Virtual Connection Service
EVCS is an extension to the point-to-point VLAN-based EoMPLS. With EVCS, the PE router forwards all Ethernet packets with a particular VLAN tag received from the customer-facing interface (excluding BPDUs) as follows:
•To a local Ethernet interface or to an emulated VC if the destination MAC address is found in the Layer 2 forwarding table.
•To all other local Ethernet interfaces and emulated VCs belonging to the same VPLS domain if the destination MAC address is a multicast or broadcast address or if the destination MAC address is not found in the Layer 2 forwarding table.
Note Because it has only local significance, the demultiplexing VLAN tag that identifies a VPLS domain is removed before forwarding the packet to the outgoing Ethernet interfaces or emulated VCs.
Benefits of VPLS
VPLS (Virtual Private LAN Service) enables enterprises to link together their Ethernet-based LANs from multiple sites via the infrastructure provided by their service provider. From the enterprise perspective, the service provider's public network looks like one giant Ethernet LAN. For the service provider, VPLS provides an opportunity to deploy another revenue-generating service on top of their existing network without major capital expenditures. Operators can extend the operational life of equipment in their network.
Configuring VPLS
This section explains how to perform a basic VPLS configuration.
Note Provisioning a VPLS link involves provisioning the associated attachment circuit and the VFI on the PE.
Note VPLS is supported on Supervisor Engine 720-based systems.
Prerequisites
Before you configure VPLS, ensure that the network is configured as follows:
•Configure IP routing in the core so that the PE routers can reach each other via IP.
•Configure MPLS in the core so that a label switched path (LSP) exists between the PE routers.
•Configure a loopback interface for originating and terminating Layer 2 traffic. Make sure the PE routers can access the other router's loopback interface. Note that the loopback interface is not needed in all cases. For example, tunnel selection does not need a loopback interface when VPLS is directly mapped to a TE tunnel.
Supported Modules
The OSM-2+4GE-WAN-GBIC+ is the only core facing module supported.
Customer facing interfaces are all Ethernet/ Fast Ethernet/ Gigabit Ethernet interfaces based on Layer 2 Catalyst LAN ports. See the Catalyst 6500 Switch Module Guide at: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/6500-emig.html
Basic VPLS Configuration
VPLS configuration requires you to identify peer PE routers and to attach Layer 2 circuits to the VPLS at each PE router.
VPLS configuration requires the following:
•Configuring the PE Layer 2 Interface to the CE
•Configuring Layer 2 VLAN Instance on the PE
•Configuring MPLS WAN Interface on the PE
•Configuring the VFI in the PE
•Associating the Attachment Circuit with the VSI at the PE
Configuring the PE Layer 2 Interface to the CE
You must configure the Layer 2 interface as a switchport for local bridging. You have the option of selecting tagged or untagged traffic from the CE device.
Note It is important to define the trunk VLANs; use the switchport trunk allow vlan command as shown in the first example below.
SUMMARY STEPS
Option 1—802.1Q Trunk for Tagged Traffic from the CE
1. interface type number
2. no ip address ip-address mask [secondary]
3. switchport
4. switchport trunk encapsulation dot1q
5. switchport trunk allow vlan
6. switchport mode trunk
Note When EVCS is configured, the PE router forwards all Ethernet packets with a particular VLAN tag to a local Ethernet interface or emulated VC if the destination MAC address is found in Layer 2 forwarding table.
DETAILED STEPS
This example shows how to configure the tagged traffic.
Router(config)# interface GigabitEthernet4/4
Router(config)# no ip address
Router(config-if)# switchport
Router(config-if)# switchport trunk encapsulation dot1q
Router(config-if)# switchport trunk allow vlan 501
Router(config-if)# switchport mode trunk
This example shows how to use the show run interface command to verify the configuration.
Router# show run interface GigabitEthernet4/4
Building configuration...
Current configuration : 212 bytes
!
interface GigabitEthernet4/4
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 501
switchport mode trunk
end
SUMMARY STEPS
Option 2—802.1Q Access Port for Untagged Traffic from CE
1. interface type number
2. no ip address ip-address mask [secondary]
3. speed [1000 | nonegotiate]
4. switchport
5. switchport mode access
6. switchport access vlan vlan-id
DETAILED STEPS
This example shows how to configure the untagged traffic.
Router(config)# interface GigabitEthernet4/4
Router(config)# no ip address
Router(config-if)# speed nonegotiate
Router(config-if)# switchport
Router(config-if)# switchport mode access
Router(config-if)# switchport access vlan 501
This example shows how to use the show run interface command to verify the configuration.
Router# show run interface GigabitEthernet4/4
Building configuration...
Current configuration : 212 bytes
!
interface GigabitEthernet4/4
speed nonegotiate
switchport
switchport mode access
switchport access vlan 501
end
SUMMARY STEPS
Option 3—Using Q-in-Q to Place All VLANs into a Single VPLS
1. interface type number
2. no ip address ip-address mask [secondary]
3. speed [1000 | nonegotiate]
4. switchport
5. switchport access vlan vlan-id
6. switchport mode dot1q-tunnel
7. l2protocol-tunnel [cdp | stp | vtp]
Note When TLS is configured, the PE router forwards all Ethernet packets received from the CE device to all local Ethernet interfaces and emulated VCs belonging to the same VPLS domain if the MAC address is not found in the Layer 2 forwarding table.
DETAILED STEPS
This example shows how to configure the tagged traffic.
Router(config)# interface GigabitEthernet4/4
Router(config)# no ip address
Router(config-if)# speed nonegotiate
Router(config-if)# switchport
Router(config-if)# switchport access vlan 501
Router(config-if)# switchport mode dot1q-tunnel
Router(config-if)# l2protocol-tunnel cdp
This example shows how to use the show run interface command to verify the configuration.
Router# show run interface GigabitEthernet4/4
Building configuration...
Current configuration : 212 bytes
!
interface GigabitEthernet4/4
no ip address
speed nonegotiate
switchport
switchport access vlan 501
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
end
Use the show spanning-tree vlan command to verify the port is not in a blocked state.
Router# show spanning-tree vlan 501
VLAN0501
Spanning tree enabled protocol ieee
Root ID Priority 33269
Address 0001.6446.2300
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33269 (priority 32768 sys-id-ext 501)
Address 0001.6446.2300
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 0
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Gi4/4 Desg FWD 4 128.388 P2p
Use the show vlan id command to verify that a specific port is configured to send and receive a specific VLANs traffic.
Router# show vlan id 501
VLAN Name Status Ports
---- -------------------------------- ---------
501 VLAN0501 active Gi4/4
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1
Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------
501 enet 100501 1500 - - - - - 0 0
Remote SPAN VLAN
----------------
Disabled
Primary Secondary Type Ports
------- --------- -----------------
Configuring Layer 2 VLAN Instance on the PE
Configuring the Layer 2 VLAN interface on the PE enables the Layer 2 VLAN instance on the PE router to the VLAN database to set up the mapping between the VPLS and VLANs.
For more information, see See "Configuring VLANs" in the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR.
SUMMARY STEPS
1. vlan vlan-id
2. interface vlan vlan-id
DETAILED STEPS
This is an example of configuring a Layer 2 VLAN instance.
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# vlan 501
Router(config)# interface vlan 501
Router(config-if)#
Use the show interfaces vlan command to verify the VLAN is in the up state (example not shown).
Configuring MPLS WAN Interface on the PE
The following commands configure the MPLS WAN interface.
Note The MPLS uplink must be on one of the supported OSMs.
SUMMARY STEPS
1. interface type number
2. ip address ip-address mask
3. tag-switching ip
4. mls qos trust [cos | dscp | ip-precedence]
DETAILED STEPS
This is an example of configuring the WAN interface.
Router(config)# interface pos4/1
Router(config)# ip address 181.10.10.1 255.255.255.0
Router(config-if)# ip directed-broadcast
Router(config-if)# ip ospf network broadcast
Router(config-if)# no keepalive
Router(config-if)# mpls label protocol ldp
Router(config-if)# tag-switching ip
Router(config-if)# mls qos trust dscp
Use the show tag-switching interfaces command to verify operation.
Router# show tag-switching interfaces pos4/1
Interface IP Tunnel Operational
POS4/1 Yes (ldp) Yes Yes
Router#
Configuring MPLS in the PE
To configure MPLS in the PE, you must provide the required MPLS parameters.
Note Before configuring MPLS, ensure that you have IP connectivity between all PEs by configuring Interior Gateway Protocol (IGP) (Open Shortes Path First [OSPF] or Intermediate System to Intermediate System [IS-IS]) between the PEs.
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls label protocol {ldp | tdp}
4. (Optional) mpls ldp logging neighbor-changes
5. tag-switching tdp discovery {hello | directed hello} {holdtime | interval} seconds
6. tag-switching tdp router-id Loopback0 force
DETAILED STEPS
This example shows global MPLS configuration.
Router(config)# mpls label protocol ldp
Router(config)# tag-switching tdp discovery directed hello
Router(config)# tag-switching tdp router-id Loopback0 force
This example shows how to use the show ip cef command to verify that LDP label is assigned.
Router# show ip cef 192.168.17.7
192.168.17.7/32, version 272, epoch 0, cached adjacency to POS4/1
0 packets, 0 bytes
tag information set
local tag: 8149
fast tag rewrite with PO4/1, point2point, tags imposed: {4017}
via 11.3.1.4, POS4/1, 283 dependencies
next hop 11.3.1.4, POS4/1
valid cached adjacency
tag rewrite with PO4/1, point2point, tags imposed: {4017}
Configuring the VFI in the PE
The virtual switch instance (VFI) specifies the VPN ID of a VPLS domain, the addresses of other PE routers in this domain, and the type of tunnel signaling and encapsulation mechanism for each peer. (This is where you create the VSI and associated VCs.) Configure a VFI as follows:
Note Only MPLS encapsulation is supported.
SUMMARY STEPS
1. l2 vfi name manual
2. vpn id vpn-id
3. neighbor remote router id [vc-id-value] {encapsulation mpls} [no-split-horizon]
4. shutdown
DETAILED STEPS
The following example shows a VFI configuration.
Router(config)# l2 vfi VPLSA manual
Router(config-vfi)# vpn id 100
Router(config-vfi)# neighbor 11.11.11.11 encapsulation mpls
Router(config-vfi)# neighbor 33.33.33.33 encapsulation mpls
Router(config-vfi)# neighbor 44.44.44.44 encapsulation mpls
The following example shows a VFI configuration for hub and spoke.
Router(config)# l2 vfi VPLSA manual
Router(config-vfi)# vpn id 100
Router(config-vfi)# neighbor 9.9.9.9 2001 encapsulation mpls
Router(config-vfi)# neighbor 12.12.12.12 2002 encapsulation mpls
Router(config-vfi)# neighbor 33.33.33.33 2003 encapsulation mpls no-split-horizon
The show mpls 12transport vc command displays various information related to PE1.
Note The show mpls l2transport vc detail command is also available to show detailed information about the VCs on a PE router as in the following example. (This example is not based on the previous VFI configurations.)
VPLS-PE2# show mpls l2transport vc 201
Local intf Local circuit Dest address VC ID Status
------------- -------------------- --------------- ---------- ----------
VFI test1 VFI 153.1.0.1 201 UP
VFI test1 VFI 153.3.0.1 201 UP
VFI test1 VFI 153.4.0.1 201 UP
Note The VC ID in the output represents the VPN ID; the VC is identified by the combination of the Dest address and the VC ID as in the example below. (This example is not based on the previous VFI configurations.)
The show vfi vfi name command shows VFI status.
nPE-3# show vfi VPLS-2
VFI name: VPLS-2, state: up
VPN ID: 100
Local attachment circuits:
Vlan2
Neighbors connected via pseudowires:
Peer Address VC ID Split-horizon
1.1.1.1 2 Y
1.1.1.2 2 Y
2.2.2.3 2 N
Associating the Attachment Circuit with the VSI at the PE
After defining the VFI, you must bind it to one or more attachment circuits (interfaces, subinterfaces, or virtual circuits).
SUMMARY STEPS
1. interface vlan vlan-id
2. no ip address (Configuring an IP address causes Layer 3 interface to be created for the VLAN.)
3. xconnect vfi vfi name
DETAILED STEPS
This example shows an interface VLAN configuration.
Router(config-if)# interface vlan 100
Router(config-if)# no ip address
Router(config-if)# xconnect vfi VPLS_501
This is an example of how to use the show vfi command for VFI status.
Router# show vfi VPLS_501
VFI name: VPLS_501, state: up
VPN ID: 100
Local attachment circuits:
vlan 100
Neighbors connected via pseudowires:
192.168.11.1 192.168.12.2 192.168.13.3 192.168.16.6
192.168.17.7
Full-Mesh Configuration Example
In a full-mesh configuration, each PE router creates a multipoint-to-multipoint forwarding relationship with all other PE routers in the VPLS domain using a VFI. An Ethernet or VLAN packet received from the customer network can be forwarded to one or more local interfaces and or emulated VCs in the VPLS domain. To avoid broadcasted packets looping around in the network, no packet received from an emulated VC can be forwarded to any emulated VC of the VPLS domain on a PE router. That is, the Layer 2 split horizon should always be enabled as the default in a full-mesh network. Figure 9-2 shows the configuration example.
Figure 9-2
VPLS Configuration Example
Configuration on PE 1
This shows the creation of the virtual switch instances (VSIs) and associated VCs.
l2 vfi PE1-VPLS-A manual
vpn id 100
neighbor 2.2.2.2 encapsulation mpls
neighbor 3.3.3.3 encapsulation mpls
!
interface Loopback 0
ip address 1.1.1.1 255.255.255.255
This configures the CE device interface (there can be multiple Layer 2 interfaces in a VLAN).
interface FastEthernet0/0
switchport
switchport mode dot1qtunnel
switchport access vlan 100
!
Here the attachment circuit (VLAN) is associated with the VSI.
interface vlan 100
no ip address
xconnect vfi PE1-VPLS-A
!
This is the enablement of the Layer 2 VLAN instance.
vlan 100
state active
Configuration on PE 2
This shows the creation of the virtual switch instances (VSIs) and associated VCs.
l2 vfi PE2-VPLS-A manual
vpn id 100
neighbor 1.1.1.1 encapsulation mpls
neighbor 3.3.3.3 encapsulation mpls
!
interface Loopback 0
ip address 2.2.2.2 255.255.255.255
This configures the CE device interface (there can be multiple Layer 2 interfaces in a VLAN).
interface FastEthernet0/0
switchport
switchport mode dot1qtunnel
switchport access vlan 100
!
Here the attachment circuit (VLAN) is associated with the VSI.
interface vlan 100
no ip address
xconnect vfi PE2-VPLS-A
!
This is the enablement of the Layer 2 VLAN instance.
vlan 100
state active
Configuration on PE 3
This shows the creation of the virtual switch instances (VSIs) and associated VCs.
l2 vfi PE3-VPLS-A manual
vpn id 100
neighbor 1.1.1.1 encapsulation mpls
neighbor 2.2.2.2 encapsulation mpls
!
interface Loopback 0
ip address 3.3.3.3 255.255.255.255
This configures the CE device interface (there can be multiple Layer 2 interfaces in a VLAN).
interface FastEthernet0/1
switchport
switchport mode dot1qtunnel
switchport access vlan 100
!
Here the attachment circuit (VLAN) is associated with the VSI.
interface vlan 100
no ip address
xconnect vfi PE3-VPLS-A .
!
This is the enablement of the Layer 2 VLAN instance.
vlan 100
state active
The show mpls l2 vc command provides information on the status of the VC.
VPLS1# show mpls l2 vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------- --------------- ---------- ----------
Vi1 VFI 22.22.22.22 100 DOWN
Vi1 VFI 22.22.22.22 200 UP
Vi1 VFI 33.33.33.33 100 UP
Vi1 VFI 44.44.44.44 100 UP
Vi1 VFI 44.44.44.44 200 UP
The show vfi command provides information on the VFI.
PE-1# show vfi PE1-VPLS-A
VFI name: VPLSA, state: up
VPN ID: 100
Local attachment circuits:
Vlan100
Neighbors connected via pseudowires:
2.2.2.2 3.3.3.3
The show mpls 12transport vc command provides information about the virtual circuits.
osr12# show mpls l2 vc detail
Local interface: VFI vfi17 up
Destination address: 1.3.1.1, VC ID: 17, VC status: up
Output interface: PO3/4, imposed label stack {18}
Create time: 3d15h, last status change time: 1d03h
Signaling protocol: LDP, peer 1.3.1.1:0 up
MPLS VC labels: local 18, remote 18
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 0, send 0
byte totals: receive 0, send 0
packet drops: receive 0, send 0
H-VPLS with MPLS Edge Configuration Example
The Hierarchical VPLS model comprises hub and spoke and full-mesh networks. In a full-mesh configuration, each PE router creates a multipoint-to-multipoint forwarding relationship with all other PE routers in the VPLS domain using VFIs.
In the hub and spoke configuration, a PE router can operate in a non-split-horizon mode that allows inter-VC connectivity without the requirement to add a Layer 2 port in the VLAN.
In the example below, the VLANs on CE1, CE2, CE3, and CE4 (in red color) connect through a full-mesh network. The VLANs on CE2, CE5, and CE6 connect through a hub and spoke network. CE2 is directly attached to the PE2 hub and CE6 is directly attached to the PE1 hub. CE4 and CE5 both are connected to the PE3 hub through the spoke uPE. Figure 9-3 shows the configuration example.
Figure 9-3 H-
VPLS Configuration
Configuration on PE1
This shows the creation of the virtual switch instances (VSIs) and associated VCs. Note that the VCs in green require the no-split-horizon keyword. The no-split-horizon command disables the default Layer 2 split horizon in the data path.
l2 vfi Internet manual
vpn id 100
neighbor 120.0.0.3 encapsulation mpls no-split-horizon
neighbor 162.0.0.2 encapsulation mpls no-split-horizon
l2 vfi PE1-VPLS-A manual
vpn id 200
neighbor 120.0.0.3 encapsulation mpls
neighbor 162.0.0.2 encapsulation mpls
interface Loopback 0
ip address 20.0.0.1 255.255.255.255
This configures the CE device interface (there can be multiple Layer 2 interfaces in a VLAN).
interface GigEthernet1/1
switchport
switchport mode trunk
switchport trunk encap dot1q
switchport trunk allow vlan 1001,1002-1005
Here the attachment circuit (VLAN) is associated with the VFI.
interface vlan 1001
xconnect vfi Internet
interface FastEthernet2/1
switchport
switchport mode trunk
switchport trunk encap dot1q
switchport trunk allow vlan 211,1002-1005
interface vlan 211
xconnect vfi PE1-VPLS-A
Configuration on PE2
This shows the creation of the VFIs and associated VCs.
l2 vfi Internet manual
vpn id 100
neighbor 20.0.0.1 encapsulation mpls
l2 vfi PE2-VPLS-A manual
vpn id 200
neighbor 120.0.0.3 encapsulation mpls
neighbor 20.0.0.1 encapsulation mpls
interface Loopback 0
ip address 162.0.0.2 255.255.255.255
This configures the CE device interface (there can be multiple Layer 2 interfaces in a VLAN).
interface GigEthernet2/1
switchport
switchport mode trunk
switchport trunk encap dot1q
switchport trunk allow vlan 211,1001,1002-1005
Here the attachment circuit (VLAN) is associated with the VFI.
interface vlan 1001
xconnect vfi Internet
interface vlan 211
xconnect vfi PE2-VPLS-A
Configuration on PE3
This shows the creation of the VFIs and associated VCs.
l2 vfi Internet manual
vpn id 100
neighbor 20.0.0.1 encapsulation mpls
neighbor 162.0.0.2 encapsulation mpls
neighbor 30.0.0.1 encapsulation mpls no-split horizon
l2 vfi PE3-VPLS-A manual
vpn id 200
neighbor 162.0.0.2 encapsulation mpls
neighbor 20.0.0.1 encapsulation mpls
neighbor 30.0.0.1 200 encapsulation mpls no-split horizon
interface Loopback 0
ip address 120.0.0.3 255.255.255.255
This configures the CE device interface.
interface GigEthernet6/1
switchport
switchport mode trunk
switchport trunk encap dot1q
switchport trunk allow vlan 211
This configures the attachment circuits.
interface vlan 1001
xconnect vfi Internet
interface vlan 211
xconnect vfi PE3-VPLS-A
Usually EoMPLS is configured on the uPE device. You can use port-based or VLAN-based EoMPLS. This configures port-based EoMPLS on the uPE (the uPE connects to CE4).
interface GigEthernet 1/1
xconnect 120.0.0.3 100 encapsulation mpls
This configures VLAN-based EoMPLS on the uPE. (the uPE connects to CE4).
interface GigEthernet 1/1.1
encapsulation dot1Q 100
xconnect 120.0.0.3 100 encapsulation mpls
MAC Limit Per VLAN
VPLS provides the ability to limit the maximum number of MAC entries per VLAN to avoid exhausting resources. To enable the MAC limit feature, use the mac-address-table limit command; see the Cisco 7600 Series Cisco IOS Software Command Reference Guide, 12.2SR.
Traffic Engineering for Transport Tunnel
MPLS traffic engineering software enables an MPLS backbone to replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay networks. See
Load Balancing
Load balancing describes a functionality in a router that distributes packets across multiple links. For information on load balancing, see
http://www.cisco.com/en/US/docs/ios/ipapp/configuration/guide/ipapp_slb.html
QoS
VPLS uses PFC-based QoS on the input side; on the core-facing interface, VPLS uses OSM-based features similar to EoMPLS, except for shaping.
Per-VLAN Shaping
Per-VLAN traffic shaping in an VPLS environment has different characteristics from EoMPLS. The queues are based on the shaping parameter on a per-MPLS port basis. A VLAN configured for a 100 Mbps shaper creates a 100 M queue on each physical MPLS uplink port in the VPLS domain. In a PE with four MPLS uplinks, this allows up to 400 Mbps of traffic to be forwarded into the core network. If two VCs share an egress interface, they would also share the same 100M shaper.
The following configuration matches all traffic input, and shapes the traffic on each egress interface to 100 Mbps.
class-map match-all all
match any
policy-map shape100
class all
shape average 100000000
interface Vlan100
no ip address
xconnect vfi 100
service-policy output shape100
For information on PFC-based QoS, see "Configuring PFC QoS" at http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/122sx/swcg/qos.htm.
For information on QoS for the core-facing interface, see the "How to Configure QoS with AToM" section.
Note If you are shaping policy to both the VLAN interface and the core-facing interface, then the policy on the VLAN interface overrides the policy on the core-facing interface.
Note VPLS supports a maximum of up to 30,000 VCs; for this number, we recommend that you configure a maximum of five different EXP classifications.
Note If a service policy is applied on the core-facing interface, then the number of VPLS VCs going out of the interfaces on a single PXF processor cannot exceed 21,000.
Configuring Dot1q Transparency for EoMPLS
The Dot1q Transparency for EoMPLS feature allows a service provider to modify the MPLS EXP bits for core-based QoS policies while leaving any VPLS customer 802.1p bits unchanged.
When applying a service policy to an EoMPLS configured VLAN interface that sets the MPLS EXP bits, the set effects both the Interior Gateway Protocol (IGP) label and the VC label. If the customer traffic includes an 802.1q label with associated 802.1p bits, the 802.1p bits are rewritten on the egress PE based on the received VC EXP bits. If the policy sets the MPLS EXP bits to a different value from the received 802.1p bits, the rewriting on the egress PE results in a modification of the customer's 802.1p bits.
The Dot1q Transparency for EoMPLS feature provides the option for the VLAN-applied policy to affect only the IGP label (for core QoS) and leaves the VC label EXP bits equal to the 802.1p bits. On the egress PE, the 802.1p bits are still rewritten based on the received VC EXP bits, however, because the EXP bits now match the ingress 802.1p bits, a VPLS customer's 802.1p bits do not change.
Restrictions
The following restrictions apply to the Dot1q Transparency for EoMPLS feature:
•Global configuration applies to all virtual forwarding instance (VFI) and switched virtual interface (SVI) EoMPLS VCs configured on the Cisco 7600 series routers.
•Only supported on OSMs.
•Interoperability requires applying the Dot1q Transparency for EoMPLS feature to all participating PE routers.
SUMMARY STEPS
1. enable
2. configure terminal
3. platform vfi dot1q-transparency
4. interface vlan
5. no ip address
6. xconnect peer-router-id vcid encapsulation mpls
7. service-policy output
DETAILED STEPS
This is an example of configuring the Dot1q Transparency feature.
platform vfi dot1q-transparency
!
l2 vfi customer-A manual
vpn id 200
neighbor 1.0.10.1 encapsulation mpls
neighbor 1.0.11.1 encapsulation mpls
neighbor 1.0.111.1 encapsulation mpls
!
class-map match-all any
match any
!
policy-map mpls-set-exp-1
class any
set mpls experimental imposition 1
!
interface Vlan200
no ip address
xconnect vfi customer-A
service-policy input mpls-set-exp-1
Use the show cwan vfi dot1q-transparent command to verify the VLAN is in the up state.
Router# show cwan vfi dot1q-transparency
VFI dot1q transparency is enabled
Router#
Feedback