• Address format--Configure the Label Distribution Protocol (LDP) router ID on all PE routers to be a loopback address with a /32 mask. Otherwise, some configurations might not function properly.

• AAL5 over MPLS is supported only in SDU mode.

• If you have TE tunnels running between the PE routers, you must enable LDP on the tunnel interfaces.
• The F4 end-to-end OAM cells are transparently transported along with the ATM cells. When a permanent virtual path (PVP) or permanent virtual circuit (PVC) is down on one PE router, the label associated with that PVP or PVC is withdrawn. Subsequently, the peer PE router detects the label withdrawal and sends an F4 AIS/RDI signal to its corresponding CE router. The PVP or PVC on the peer PE router remains in the up state.
• VC class configuration mode is not supported in port mode.
• The AToM control word is supported. However, if a peer PE does not support the control word, it is disabled.

For configuring ATM cell relay over MPLS in VP mode, the following restrictions apply:

• If a VPI is configured for VP cell relay, you cannot configure a PVC using the same VPI.
• VP trunking (mapping multiple VPs to one emulated VC label) is not supported. Each VP is mapped to one emulated VC.
• VP mode and VC mode drop idle cells.

• The subinterfaces between the CE and PE routers that are running Ethernet over MPLS must be in the same subnet.
• The subinterface on the adjoining CE router must be on the same VLAN as the PE router.
• 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 CE routers.
• The AToM control word is supported. However, if the peer PE does not support a control word, the control word is disabled.
• Ethernet packets with hardware-level cyclic redundancy check (CRC) errors, framing errors, and runt packets are discarded on input.

• The following features do not support MTU values in xconnect subinterface configuration mode:

  • Layer 2 Tunnel Protocol Version 3 (L2TPv3)
  • Virtual Private LAN services (VPLS)
  • L2VPN Pseudowire Switching
• The MTU value can be configured in xconnect subinterface configuration mode only on the following interfaces and subinterfaces:

  • Fast Ethernet
  • Gigabit Ethernet
• The router uses an MTU validation process for remote VCs established through LDP, which compares the MTU value configured in xconnect subinterface configuration mode to the MTU value of the remote customer interface. If an MTU value has not been configured in xconnect subinterface configuration mode, then the validation process compares the MTU value of the local customer interface to the MTU value of the remote xconnect, either explicitly configured or inherited from the underlying interface or subinterface.
• When you configure the MTU value in xconnect subinterface configuration mode, the specified MTU value is not enforced by the dataplane. The dataplane enforces the MTU values of the interface (port mode) or subinterface (VLAN mode).
• Ensure that the interface MTU is larger than the MTU value configured in xconnect subinterface configuration mode. If the MTU value of the customer-facing subinterface is larger than the MTU value of the core-facing interface, traffic may not be able to travel across the pseudowire.

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

• Asynchronous interfaces are not supported.
• You must configure HDLC over MPLS on router interfaces only. You cannot configure HDLC over MPLS on subinterfaces.

• Zero hops on one router is not supported. However, you can have back-to-back PE routers.
• 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.
• You must configure PPP on router interfaces only. You cannot configure PPP on subinterfaces.

• The selected path should be an LSP destined to the peer PE router.
• The selected tunnel must be an MPLS TE tunnel.
• If you select a tunnel, the tunnel tailend must be on the remote PE router.
• If you specify an IP address, that address must be the IP address of the loopback interface on the remote PE router. The address must have a /32 mask. There must be an LSP destined to that selected address. The LSP need not be a TE tunnel.

• You must statically set the experimental (EXP) bits in both the VC label and the LSP tunnel label, because the LSP tunnel label might be removed at the penultimate router.
• For EXP bits and ATM AAL5 over MPLS and for EXP bits and Frame Relay over MPLS, if you do not assign values to the experimental bits, the priority bits in the header’s “tag control information” field are set to zero.
• For EXP bits and ATM Cell Relay over MPLS in VC mode, if you do not assign values to the experimental bits, the priority bits in the header’s “tag control information” field are set to zero.
• For EXP bits and HDLC over MPLS and PPP over MPLS, if you do not assign values to the experimental bits, zeros are written into the experimental bit fields.

This feature is not symmetrical if the remote PE router is running an older version 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.

AToM encapsulates Layer 2 frames at the ingress PE and sends them to a corresponding PE at the other end of a pseudowire, which is a connection between the two PE routers. The egress PE removes the encapsulation and sends out the Layer 2 frame.

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

• The type of Layer 2 data that will be transported across the pseudowire, such as Ethernet, Frame Relay, or ATM
• The IP address of the loopback interface of the peer PE router, which enables the PE routers to communicate
• A unique combination of peer PE IP address and VC ID that identifies the pseudowire

The following example shows the basic configuration steps on a PE router that enable the transport of Layer 2 packets. Each transport type has slightly different steps.

Step 1 defines the interface or subinterface on the PE router:

Router# interface 
interface-type interface-number

Step 2 specifies the encapsulation type for the interface, such as dot1q:

Router(config-if)# encapsulation 
encapsulation-type

Step 3 does the following:

• Makes a connection to the peer PE router by specifying the LDP router ID of the peer PE router.
• Specifies a 32-bit unique identifier, called the VC ID, which is shared between the two PE routers.

The combination of the peer router ID and the VC ID must be unique 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. AToM uses MPLS as the tunneling method.

Router(config-if)# xconnect 
peer-router-id vcid 
encapsulation mpls

As an alternative, you can set up a pseudowire class to specify the tunneling method and other characteristics. For more information, see the Configuring the Pseudowire Class.

AToM encapsulates Layer 2 frames at the ingress PE and sends them to a corresponding PE at the other end of a pseudowire, which is a connection between the two PE routers. The egress PE removes the encapsulation and sends out the Layer 2 frame.

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

• The type of Layer 2 data that will be transported across the pseudowire, such as Ethernet, Frame Relay, or ATM
• The IP address of the loopback interface of the peer PE router, which enables the PE routers to communicate
• A unique combination of peer PE IP address and VC ID that identifies the pseudowire

The following example shows the basic configuration steps on a PE router that enable the transport of Layer 2 packets. Each transport type has slightly different steps.

Step 1 defines the interface or subinterface on the PE router:

Router# interface 
interface-type interface-number

Step 2 specifies the encapsulation type for the interface, such as dot1q:

Router(config-if)# encapsulation 
encapsulation-type

Step 3 does the following:

• Makes a connection to the peer PE router by specifying the LDP router ID of the peer PE router.
• Specifies a 32-bit unique identifier, called the VC ID, which is shared between the two PE routers.

The combination of the peer router ID and the VC ID must be unique 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. AToM uses MPLS as the tunneling method.

Router(config)# interface pseudowire 100
Router(config-if)# encapsulation mpls
Router(config-if)# neighbor 10.0.0.1 123
Router(config-if)# exit
!
Router(config)# l2vpn xconnect context A
Router(config-xconnect)# member pseudowire 100
Router(config-xconnect)# member gigabitethernet0/0/0.1
Router(config-xconnect)# exit

As an alternative, you can set up a pseudowire class to specify the tunneling method and other characteristics. For more information, see the Configuring the Pseudowire Class.

The following list explains some of the benefits of enabling Layer 2 packets to be sent in the MPLS network:

• The AToM product set accommodates many types of Layer 2 packets, including Ethernet and Frame Relay, across multiple Cisco router platforms. 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. This benefits the service provider that 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.

AToM can use MPLS traffic engineering (TE) tunnels with fast reroute (FRR) support. AToM VCs can be rerouted around a failed link or node at the same time as MPLS and IP prefixes.

Enabling fast reroute on AToM does not require any special commands; you can use standard fast reroute commands. At the ingress PE, an AToM tunnel is protected by fast reroute when it is routed to an FRR-protected TE tunnel. Both link and node protection are supported for AToM VCs at the ingress PE.

In the following example, the primary link is disabled, which causes the backup tunnel (Tunnel 1) to become the primary path. The output in boldface font shows the status of the tunnel:

Router# execute-on slot 3 debug mpls l2transport fast-reroute
========= Line Card (Slot 3) =========
AToM fast reroute debugging is on
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Processing TFIB FRR event for 10.4.0.1
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Finished processing TFIB FRR event for 10.4.0.1
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Processing TFIB FRR event for Tunnel41
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Finished processing TFIB FRR event for Tunnel41
Sep 16 17:58:58.342: %LINK-3-UPDOWN: Interface POS0/0/0, changed state to down
Sep 16 17:58:58.342: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on POS0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Sep 16 17:58:59.342: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0/0/0, changed state to down

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 * MPLS label size))

The following sections describe the variables used in the equation.

MTU values can be specified in xconnect subinterface configuration mode. When you use xconnect subinterface configuration mode to set the MTU value, you establish a pseudowire connection for situations where the interfaces have different MTU values that cannot be changed.

If you specify an MTU value in xconnect subinterface configuration mode that is outside the range of supported MTU values (64 bytes to the maximum number of bytes supported by the interface), the command might be rejected. If you specify an MTU value that is out of range in xconnect subinterface configuration mode, the router enters the command in subinterface configuration mode.

For example, if you specify an MTU of 1501 in xconnect subinterface configuration mode, and that value is out of range, the router enters the command in subinterface configuration mode, where it is accepted:

Router# configure terminal
Router(config)# interface gigabitethernet0/0/2.1
Router(config-subif)# xconnect 10.10.10.1 100 encapsulation mpls
Router(config-subif-xconn)# mtu ?
<64 - 1500> MTU size in bytes
Router(config-subif-xconn)# mtu 1501 <<================
Router(config-subif)# mtu ?
<64 - 17940> MTU size in bytes

If the MTU value is not accepted in either xconnect subinterface configuration mode or subinterface configuration mode, then the command is rejected.

MTU values can be specified in xconnect configuration mode. When you use xconnect configuration mode to set the MTU value, you establish a pseudowire connection for situations where the interfaces have different MTU values that cannot be changed.

If you specify an MTU value in xconnect configuration mode that is outside the range of supported MTU values (64 bytes to the maximum number of bytes supported by the interface), the command might be rejected. If you specify an MTU value that is out of range in xconnect configuration mode, the router enters the command in subinterface configuration mode.

For example, if you specify an MTU of 1501 in xconnect configuration mode, and that value is out of range, the router enters the command in subinterface configuration mode, where it is accepted:

Router# configure terminal
Router(config)# interface gigabitethernet0/0/2.1
Router(config)# interface pseudowire 100
Router(config-if)# encapsulation mpls
Router(config-if)# neighbor 10.10.10.1 100
Router(config-if)# mtu ?
<64 - 1500> MTU size in bytes
Router(config-if)# mtu 1501 <<================
Router(config-if)# mtu ?
<64 - 17940> MTU size in bytes
Router(config-if)# exit
!
Router(config)# l2vpn xconnect context A
Router(config-xconnect)# member pseudowire 100 Router
Router(config-xconnect)# member gigabitethernet0/0/2.1
Router(config-xconnect)# exit

If the MTU value is not accepted in either xconnect configuration mode or subinterface configuration mode, then the command is rejected.

You can configure an interface as a DTE device or a 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 keywords are explained in the table below.

The tables below list the QoS features supported by AToM.

If a PE router does not support the transport of Operation, Administration, and Maintenance (OAM) cells across a label switched path (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 Cisco software 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 has been 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 cells:

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

This Cisco IOS XE 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 cause the 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.

The figure below illustrates a condition in an EoMPLS WAN, with a down Layer 2 tunnel link between a CE router (Customer Edge 1) and the PE router (Provider Edge 1). A CE router on the far side of the Layer 2 tunnel (Customer Edge 2), continues to forward traffic to Customer Edge 1 through the L2 tunnel.

Figure 2. Remote Link Outage in EoMPLS WAN

Previous to this feature, the Provider Edge 2 router could not detect a failed remote link. Traffic forwarded from Customer Edge 2 to Customer Edge 1 would be lost until routing or spanning tree protocols detected the down remote link. If the link was configured with static routing, the remote link outage would be even more difficult to detect.

With this feature, the Provider Edge 2 router detects the remote link failure and causes a shutdown of the local Customer Edge 2 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 the figure above, the Remote Ethernet Shutdown sequence is generally described as follows:

1. The remote link between Customer Edge 1 and Provider Edge 1 fails.
2. Provider Edge 2 detects the remote link failure and disables the transmit laser on the line card interface connected to Customer Edge 2.
3. An RX_LOS error alarm is received by Customer Edge 2 causing Customer Edge 2 to bring down the interface.
4. Provider Edge 2 maintains its interface with Customer Edge 2 in an up state.
5. When the remote link and EoMPLS connection is restored, the Provider Edge 2 router enables the transmit laser.
6. The Customer Edge 2 router brings up its downed interface.

This feature is enabled by default for Ethernet over MPLS (EoMPLS). You can also enable this feature by using the remote link failure notification command in xconnect configuration mode as shown in the following example:

pseudowire-class eompls
 encapsulation mpls
!
interface GigabitEthernet1/0/0
 xconnect 10.13.13.13 1 pw-class eompls
  remote link failure notification
!

This feature can be disabled using the no remote link failure notification command in xconnect configuration mode. Use the show ip interface brief privileged EXEC command to display the status of all remote L2 tunnel links. Use the show interface privileged EXEC command to show the status of the L2 tunnel on a specific interface.

Note	The no remote link failure notification command will not give notification to clients for remote attachment circuit status down.

This Cisco IOS XE 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 cause the 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.

The figure below illustrates a condition in an EoMPLS WAN, with a down Layer 2 tunnel link between a CE router (Customer Edge 1) and the PE router (Provider Edge 1). A CE router on the far side of the Layer 2 tunnel (Customer Edge 2), continues to forward traffic to Customer Edge 1 through the L2 tunnel.

Figure 3. Remote Link Outage in EoMPLS WAN

Previous to this feature, the Provider Edge 2 router could not detect a failed remote link. Traffic forwarded from Customer Edge 2 to Customer Edge 1 would be lost until routing or spanning tree protocols detected the down remote link. If the link was configured with static routing, the remote link outage would be even more difficult to detect.

With this feature, the Provider Edge 2 router detects the remote link failure and causes a shutdown of the local Customer Edge 2 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 the figure above, the Remote Ethernet Shutdown sequence is generally described as follows:

1. The remote link between Customer Edge 1 and Provider Edge 1 fails.
2. Provider Edge 2 detects the remote link failure and disables the transmit laser on the line card interface connected to Customer Edge 2.
3. An RX_LOS error alarm is received by Customer Edge 2 causing Customer Edge 2 to bring down the interface.
4. Provider Edge 2 maintains its interface with Customer Edge 2 in an up state.
5. When the remote link and EoMPLS connection is restored, the Provider Edge 2 router enables the transmit laser.
6. The Customer Edge 2 router brings up its downed interface.

This feature is enabled by default for Ethernet over MPLS (EoMPLS). You can also enable this feature by using the remote link failure notification command in xconnect configuration mode as shown in the following example:

template type pseudowire eompls
 encapsulation mpls
!
interface Pseudowire 100
 source template type pseudowire test
 neighbor 10.13.13.13 1
interface GigabitEthernet1/0/0
	service instance 300 ethernet
 remote link failure notification
l2vpn xconnect context con1
 member GigabitEthernet1/0/0 service-instance 300
 member Pseudowire 100
!

This feature can be disabled using the no remote link failure notification command in xconnect configuration mode. Use the show ip interface brief privileged EXEC command to display the status of all remote L2 tunnel links. Use the show interface privileged EXEC command to show the status of the L2 tunnel on a specific interface.

Note	The no remote link failure notification command will not give notification to clients for remote attachment circuit status down.

The AToM Load Balancing with Single PW feature enables load balancing for packets within the same pseudowire by further classifying packets within the same pseudowire into different flows based on certain fields in the packet received on an attachment circuit. For example, for Ethernet this load balancing is based on the source MAC address in the incoming packets.

The Flow-Aware Transport of MPLS Pseudowires feature enables load balancing of packets within the same pseudowire by further classifying the packets into different flows by adding a flow label at the bottom of the MPLS label stack.

Note	In simple configurations, this task is optional. You need not specify a pseudowire class if you specify the tunneling method as part of the xconnect command.

• You must specify the encapsulation mpls command as part of the pseudowire class or as part of the xconnect command for the AToM VCs to work properly. If you omit the encapsulation mpls command as part of the xconnect command, you receive the following error:

% Incomplete command.

1.    enable


2.    configure terminal


3.    pseudowire-class name


4.    encapsulation mpls

Router> enable

Router# configure terminal

Router(config)# pseudowire-class atom

Router(config-pw)# encapsulation mpls 

Note	In simple configurations, this task is optional. You need not specify a pseudowire class if you specify the tunneling method as part of the l2vpn xconnect context command.

• You must specify the encapsulation mpls command as part of the pseudowire class or as part of the l2vpn xconnect context command for the AToM VCs to work properly. If you omit the encapsulation mpls command as part of the l2vpn xconnect contextcommand, you receive the following error:

% Incomplete command.

1.    enable


2.    configure terminal


3.    interface pseudowire name


4.    encapsulation mpls


5.    neighbor peer-address vcid-value

Router> enable

Router# configure terminal

Router(config)# interface pseudowire atom

Router(config-pw-class)# encapsulation mpls 

Router(config-pw-class)#  neighbor 33.33.33.33 1

Once you specify the encapsulation mpls command, you cannot remove it using the no encapsulation mpls command.

Those methods result in the following error message:

Encapsulation changes are not allowed on an existing pw-class.

To remove the encapsulation mpls command, you must delete the pseudowire with the no pseudowire-class command.

To change the type of encapsulation, remove the pseudowire using the no pseudowire-class command and reconfigure the pseudowire to specify the new encapsulation type.

Once you specify the encapsulation mpls command, you cannot remove it using the no encapsulation mpls command.

Those methods result in the following error message:

Encapsulation changes are not allowed on an existing pw-class.

To remove the encapsulation mpls command, you must delete the pseudowire with the no template type pseudowire command.

To change the type of encapsulation, remove the pseudowire using the no template type pseudowire command and reconfigure the pseudowire to specify the new encapsulation type.

• Configuring ATM AAL5 over MPLS on PVCs
• Configuring ATM AAL5 over MPLS on PVCs using the commands associated with the L2VPN Protocol-Based CLIs feature
• Configuring ATM AAL5 over MPLS in VC Class Configuration Mode
• Configuring ATM AAL5 over MPLS in VC Class Configuration Mode using the commands associated with the L2VPN Protocol-Based CLIs feature

Router> enable

Router# configure terminal

Router(config)# interface atm1/0/0

Router(config-if)# pvc 1/200 l2transport

Router(config-if-atm-l2trans-pvc)# encapsulation aal5

Router(config-if-atm-l2trans-pvc)# xconnect 10.13.13.13 100 encapsulation mpls

Router(config-if-atm-l2trans-pvc)# end

Router# show mpls l2transport vc

Router# show mpls l2transport vc
Local intf   Local circuit          Dest address      VC ID      Status
---------    -------------          ------------      -----      ------
ATM1/0       ATM AAL5 1/100         10.4.4.4           100        UP

Device> enable

Device# configure terminal

Device(config)# interface atm1/0/0

Device(config-if)# pvc 1/200 l2transport

Device(config-if-atm-l2trans-pvc)# encapsulation aal5

Device(config-if-atm-l2trans-pvc)# end

Device(config)# interface pseudowire 100

Device(config-if)# encapsulation mpls

Device(config-if)# neighbor 10.13.13.13 100

Device(config-if)# exit

Device(config)# l2vpn xconnect context con1

Device(config-xconnect)# member pseudowire 100

Device(config-xconnect)# member atm 100 pvc 1/200

Device(config-xconnect)# end

Device# show l2vpn atom vc

Device# show l2vpn atom vc
Local intf   Local circuit          Dest address      VC ID      Status
---------    -------------          ------------      -----      ------
ATM1/0       ATM AAL5 1/100         10.4.4.4           100        UP

Router> enable

Router# configure terminal

Router(config)# vc-class atm aal5class

Router(config-vc-class)# encapsulation aal5

Router(config-vc-class)# exit

Router(config)# interface atm1/0/0

Router(config-if)# class-int aal5class

Router(config-if)# pvc 1/200 l2transport

Router(config-if-atm-l2trans-pvc)# xconnect 10.13.13.13 100 encapsulation mpls

Router(config-if-atm-l2trans-pvc)# end

Router# show atm class-links

Router# show atm class-links 1/100
Displaying vc-class inheritance for ATM1/0/0.0, vc 1/100:
no broadcast - Not configured - using default
encapsulation aal5 - VC-class configured on main interface

Router> enable

Router# configure terminal

Router(config)# vc-class atm aal5class

Router(config-vc-class)# encapsulation aal5

Router(config-vc-class)# exit

Router(config)# interface atm1/0/0

Router(config-if)# class-int aal5class

Router(config-if)# pvc 1/200 l2transport

Router(config-if)# exit

Router(config)# interface pseudowire 100

Router(config-if)# encapsulation mpls

Router(config-if)# neighbor 10.0.0.1 123

Router(config-if)# exit

Router(config)# l2vpn xconnect context con1

Router(config-xconnect)# member pseudowire 100

Device(config-xconnect)# member atm 100

Router(config-if-atm-l2trans-pvc)# end

Router# show atm class-links

Router# show atm class-links 1/100
Displaying vc-class inheritance for ATM1/0/0.0, vc 1/100:
no broadcast - Not configured - using default
encapsulation aal5 - VC-class configured on main interface