Table Of Contents

Configuring L2 Virtual Private Networks

Feature History for L2VPN

Supported L2VPN Transport Types

Prerequisites for L2VPN: AToM

Supported Line Cards

Restrictions for L2VPN

Standards and RFCs

MIBs

NSF and SSO—L2VPN

Checkpointing AToM Information

Checkpointing Troubleshooting Tips

Prerequisites for NSF/SSO - L2VPN

Neighbor Routers in the MPLS HA Environment

Stateful Switchover

Nonstop Forwarding for Routing Protocols

Restrictions for NSF/SSO - L2VPN

Configuring NSF/SSO - L2VPN

Configuration Examples of NSF/SSO—Layer 2 VPN

L2VPN Local Switching—HDLC/PPP

Prerequisites of L2VPN Local Switching—HDLC/PPP

Restrictions of L2VPN Local Switching—HDLC/PPP

PPP Like-to-Like Local Switching

HDLC Like-to-Like Local Switching

Configuration Tasks and Examples

Configuration Tasks for L2VPN

Setting Up the Pseudowire—AToM Circuit

Configuring ATM AAL5 SDU Support over MPLS

Verifying ATM AAL5 SDU Support over MPLS

Configuring ATM-to-ATM PVC Local Switching

Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS

Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS on PVCs

Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS in VC Class Configuration Mode

Configuring Ethernet over MPLS

Ethernet over MPLS Restrictions

Configuring Ethernet over MPLS in VLAN Mode

Configuring Ethernet over MPLS in Port Mode

IEEE 802.1Q Tunneling for AToM—QinQ

Prerequisites for IEEE 802.1Q Tunneling (QinQ) for AToM

Restrictions for IEEE 802.1Q Tunneling (QinQ) for AToM

Ethernet VLAN Q-in-Q AToM

Configuration Examples

Verifying QinQ AToM

Remote Ethernet Port Shutdown

Restrictions for Configuring Remote Ethernet Port Shutdown

Configuring Remote Ethernet Port Shutdown

Configuring Ethernet over MPLS with VLAN ID Rewrite

Configuring Frame Relay over MPLS

Configuring Frame Relay over MPLS with DLCI-to-DLCI Connections

Configuring Frame Relay over MPLS with Port-to-Port Connections

Enabling Other PE Devices to Transport Frame Relay Packets

Configuring Frame Relay-to-Frame Relay Local Switching

Configuring Frame Relay for Local Switching

Configuring Frame Relay Same-Port Switching

Verifying Layer 2 Local Switching for Frame Relay

Configuring QoS Features

Configuring HDLC and PPP over MPLS

Restrictions for HDLC over MPLS

Restrictions for PPP over MPLS

Configuring HDLC over MPLS or PPP over MPLS

Estimating the Size of Packets Traveling Through the Core Network

Estimating Packet Size—Example

Changing the MTU Size on P and PE Routers

Setting Experimental Bits with AToM

Configuring QoS Features

Monitoring and Maintaining L2VPN

Configuration Example—Frame Relay over MPLS

Any Transport over MPLS—Tunnel Selection

Configuration Example—Any Transport over MPLS: Tunnel Selection

Configuring L2 Virtual Private Networks

---

To improve profitability, service providers (SPs) introduce new services to reduce operational expenditures. To reduce the number of managed networks, use network convergence, a multiphase transition of the network. This affects both the core and edge/aggregation side. The technology is predominantly Multiprotocol Label Switching (MPLS) based core networks. However, IP cores are the service of choice in a number of large SPs. Both the IP and the MPLS cores carry multiservice traffic. The edges of the network is constructed with network elements providing a single network element for convergence between Layer 2 and Layer 3 services.

The following Layer 2 virtual private network (L2VPN) solutions enable existing or emerging Layer 2 transport technology to interwork through converged MPLS or IP core networks.

•Virtual Private Wire Services (VPWS)—A point-to-point service consisting of individual point-to-point connections cross-connected to native interfaces.

•Virtual Private LAN Services (VPLS)—A service consisting of a set of point-to-multipoint connections.

L2VPN features are of the VPWS type and are designed for the benefit of the carriers. L2VPN features allow for a transparent use of network resources, and a way of reducing the number of networks that need managing.

Cisco nonstop forwarding (NSF) with stateful switchover (SSO) is effective at increasing availability of network services. Cisco NSF with SSO provides continuous packet forwarding, even during a network processor hardware or software failure. In a redundant system, the secondary processor recovers control plane service during a critical failure in the primary processor. SSO synchronizes network state information between the primary and the secondary processor."

Any Transport over MPLS (AToM) uses NSF, SSO, and Graceful Restart to allow a route processor (RP) to recover from a disruption in control plane service without losing the MPLS forwarding state. In Cisco IOS Release 12.2(33) SB, the L2VPN features support NSF/SSO. See the "NSF and SSO—L2VPN" section.

Cisco 10000 series routers also support the following two L2VPN technology solutions:

•Local Switching (LS)—The ordered duple <AC, AC>. This is the point-to-point interconnection of two attachment circuits within a Cisco 10000 series router chassis. Also, two attachment circuits (ACs) can be of:

–The same type—Creating a like-to-like LS connection.

–A distinct type—Creating an any-to-any LS connection.

•AToM—The ordered triple <AC, PW, AC>. This is the point-to-point interconnection of two attachment circuits in separate Cisco 10000 series router chassis through a pseudowire (MPLS). Also, two ACs can be of the same type in which case a like-to-like AToM connection exists. Or, two ACs can be of a distinct type, in which case an any-to-any AToM connection exists.

Using the Label Distribution Protocol (LDP), an AToM circuit session is identified by a unique VC (virtual circuit) between two PE routers. When a Layer 2 frame is received by the imposition PE router, it is encapsulated in an MPLS packet with a VC label, IGP label, and possibly other labels. When the MPLS packet reaches the disposition PE router, the packet is converted back into its Layer 2 encapsulation.

AToM encapsulates Layer 2 frames at the ingress (or imposition) provider edge (PE) router, and sends them to a corresponding PE router at the other end of the connection. The corresponding router is the egress (or disposition) PE router, and it 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. An AToM circuit is one type of pseudowire connection.

Benefits of Enabling Layer 2 Packets to Send in an MPLS Network

Some of the benefits of enabling Layer 2 packets to be sent in the MPLS network include:

•The AToM product set accommodates many types of Layer 2 packets, including Ethernet and Frame Relay, across multiple Cisco router platforms. 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 "Standards and RFCs" 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.

A control word (also referred to as a shim header) can be added at the imposition router and, if so, this control word is removed at the disposition router.

Cisco 10000 series router supports up to 8000 attachment circuits (ACs). An AToM circuit use one AC and a LS circuit use two ACs. Therefore, Cisco 10000 series router supports 8000 AToM connections or 4000 LS connections or any combination of both AToM and LS connections that sums up to 8000 ACs. Also, Tunnel selection allows you to specify the path that AToM traffic uses. See the "Any Transport over MPLS—Tunnel Selection" section.

This chapter contains the following topics:

•Feature History for L2VPN

•Supported L2VPN Transport Types

•Prerequisites for L2VPN: AToM

•Restrictions for L2VPN

•Standards and RFCs

•MIBs

•NSF and SSO—L2VPN

•L2VPN Local Switching—HDLC/PPP

•Configuration Tasks for L2VPN

•Monitoring and Maintaining L2VPN

•Configuration Example—Frame Relay over MPLS

•Any Transport over MPLS—Tunnel Selection

Feature History for L2VPN

Cisco IOS Release	Description	Required PRE
12.2(28)SB	This feature was introduced on the Cisco 10000 series router.	PRE2
12.2(31)SB2	Support was added for the PRE3.	PRE3
12.2(31)SB2	Ethernet to VLAN over AToM (Bridged) functionality was added.	PRE2/PRE3
12.2(33)SB	The following L2VPN features were added on the Cisco 10000 series router: •IEEE 802.1Q Tunneling (QinQ) for AToM •NSF/SSO - Any Transport over MPLS (AToM) •Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown •Any Transport over MPLS: Tunnel Selection •L2VPN Local Switching - HDLC/PPP •Ethernet/VLAN to ATM AAL5 Interworking •Ethernet VLAN to Frame Relay Interworking	PRE2/PRE3/PRE4

Supported L2VPN Transport Types

In Cisco IOS Release 12.2(28)SB, the Cisco 10000 series router supports the following AToM transport types:

•ATM AAL5 SDU support over MPLS

•Ethernet over MPLS

–VLAN mode

–Port mode

•Frame Relay over MPLS

–DLCI-to-DLCI connections

–Port-to-port connections

•HDLC over MPLS

•PPP over MPLS

---

Note Functionally, both HDLC over MPLS and Frame Relay port-to-port connections are the same.

---

Prerequisites for L2VPN: AToM

Before configuring L2VPN, ensure that the network is configured as follows:

•Configure IP routing in the core so that the PE routers can reach each other using IP.

•Configure the label distribution protocol to be Label Distribution Protocol (LDP).

•Configure label-switched paths (LSPs) between the PE routers. To enable dynamic MPLS labeling on all paths between the imposition and disposition PE routers, use the mpls ip command.

•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 AToM is directly mapped to a TE tunnel.

---

Note For L2VPN: LS, it is not necessary to configure:

—The label distribution protocol to be Label Distribution Protocol (LDP).

—Label-switched paths (LSPs) between the PE routers using the mpls ip command.

---

Supported Line Cards

Table 20-1 lists line cards supported by the Cisco 10000 series router.

Table 20-1 Cisco 10000 Series Line Cards that Support L2VPN

Transport Type	Supported Line Cards
ATM AAL5 SDU support over MPLS	4-port OC-3/STM-1 ATM 8-port E3/DS3 ATM 1-port OC-12 ATM
Ethernet over MPLS: VLAN mode Port mode	8-port Fast Ethernet Half-Height 1-port Gigabit Ethernet Half-Height 1-port Gigabit Ethernet SIP-600 SPA-1X10GE-L-V2 (10GE) SPA-2X1GE-V2 (2 port GE) SPA-5X1GE-V2 (5 port GE)
Frame Relay over MPLS: DLCI-to-DLCI connections Port-to-port connections HDLC over MPLS PPP over MPLS	24-port Channelized E1/T1 1-port Channelized OC-12/STM-4 4-port Channelized OC-3/STM-1 4-port Channelized T3 6-port Channelized T3 8-port Unchannelized E3/T3 6-port OC-3/STM1 Packet over SONET 1-port OC-12 Packet over SONET 1-port OC-48/STM-16 Packet over SONET

Restrictions for L2VPN

The L2VPN feature has the following restrictions:

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

•The size of maximum transmission unit (MTU) must be the same at both ends of the circuit. To avoid fragmentation of the packets along the way, ensure that the size of MTU at both end of the circuit is smaller than the size of MTU in the core.

•The following L2VPN features are not supported:

–ATM cell switching of any kind

–ATM AAL5 PDU mode

–Fragmentation and reassembly, as defined in "PWE3 Fragmentation and Reassembly," draft-ietf-pwe3-fragmentation-05.txt, February 2004

–Sequence number support in the control word

–Tunnel stitching

–Pseudowire termination

Standards and RFCs

L2VPN conforms to the industry standards and RFCs listed in Table 20-2.

Table 20-2 Standards and RFCs Supported by L2VPN

Standard or RFC	Title
draft-martini-l2circuit-trans-mpls-08.txt	Transport of Layer 2 Frames over MPLS
draft-martini-l2circuit-encap-mpls-04.txt	Encapsulation Methods for Transport of Layer 2 Frames over MPLS
RFC 3032	MPLS Label Stack Encoding
RFC 3036	LDP Specification

MIBs

Table 20-3 lists the MIBs that L2VPN supports.

Table 20-3 MIBs Supported by L2VPN 

Transport Type	MIB
ATM AAL5 SDU support over MPLS	MPLS LDP MIB (MPLS-LDP-MIB.my) ATM MIB (ATM-MIB.my) CISCO AAL5 MIB (CISCO-AAL5-MIB.my) Cisco Enterprise ATM Extension MIB (CISCO-ATM-EXT-MIB.my) Supplemental ATM Management Objects (CISCO-IETF-ATM2-PVCTRAP-MIB.my) Interfaces MIB (IF-MIB.my)
Ethernet over MPLS: VLAN mode Port mode	CISCO-ETHERLIKE-CAPABILITIES.my Ethernet MIB (ETHERLIKE-MIB.my) Interfaces MIB (IF-MIB.my) MPLS LDP MIB (MPLS-LDP-MIB.my)
Frame Relay over MPLS: DLCI-to-DLCI connections Port-to-port connections	Cisco Frame Relay MIB (CISCO-FRAME-RELAY-MIB.my) Interfaces MIB (IF-MIB.my) MPLS LDP MIB (MPLS-LDP-MIB.my)
HDLC over MPLS PPP over MPLS	MPLS LDP MIB (MPLS-LDP-MIB.my) Interface MIB (IF-MIB.my)

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator at:

http://tools.cisco.com/go/mibs

NSF and SSO—L2VPN

L2VPN NSF improves the availability of a service provider's network that uses AToM to provide Layer 2 VPN services to its customers. High availability (HA) provides the ability to detect failures and manage them with minimal disruption to the service being provided. L2VPN NSF is achieved by SSO and NSF mechanisms. A standby RP provides control-plane redundancy. The control plane state and data plane provisioning information for the attachment circuits (ACs) and AToM pseudowires (PWs) are checkpointed to the standby RP to provide NSF for AToM L2VPNs.

Checkpointing AToM Information

Checkpointing is a function that copies state information from the active RP to the backup RP, thereby ensuring that the backup RP has the latest information. If the active RP fails, the backup RP can take over.

For the L2VPN NSF feature, the checkpointing function copies the active RP's information bindings to the backup RP. The active RP sends updates to the backup RP when information is modified.

To display checkpointing data, issue the show acircuit checkpoint command on the active and backup RPs. The active and backup RPs have identical copies of the information.

Checkpointing Troubleshooting Tips

To help troubleshoot checkpointing errors, enter the following commands:

•debug acircuit checkpoint command—To enable checkpointing debug messages for ACs.

•debug mpls l2transport checkpoint command—To enable checkpointing debug messages for AToM.

•show acircuit checkpoint command—To display the AC checkpoint information.

•show mpls l2transport checkpoint command—To display if checkpointing is allowed, the quantity of AToM VCs that were bulk-synced (on the active RP), and the quantity of AToM VCs that have checkpoint data (on the standby RP).

•show mpls l2transport vc detail command—To display details of VC checkpointed information.

The NSF/SSO - L2VPN feature is described in the following topics:

•Prerequisites for NSF/SSO - L2VPN

•Restrictions for NSF/SSO - L2VPN

•Configuring NSF/SSO - L2VPN

•Configuration Examples of NSF/SSO—Layer 2 VPN

Prerequisites for NSF/SSO - L2VPN

This section lists the following prerequisites for the feature:

•Neighbor Routers in the MPLS HA Environment

•Stateful Switchover

•Nonstop Forwarding for Routing Protocols

Neighbor Routers in the MPLS HA Environment

Cisco 10000 routers must be used as the neighboring device.

Stateful Switchover

For information on this topic, see the Stateful Switchover section in the NSF/SSO: Any Transport over MPLS and Graceful Restart document at:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsatomha.html#wp1098167

Nonstop Forwarding for Routing Protocols

For information on this topic, see the Nonstop Forwarding for Routing Protocols section in the NSF/SSO: Any Transport over MPLS and Graceful Restart document at:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsatomha.html#wp1098561

Restrictions for NSF/SSO - L2VPN

For information on this topic, see the Restrictions for AToM NSF section in the NSF/SSO: Any Transport over MPLS and Graceful Restart document at:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsatomha.html#wp1068923

Configuring NSF/SSO - L2VPN

For information on this topic, see the How to Configure AToM NSF section in the NSF/SSO: Any Transport over MPLS and Graceful Restart document at:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsatomha.html#wp1112888

Configuration Examples of NSF/SSO—Layer 2 VPN

Example 20-1 illustrates how to configure AToM NSF on two PE routers:

Example 20-1 Ethernet to VLAN Interworking with AToM NSF

PE1

PE2

ip cef ! redundancy mode sso ! mpls ldp graceful-restart mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 force mpls ldp advertise-tags ! pseudowire-class atom-eth encapsulation mpls interworking ethernet ! interface Loopback0 ip address 10.8.8.8 255.255.255.255 ! interface FastEthernet1/1/0 xconnect 10.9.9.9 123 encap mpls pw-class atom_eth interface POS6/1/0 ip address 10.1.1.1 255.255.255.0 mpls ip mpls label protocol ldp clock source internal crc 32 ! interface Loopback0 ip address 10.8.8.8 255.255.255.255 no shutdown ! router ospf 10 nsf ietf network 10.8.8.8 0.0.0.0 area 0 network 19.1.1.1 0.0.0.0 area 0

ip cef ! redundancy mode sso ! mpls ldp graceful-restart mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 force mpls ldp advertise-tags ! pseudowire-class atom-eth encapsulation mpls interworking eth ! interface Loopback0 ip address 10.9.9.9 255.255.255.255 ! interface FastEthernet3/0/0 ip route-cache cef ! interface FastEthernet3/0/0.3 encapsulation dot1Q 10 xconnect 10.8.8.8 123 encap mpls pw-class atom_eth interface POS1/0/0 ip address 10.1.1.2 255.255.255.0 mpls ip mpls label protocol ldp clock source internal crc 32 ! interface Loopback0 ip address 10.9.9.9 255.255.255.255 ! router ospf 10 nsf ietf network 10.9.9.9 0.0.0.0 area 0 network 10.1.1.2 0.0.0.0 area 0

---

Note NSF must be enabled for routing protocols. You can use either the cisco or ietf option. Example 20-1 has the ietf option because it is a standard option, whereas cisco is proprietary option.

---

L2VPN Local Switching—HDLC/PPP

The L2VPN Local Switching - HDLC/PPP feature enables service providers to support different encapsulations over HDLC local switched circuits that function as back-to-back circuits. The provisioned HDLC Local Switched circuits can also be backed by using PWRED.

Prerequisites of L2VPN Local Switching—HDLC/PPP

In Cisco IOS Release 12.2(33)SB, the L2VPN Local Switching - HDLC/PPP, you must ensure that interfaces must be HDLC encapsulated on the PE router. The CE routers can choose any HDLC-based encapsulation, including Frame Relay and PPP.

Restrictions of L2VPN Local Switching—HDLC/PPP

In Cisco IOS Release 12.2(33)SB, the L2VPN Local Switching - HDLC/PPP feature has the following restrictions:

•On the PE HDLC interface, the IP address cannot be configured because it conflicts with the connect command.

•Interworking is not supported on HDLC/PPP interfaces.

•Only same-speed interfaces should be connected, to avoid arbitrary packet drops due to a higher speed interface overrunning a lower speed one.

•For some HDLC/PPP applications which are sensitive to time delay, the PE may introduce some network delay, enough to prevent the HDLC/PPP link from coming up because of a protocol timeout (an ISDN Q921 link).

PPP Like-to-Like Local Switching

Some applications, such as transport of compressed voice between the two CEs, require a setup of an end-to-end PPP session between two CE routers that are connected to the same PE router. In such cases, HDLC pass-through mechanism is proposed and the interworking scenario is simplified to PPP transport for like-to-like services. PPP local switching functionality on the PE router provides simple HDLC connectivity between two end-users found on different CE routers as shown in Figure 20-1.

Figure 20-1 PPP Local Switching

The interfaces are HDLC encapsulated on the PE router. The CE routers may use PPP-based encapsulation.

Frames manipulated by the PE router preserve the PPP header as described in RFC-1661.

HDLC Like-to-Like Local Switching

Like PPP, HDLC sessions can be forwarded between two CE routers connected to the same PE router. The microcode implements a HDLC pass-through mechanism for the HDLC traffic. As the service provided is equivalent to a back-to-back serial connection between the two CE routers, the connection should be between same-speed interfaces with the matched Maximum Transmission Unit (MTU) configuration. There are no QoS requirements on the PE router since one interface cannot overrun another.

The interfaces are HDLC encapsulated on the PE router. CE routers may use any HDLC-based encapsulation, including Frame Relay.

Configuration Tasks and Examples

You can configure the L2VPN Local Switching - HDLC/PPP feature on a PE router using the following steps:

1. config t

2. interface serial slot/subslot/port:channel-id

3. encapsulation hdlc

4. interface serial slot/subslot/port:channel-id

5. encapsulation hdlc

6. connect connection-name interface interface

The following example shows you how to configure the L2VPN Local Switching - HDLC/PPP feature on the PE router:

config t

interface serial 3/0/20:0

 encapsulation hdlc

interface serial 4/0/11:9

 encapsulation hdlc

 connect hdlcls serial3/0/20:0 serial4/0/11:9

---

Note Because the default encapsulation of a serial interface is HDLC, the encapsulation command is optional. However, when you configure the CE router, you must specify the encapsulation command because of the difference in configuration.

---

You can configure PPP on the CE router using the following steps:

1. config t

2. interface serial slot/subslot/port:channel-id

3. encapsulation ppp

You can configure HDLC on the CE router using the following steps:

1. config t

2. interface serial slot/subslot/port:channel-id

3. encapsulation hdlc

Configuration Tasks for L2VPN

To configure L2VPN, you have to configure the following L2VPN features:

•Setting Up the Pseudowire—AToM Circuit

•Configuring ATM AAL5 SDU Support over MPLS

•Configuring ATM-to-ATM PVC Local Switching

•Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS

•Configuring Ethernet over MPLS

•IEEE 802.1Q Tunneling for AToM—QinQ

•Remote Ethernet Port Shutdown

•Configuring Frame Relay over MPLS

•Configuring Frame Relay-to-Frame Relay Local Switching

•Configuring HDLC and PPP over MPLS

•Estimating the Size of Packets Traveling Through the Core Network

•Setting Experimental Bits with AToM

•Configuring QoS Features

Setting Up the Pseudowire—AToM Circuit

The successful transmission of the Layer 2 frames between PE routers is due to the configuration of a connection called a pseudowire between the routers. You specify the following information on each PE router:

•The type of Layer 2 data to 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 unique combination of peer PE IP address and VC ID that identifies the pseudowire

To set up a pseudowire connection or AToM circuit between two PE routers, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# pseudowire-class name	(Optional) Establishes a pseudowire class with a name that you specify and specifies the tunneling encapsulation. It is not necessary to specify a pseudowire class if you specify the tunneling method as part of the xconnect command. The pseudowire-class configuration group specifies the characteristics of the tunneling mechanism, including: •Encapsulation type •Control protocol •Payload-specific options
Step 2	Router(config)# interface interface-type interface-number	Defines the interface or subinterface on the PE router.
Step 3	Router(config-if)# encapsulation encapsulation-type	Specifies the encapsulation type for the interface, such as dot1q.
Step 4	Router(config-if)# xconnect peer-router-id vcid encapsulation mpls	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. Note 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.

Example 20-2 shows a sample configuration for the ATM AAL5 SDU over MPLS transport. The PVC on 0/100 is configured for AAL5 transport.

Example 20-2 ATM AAL5 SDU Support over MPLS

interface ATM4/0

    pvc 0/100 l2transport

        encapsulation aal5

        xconnect 13.13.13.13 100 encapsulation mpls

Configuring ATM AAL5 SDU Support over MPLS

ATM AAL5 SDU support over MPLS encapsulates ATM AAL5 service data units (SDUs) in MPLS packets and forwards them across the MPLS network. Each ATM AAL5 SDU is transported as one packet.

To configure ATM AAL5 SDU support over MPLS, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface type slot/port	Specifies the interface by type, slot, and port number, and enters interface configuration mode.
Step 2	Router(config-if)# pvc [name] vpi/vci l2transport	Creates or assigns a name to an ATM PVC. The l2transport keyword indicates that the PVC is a switched PVC instead of a terminated PVC. Enters L2transport VC configuration mode.
Step 3	Router(config-if-atm-l2trans-pvc)# encapsulation aal5	Specifies ATM AAL5 encapsulation for the PVC. Make sure you specify the same encapsulation type on the PE and CE routers.
Step 4	Router(config-if-atm-l2trans-pvc)# xconnect peer-router-id vcid encapsulation mpls	Binds the attachment circuit to a pseudowire VC.

Example 20-3 shows how to enable ATM AAL5 SDU support over MPLS on an ATM PVC.

Example 20-3 ATM AAL5 SDU Support over MPLS on an ATM PVC

interface atm1/0

pvc 1/200 l2transport

encapsulation aal5

xconnect 13.13.13.13 100 encapsulation mpls

Verifying ATM AAL5 SDU Support over MPLS

To verify that ATM AAL5 SDU support over MPLS is configured on a PVC, issue the show mpls l2transport vc command. Example 20-4 shows sample output for this command.

Example 20-4 show mpls l2transport vc Command Output

Router# show mpls l2transport vc

Local intf   Local circuit          Dest address      VC ID      Status

---------    -------------          ------------      -----      ------

ATM1/0       ATM AAL5 1/100         4.4.4.4           100        UP

Configuring ATM-to-ATM PVC Local Switching

The following ATM line cards are supported for Cisco 10000 series routers:

•4-port OC-3/STM-1

•8-port E3/DS3

•1-port OC-12

To configure ATM-to-ATM PVC local switching, enter the following commands, beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface atm slot/port	Specifies an ATM interface and enters interface configuration mode.
Step 2	Router(config-if)# pvc vpi/vci l2transport	Assigns a virtual path identifier (VPI) and virtual channel identifier (VCI). The l2transport keyword indicates that the permanent virtual circuit (PVC) is a switched PVC instead of a terminated PVC.
Step 3	Router(cfg-if-atm-l2trans-pvc)# encapsulation layer-type	Specifies the encapsulation type for the PVCs, AAL5 is the only layer type supported. Repeat Steps 1, 2, and 3 for another ATM PVC on the same router.
Step 4	Router(config)# connect connection-name interface pvc interface pvc	Creates a local connection between the two specified PVCs.

Example 20-5 shows how to enable ATM AAL5 SDU mode Layer 2 local switching.

Example 20-5 Enabling ATM AAL5 SDU Mode Layer 2 Local Switching

interface atm 1/0/0

   pvc 0/100 l2transport

     encapsulation aal5

interface atm 2/0/0

   pvc 0/50 l2transport

     encapsulation aal5

connect conn1 atm 1/0/0 0/100 atm 2/0/0 0/50

Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS

If a PE router does not support the transport of Operation, Administration, and Maintenance (OAM) cells across an LSP, you can use OAM cell emulation to locally terminate or loop back the OAM cells. You configure OAM cell emulation on both PE routers, which emulates a VC by forming two unidirectional LSPs. You use the oam-ac emulation-enable and oam-pvc manage commands on both PE routers to enable OAM cell emulation.

After you enable OAM cell emulation on a router, you can configure and manage the ATM VC in the same manner as you would a terminated VC. A VC that is configured with OAM cell emulation can send loopback cells at configured intervals toward the local CE router.

The endpoint can be either of the following:

•End-to-end loopback, which sends OAM cells to the local CE router.

•Segment loopback, which responds to OAM cells to a device along the path between the PE and CE routers.

The OAM cells include the following:

•Alarm indication signal (AIS)

•Remote defect indication (RDI)

These cells identify and report defects along a VC. When a physical link or interface failure occurs, intermediate nodes insert OAM AIS cells into all the downstream devices affected by the failure. When a router receives an AIS cell, it marks the ATM VC down and sends an RDI cell to let the remote end know about the failure.

---

Note For AAL5 SDU support over MPLS, you can configure the oam-pvc manage command only after you issue the oam-ac emulation-enable command.

---

You can configure OAM cell emulation for ATM AAL5 SDU support over MPLS in the following ways:

•Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS on PVCs

•Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS in VC Class Configuration Mode

Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS on PVCs

To configure OAM cell emulation for ATM AAL5 SDU support over MPLS on a PVC, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface type slot/port	Specifies the interface by type, slot, and port number, and enters interface configuration mode.
Step 2	Router(config-if)# pvc [name] vpi/vci l2transport	Creates or assigns a name to an ATM PVC. The l2transport keyword indicates that the PVC is a switched PVC instead of a terminated PVC. Enters L2 Transport VC configuration mode.
Step 3	Router(config-if-atm-l2trans-pvc)# encapsulation aal5	Specifies ATM AAL5 encapsulation for the PVC. Make sure you specify the same encapsulation type on the PE and CE routers.
Step 4	Router(config-if-atm-l2trans-pvc)# xconnect peer-router-id vcid encapsulation mpls	Binds the attachment circuit to a pseudowire VC.
Step 5	Router(config-if-atm-l2trans-pvc)# oam-ac emulation-enable [ais-rate]	Enables OAM cell emulation for AAL5 over MPLS. The ais-rate variable lets you specify the rate at which AIS cells are sent. The range is 0 to 60 seconds. The default is 1 second, which means that one AIS cell is sent every second.
Step 6	Router(config-if-atm-l2trans-pvc)# oam-pvc manage [frequency]	Enables the PVC to generate end-to-end OAM loopback cells that verify connectivity on the virtual circuit. The optional frequency variable is the interval between transmission of loopback cells and ranges from 0 to 600 seconds. The default value is 10 seconds.

Example 20-6 shows how to enable OAM cell emulation on an ATM PVC.

Example 20-6 OAM Cell Emulation on an ATM PVC

interface ATM 1/0/0

pvc 1/200 l2transport

encapsulation aal5

xconnect 13.13.13.13 100 encapsulation mpls 

oam-ac emulation-enable

oam-pvc manage

Example 20-7 shows how to set the rate at which an AIS cell is sent to every 30 seconds.

Example 20-7 Setting the AIS Send Rate in OAM Cell Emulation on an ATM PVC

interface ATM 1/0/0

pvc 1/200 l2transport

encapsulation aal5

xconnect 13.13.13.13 100 encapsulation mpls 

oam-ac emulation-enable 30

oam-pvc manage

Verifying OAM Cell Emulation on an ATM PVC

In Example 20-8, the show atm pvc command shows that OAM cell emulation is enabled on the ATM PVC.

Example 20-8 show atm pvc Command Output

Router# show atm pvc 5/500

ATM4/1/0.200: VCD: 6, VPI: 5, VCI: 500                    

UBR, PeakRate: 1                                         

AAL5-LLC/SNAP, etype:0x0, Flags: 0x34000C20, VCmode: 0x0 

OAM Cell Emulation: enabled, F5 End2end AIS Xmit frequency: 1 second(s) 

OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)

OAM up retry count: 3, OAM down retry count: 5

OAM Loopback status: OAM Disabled

OAM VC state: Not ManagedVerified

ILMI VC state: Not Managed

InPkts: 564, OutPkts: 560, InBytes: 19792, OutBytes: 19680

InPRoc: 0, OutPRoc: 0

InFast: 4, OutFast: 0, InAS: 560, OutAS: 560

InPktDrops: 0, OutPktDrops: 0

CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0

Out CLP=1 Pkts: 0

OAM cells received: 26

F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 26

OAM cells sent: 77

F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutAIS: 77, F5 OutRDI: 0 

OAM cell drops: 0

Status: UP

Configuring OAM Cell Emulation for ATM AAL5 SDU Support over MPLS in VC Class Configuration Mode

The following steps explain how to configure OAM cell emulation as part of a VC class. You can then apply the VC class to an interface, a subinterface, or a VC. When you configure OAM cell emulation in VC class configuration mode and then apply the VC class to an interface, the settings in the VC class apply to all the VCs on the interface, unless you specify a different OAM cell emulation value at a lower level, such as the subinterface or VC level.

For example, you can create a VC class that specifies OAM cell emulation and sets the rate of AIS cells to every 30 seconds. You can apply the VC class to an interface. Then, for one PVC, you can enable OAM cell emulation and set the rate of AIS cells to every 15 seconds. All the PVCs on the interface use the cell rate of 30 seconds, except for the one PVC that was set to 15 seconds.

To enable OAM cell emulation as part of a VC class and apply it to an interface, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# vc-class atm name	Creates a VC class and enters VC class configuration mode.
Step 2	Router(config-vc-class)# encapsulation layer-type	Configures the ATM adaptation layer (AAL) and encapsulation type.
Step 3	Router(config-vc-class)# oam-ac emulation-enable [ais-rate]	Enables OAM cell emulation for AAL5 over MPLS. The ais-rate variable lets you specify the rate at which AIS cells are sent. The range is 0 to 60 seconds. The default is 1 second, which means that one AIS cell is sent every second.
Step 4	Router(config-vc-class)# oam-pvc manage [frequency]	Enables the PVC to generate end-to-end OAM loopback cells that verify connectivity on the virtual circuit. The optional frequency variable is the interval between transmission of loopback cells and ranges from 0 to 600 seconds. The default value is 10 seconds.
Step 5	Router(config-vc-class)# exit	Returns to global configuration mode.
Step 6	Router(config)# interface type slot/port	Specifies the interface by type, slot, and port number, and enters interface configuration mode.
Step 7	Router(config-if)# class-int vc-class-name	Applies a VC class to the ATM main interface or subinterface. Note You can also apply a VC class to a PVC.
Step 8	Router(config-if)# pvc [name] vpi/vci l2transport	Creates or assigns a name to an ATM PVC. The l2transport keyword indicates that the PVC is a switched PVC instead of a terminated PVC. Enters L2 Transport VC configuration mode.
Step 9	Router(config-if-atm-l2trans-pvc)# xconnect peer-router-id vcid encapsulation mpls	Binds the attachment circuit to a pseudowire VC.

Example 20-9 configures OAM cell emulation for ATM AAL5 SDU support over MPLS in VC class configuration mode. The VC class is then applied to an interface.

Example 20-9 OAM Cell Emulation for ATM AAL5 SDU Support over MPLS in VC Class Configuration Mode—VC Class Applied to an Interface

vc-class atm oamclass

encapsulation aal5

oam-ac emulation-enable 30

oam-pvc manage

interface atm1/0

class-int oamclass

pvc 1/200 l2transport

xconnect 13.13.13.13 100 encapsulation mpls

Example 20-10 shows how to configure OAM cell emulation for ATM AAL5 over MPLS in VC class configuration mode. The VC class is then applied to a PVC.

Example 20-10 OAM Cell Emulation for ATM AAL5 SDU Support over MPLS in VC Class Configuration Mode—VC Class Applied to a PVC

vc-class atm oamclass

encapsulation aal5

oam-ac emulation-enable 30

oam-pvc manage

interface atm1/0

pvc 1/200 l2transport

class-vc oamclass

xconnect 13.13.13.13 100 encapsulation mpls

Example 20-11 shows how to configure OAM cell emulation for ATM AAL5 over MPLS in VC class configuration mode. The VC class is then applied to an interface. One PVC is configured with OAM cell emulation at an AIS rate of 10. That PVC uses the AIS rate of 10 instead of 30.

Example 20-11 OAM Cell Emulation for ATM AAL5 SDU Support over MPLS in VC Class Configuration Mode—VC Class Applied to an Interface

vc-class atm oamclass

encapsulation aal5

oam-ac emulation-enable 30

oam-pvc manage

interface atm1/0

class-int oamclass

pvc 1/200 l2transport

oam-ac emulation-enable 10

xconnect 13.13.13.13 100 encapsulation mpls

Configuring Ethernet over MPLS

Ethernet over MPLS works by encapsulating Ethernet protocol data units (PDUs) in MPLS packets and forwarding them across the MPLS network. Each PDU is transported as a single packet. Several methods exists for configuring Ethernet over MPLS:

•VLAN mode—Transports Ethernet traffic from a source 802.1Q VLAN to a destination 802.1Q VLAN over a core MPLS network.

•Port mode—Allows a frame coming into an interface to be packed into an MPLS packet and transported over the MPLS backbone to an egress interface. The entire Ethernet frame is transported without the preamble or FCS as a single packet.

•VLAN ID Rewrite—Enables you to use VLAN interfaces with different VLAN IDs at both ends of the tunnel.

You can configure Ethernet over MPLS in the following ways:

•Configuring Ethernet over MPLS in VLAN Mode

•Configuring Ethernet over MPLS in Port Mode

•Configuring Ethernet over MPLS with VLAN ID Rewrite

Ethernet over MPLS Restrictions

The following restrictions pertain to the Ethernet over MPLS transport:

•Packet format: Ethernet over MPLS supports VLAN packets that conform to the IEEE 802.1Q standard. The 802.1Q specification establishes a standard method for inserting VLAN membership information into Ethernet frames. The Inter-Switch Link (ISL) protocol is not supported between the PE and customer edge (CE) routers.

•When the first Ethernet over MPLS in VLAN mode circuit is configured, the controller (the entire port) is automatically placed in promiscuous mode. The promiscuous mode is removed only when the last Ethernet over MPLS in VLAN mode circuit associated with that controller is removed.

•The AToM control word is supported. However, if the peer PE router 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.

Configuring Ethernet over MPLS in VLAN Mode

A virtual LAN (VLAN) is a switched network that is logically segmented by functions, project teams, or applications regardless of the physical location of users. Ethernet over MPLS allows you to connect two VLAN networks that are in different locations. You configure the PE routers at each end of the MPLS backbone and add a point-to-point virtual circuit (VC). Only the two PE routers at the ingress and egress points of the MPLS backbone know about the VCs dedicated to transporting Layer 2 VLAN traffic. All other routers do not have table entries for those VCs.

For Ethernet over MPLS in VLAN mode, it is possible for VPN circuits to coexist with pseudowire circuits. Because the port is in promiscuous mode, the frames are filtered by the VLAN ID.

---

Note You must configure Ethernet over MPLS in VLAN mode on the subinterfaces. However, you cannot configure Ethernet over MPLS (VLAN mode) on a Q-in-Q subinterface.

---

To configure Ethernet over MPLS in VLAN mode, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface gigabitethernet slot/interface.subinterface	Specifies the Gigabit Ethernet subinterface and enters subinterface configuration mode. Make sure the subinterface on the adjoining CE router is on the same VLAN as this PE router.
Step 2	Router(config-subif)# encapsulation dot1q vlan-id	Enables the subinterface to accept 802.1Q VLAN packets. The subinterfaces between the CE and PE routers that are running Ethernet over MPLS must be in the same subnet. All other subinterfaces and backbone routers do not need to be on the same subnet.
Step 3	Router(config-subif)# xconnect peer-router-id vcid encapsulation mpls	Binds the attachment circuit to a pseudowire VC. The syntax for this command is the same as for all other Layer 2 transports.

Configuring Ethernet over MPLS in Port Mode

Port mode allows a frame coming into an interface to be packed into an MPLS packet and transported over the MPLS backbone to an egress interface. The entire Ethernet frame without the preamble or FCS is transported as one packet. To configure port mode, use the xconnect command in main interface mode and specify the destination address and the VC ID. The syntax and semantics of the xconnect command are the same as for all other transport types. Each interface is associated with one unique pseudowire VC label.

When configuring Ethernet over MPLS in port mode, use the following guidelines:

•The pseudowire VC type is set to Ethernet.

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

To configure Ethernet over MPLS in port mode, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface gigabitethernet slot/interface	Specifies the Gigabit Ethernet interface and enters interface configuration mode. Make sure the interface on the adjoining CE router is on the same VLAN as this PE router.
Step 2	Router(config-if)# xconnect peer-router-id vcid encapsulation mpls	Binds the attachment circuit to a pseudowire VC. The syntax for this command is the same as for all other Layer 2 transports.

Example 20-12 shows how to configure VC 123 in Ethernet port mode:

Example 20-12 Ethernet over MPLS in Port Mode

pseudowire-class ethernet-port

  encapsulation mpls

interface gigabitethernet1/0 

  xconnect 10.0.0.1 123 pw-class ethernet-port

---

Note Depending on the interface type, you can also use the interface fastethernet command.

---

Verifying Ethernet over MPLS in VLAN Mode and Port Mode

To determine if a VC is set up in VLAN mode or port mode, issue the show mpls l2transport vc command.

Example 20-13 shows two VCs set up for Ethernet over MPLS:

•VC 2 is set up in Ethernet VLAN mode.

•VC 8 is set up in Ethernet port mode.

Example 20-13 show mpls l2transport vc Command Output

Router# show mpls l2transport vc 

Local intf     Local circuit        Dest address    VC ID      Status    

-------------  -------------------- --------------- ---------- ----------

Gi4/0.1        Eth VLAN 2           11.1.1.1        2          UP        

Gi8/0/1        Ethernet             11.1.1.1        8          UP        

If you issue the show mpls l2transport vc detail command, the output is similar, as shown in Example 20-14.

Example 20-14 show mpls l2transport vc detail Command Output

Router# show mpls l2transport vc detail

Local interface: Gi4/0.1 up, line protocol up, Eth VLAN 2 up

Destination address: 11.1.1.1, VC ID: 2, VC status: up

...

Local interface: Gi8/0/1 up, line protocol up, Ethernet up

  Destination address: 11.1.1.1, VC ID: 8, VC status: up

IEEE 802.1Q Tunneling for AToM—QinQ

The IEEE 802.1Q Tunneling (QinQ) for AToM feature is described in the following topics:

•Prerequisites for IEEE 802.1Q Tunneling (QinQ) for AToM

•Restrictions for IEEE 802.1Q Tunneling (QinQ) for AToM

•Ethernet VLAN Q-in-Q AToM

•Configuration Examples

•Verifying QinQ AToM

Prerequisites for IEEE 802.1Q Tunneling (QinQ) for AToM

In Cisco IOS software Release 12.2(33)SB, the QinQ (short for 802.1Q-in-802.1Q) tunneling and tag rewrite feature is supported on the following Cisco 10000 series engines and line cards:

•PRE-2, PRE-3, and PRE-4 engines

•8-port Fast Ethernet line card (ESR-HH-8FE-TX)

•2-port half-height Gigabit Ethernet line card (ESR-HH-1GE)

•1-port full-height Gigabit Ethernet line card (ESR-1GE)

•SPA line cards

Restrictions for IEEE 802.1Q Tunneling (QinQ) for AToM

In Cisco IOS Release 12.2(33)SB, the QinQ tunneling and tag rewrite feature has the following restrictions:

•Up to a maximum of 447 outer-VLAN IDs and up to 4095 inner VLAN IDs can be supported for the Ethernet QinQ over AToM feature.

•Only Unambiguous VLAN tagged Ethernet QinQ interfaces are supported in this release. i.e. The Ethernet VLAN QinQ rewrite of both VLAN Tags capability is supported only on ethernet sub-interfaces with a QinQ encapsulation and explicit pair of VLAN IDs defined.

Ethernet VLAN Q-in-Q AToM

In Metro Ethernet deployment, in which CE routers and PE routers are connected through an Ethernet switched access network, packets that arrive at PE routers can contain up to two IEEE 802.1q VLAN tags (one inner VLAN tag which identifies the customer; and another outer VLAN tag which denotes the customer's service provider). This technique of allowing multiple VLAN tagging on the same Ethernet packet and creating a stack of VLAN IDs is known as QinQ (short for 802.1Q-in-802.1Q). Figure 20-2 shows how different edge devices can do L2 switching on the different levels of the VLAN stack.

Figure 20-2 Ethernet VLAN QinQ

When the outer VLAN tag is the service-delimiting VLAN tag, QinQ packets are processed similar to the ones with one VLAN tag (case previously named Ethernet VLAN Q-in-Q modified, which is already supported in the 12.2(31) SB release). However, when a customer must use a combination of the outer and inner VLAN tags to delimit service for customers, the edge device should be able to choose a unique pseudowire based on a combination of the inner and outer VLAN IDs on the packet shown in Figure 20-3. The customer may want to be able to rewrite both the inner and the outer VLAN IDs on the traffic egress side.

Figure 20-3 Ethernet VLAN QinQ Header

The IEEE 802.1Q Tunneling (QinQ) for AToM can be further explained as follows:

•QinQ Tunneling Based on Inner and Outer VLAN Tags

•Rewriting Inner and Outer VLAN Tags on QinQ Frames

QinQ Tunneling Based on Inner and Outer VLAN Tags

When handling incoming QinQ Ethernet traffic, the Cisco 10000 series edge router allows a customer to choose a unique pseudowire endpoint to switch the traffic based on the combination of inner and outer VLAN IDs. For example, Figure 20-4 shows how a unique pseudowire is selected depending upon the combination of inner (customer edge) and outer (service provider) VLAN IDs. Thus, traffic for different customers can be kept separate.

Figure 20-4 QinQ Connection

Rewriting Inner and Outer VLAN Tags on QinQ Frames

When managing incoming AToM Ethernet QinQ traffic, the Cisco 10000 edge router:

1. Strips off the MPLS labels.

2. Allows the customer to rewrite both the inner and outer VLAN IDs before sending the packets to the egress QinQ interface. Note this capability is provided only for AToM like-to-like Ethernet QinQ traffic.

Support for these features is added in Cisco IOS Release 12.2(33). The QinQ AToM feature is a like-to-like interworking case over AToM. This feature requires changes to the microcode to allow it to overwrite two layers of VLAN tags on Ethernet QinQ traffic, transported across AToM pseudowires.

•On the ingress side—The packets preserve their L2 header with the two VLAN tags, and it is sent across the pseudowire with VC type of 4.

•On the egress side—The MPLS label is stripped, and up to two levels of VLAN tags are rewritten per the configuration.

Only Unambiguous VLAN tagged Ethernet QinQ interfaces are supported in this release. The Ethernet VLAN Q-in-Q rewrite of both VLAN Tags capability is supported only on Ethernet sub-interfaces with a QinQ encapsulation and explicit pair of VLAN IDs defined.

Configuration Examples

Example 20-15 shows an unambiguous QinQ configured on GigE subinterface.

Example 20-15 Unambiguous QinQ

interface GigabitEthernet1/0/0.100

encapsulation dot1q 100 second-dot1q 200

xconnect 23.0.0.16 410 encapsulation mpls 

Example 20-16 shows an ambiguous QinQ configured on a GigE subinterface.

Example 20-16 Ambiguous QinQ

interface GigabitEthernet1/0/0.200

encapsulation dot1q 200 second-dot1q 1000-2000,3000,3500-4000

xconnect 23.0.0.16 420 encapsulation mpls

interface GigabitEthernet1/0/0.201

encapsulation dot1q 201 second-dot1q any

xconnect 23.0.0.16 430 encapsulation mpls

---

Note Ambiguous inner VLAN IDs are not supported in this release.

---

Verifying QinQ AToM

Example 20-17 shows the command output of the show mpls l2transport vc command, which is used to verify the VC set up in EoMPLS QinQ mode.

Example 20-17 show mpls l2transport vc Command Output

Local intf     Local circuit              Dest address    VC ID      Status    

-------------  -------------------------- --------------- ---------- ----------

Gi1/0/0.1      Eth VLAN:100/200           100.1.1.2       1         UP 

Remote Ethernet Port Shutdown

This Cisco IOS feature allows a service provider edge (PE) router on the local end of an Ethernet over MPLS (EoMPLS) pseudowire to detect a remote link failure and shutdown of the Ethernet port on the local customer edge (CE) router. Because the Ethernet port on the local CE router is shut down, the router does not lose data by continuously sending traffic to the failed remote link. This is beneficial if the link is configured as a static IP route.

Figure 20-5 illustrates a condition in an EoMPLS wide area network (WAN) with a down Layer 2 tunnel link between a CE1 router and the PE1 router. A CE2 router on the far side of the Layer 2 tunnel, continues to forward traffic to CE1 through the L2 tunnel.

Figure 20-5 Remote Link Outage in EoMPLS Wide Area Network

In earlier releases than Cisco IOS Release 12.2(33)SB, the PE2 router did not detect a failed remote link. Traffic forwarded from CE2 to CE1 is lost until routing or spanning tree protocols detected the down remote link. If the link was configured with static routing, remote link outage can be difficult to detect by the L3 routing protocol.

With Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown, the PE2 router detects the remote link failure and causes a shutdown of the local CE2 Ethernet port. When the remote L2 tunnel link is restored, the local interface is automatically restored as well. The possibility of data loss is thus diminished.

With reference to Figure 20-5, a remote Ethernet shutdown sequence occurs as follows:

1. The remote link between CE1 and PE1 fails.

2. PE2 with remote Ethernet port shutdown enabled detects the remote link failure and disables the transmit laser on the line card interface connected to CE2.

3. CE2 receives an RX_LOS error alarm causing CE2 to bring down the interface.

4. PE2 maintains its interface with CE2 in an up state.

5. When the remote link and EoMPLS connection is restored, the PE2 router enables the transmit laser.

6. The CE2 router brings up its downed interface.

Restrictions for Configuring Remote Ethernet Port Shutdown

The following restrictions pertain to the Remote Ethernet Port Shutdown feature:

•For Cisco IOS Release 12.2(33) SB, this feature is implemented for port mode Ethernet over MPLS connections between Cisco 10000 series Ethernet line cards only.

•This feature is not symmetrical if the remote PE router is running an older version of image or is on another platform that does not support the EoMPLS remote Ethernet port shutdown feature and the local PE is running an image which supports this feature.

Configuring Remote Ethernet Port Shutdown

By default, the Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown feature is automatically enabled when an image with this feature supported is loaded on the Cisco 10000 series router. However, to enable the Remote Ethernet Port Shutdown feature, enter the remote link failure notification command, as shown in Example 20-18.

To disable the feature, enter the no remote link failure notification command (Example 20-19).

Example 20-18 Enabling Remote Ethernet Port Shutdown under the Xconnect Configuration

pseudowire-class eompls

 encapsulation mpls

!

interface GigabitEthernet1/0/0

 xconnect 1.1.1.1 1 pw-class eompls

  remote link failure notification

!

Example 20-19 Disabling Remote Ethernet Port Shutdown under the Xconnect Configuration

pseudowire-class eompls

 encapsulation mpls

!

interface GigabitEthernet1/0/0			

 xconnect 1.1.1.1 1 pw-class eompls

  no remote link failure notification

!

To see the operational status of all remote L2 tunnels by interface, enter show interface and show ip interface brief commands, as shown in Example 20-20.

Example 20-20 Operational Status for All Remote L2 Tunnels by Interface

router# show interface GigabitEthernet1/0/0

GigabitEthernet1/0/0 is L2 Tunnel remote down, line protocol is up 

  Hardware is Half-height Gigabit Ethernet MAC Controller, address is 0009.b68f.9b18 (bia 
0009.b68f.9b18)

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

  ......

  ......

router# sh ip interface brief

Interface              IP-Address      OK? Method Status                Protocol

FastEthernet0/0/0      24.3.8.1        YES NVRAM  up                    up      

GigabitEthernet1/0/0   unassigned      YES NVRAM  L2 Tunnel remote down up      

GigabitEthernet2/0/0   30.1.1.1        YES manual up                    up  

Enter show controller and show controller interface commands to see the port transceiver state, as shown in Example 20-21.

Example 20-21 Port Transceiver State

router# show controller GigabitEthernet1/0/0

Interface GigabitEthernet1/0/0(idb 0x4FB5CA7C)

Hardware is Half-height Gigabit Ethernet MAC Controller, network connection mode is auto

  network link is L2 Tunnel remote down

  loopback type is none		

  ......

Configuring Ethernet over MPLS with VLAN ID Rewrite

The VLAN ID Rewrite feature enables you to use VLAN interfaces with different VLAN IDs at both ends of the tunnel. The Cisco 10000 series router automatically performs VLAN ID Rewrite on the disposition PE router. There is no configuration required.

Configuring Frame Relay over MPLS

Frame Relay over MPLS encapsulates Frame Relay protocol data units (PDUs) in MPLS packets and forwards them across the MPLS network. For Frame Relay, you can set up data-link connection identifier (DLCI)-to-DLCI connections or port-to-port connections.

•With DLCI-to-DLCI connections, the PE routers manipulate the packet by removing headers, adding labels, and copying control word elements from the header to the PDU.

•With port-to-port connections, you use HDLC mode to transport the Frame Relay encapsulated packets. In HDLC mode, the entire HDLC packet is transported. Only the HDLC flags and FCS bits are removed. The contents of the packet are not used or changed, including the FECN, BECN, and DE bits.

---

Note Frame Relay traffic shaping is not supported with AToM-switched VCs.

---

You can configure Frame Relay over MPLS in the following ways:

•Configuring Frame Relay over MPLS with DLCI-to-DLCI Connections

•Configuring Frame Relay over MPLS with Port-to-Port Connections

•Enabling Other PE Devices to Transport Frame Relay Packets

Configuring Frame Relay over MPLS with DLCI-to-DLCI Connections

To configure Frame Relay over MPLS with DLCI-to-DLCI connections, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# frame-relay switching	Enables permanent virtual circuit (PVC) switching on a Frame Relay device.
Step 2	Router(config)# interface serial slot/port	Specifies a serial interface and enters interface configuration mode.
Step 3	Router(config-if)# encapsulation frame-relay [cisco | ietf]	Specifies Frame Relay encapsulation for the interface. You can specify different types of encapsulations. You can set one interface to Cisco encapsulation and the other interface to IETF encapsulation.
Step 4	Router(config-if)# frame-relay intf-type dce	Specifies that the interface is a DCE switch. You can also specify the interface to support NNI and DTE connections.
Step 5	Router(config-if)# exit	Exits from interface configuration mode.
Step 6	Router(config)# connect connection-name interface dlci l2transport	Defines connections between Frame Relay PVCs and enters connect submode. Using the l2transport keyword specifies that the PVC will not be a locally switched PVC, but will be tunneled over the backbone network. The connection-name argument is a text string that you provide. The interface argument is the interface on which a PVC connection is defined. The dlci argument is the DLCI number of the PVC that will be connected.
Step 7	Router(config-fr-pw-switching)# xconnect peer-router-id vcid encapsulation mpls	Creates the VC to transport the Layer 2 packets. In a DLCI-to DLCI connection type, Frame Relay over MPLS uses the xconnect command in connect submode.

Example 20-22 shows how to enable Frame Relay over MPLS with DLCI-to-DLCI connections.

Example 20-22 Frame Relay over MPSL with DLCI-to-DLCI Connections

frame-relay switching 

interface Serial3/1 

encapsulation frame-relay ietf 

frame-relay intf-type dce 

exit 

connect fr1 Serial 5/0 1000 l2transport 

xconnect 10.0.0.1 123 encapsulation mpls

Configuring Frame Relay over MPLS with Port-to-Port Connections

When you set up a port-to-port connection between PE routers, you use HDLC mode to transport the Frame Relay encapsulated packets. Perform this task to set up Frame Relay port-to-port connections.

To configure Frame Relay over MPLS with port-to-port connections, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface serial slot/port	Specifies a serial interface and enters interface configuration mode.
Step 2	Router(config-if)# encapsulation hdlc	Specifies that Frame Relay PDUs is encapsulated in HDLC packets.
Step 3	Router(config-if)# xconnect peer-router-id vcid encapsulation mpls	Creates the VC to transport the Layer 2 packets.

Example 20-23 shows how to enable Frame Relay over MPLS with port-to-port connections.

Example 20-23 Frame Relay over MPLS With Port-to-Port Connections

interface serial5/0

encapsulation hdlc

xconnect 10.0.0.1 123 encapsulation mpls

Enabling Other PE Devices to Transport Frame Relay Packets

You can configure an interface as a data terminal equipment (DTE) device or a data circuit-terminating equipment (DCE) switch, or as a switch connected to a switch with network-to-network interface (NNI) connections. Use the following command in interface configuration mode:

frame-relay intf-type [dce | dte | nni]

The following table explains the keywords:

Keyword	Description
dce	Enables the router or access server to function as a switch connected to a router.
dte	Enables the router or access server to function as a DTE device. DTE is the default.
nni	Enables the router or access server to function as a switch connected to a switch.

Local Management Interface and Frame Relay over MPLS

Local Management Interface (LMI) is a protocol that communicates status information about permanent virtual circuits (PVCs). When a PVC is added, deleted, or changed, the LMI notifies the endpoint of the status change. LMI also provides a polling mechanism that verifies that a link is up.

LMI Process

To determine the PVC status, LMI checks that a PVC is available from the reporting device to the Frame Relay end-user device. If a PVC is available, LMI reports that the status is "Active," which means that all interfaces, line protocols, and core segments are operational between the reporting device and the Frame Relay end-user device. If any of those components is not available, the LMI reports a status of "Inactive."

---

Note Only the DCE and NNI interface types can report LMI status.

---

Figure 20-6 is a sample topology that illustrates how LMI works.

Figure 20-6 Sample LMI Topology

In Figure 20-6, note the following:

•CE1 and PE1 and PE2 and CE2 are Frame Relay LMI peers.

•CE1 and CE2 can be Frame Relay switches or end-user devices.

•Each Frame Relay PVC is composed of multiple segments.

•The DLCI value is local to each segment and is changed as traffic is switched from segment to segment. Two Frame Relay PVC segments exist in Figure 20-6; one is between PE1 and CE1 and the other is between PE2 and CE2.

The LMI protocol behavior depends on DLCI-to-DLCI connections versus port-to-port connections.

DLCI-to-DLCI Connections

If DLCI-to-DLCI connections are configured, LMI runs locally on the Frame Relay ports between the PE and CE devices.

•CE1 sends an active status to PE1 if the PVC for CE1 is available. If CE1 is a switch, LMI checks that the PVC is available from CE1 to the user device attached to CE1.

•PE1 sends an active status to CE1 if the following conditions are met:

–A PVC for PE1 is available.

–PE1 received an MPLS label from the remote PE router.

–An MPLS tunnel label exists between PE1 and the remote PE router.

For DTE/DCE configurations, the following LMI behavior exists:

The Frame Relay device accessing the network (DTE) does not report PVC status. Only the network device (DCE) or NNI can report status. Therefore, if a problem exists on the DTE side, the DCE is not aware of the problem.

Port-to-Port Connections

If port-to-port connections are configured, the PE routers do not participate in the LMI status-checking procedures. LMI operates between the CE routers only. The CE routers must be configured as DCE-DTE or NNI-NNI.

For information about LMI, including configuration instructions, see the "Configuring the LMI" section of the Configuring Frame Relay document.

Configuring Frame Relay-to-Frame Relay Local Switching

Frame Relay switching is a means of switching packets based upon the data link connection identifier (DLCI), which can be looked upon as the Frame Relay equivalent of a MAC address. You perform the switching by configuring your router or access server as a Frame Relay network. There are two parts to a Frame Relay network: the Frame Relay data terminal equipment (DTE) (the router or access server) and the Frame Relay data communications equipment (DCE) switch.

Local switching allows you to switch Layer 2 data between two interfaces of the same type for example, ATM-to-ATM, or Frame-Relay-to-Frame-Relay.

For background information about Frame-Relay-to-Frame-Relay Local Switching, see the Distributed Frame Relay Switching feature guide.

You can switch between virtual circuits on the same port, as detailed in the "Configuring Frame Relay Same-Port Switching" section.

The following channelized line cards are supported for the Cisco 10000 series routers:

•1-port channelized OC-12/STM-4

•4-port channelized OC-3/STM-1

•6-port channelized T3

•24-port channelized E1/T1

The following packet over SONET line cards are supported for the Cisco 10000 series routers:

•1-port OC-12 Packet over SONET

•1-port OC-48/STM-16 Packet over SONET

•6-port OC-3/STM-1 Packet over SONET

The Frame Relay-to-Frame Relay Local Switching feature is described in the following topics:

•Configuring Frame Relay for Local Switching

•Configuring Frame Relay Same-Port Switching

•Verifying Layer 2 Local Switching for Frame Relay

•Configuring QoS Features

Configuring Frame Relay for Local Switching

To configure Frame Relay for local switching, enter the following commands, beginning in global configuration mode.

	Command	Purpose
Step 1	Router(config)# frame-relay switching	Enables Permanent Virtual Circuits (PVCs) switching on a Frame Relay DCE device or a Network-to-Network Interface (NNI).
Step 2	Router(config)# interface type number	Specifies an interface and enters interface configuration mode.
Step 3	Router(config-if)# encapsulation frame-relay [cisco | ietf]	Enables Frame Relay encapsulation. •cisco—Cisco's own encapsulation (default) •ietf—Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.
Step 4	Router(config-if)# frame-relay interface-dlci dlci switched	(Optional) Creates a switched PVC and enters Frame Relay DLCI configuration mode. Repeat Step 1 through Step 4 for each switched PVC. If you do not create a Frame Relay PVC in this step, it is automatically created in Step 6 by the connect command.
Step 5	Router(config-fr-dlci)# exit	Exits Frame Relay DLCI configuration mode and returns to global configuration mode.
Step 6	Router(config)# connect connection-name interface dlci interface dlci	Defines a connection between Frame Relay PVCs.

Example 20-24 configures Frame-Relay-to-Frame-Relay for local switching.

Example 20-24 Configuring Frame Relay-to-Frame Relay for Local Switching

frame-relay switching

interface serial 1/0/0.1/1:0

encapsulation frame-relay

frame-relay interface-dlci 100 switched

exit

connect connection1 serial1/0/0.1/1:0 100 serial2/0/0.1/2:0 101

Configuring Frame Relay Same-Port Switching

Use the following steps to configure local Frame Relay same-port switching on a single interface, beginning in global configuration mode.

	Command	Purpose
Step 1	Router(config)# frame-relay switching	Enables PVC switching on a Frame Relay DCE device or a NNI.
Step 2	Router(config)# interface type number	Specifies the interface and enters interface configuration mode.
Step 3	Router(config-if)# encapsulation frame-relay [cisco | ietf]	Enables Frame Relay encapsulation. •cisco—Cisco's own encapsulation (default) •ietf—Internet Engineering Task Force (IETF) standard (RFC 1490). Use this keyword when connecting to another vendor's equipment across a Frame Relay network.
Step 4	Router(config-if)# frame-relay intf-type {dce | dte | nni}	(Optional) Enables support for a particular type of connection. •dce—data communications equipment •dte—data terminal equipment •nni—network-to-network interface
Step 5	Router(config-if)# frame-relay interface-dlci dlci switched	(Optional) Creates a switched PVC and enters Frame Relay DLCI configuration mode. Repeat Step 1 through Step 5 for each switched PVC. If you do not create a Frame Relay PVC in this step, it is automatically created in Step 8 by the connect command.
Step 6	Router(config-fr-dlci)# exit	Exits Frame Relay DLCI configuration mode and returns to interface configuration mode.
Step 7	Router(config-if)# exit	Exits interface configuration mode and returns to global configuration mode.
Step 8	Router(config)# connect connection-name interface dlci interface dlci	Defines a connection between the two data links.

Example 20-25 shows how to configure Frame Relay same-port switching.

Example 20-25 Configuring Frame Relay Same-Port Switching

frame-relay switching

interface serial 1/0/0.1/1:0

encapsulation frame-relay

frame-relay intf-type nni

frame-relay interface-dlci 100 switched

exit

exit

connect connection1 serial1/0 100 serial1/0 200

Verifying Layer 2 Local Switching for Frame Relay

To verify configuration of the Layer 2 Local Switching feature, use the show connection frame-relay-to-frame-relay command and the show frame-relay pvc command in privileged EXEC mode.

Example 20-26 shows the output of the show connection frame-relay-to-frame-relay command, which displays the local connection between a Frame Relay interface and a Frame Relay local switching interface.

Example 20-26 show connection frame-relay-to-frame-relay Command Output

Router# show connection frame-relay-to-frame-relay 

ID  Name            Segment 1              Segment 2           State

==================================================================

1   fr2fr           Se3/0/0.1/1:0 100       Se3/0/0.1/2:0 200  UP

Example 20-27 shows the output of the show frame-relay pvc command, which shows a switched Frame Relay PVC.

Example 20-27 show frame-relay pvc Command Output

Router# show frame-relay pvc 16

PVC Statistics for interface POS5/0 (Frame Relay NNI)

DLCI = 16, DLCI USAGE = SWITCHED, PVC STATUS = UP, INTERFACE = POS5/0

LOCAL PVC STATUS = UP, NNI PVC STATUS = ACTIVE

input pkts 0 output pkts 0 in bytes 0

out bytes 0 dropped pkts 100 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 0 out bcast bytes 0

switched pkts 0

Detailed packet drop counters:

no out intf 0 out intf down 100 no out PVC 0

in PVC down 0 out PVC down 0 pkt too big 0

pvc create time 00:25:32, last time pvc status changed 00:06:31

Configuring QoS Features

For information about configuring QoS features on the Cisco 10000 series router, see the Cisco 10000 Series Router Quality of Service Configuration Guide.

Table 20-4 and Table 20-5 outline the level of support for modular QoS CLI (MQC) commands as they relate to Frame Relay DLCI interfaces.

The values shown in the tables are as follows:

•No—You cannot perform this policy map action

•Yes—You can perform this policy map action

•N/A (not applicable)—You can apply the policy map action but it does not have any effect on packets

Table 20-4 Frame Relay DLCI Input Policy Map Actions

Policy Map Actions	Frame Relay DLCI Interface
bandwidth	no
queue-limit	no
priority	no
shape	no
random-detect	no
set ip prec/dscp	N/A
set qos-group	yes
set discard class	yes
set atm-clp	N/A
set fr-de	no
set cos	no
police	yes
set mpls-exp topmost	N/A
set mpls-exp imposition	N/A

Table 20-5 Frame Relay Output (Disposition Router) Policy Map Actions

Policy Map Actions	Frame Relay DLCI Interface
bandwidth	yes
queue-limit	yes
priority	yes
shape	yes
random-detect	yes (discard class only)
set ip prec/dscp	N/A
set qos-group	N/A
set discard class	yes
set atm-clp	no
set fr-de	not supported
set cos	no
police	yes
set mpls-exp topmost	N/A

Configuring HDLC and PPP over MPLS

With HDLC over MPLS, the entire HDLC packet is transported. The ingress PE router removes only the HDLC flags and frame check sequence (FCS) bits. The contents of the packet are not used or changed.

With PPP over MPLS, the ingress PE router removes the flags, address, control field, and the FCS.

HDLC over MPLS is described in:

•Restrictions for HDLC over MPLS

•Restrictions for PPP over MPLS

•Configuring HDLC over MPLS or PPP over MPLS

Restrictions for HDLC over MPLS

The following restrictions pertain to the HDLC over MPLS feature:

•Asynchronous interfaces: Asynchronous interfaces are not supported.

•Interface configuration: You must configure HDLC over MPLS on router interfaces only. You cannot configure HDLC over MPLS on subinterfaces.

Restrictions for PPP over MPLS

The following restrictions pertain to the PPP over MPLS feature:

•Asynchronous interfaces—Are not supported. The connections between the CE and PE routers on both ends of the backbone must have similar link layer characteristics. The connections between the CE and PE routers must both be synchronous.

•Multilink PPP (MLP)—Is not supported.

•Interface configuration: You must configure PPP on router interfaces only. You cannot configure PPP on subinterfaces.

Configuring HDLC over MPLS or PPP over MPLS

To configure HDLC over MPLS or PPP over MPLS, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# interface serial slot/port	Specifies a serial interface and enters interface configuration mode. You must configure HDLC and PPP over MPLS on router interfaces only. You cannot configure HDLC over MPLS on subinterfaces.
Step 2	Router(config-if)# encapsulation encapsulation-type	Specifies HDLC or PPP encapsulation and enters connect submode. encapsulation-type can be HDLC or PPP.
Step 3	Router(config-fr-pw-switching)# xconnect peer-router-id vcid encapsulation mpls	Creates the VC to transport the Layer 2 packets.

Estimating the Size of Packets Traveling Through the Core Network

The following calculation helps you determine the size of the packets traveling through the core network. You set the maximum transmission unit (MTU) on the core-facing interfaces of the P and PE routers to accommodate packets of this size.

The MTU should be greater than or equal to the total bytes of the items in the following equation:

Core MTU >= (Edge MTU + Transport header + AToM header + (MPLS label stack size* MPLS 
label size))

The following sections describe the variables used in the equation.

Edge MTU

The edge MTU is the MTU for the customer-facing interfaces.

Transport Header

The transport header depends on the transport type. Table 20-6 lists the specific sizes of the headers.

Table 20-6 Header Size of Packets 

Transport Type	Header Size (bytes)
ATM AAL5 SDU support over MPLS	12
Ethernet over MPLS in VLAN mode	18
Ethernet over MPLS in port mode	14
Frame Relay over MPLS with DLCI-to-DLCI connections	4
HDLC over MPLS	4
PPP over MPLS	4

AToM Header

The AToM header is 4 bytes (control word). The Cisco 10000 series router adds the control word for all supported transport types by default.

MPLS Label Stack

The MPLS label stack size depends on the configuration of the core MPLS network.

•AToM uses one MPLS label to identify the AToM VCs (VC label). Therefore, the minimum MPLS label stack is 1 for directly connected AToM PE routers, which are PE routers that do not have a P router between them.

•If LDP is used in the MPLS network, the label stack size is 2 (the LDP label and the VC label).

•If a TE tunnel instead of LDP is used between PE routers in the MPLS network, the label stack size is 2 (the TE label and the VC label).

•If a TE tunnel and LDP are used in the MPLS network (for example, a TE tunnel between P routers or between P and PE routers, with LDP on the tunnel), the label stack is 3 (TE label, LDP label, VC label).

•If you use MPLS Fast Reroute in the MPLS network, you add a label to the stack. The maximum MPLS label stack in this case is 4 (FRR label, TE label, LDP label, VC label).

•If AToM is used by the customer carrier in the MPLS-VPN Carrier Supporting Carrier environment, you add a label to the stack. The maximum MPLS label stack in the provider carrier network is 5 (FRR label, TE label, LDP label, VPN label, VC label).

•If an AToM tunnel spans different service providers that exchange MPLS labels using IPv4 BGP (RFC 3107), you add a label to the stack. The maximum MPLS label stack is 5 (FRR label, TE label, BGP label, LDP label, VC label).

Other circumstances can increase the MPLS label stack size. Therefore, analyze the complete data path between the AToM tunnel endpoints and determine the maximum MPLS label stack size for your network. Then multiply the label stack size by the size of the MPLS label.

Estimating Packet Size—Example

Example 20-28 shows how to estimate the size of packets. The example uses the following assumptions:

•The edge MTU is 1500 bytes.

•The transport type is Ethernet VLAN, which designates 18 bytes for the transport header.

•The AToM header is 4 bytes, because the control word is always used.

•The MPLS label stack size is 2, because LDP is used. The MPLS label size is 4 bytes.

Example 20-28 Estimating the MTU for Packets

Core MTU >= (Edge MTU + Transport header + AToM header + (MPLS label stack size* MPLS 
label size))

1500     + 18                    + 0      + (2                * 4         ) = 1526

You must configure the P and PE routers in the core to accept packets of 1526 bytes. See the following section for setting the MTU size on the P and PE routers.

Changing the MTU Size on P and PE Routers

After you determine the MTU size to set on your P and PE routers, you can issue the mtu command on the routers to set the MTU size. The following example specifies an MTU size of 1526 bytes.

Router(config-if)# mtu 1526

Setting Experimental Bits with AToM

MPLS AToM uses the three experimental (EXP) bits in a label to determine the queue of packets.The EXP bits are set to 0 (zero) by default. Table 20-7 summarizes the commands you can use to override the default values.

Table 20-7 Commands Supported to Change EXP Bits 

Transport Type	Supported Commands
ATM AAL5 SDU support over MPLS Ethernet over MPLS: Port mode Frame Relay over MPLS: DLCI-to-DLCI connections Port-to-port connections HDLC over MPLS PPP over MPLS	set mpls experimental match any
Ethernet over MPLS: VLAN mode	set mpls experimental match cos

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.

To set the experimental bits, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# class-map class-name	Specifies the user-defined name of the traffic class and enters class map configuration mode.
Step 2	For all transport types except Ethernet over MPLS in VLAN mode: Router(config-cmap)# match any For Ethernet over MPLS in VLAN mode only: Router(config-cmap)# match cos cos-value	Specifies that all packets are matched. cos-value is from 0 to 7; up to four CoS values can be specified in one match cos statement.
Step 3	Router(config-cmap)# policy-map policy-name	Specifies the name of the traffic policy to configure and enters policy map configuration mode.
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. Enters policy-map configuration mode.
Step 5	Router(config-pmap-c)# set mpls experimental value	Designates the value to which the MPLS bits are set if the packets match the specified policy map.
Step 6	Router(config-pmap-c)# exit	Exits policy map configuration mode.
Step 7	Router(config-pmap)# exit	Exits policy map mode.
Step 8	Router(config)# interface slot/port	Specifies the interface and enters interface configuration mode.
Step 9	Router(config-if)# service-policy input policy-name	Attaches a traffic policy to an interface.

Displaying the Traffic Policy Assigned to an Interface

To display the traffic policy attached to an interface, use the show policy-map interface command.

Example 20-29 uses the set mpls experimental command with the match any command under a default class. This means that every packet tunneled onto a particular AToM VC carries the same MPLS experimental bit value.

Example 20-29 Setting EXP Bits Using the match any Command

class-map match-any default-class

  match any

policy-map atm-default-policy

  class default-class

    set mpls experimental 3

!

!

interface atm4/0 

service-policy input atm-default-policy

Example 20-30 uses the set mpls experimental command with the match cos command. This allows packets tunneled onto a particular AToM VC to carry different MPLS experimental bit values. The match cos command is only configurable on Ethernet VLAN subinterfaces.

Example 20-30 Setting EXP Bits Using the match cos Command

class-map match-any match_cos_low

  match cos 0 1 2 3

class-map match-any match_cos_high

  match cos 4 5 6 7

policy-map ether-clp-policy

  class match_cos_low

    set mpls experimental 1

  class match_cos_high

    set mpls experimental 5

!

!

interface Gi0/0.1

service-policy input ether-clp-policy

Configuring QoS Features

For information about configuring QoS features on the Cisco 10000 series router, see the Cisco 10000 Series Router Quality of Service Configuration Guide.

Table 20-8 and Table 20-9 describe the policy map actions supported on various interfaces. The tables indicate the following:

•No—You cannot perform this policy map action or match criteria.

•Yes—You can perform this policy map action or match criteria.

•N/A (Not Applicable)—You can apply the policy map action or match criteria, but it does not have any effect on packets.

Table 20-8 Input (Imposition Router) Policy Map Actions 

Policy Map Actions	Interface
	ATM	Ethernet	Frame Relay	HDLC and PPP
bandwidth	no	no	no	no
queue-limit	no	no	no	no
priority	no	no	no	no
shape	no	no	no	no
random-detect	no	no	no	no
set ip prec/dscp	N/A	N/A	N/A	N/A
set qos-group	yes	yes	yes	yes
set discard class	yes	yes	yes	yes
set atm-clp	N/A	N/A	N/A	N/A
set fr-de	N/A	N/A	N/A	N/A
set cos	N/A	N/A	N/A	N/A
police	yes	yes	yes	yes
set mpls-exp topmost	N/A	N/A	N/A	N/A
set mpls-exp imposition	yes	yes	yes	yes

Table 20-9 Output (Disposition Router) Policy Map Actions 

Policy Map Actions	Interface
	ATM	Ethernet	Frame Relay	HDLC and PPP
bandwidth	yes	yes	yes	yes
queue-limit	yes	yes	yes	yes
priority	yes	yes	yes	yes
shape	yes	yes	yes	yes
random-detect	yes (discard class only)	yes (discard class only)	yes (discard class only)	yes (discard class only)
set ip prec/dscp	no	no	no	no
set qos-group	N/A	N/A	N/A	N/A
set discard class	no	no	no	no
set atm-clp	yes	no	no	no
set fr-de	no	no	no	no
set cos	no	yes	no	no
police	yes	yes	yes	yes
set mpls-exp topmost	no	no	no	no
set mpls-exp imposition	N/A	N/A	N/A	N/A

Table 20-10 and Table 20-11 describe support for class map match criteria on various interfaces. Table 20-10 describes match criteria support for inbound traffic and Table 20-11 describes support for outbound traffic.

Table 20-10 Input (Imposition Router) Class Map Match Criteria 

Match Criteria	Interface
	ATM	Ethernet	Frame Relay	HDLC and PPP
DSCP	no	no	no	no
IP precedence	no	no	no	no
MPLS EXP	no	no	no	no
IEE 802.1P bits	no	yes	no	no
Access-list	no	no	no	no
QoS group	N/A	N/A	N/A	N/A
Discard class	N/A	N/A	N/A	N/A
Input interface	yes	yes	yes	yes
Protocol	no	no	no	no
RTP	no	no	no	no
atm-clp	no	no	no	no
MAC address	no	no	no	no
Frame Relay DLCI	no	no	no	no
VLAN ID	no	no	no	no
Packet length	no	no	no	no
DE bit (Frame Relay)	no	no	no	no

Table 20-11 Output (Disposition Router) Class Map Match Criteria 

Match Criteria	Interface
	ATM	Ethernet	Frame Relay	HDLC and PPP
DSCP	no	no	no	no
IP precedence	no	no	no	no
MPLS EXP	N/A	N/A	N/A	N/A
IEEE 802.1P bits	N/A	N/A	N/A	N/A
Access-list	no	no	no	no
QoS group	yes	yes	yes	yes
Discard class	yes	yes	yes	yes
Input interface	yes	yes	yes	yes
Protocol	no	no	no	no
RTP	no	no	no	no
atm-clp	N/A	N/A	N/A	N/A
MAC address	no	no	no	no
Frame Relay DLCI	no	no	no	no
VLAN ID	no	no	no	no
Packet Length	no	no	no	no
DE bit (Frame Relay)	N/A	N/A	N/A	N/A

Monitoring and Maintaining L2VPN

To monitor and maintain the configuration of L2VPN features, use the following commands in privileged EXEC mode. Note that with the exception of the show mpls l2transport command, these commands can produce output that is meant to be used by Cisco Systems technical support personnel only.

Command	Displays
show mpls l2transport	Information about AToM VCs that have been enabled to route Layer 2 packets on a router, including platform-independent AToM status and the AToM capabilities of a particular interface.
show pxf cpu atom	PXF-specific forwarding AToM and LS information for an interface or VCCI (column 1 forwarding information).
show mpls l2transport vc	Information about AToM virtual circuits (VCs) that have been enabled to route Layer 2 packets on a router.
show pxf cpu mpls label	PXF-specific forwarding information for a label. The output has been extended to indicate AToM disposition labels, specifically, the transport type associated with the label and the set of output features associated with the label, such as control word and sequencing.
show pxf cpu subblocks	Status and PXF-related parameters for the interface and has been extended to display column 0 of AToM status.
show ssm	Platform-specific information about active segments.
debug pxf atom ac	AToM information related to attachment circuit events.
debug pxf atom mpls	AToM information related to MPLS Forwarding Information (MFI)-driven events.

---

Caution Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco Systems technical support personnel. Moreover, it is best to use debug commands during periods of low network traffic and few users. This decreases the likelihood that increased debug command processing overhead will affect system use.

---

Configuration Example—Frame Relay over MPLS

Example 20-31 shows the configuration of Frame Relay over MPLS on two provider edge routers, PE1 and PE2, and on two customer edge routers, CE1 and CE2. The topology for the example is shown in Figure 20-7.

Figure 20-7 Frame Relay over MPLS Example Topology

For the AToM VCs to come up, MPLS/LDP and a routing protocol need to be run in the core network (PE1---P----PE2). PE1 and PE2 show that they are enabled with the OSPF routing protocol and MPLS/LDP.

Example 20-31 Frame Relay over MPLS Configuration

CE1 Configuration for Frame Relay

================================ 

interface Serial8/0/0.1/1:0 

no ip address 

encapsulation frame-relay 

no fair-queue 

frame-relay lmi-type q933a 

frame-relay intf-type dce

interface Serial8/0/0.1/1:0.1 point-to-point 

ip address 192.1.1.1 255.255.255.0 

frame-relay interface-dlci 17 

! 

interface Serial8/0/0.1/1:0.2 point-to-point 

ip address 192.1.2.1 255.255.255.0 

frame-relay interface-dlci 18 

PE1 Configuration for LDP and AToM VC

==================================

!Enabling LDP 

mpls ldp graceful-restart timers neighbor-liveness 300 

mpls ldp graceful-restart timers max-recovery 600 

mpls ldp graceful-restart 

mpls ldp router-id Loopback0 force 

mpls label protocol ldp

!Define Loopback address for LDP protocol 

interface Loopback0 

ip address 1.1.1.1 255.255.255.255

!Enable MPLS/LDP on the core interface 

interface POS4/0/0 

ip address 50.0.0.1 255.0.0.0 

mpls label protocol ldp 

mpls ip 

crc 32 

clock source internal 

!

!Enabling OSPF protocol 

router ospf 100 

log-adjacency-changes 

network 1.0.0.0 0.255.255.255 area 100 

network 50.0.0.0 0.255.255.255 area 100

!Define pseudowire-class 

pseudowire-class pw_atom1 

encapsulation mpls

!FR configuration with two subinterfaces 

interface Serial8/0/0.1/1:0 

no ip address 

encapsulation frame-relay 

no fair-queue 

frame-relay lmi-type q933a 

! 

interface Serial8/0/0.1/1:0.1 point-to-point 

! 

interface Serial8/0/0.1/1:0.2 point-to-point 

!

!Two AToM VC configuration with vc ids 1 & 2, 2.2.2.2 is LB addr of PE2 

connect atom1 Serial8/0/0.1/1:0 17 l2transport 

xconnect 2.2.2.2 1 pw-class pw_atom1 

! 

! 

connect atom2 Serial8/0/0.1/1:0 18 l2transport 

xconnect 2.2.2.2 2 pw-class pw_atom1 

PE2 Configuration

================================ 

!Enabling LDP 

mpls ldp graceful-restart timers neighbor-liveness 300 

mpls ldp graceful-restart timers max-recovery 600 

mpls ldp graceful-restart 

mpls ldp router-id Loopback0 force 

mpls label protocol ldp

!Define Loopback address for LDP protocol 

interface Loopback0 

ip address 2.2.2.2 255.255.255.255

!Enable MPLS/LDP on the core interface 

interface POS4/0/0 

ip address 60.0.0.2 255.0.0.0 

mpls label protocol ldp 

mpls ip 

crc 32 

clock source internal 

! 

!Enabling OSPF protocol 

router ospf 100 

log-adjacency-changes 

network 2.0.0.0 0.255.255.255 area 100 

network 60.0.0.0 0.255.255.255 area 100

!Define pseudowire-class 

pseudowire-class pw_atom1 

encapsulation mpls

!FR configuration with two subinterfaces 

interface Serial8/0/0.1/1:0 

no ip address 

encapsulation frame-relay 

no fair-queue 

frame-relay lmi-type q933a

interface Serial8/0/0.1/1:0.1 point-to-point 

interface Serial8/0/0.1/1:0.2 point-to-point

!Two AToM VC configuration with vc ids 1 & 2 

connect atom1 Serial8/0/0.1/1:0 17 l2transport 

xconnect 1.1.1.1 1 pw-class pw_atom1 

! 

! 

connect atom2 Serial8/0/0.1/1:0 18 l2transport 

xconnect 1.1.1.1 2 pw-class pw_atom1

CE2 Configuration

================================ 

interface Serial8/0/0.1/1:0 

no ip address 

encapsulation frame-relay 

no fair-queue 

frame-relay lmi-type q933a 

frame-relay intf-type dce 

! 

interface Serial8/0/0.1/1:0.1 point-to-point 

ip address 192.1.1.2 255.255.255.0 

frame-relay interface-dlci 17 

! 

interface Serial8/0/0.1/1:0.2 point-to-point 

ip address 192.1.2.2 255.255.255.0 

frame-relay interface-dlci 18 

Verifying PE1 Configuration

The PE1 router shows two AToM VCs are up.

================================ 

router# show mpls l2tran vc

Local intf Local circuit Dest address VC ID Status 

------------- -------------------------- --------------- ---------- ---------- 

Se8/0/0.1/1:0 FR DLCI 17 2.2.2.2 1 UP 

Se8/0/0.1/1:0 FR DLCI 18 2.2.2.2 2 UP 

router# show mpls l2tran vc 1 det 

Local interface: Se8/0/0.1/1:0 up, line protocol up, FR DLCI 17 up 

Destination address: 2.2.2.2, VC ID: 1, VC status: up 

Output interface: PO4/0/0, imposed label stack {93 19} 

Preferred path: not configured 

Default path: active 

Next hop: point2point 

Create time: 00:00:49, last status change time: 00:00:06 

Signaling protocol: LDP, peer 2.2.2.2:0 up 

MPLS VC labels: local 19, remote 93 

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, seq error 0, send 0

router# sh mpls l2tran vc 2 det 

Local interface: Se8/0/0.1/1:0 up, line protocol up, FR DLCI 18 up 

Destination address: 2.2.2.2, VC ID: 2, VC status: up 

Output interface: PO4/0/0, imposed label stack {98 19} 

Preferred path: not configured 

Default path: active 

Next hop: point2point 

Create time: 00:00:53, last status change time: 00:00:10 

Signaling protocol: LDP, peer 2.2.2.2:0 up 

MPLS VC labels: local 22, remote 98 

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, seq error 0, send 0

Any Transport over MPLS—Tunnel Selection

Tunnel Selection allows you to specify the path that Any Transport over MPLS (AToM) traffic uses. You can specify either a MPLS traffic engineering tunnel or a destination IP address. If the specified path is unreachable, you can specify that the virtual circuits (VCs) should use the default path, which is the path that MPLS Label Distribution Protocol (LDP) uses for signaling.

---

Note By default, the preferred-path sub-command has a fallback pseudowire. If the preferred pseudowire goes down, the MPLS/LDP module switch the circuit temporarily to another pseudowire. When the preferred pseudowire is up again, the circuit is switched back to the preferred pseudowire. The preferred-path subcommand also has an disable-fallback option, so that no random pseudowire is chosen if the preferred path goes down. The circuit is down until the preferred path pseudowire comes back up. However, in the 12.2(33) SB release, by default, the preferred-path sub-command has the disable-fallback option. There is no fallback pseudowire in this release, even when the option is stated explicitly.

---

See the Any Transport over MPLS: Tunnel Selection document for the following information:

•Prerequisites for Any Transport over MPLS: Tunnel Selection

•Restrictions for Any Transport over MPLS: Tunnel Selection

•Configuring Any Transport over MPLS: Tunnel Selection

•The debug mpls l2transport vc command for verifying Any Transport over MPLS: Tunnel Selection

•Verifying the Configuration—Example

•Troubleshooting Any Transport over MPLS: Tunnel Selection—Example

Configuration Example—Any Transport over MPLS: Tunnel Selection

The following example sets up two preferred paths for PE1. One preferred path specifies an MPLS traffic engineering tunnel. The other preferred path specifies an IP address of a loopback address on PE2. There is a static route configured on PE1 that uses a TE tunnel to reach the IP address on PE2.

Router PE1

mpls label protocol ldp

mpls traffic-eng tunnels

mpls ldp router-id Loopback0

pseudowire-class pw1

encapsulation mpls

preferred-path interface Tunnel1 disable-fallback

!

pseudowire-class pw2

encapsulation mpls

preferred-path peer 10.18.18.18

!

interface Loopback0

ip address 10.2.2.2 255.255.255.255

no ip directed-broadcast

no ip mroute-cache

!

interface Tunnel1

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination 10.16.16.16

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng priority 7 7

tunnel mpls traffic-eng bandwidth 1500

tunnel mpls traffic-eng path-option 1 explicit name path-tu1

!

interface Tunnel2

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination 10.16.16.16

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng priority 7 7

tunnel mpls traffic-eng bandwidth 1500

tunnel mpls traffic-eng path-option 1 dynamic

!

interface gigabitethernet0/0/0

no ip address

no ip directed-broadcast

no negotiation auto

!

interface gigabitethernet0/0/0.1

encapsulation dot1Q 222

no ip directed-broadcast

xconnect 10.16.16.16 101 pw-class pw1

!

interface ATM1/0/0

no ip address

no ip directed-broadcast

no atm enable-ilmi-trap

no atm ilmi-keepalive

pvc 0/50 l2transport

encapsulation aal5

xconnect 10.16.16.16 150 pw-class pw2

!

interface gigabitEthernet2/0/1

ip address 10.0.0.1 255.255.255.0

no ip directed-broadcast

tag-switching ip

mpls traffic-eng tunnels

ip rsvp bandwidth 15000 15000

!

router ospf 1

log-adjacency-changes

network 10.0.0.0 0.0.0.255 area 0

network 10.2.2.2 0.0.0.0 area 0

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

!

ip route 10.18.18.18 255.255.255.255 Tunnel2

!

ip explicit-path name path-tu1 enable

next-address 10.0.0.1

index 3 next-address 10.0.0.1

Router PE2

mpls label protocol ldp

mpls traffic-eng tunnels

mpls ldp router-id Loopback0

interface Loopback0

ip address 10.16.16.16 255.255.255.255

no ip directed-broadcast

no ip mroute-cache

!

interface Loopback2

ip address 10.18.18.18 255.255.255.255

no ip directed-broadcast

!

interface gigabitEthernet3/1

ip address 10.0.0.2 255.255.255.0

no ip directed-broadcast

mpls traffic-eng tunnels

mpls ip

no cdp enable

ip rsvp bandwidth 15000 15000

!

interface gigabitEthernet3/3

no ip address

no ip directed-broadcast

no cdp enable

!

interface gigabitEthernet3/3.1

encapsulation dot1Q 222

no ip directed-broadcast

no cdp enable

mpls l2transport route 10.2.2.2 101

!

interface ATM5/0

no ip address

no ip directed-broadcast

no atm enable-ilmi-trap

no atm ilmi-keepalive

pvc 0/50 l2transport

encapsulation aal5

xconnect 10.2.2.2 150 encapsulation mpls

!

router ospf 1

log-adjacency-changes

network 10.0.0.0 0.0.0.255 area 0

network 10.16.16.16 0.0.0.0 area 0

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0