The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This module describes
how to configure Any Transport over MPLS (AToM) transports data link layer
(Layer 2) packets over a Multiprotocol Label Switching (MPLS) backbone. AToM
enables service providers to connect customer sites with existing Layer 2
networks by using a single, integrated, packet-based network infrastructure--a
Cisco MPLS network. Instead of using separate networks with network management
environments, service providers can deliver Layer 2 connections over an MPLS
backbone. AToM provides a common framework to encapsulate and transport
supported Layer 2 traffic types over an MPLS network core.
AToM supports the
following like-to-like transport types:
ATM Adaptation
Layer Type-5 (AAL5) over MPLS
ATM Cell Relay
over MPLS
Ethernet over
MPLS (port modes)
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information,
see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module,
and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature
Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Any
Transport over MPLS
IP routing must
be configured in the core so that the provider edge (PE) routers can reach each
other via IP.
MPLS must be
configured in the core so that a label-switched path (LSP) exists between the
PE routers.
A loopback
interface must be configured for originating and terminating Layer 2 traffic.
Ensure that 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 traffic engineering (TE) tunnel.
Restrictions for Any
Transport over MPLS
General Restrictions
The following
general restrictions pertain to all transport types under AToM:
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.
Ethernet over MPLS (EoMPLS)
Restrictions
The following
restrictions pertain to the Ethernet over MPLS feature:
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. 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.
General Restrictions
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.
For PTPoIP
configuration with explicit Null MPLS encapsulation, when a Transparent Clock
(TC) is placed between a PTP master and a PTP slave, the TC does not update the
correction field.
If an AToM tunnel spans different service providers that exchange MPLS labels using IPv4 Border Gateway Protocol (BGP) (RFC
3107), you add a label to the stack. The maximum MPLS label stack is .
Hot standby pseudowire (HSPW) convergence without pseudowire grouping increments linearly. For example, for a thousand virtual
circuits, it requires about 54 seconds of convergence time. This is applicable only for the Cisco RSP3 Module.
Clear interface is not the recommended way to measure the convergence numbers.
ATM AAL5 over MPLS
Restrictions
AAL5 over MPLS is
supported only in SDU mode.
ATM Cell Relay over MPLS Restrictions
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.
Ethernet over MPLS (EoMPLS)
Restrictions
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.
Per-Subinterface MTU for Ethernet over MPLS Restrictions
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 over MPLS Restrictions
Frame Relay traffic shaping is not supported with AToM switched VCs.
HDLC over MPLS Restrictions
Asynchronous interfaces are not supported.
You must configure HDLC over MPLS on router interfaces only. You cannot configure HDLC over MPLS on subinterfaces.
PPP over MPLS Restrictions
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.
Tunnel Selection
Restrictions
The selected path
should be an LSP destined to the peer PE router.
The selected tunnel must be an MPLS TE tunnel.
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.
Experimental Bits with AToM
Restrictions
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.
Remote Ethernet Port Shutdown Restrictions
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.
Remote Ethernet Port Shutdown is supported only on EFP with encapsulation default.
Information About Any Transport over MPLS
To configure AToM, you must understand the following concepts:
How AToM Transports Layer 2
Packets
AToM encapsulates
Layer 2 frames at the ingress PE and sends them to a corresponding PE at the
other end of a pseudowire, which is a connection between the two PE routers.
The egress PE removes the encapsulation and sends out the Layer 2 frame.
The successful
transmission of the Layer 2 frames between PE routers is due to the
configuration of the PE routers. You set up the connection, called a
pseudowire, between the routers. You specify the following information on each
PE router:
The type of Layer
2 data that will be transported across the pseudowire, such as Ethernet, Frame
Relay, or ATM
The IP address of
the loopback interface of the peer PE router, which enables the PE routers to
communicate
A 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
specifies the encapsulation type for the
interface, such as dot1q:
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.
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.
How AToM Transports Layer 2 Packets Using Commands Associated with L2VPN Protocol-Based 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 3 specifies the
encapsulation type for the interface, such as dot1q:
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.
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.
Benefits of AToM
The following list explains some of the benefits of enabling Layer 2 packets to be sent in the MPLS network:
The AToM product set accommodates many types of Layer 2 packets, including Ethernet and Frame Relay, across multiple Cisco
router platforms. 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.
MPLS Traffic Engineering Fast
Reroute
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.
Maximum Transmission Unit
Guidelines for Estimating Packet Size
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.
Edge MTU
The edge MTU is the
MTU for the customer-facing interfaces.
Transport Header
The Transport
header depends on the transport type. The table below lists the specific sizes
of the headers.
Table 1. Header Size of Packets
Transport
Type
Packet Size
AAL5
0-32 bytes
Ethernet
VLAN
18 bytes
Ethernet
Port
14 bytes
Frame Relay
DLCI
2 bytes for Cisco encapsulation, 8 bytes for Internet Engineering Task Force (IETF) encapsulation
HDLC
4 bytes
PPP
4 bytes
AToM Header
The AToM header is
4 bytes (control word). The control word is optional for Ethernet, PPP, HDLC,
and cell relay transport types. The control word is required for Frame Relay
and ATM AAL5 transport types.
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 one for directly connected AToM PEs, 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 two (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 two (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 three (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 four (FRR label, TE label, LDP label, VC label).
If AToM is used by the customer carrier in an MPLS VPN Carrier Supporting Carrier environment, you add a label to the stack.
The maximum MPLS label stack in the provider carrier network is .
If an AToM tunnel spans different service providers that exchange MPLS labels using IPv4 Border Gateway Protocol (BGP) (RFC
3107), you add a label to the stack. The maximum MPLS label stack is
TE-FRR with BGP labels for layer 2 and layer 3 VPNs must terminate on the BGP gateway because of the four-label limitation.
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
The estimated packet size in the following example is 1526 bytes, based on 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 0, because the control word is not used.
The MPLS label stack is 2, because LDP is used. The MPLS label is 4 bytes.
Edge MTU + Transport header + AToM header + (MPLS label stack * MPLS label) = Core MTU
1500 + 18 + 0 + (2 * 4 ) = 1526
You must configure the P and PE routers in the core to accept packets of 1526 bytes.
Per-Subinterface MTU for Ethernet over MPLS
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.
Per-Subinterface MTU for Ethernet over MPLS using the commands associated with the L2VPN Protocol-Based CLIs feature
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.
Frame Relay over MPLS and DTE DCE and NNI Connections
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.
Table 2. frame-relay intf-type Command 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 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.
How LMI Works
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 the LMI status.
The figure below is a sample topology that helps illustrate how LMI works.
Figure 1. Sample Topology
In the figure above, 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 comprises 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 the figure; one is between PE1 and CE1 and the other is between PE2 and CE2.
The LMI protocol behavior depends on whether you have DLCI-to-DLCI or port-to-port connections.
DLCI-to-DLCI Connections
If you have DLCI-to-DLCI connections, 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.
For DTE or DCE configurations, the following LMI behavior exists: The Frame Relay device accessing the network (DTE) does
not report the PVC status. Only the network device (DCE) or NNI can report the status. Therefore, if a problem exists on the
DTE side, the DCE is not aware of the problem.
Port-to-Port Connections
If you have port-to-port connections, the PE routers do not participate in the LMI status-checking procedures. LMI operates
only between the CE routers. 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.
QoS Features Supported with
AToM
The tables below list
the QoS features supported by AToM.
Table 3. QoS Features Supported with
Ethernet over MPLS
QoS Feature
Ethernet over
MPLS
Service
policy
Can be
applied to:
Interface
(input and output)
Classification
Supports the
following commands:
match cos (on interfaces)
match mpls experimental (on interfaces)
match qos-group (on interfaces) (output policy)
Marking
Supports the
following commands:
set cos (output policy)
set discard-class (input policy)
set mpls experimental (input policy) (on interfaces)
set qos-group (input policy)
Policing
Supports the
following:
Color-aware policing
Multiple-action policing
Single-rate policing
Two-rate
policing
Queueing and
shaping
Supports the
following:
Byte-based WRED
Low
Latency Queueing (LLQ)
Weighted
Random Early Detection (WRED)
Table 4. QoS Features Supported with
Frame Relay over MPLS
QoS Feature
Frame Relay
over MPLS
Service
policy
Can be
applied to:
Interface
(input and output)
PVC
(input and output)
Classification
Supports
the following commands:
match fr-de (on interfaces and VCs)
match fr-dlci (on interfaces)
match qos-group
Marking
Supports
the following commands:
frame-relay congestion management (output)
set discard-class
set fr-de (output policy)
set fr-fecn-becn (output)
set mpls experimental
set qos-group
threshold ecn (output)
Policing
Supports
the following:
Color-aware policing
Multiple-action policing
Single-rate policing
Two-rate policing
Queueing
and shaping
Supports
the following:
Byte-based WRED
Class-based weighted fair queueing (CBWFQ)
LLQ
random-detect discard-class-based command
Traffic
shaping
WRED
Table 5. QoS Features Supported with
ATM Cell Relay and AAL5 over MPLS
QoS Feature
ATM Cell
Relay and AAL5 over MPLS
Service
policy
Can be
applied to:
Interface (input and output)
PVC
(input and output)
Subinterface (input and output)
Classification
Supports
the following commands:
match mpls experimental (on VCs)
match qos-group (output)
Marking
Supports
the following commands:
random-detect discard-class-based (input)
set clp (output) (on interfaces, subinterfaces, and VCs)
set discard-class (input)
set mpls experimental (input) (on interfaces, subinterfaces, and VCs)
set qos-group (input)
Policing
Supports
the following:
Color-aware policing
Multiple-action policing
Single-rate policing
Two-rate policing
Queueing
and shaping
Supports
the following:
Byte-based WRED
CBWFQ
Class-based shaping support on ATM PVCs
LLQ
random-detect discard-class-based command
WRED
OAM Cell Emulation for ATM AAL5 over MPLS
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.
OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode
You can configure OAM cell emulation as part of a VC class and 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.
Any Transport over MPLS
(AToM) Remote Ethernet Port Shutdown
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:
The remote link
between Customer Edge 1 and Provider Edge 1 fails.
Provider Edge 2
detects the remote link failure and disables the transmit laser on the line
card interface connected to Customer Edge 2.
An RX_LOS error
alarm is received by Customer Edge 2 causing Customer Edge 2 to bring down the
interface.
Provider Edge 2
maintains its interface with Customer Edge 2 in an up state.
When the remote
link and EoMPLS connection is restored, the Provider Edge 2 router enables the
transmit laser.
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:
This feature can be
disabled using the
no remote link failure notification command in xconnect configuration
mode. Use theshow 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.
Note
Remote Ethernet Port Shutdown is supported only on EFP with encapsulation default.
Any Transport over MPLS (AToM) Remote Ethernet Port Shutdown Using Commands Associated with L2VPN Protocol-Based Feature
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:
The remote link
between Customer Edge 1 and Provider Edge 1 fails.
Provider Edge 2
detects the remote link failure and disables the transmit laser on the line
card interface connected to Customer Edge 2.
An RX_LOS error
alarm is received by Customer Edge 2 causing Customer Edge 2 to bring down the
interface.
Provider Edge 2
maintains its interface with Customer Edge 2 in an up state.
When the remote
link and EoMPLS connection is restored, the Provider Edge 2 router enables the
transmit laser.
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:
This feature can be
disabled using the
no remote link failure notification command in xconnect configuration
mode. Use theshow 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.
AToM Load Balancing with
Single PW
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.
Flow-Aware Transport (FAT)
Load Balancing
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.
Information About
EoMPLS over IPv6 GRE Tunnel
Ethernet over MPLS (EoMPLS) is a tunneling mechanism that allows you to
tunnel Layer 2 traffic through a Layer 3 MPLS network. EoMPLS is also known as
Layer 2 tunneling.
The EoMPLS over IPv6 GRE Tunnel feature supports tunneling of EoMPLS
traffic via an IPv6 network by using GRE tunnels. Effective from Cisco IOS XE
Release 3.15s, EoMPLS is supported over IPv6 GRE tunnel.
The following figure shows a deployment model of the EoMPLS over IPv6
GRE Tunnel on a Cisco ASR 1000 Series Aggregation Services Router.
Figure 4. EoMPLS over IPv6 GRE Tunnel Deployment on a Cisco ASR 1000 Series
Aggregation Services Router
Additional Information on EoMPLS
over IPv6 GRE Tunnel
For more information
on EoMPLS over IPv6 GRE Tunnel feature, see
GRE IPv6 Tunnels
chapter of the
Interface and
Hardware Component Configuration Guide, Cisco IOS XE Release 3S (ASR 1000).
How to Configure Any Transport over MPLS
This section explains how to perform a basic AToM configuration and includes the following procedures:
Configuring the Pseudowire
Class
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.
SUMMARY STEPS
enable
configure terminal
pseudowire-class name
encapsulation mpls
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
pseudowire-class name
Example:
Router(config)# pseudowire-class atom
Establishes a
pseudowire class with a name that you specify and enters pseudowire class
configuration mode.
Step 4
encapsulation mpls
Example:
Router(config-pw)# encapsulation mpls
Specifies the
tunneling encapsulation.
Configuring the Pseudowire Class Using Commands Associated with L2VPN Protocol-Based Feature
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 context command, you receive the following error:
% Incomplete command.
SUMMARY STEPS
enable
configure terminal
interface pseudowire name
encapsulation mpls
neighbor peer-address vcid-value
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
interface pseudowire name
Example:
Router(config)# interface pseudowire atom
Establishes an interface pseudowire with a name that you specify and enters pseudowire class configuration mode.
Step 4
encapsulation mpls
Example:
Router(config-pw-class)# encapsulation mpls
Specifies the tunneling encapsulation.
Step 5
neighbor peer-address vcid-value
Example:
Router(config-pw-class)# neighbor 33.33.33.33 1
Specifies the peer IP address and virtual circuit (VC) ID value of a Layer 2 VPN (L2VPN) pseudowire.
Changing the Encapsulation
Type and Removing a Pseudowire
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.
Changing the Encapsulation Type and Removing a Pseudowire Using Commands Associated with the L2VPN Protocol-Based Feature
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:
To remove the encapsulation mpls command, you must delete the pseudowire with the no interface 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
Configuring ATM AAL5 over
MPLS on PVCs
SUMMARY STEPS
enable
configure terminal
interface typeslot/ subslot/ port[. subinterface]
pvc [name]
vpi/ vcil2transport
encapsulation aal5
xconnect peer-router-idvcidencapsulation mpls
end
show mpls l2transport vc
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
interface typeslot/ subslot/ port[. subinterface]
Example:
Router(config)# interface atm1/0/0
Specifies the
interface type and enters interface configuration mode.
Step 4
pvc [name]
vpi/ vcil2transport
Example:
Router(config-if)# pvc 1/200 l2transport
Creates or
assigns a name to an ATM PVC and enters L2transport PVC configuration mode.
The
l2transport
keyword indicates that the PVC is a switched PVC instead of a terminated PVC.
Displays
output that shows ATM AAL5 over MPLS is configured on a PVC.
Examples
The following is
sample output from the
show mpls l2transport vc command that shows that ATM AAL5 over MPLS is
configured on a PVC:
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
Configuring ATM AAL5 over
MPLS on PVCs using the commands associated with the L2VPN Protocol-Based CLIs
feature
SUMMARY STEPS
enable
configure terminal
interface typeslot/ subslot/ port[. subinterface]
pvc [name]
vpi/ vcil2transport
encapsulation aal5
end
interface pseudowire number
encapsulation mpls
neighbor peer-addressvcid-value
exit
l2vpn xconnect context context-name
member pseudowire interface-number
member atm interface-numberpvc vpi/ vci
end
show l2vpn atom vc
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Device# configure terminal
Enters global
configuration mode.
Step 3
interface typeslot/ subslot/ port[. subinterface]
Example:
Device(config)# interface atm1/0/0
Specifies the
interface type and enters interface configuration mode.
Step 4
pvc [name]
vpi/ vcil2transport
Example:
Device(config-if)# pvc 1/200 l2transport
Creates or
assigns a name to an ATM PVC and enters L2transport PVC configuration mode.
The
l2transport
keyword indicates that the PVC is a switched PVC instead of a terminated PVC.
Specifies ATM
AAL5 encapsulation for the PVC. Make sure you specify the same encapsulation
type on the PE and customer edge (CE) routers.
Step 6
end
Example:
Device(config-if-atm-l2trans-pvc)# end
Exits to
privileged EXEC mode.
Step 7
interface pseudowire number
Example:
Device(config)# interface pseudowire 100
Specifies the
pseudowire interface and enters interface configuration mode.
Step 8
encapsulation mpls
Example:
Device(config-if)# encapsulation mpls
Specifies
that Multiprotocol Label Switching (MPLS) is used as the data encapsulation
method.
Step 9
neighbor peer-addressvcid-value
Example:
Device(config-if)# neighbor 10.13.13.13 100
Specifies the
peer IP address and virtual circuit (VC) ID value of the Layer 2 VPN (L2VPN)
pseudowire.
Step 10
exit
Example:
Device(config-if)# exit
Exits
interface configuration mode.
Step 11
l2vpn xconnect context context-name
Example:
Device(config)# l2vpn xconnect context con1
Creates a Layer
2 VPN (L2VPN) cross connect context and enters xconnect configuration mode.
Step 12
member pseudowire interface-number
Example:
Device(config-xconnect)# member pseudowire 100
Specifies a
member pseudowire to form a Layer 2 VPN (L2VPN) cross connect.
Step 13
member atm interface-numberpvc vpi/ vci
Example:
Device(config-xconnect)# member atm 100 pvc 1/200
Specifies the
location of the ATM member interface.
Step 14
end
Example:
Device(config-xconnect)# end
Exits to
privileged EXEC mode.
Step 15
show l2vpn atom vc
Example:
Device# show l2vpn atom vc
Displays
output that shows ATM AAL5 over MPLS is configured on a PVC.
Examples
The following is
sample output from the
show l2vpn atom vc command that shows that ATM AAL5 over MPLS is
configured on a PVC:
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
Configuring ATM AAL5 over
MPLS in VC Class Configuration Mode
SUMMARY STEPS
enable
configure terminal
vc-class atm vc-class-name
encapsulation layer-type
exit
interface typeslot/ subslot/ port[. subinterface]
class-int vc-class-name
pvc [name]
vpi/ vcil2transport
xconnect peer-router-idvcidencapsulation mpls
end
show atm class-links
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
vc-class atm vc-class-name
Example:
Router(config)# vc-class atm aal5class
Creates a VC
class and enters VC class configuration mode.
Step 4
encapsulation layer-type
Example:
Router(config-vc-class)# encapsulation aal5
Configures the
AAL and encapsulation type.
Step 5
exit
Example:
Router(config-vc-class)# exit
Exits VC class
configuration mode.
Step 6
interface typeslot/ subslot/ port[. subinterface]
Example:
Router(config)# interface atm1/0/0
Specifies the
interface type enters interface configuration mode.
Step 7
class-int vc-class-name
Example:
Router(config-if)# class-int aal5class
Applies a VC
class to the ATM main interface or subinterface.
Note
You can also
apply a VC class to a PVC.
Step 8
pvc [name]
vpi/ vcil2transport
Example:
Router(config-if)# pvc 1/200 l2transport
Creates or
assigns a name to an ATM PVC and enters L2transport PVC configuration mode.
The
l2transport
keyword indicates that the PVC is a switched PVC instead of a terminated PVC.
Displays the
type of encapsulation and that the VC class was applied to an interface.
Examples
In the following
example, the command output from the
show atm class-links command verifies that ATM AAL5 over
MPLS is configured as part of a VC class. The command output shows the type of
encapsulation and that the VC class was applied to an interface.
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
Configuring ATM AAL5 over
MPLS in VC Class Configuration Mode using the commands associated with the
L2VPN Protocol-Based CLIs feature
SUMMARY STEPS
enable
configure terminal
vc-class atm vc-class-name
encapsulation layer-type
exit
interface typeslot/ subslot/ port[. subinterface]
class-int vc-class-name
pvc [name]
vpi/ vcil2transport
exit
interface pseudowire number
encapsulation mpls
neighbor peer-addressvcid-value
exit
l2vpn xconnect context context-name
member pseudowire interface-number
member atm interface-number
end
show atm class-links
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
vc-class atm vc-class-name
Example:
Router(config)# vc-class atm aal5class
Creates a VC
class and enters VC class configuration mode.
Step 4
encapsulation layer-type
Example:
Router(config-vc-class)# encapsulation aal5
Configures the
AAL and encapsulation type.
Step 5
exit
Example:
Router(config-vc-class)# exit
Exits VC class
configuration mode.
Step 6
interface typeslot/ subslot/ port[. subinterface]
Example:
Router(config)# interface atm1/0/0
Specifies the
interface type enters interface configuration mode.
Step 7
class-int vc-class-name
Example:
Router(config-if)# class-int aal5class
Applies a VC
class to the ATM main interface or subinterface.
Note
You can also
apply a VC class to a PVC.
Step 8
pvc [name]
vpi/ vcil2transport
Example:
Router(config-if)# pvc 1/200 l2transport
Creates or
assigns a name to an ATM PVC and enters L2transport PVC configuration mode.
The
l2transport
keyword indicates that the PVC is a switched PVC instead of a terminated PVC.
Step 9
exit
Example:
Router(config-if)# exit
Exits
interface configuration mode.
Step 10
interface pseudowire number
Example:
Router(config)# interface pseudowire 100
Specifies the
pseudowire interface and enters interface configuration mode.
Step 11
encapsulation mpls
Example:
Router(config-if)# encapsulation mpls
Specifies
that Multiprotocol Label Switching (MPLS) is used as the data encapsulation
method.
Step 12
neighbor peer-addressvcid-value
Example:
Router(config-if)# neighbor 10.0.0.1 123
Specifies the
peer IP address and virtual circuit (VC) ID value of the Layer 2 VPN (L2VPN)
pseudowire.
Step 13
exit
Example:
Router(config-if)# exit
Exits
interface configuration mode.
Step 14
l2vpn xconnect context context-name
Example:
Router(config)# l2vpn xconnect context con1
Creates a
Layer 2 VPN (L2VPN) cross connect context and enters xconnect configuration
mode.
Step 15
member pseudowire interface-number
Example:
Router(config-xconnect)# member pseudowire 100
Specifies a
member pseudowire to form a Layer 2 VPN (L2VPN) cross connect.
Step 16
member atm interface-number
Example:
Device(config-xconnect)# member atm 100
Specifies the
location of the ATM member interface.
Step 17
end
Example:
Router(config-if-atm-l2trans-pvc)# end
Exits to
privileged EXEC mode.
Step 18
show atm class-links
Example:
Router# show atm class-links
Displays the
type of encapsulation and that the VC class was applied to an interface.
Examples
In the following
example, the command output from the
show atm class-links command verifies that ATM AAL5 over
MPLS is configured as part of a VC class. The command output shows the type of
encapsulation and that the VC class was applied to an interface.
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
Configuring OAM Cell Emulation for ATM AAL5 over MPLS
Configuring OAM Cell
Emulation for ATM AAL5 over MPLS on PVCs
SUMMARY STEPS
enable
configure terminal
interface typeslot/ subslot/ port[. subinterface]
pvc [name]
vpi/ vcil2transport
encapsulation aal5
xconnect peer-router-idvcidencapsulation mpls
oam-ac emulation-enable [ais-rate]
oam-pvcmanage [frequency]
end
show atm pvc
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
interface typeslot/ subslot/ port[. subinterface]
Example:
Router(config)# interface atm1/0/0
Specifies the
interface type enters interface configuration mode.
Step 4
pvc [name]
vpi/ vcil2transport
Example:
Router(config-if)# pvc 1/200 l2transport
Creates or
assigns a name to an ATM PVC and enters L2transport PVC configuration mode.
The
l2transport
keyword indicates that the PVC is a switched PVC instead of a terminated PVC.
Enables OAM
cell emulation for AAL5 over MPLS. The
ais-rate
argument lets you specify the rate at which AIS cells are sent. The default is
one cell every second. The range is 0 to 60 seconds.
Step 8
oam-pvcmanage [frequency]
Example:
Router(config-if-atm-l2trans-pvc)# oam-pvc manage
Enables the
PVC to generate end-to-end OAM loopback cells that verify connectivity on the
virtual circuit.
The optional
frequency
argument is the interval between transmission of loopback cells and ranges from
0 to 600 seconds. The default value is 10 seconds.
Step 9
end
Example:
Router(config-if-atm-l2trans-pvc)# end
Exits to
privileged EXEC mode.
Step 10
show atm pvc
Example:
Router# show atm pvc
Displays
output that shows OAM cell emulation is enabled on the ATM PVC.
Examples
The following
output from the
show atm pvc command shows that OAM cell emulation is
enabled on the ATM PVC:
Enables OAM
cell emulation for AAL5 over MPLS. The
ais-rate
argument lets you specify the rate at which AIS cells are sent. The default is
one cell every second. The range is 0 to 60 seconds.
Step 17
oam-pvcmanage [frequency]
Example:
Router(config-if-atm-l2trans-pvc)# oam-pvc manage
Enables the
PVC to generate end-to-end OAM loopback cells that verify connectivity on the
virtual circuit.
The optional
frequency
argument is the interval between transmission of loopback cells and ranges from
0 to 600 seconds. The default value is 10 seconds.
Step 18
end
Example:
Router(config-if-atm-l2trans-pvc)# end
Exits to
privileged EXEC mode.
Step 19
show atm pvc
Example:
Router# show atm pvc
Displays
output that shows OAM cell emulation is enabled on the ATM PVC.
Examples
The following
output from the
show atm pvc command shows that OAM cell emulation is
enabled on the ATM PVC:
Configuring OAM Cell
Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode using the
commands associated with the L2VPN Protocol-Based CLIs feature
SUMMARY STEPS
enable
configure terminal
vc-class atm name
encapsulation layer-type
oam-ac emulation-enable [ais-rate]
oam-pvc manage [frequency]
exit
interface typeslot/ subslot/ port[. subinterface]
class-int vc-class-name
pvc [name]
vpi/ vcil2transport
end
interface pseudowire number
encapsulation mpls
neighbor peer-addressvcid-value
exit
l2vpn xconnect context context-name
member pseudowire interface-number
member atm interface-number
end
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
vc-class atm name
Example:
Router(config)# vc-class atm oamclass
Creates a VC
class and enters VC class configuration mode.
Configuring ATM Cell Relay
over MPLS in VC Mode Using VC Class Configuration Mode using the commands
associated with the L2VPN Protocol-Based CLIs feature
SUMMARY STEPS
enable
configure terminal
vc-class atm name
encapsulation layer-type
exit
interface typeslot/ subslot/ port[. subinterface]
class-int vc-class-name
pvc [name]
vpi/ vcil2transport
end
interface pseudowire number
encapsulation mpls
neighbor peer-addressvcid-value
exit
l2vpn xconnect context context-name
member pseudowire interface-number
member atm interface-number
end
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
vc-class atm name
Example:
Router(config)# vc-class atm cellrelay
Creates a VC
class and enters VC class configuration mode.
Step 4
encapsulation layer-type
Example:
Router(config-vc-class)# encapsulation aal0
Configures the
AAL and encapsulation type.
Step 5
exit
Example:
Router(config-vc-class)# exit
Exits VC class
configuration mode.
Step 6
interface typeslot/ subslot/ port[. subinterface]
Example:
Router(config)# interface atm1/0/0
Specifies the
interface type and enters interface configuration mode.
Step 7
class-int vc-class-name
Example:
Router(config-if)# class-int cellrelay
Applies a VC
class to the ATM main interface or subinterface.
Note
You can also
apply a VC class to a PVC.
Step 8
pvc [name]
vpi/ vcil2transport
Example:
Router(config-if)# pvc 1/200 l2transport
Creates or
assigns a name to an ATM PVC and enters L2transport PVC configuration mode.
Step 9
end
Example:
Router(config-if-atm-l2trans-pvc)# end
Exits to
privileged EXEC mode.
Step 10
interface pseudowire number
Example:
Router(config)# interface pseudowire 100
Specifies the
pseudowire interface and enters interface configuration mode.
Step 11
encapsulation mpls
Example:
Router(config-if)# encapsulation mpls
Specifies
that Multiprotocol Label Switching (MPLS) is used as the data encapsulation
method.
Step 12
neighbor peer-addressvcid-value
Example:
Router(config-if)# neighbor 10.0.0.1 123
Specifies the
peer IP address and virtual circuit (VC) ID value of the Layer 2 VPN (L2VPN)
pseudowire.
Step 13
exit
Example:
Router(config-if)# exit
Exits
interface configuration mode.
Step 14
l2vpn xconnect context context-name
Example:
Router(config)# l2vpn xconnect context con1
Creates a
Layer 2 VPN (L2VPN) cross connect context and enters xconnect configuration
mode.
Step 15
member pseudowire interface-number
Example:
Router(config-xconnect)# member pseudowire 100
Specifies a
member pseudowire to form a Layer 2 VPN (L2VPN) cross connect.
Step 16
member atm interface-number
Example:
Device(config-xconnect)# member atm 100
Specifies the
location of the ATM member interface.
Step 17
end
Example:
Router(config-xconnect)# end
Exits to
privileged EXEC mode.
Configuring ATM Cell Relay
over MPLS in PVP Mode
SUMMARY STEPS
enable
configure terminal
interface atm slot/ subslot/ port[. subinterface]
atm pvp vpil2transport
xconnect peer-router-idvcidencapsulation mpls
end
show atm vp
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configure terminal
Example:
Router# configure terminal
Enters global
configuration mode.
Step 3
interface atm slot/ subslot/ port[. subinterface]
Example:
Router(config)# interface atm1/0/0
Defines the
interface and enters interface configuration mode.
Step 4
atm pvp vpil2transport
Example:
Router(config-if)# atm pvp 1 l2transport
Specifies that
the PVP is dedicated to transporting ATM cells and enters L2transport PVP
configuration mode.
The
l2transport
keyword indicates that the PVP is for cell relay. This mode is for Layer 2
transport only; it is not for regular PVPs.
Configuring Ethernet over MPLS in VLAN Mode to Connect Two VLAN Networks That Are in Different Locations using the commands
associated with the L2VPN Protocol-Based CLIs feature
