Any Transport over MPLS

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 can set up the connection, called a pseudowire, between the routers and 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 the 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.

In releases of AToM before Cisco IOS 12.0(25)S, the mpls l2 transport routecommand was used to configure AToM circuits.This command has been replaced with the xconnectcommand.

No enhancements will be made to the mpls l2transport routecommand. Enhancements will be made to either the xconnectcommand or the pseudowire-classcommand. Therefore, Cisco recommends that you use the xconnect command to configure AToM circuits.

Configurations from releases before Cisco IOS 12.0(25)S that use the mpls l2transport routecommand are still supported.

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, such as the Cisco 7200 and Cisco 7500 series routers. This enables the service provider to transport all types of traffic over the backbone and accommodate all types of customers.
• AToM adheres to the standards developed for transporting Layer 2 packets over MPLS. (See the "Standards" section for the specific standards that AToM follows.) 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 the standard fast reroute (FRR) 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. For more information on configuring MPLS TE fast reroute, see the following document:

MPLS Traffic Engineering (TE)--Link and Node Protection, with RSVP Hellos Support

Note

The AToM VC independence feature was introduced in Cisco IOS Release 12.0(31)S. This feature enables the Cisco 12000 series router to perform fast reroute in fewer than 50 milliseconds, regardless of the number of VCs configured. In previous releases, the fast reroute time depended on the number of VCs inside the protected TE tunnel.

For the Cisco 12000 series routers, fast reroute uses three or more labels, depending on where the TE tunnel ends:

• If the TE tunnel is from a PE router to a PE router, three labels are used.
• If the TE tunnel is from a PE router to the core router, four labels are used.

Engine 0 ATM line cards support three or more labels, but the performance degrades. Engine 2 Gigabit Ethernet line cards and engine 3 line cards support three or more labels and can work with the fast reroute feature.

You can issue the debug mpls l2transport fast-reroutecommand to debug fast reroute with AToM.

Note

This command does not display output on platforms where AToM fast reroute is implemented in the forwarding code. The command does display output on Cisco 10720 Internet router line cards and Cisco 12000 series line cards. This command does not display output for the Cisco 7500 (both Route Processor (RP) and Versatile Interface Processor (VIP)) series routers, Cisco 7200 series routers, and Cisco 12000 series RP.

In the following example, the primary link is disabled, which causes the backup tunnel (Tunnel 1) to become the primary path. In the following example, bolded output 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, 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, 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:

• Example Estimating Packet Size
  
• mpls mtu Command Changes
  

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.

• Local Management Interface and Frame Relay over MPLS
  

For information about configuring QoS features on Cisco 12000 series routers, see the following feature module:

Any Transport over MPLS (AToM): Layer 2 QoS for the Cisco 12000 Series Router (Quality of Service)

The tables below list the QoS features supported by AToM on the Cisco 7200 and 7500 series routers.

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.

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

The pseudowire-class configuration group specifies the following characteristics of the tunneling mechanism:

• Encapsulation type
• Control protocol
• Payload-specific options

For more information about the pseudowire-classcommand, see the following feature module: Layer 2 Tunnel Protocol Version 3.

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

% Incomplete command.

1.    enable

2.    configure terminal

3.    pseudowire-class name

4.    encapsulation mpls

5.    end

To change the type of encapsulation, remove the pseudowire with the no pseudowire-class command, reestablish the pseudowire, and specify the new encapsulation type.

Once you specify the encapsulation mpls command, you can neither remove it using the no encapsulation mplscommand nor change the command setting using the encapsulation l2tpv3 command. If you try to remove or change the encapsulation type using the above-mentioned commands, you will get the following error message:

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

To remove a pseudowire, use the clear xconnect command in privileged EXEC mode. You can remove all pseudowires or specific pseudowires on an interface or peer router.

ATM AAL5 over MPLS for PVCs encapsulates ATM AAL5 service data unit (SDUs) in MPLS packets and forwards them across the MPLS network. Each ATM AAL5 SDU is transported as a single packet.

Note	AAL5 over MPLS is supported only in SDU mode. >

1.    enable

2.    configure terminal

3.    interface typeslot/port

4.    pvc [name] vpi/vci l2transport

5.    encapsulation aal5

6.    xconnect peer-router-id vcid encapsulation mpls

7.    exit

8.    exit

9.    exit

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

You can create a VC class that specifies the AAL5 encapsulation and then attach the encapsulation type to an interface, subinterface, or PVC. The following task creates a VC class and attaches it to a main interface.

Note	AAL5 over MPLS is supported only in SDU mode. >

1.    enable

2.    configure terminal

3.    vc-class atm vc-class-name

4.    encapsulation layer-type

5.    exit

6.    interface typeslot/port

7.    class-int vc-class-name

8.    pvc [name] vpi/vci l2transport

9.    xconnect peer-router-id vcid encapsulation mpls

10.    exit

11.    exit

12.    exit

13.    show atm class-links

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

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 the oam-ac emulation-enableand oam-pvc managecommands 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 section contains two tasks:

• Configuring OAM Cell Emulation for ATM AAL5 over MPLS on PVCs
  
• Configuring OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode
  

1.    enable

2.    configure terminal

3.    interface atm slot /port

4.    pvc vpi/vci l2transport

5.    encapsulation aal0

6.    xconnect peer-router-id vcid encapsulation mpls

7.    exit

8.    exit

9.    exit

10.    show atm vc

Router# show atm vc 7
ATM3/0: VCD: 7, VPI: 23, VCI: 100
UBR, PeakRate: 149760
AAL0-Cell Relay, etype:0x10, Flags: 0x10000C2D, VCmode: 0x0
OAM Cell Emulation: not configured
InBytes: 0, OutBytes: 0
Status: UP

You can create a VC class that specifies the ATM cell relay encapsulation and then attach the VC class to an interface, subinterface, or VC. The following task creates a VC class that specifies the ATM cell relay encapsulation and attaches it to a main interface.

Note	You can configure VC class configuration mode only in VC mode. VC class configuration mode is not supported on VP or port mode.

1.    enable

2.    configure terminal

3.    vc-class atm name

4.    encapsulation layer-type

5.    exit

6.    interface typeslot /port

7.    class-int vc-class-name

8.    pvc [name] vpi/vci l2transport

9.    xconnect peer-router-id vcid encapsulation mpls

10.    end

1.    enable

2.    configure terminal

3.    interface atm slot /port

4.    atm pvp vpi l2transport

5.    xconnect peer-router-id vcid encapsulation mpls

6.    exit

7.    exit

8.    exit

9.    show atm vp

Router# show atm vp 1
ATM5/0  VPI: 1, Cell Relay, PeakRate: 149760, CesRate: 0, DataVCs: 1, CesVCs: 0, Status: ACTIVE
  VCD    VCI   Type   InPkts   OutPkts   AAL/Encap     Status
  6      3     PVC    0        0         F4 OAM        ACTIVE  
  7      4     PVC    0        0         F4 OAM        ACTIVE  
TotalInPkts: 0, TotalOutPkts: 0, TotalInFast: 0, TotalOutFast: 0,
TotalBroadcasts: 0 TotalInPktDrops: 0, TotalOutPktDrops: 0

Port mode cell relay allows cells coming into an ATM interface to be packed into an MPLS packet and transported over the MPLS backbone to an egress ATM interface.

To configure port mode, issue the xconnect command from an ATM main interface and specify the destination address and the VC ID. The syntax of the xconnect command is the same as for all other transport types. Each ATM port is associated with one unique pseudowire VC label.

When configuring ATM cell relay over MPLS in port mode, use the following guidelines:

• The pseudowire VC type is set to ATM transparent cell transport (AAL0).
• 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.

Note	The AToM control word is not supported for port mode cell relay on Cisco 7600 series routers.

• Port mode and VP and VC mode are mutually exclusive. If you enable an ATM main interface for cell relay, you cannot enter any PVP or PVC commands.
• If the pseudowire VC label is withdrawn due to an MPLS core network failure, the PE router sends a line AIS to the CE router.
• For the Cisco 7600 series routers, you must specify the interface ATM slot, bay, and port for the SIP400 or SIP200.

1.    enable

2.    configure terminal

3.    interface atm slot /port

4.    xconnect peer-router-id vcid encapsulation mpls

5.    exit

6.    exit

7.    show atm route

8.    show mpls l2transport vc

Router# show atm route
Input Intf        Output Intf     Output VC       Status
ATM1/0            ATOM Tunnel     123             DOWN

Router# show mpls l2transport vc
Local intf     Local circuit        Dest address    VC ID      Status    
-------------  -------------------- --------------- ---------- ----------
AT1/0          ATM CELL ATM1/0      10.1.1.121     1121       UP      

• Troubleshooting Tips
  

1.    enable

2.    configure terminal

3.    interface atm slot/port

4.    pvc vpi/vci l2transport

5.    encapsulation aal0

6.    xconnect peer-router-id vcid encapsulation mpls

7.    end

The packed cell relay feature allows you to insert multiple concatenated ATM cells in an MPLS packet. The packed cell relay feature is more efficient than single cell relay, because each ATM cell is 52 bytes, and each AToM packet is at least 64 bytes.

At a high level, packed cell relay configuration consists of the following steps:

1. You specify the amount of time a PE router can wait for cells to be packed into an MPLS packet. You can set up three timers by default with different amounts of time attributed to each timer.
2. You enable packed cell relay, specify how many cells should be packed into each MPLS packet, and choose which timer to use during the cell packing process.

• Restrictions
  
• Configuring ATM Packed Cell Relay over MPLS in VC Mode
  
• Configuring ATM Packed Cell Relay over MPLS in VC Mode Using VC Class Configuration Mode
  
• Configuring ATM Packed Cell Relay over MPLS in VP Mode
  
• Configuring ATM Packed Cell Relay over MPLS in Port Mode
  
• Troubleshooting Tips
  

A 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 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. Ethernet over MPLS in VLAN mode transports Ethernet traffic from a source 802.1Q VLAN to a destination 802.1Q VLAN over a core MPLS network.

Note	You must configure Ethernet over MPLS (VLAN mode) on the subinterfaces.

1.    enable

2.    configure terminal

3.    interface gigabitethernet slot /interface.subinterface

4.    encapsulation dot1q vlan-id

5.    xconnect peer-router-id vcid encapsulation mpls

6.    end

1.    enable

2.    configure terminal

3.    interface gigabitethernet slot/interface

4.    xconnect peer-router-id vcid encapsulation mpls

5.    exit

6.    exit

7.    show mpls l2transport vc

Router# show mpls l2transport vc detail
Local interface: Gi4/0.1 up, line protocol up, Eth VLAN 2 up
Destination address: 10.1.1.1, VC ID: 2, VC status: up
.
.
.
Local interface: Gi8/0/1 up, line protocol up, Ethernet up
  Destination address: 10.1.1.1, VC ID: 8, VC status: up

The VLAN ID rewrite feature enables you to use VLAN interfaces with different VLAN IDs at both ends of the tunnel.

The Cisco 12000 series router requires you to configure VLAN ID rewrite manually, as described in the following sections.

The following routers automatically perform VLAN ID rewrite on the disposition PE router. No configuration is required:

• Cisco 7200 series routers.
• Cisco 7500 series routers.
• Cisco 10720 series routers.
• Routers supported on Cisco IOS Release 12.4(11)T. (Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support.)

The following sections explain how to configure the VLAN ID rewrite feature:

Use the following guidelines for the VLAN ID rewrite feature for the Cisco 12000 series routers in Cisco IOS releases earlier than 12.0(29)S:

• The IP Service Engine (ISE) 4-port Gigabit Ethernet line card performs the VLAN ID rewrite on the disposition side at the edge-facing line card.
• The engine 2 3-port Gigabit Ethernet line card performs the VLAN ID rewrite on the imposition side at the edge-facing line card.

The VLAN ID rewrite functionality requires that both ends of the Ethernet over MPLS connections be provisioned with the same line cards. Make sure that both edge-facing ends of the virtual circuit use either the engine 2 or ISE Ethernet line card. The following example shows the system flow with the VLAN ID rewrite feature:

• The ISE 4-port Gigabit Ethernet line card:

Traffic flows from VLAN1 on CE1 to VLAN2 on CE2. As the frame reaches the edge-facing line card of the disposition router PE2, the VLAN ID in the dot1Q header changes to the VLAN ID assigned to VLAN2.

• The engine 2 3-port Gigabit Ethernet line card:

Traffic flows from VLAN1 on CE1 to VLAN2 on CE2. As the frame reaches the edge-facing line card of the imposition router PE1, the VLAN ID in the dot1Q header changes to the VLAN ID assigned to VLAN2.

For the Cisco 12000 series router engine 2 3-port Gigabit Ethernet line card, you must issue the remote circuit id command as part of the Ethernet over MPLS VLAN ID rewrite configuration.

1.    enable

2.    configure terminal

3.    interface gigabitethernet slot /interface.subinterface

4.    encapsulation dot1q vlan-id

5.    xconnect peer-router-id vcid encapsulation mpls

6.    remote circuit id remote-vlan-id

7.    exit

8.    exit

9.    exit

10.    show controllers eompls forwarding-table

Router# execute slot 0 show controllers eompls forwarding-table 0 2
Port # 0, VLAN-ID # 2, Table-index 2
EoMPLS configured: 1
tag_rew_ptr             = D001BB58
Leaf entry?     = 1
FCR index       = 20
           **tagrew_psa_addr    = 0006ED60
           **tagrew_vir_addr    = 7006ED60
           **tagrew_phy_addr    = F006ED60
        [0-7] loq 8800 mtu 4458  oq 4000 ai 3 oi 04019110 (encaps size 4)
        cw-size 4 vlanid-rew 3
        gather A30 (bufhdr size 32 EoMPLS (Control Word) Imposition profile 81)
        2 tag: 18 18
        counters 1182, 10 reported 1182, 10.
    Local OutputQ (Unicast):    Slot:2  Port:0  RED queue:0  COS queue:0
    Output Q (Unicast):         Port:0          RED queue:0  COS queue:0

Router# execute slot 0 show controllers eompls forwarding-table 0 3
 
Port # 0, VLAN-ID # 3, Table-index 3
EoMPLS configured: 1
tag_rew_ptr             = D0027B90
Leaf entry?     = 1
FCR index       = 20
           **tagrew_psa_addr    = 0009EE40
           **tagrew_vir_addr    = 7009EE40
           **tagrew_phy_addr    = F009EE40
        [0-7] loq 9400 mtu 4458  oq 4000 ai 8 oi 84000002 (encaps size 4)
        cw-size 4 vlanid-rew 2
        gather A30 (bufhdr size 32 EoMPLS (Control Word) Imposition profile 81)
        2 tag: 17 18
        counters 1182, 10 reported 1182, 10.
    Local OutputQ (Unicast):    Slot:5  Port:0  RED queue:0  COS queue:0
    Output Q (Unicast):         Port:0          RED queue:0  COS queue:0

Cisco IOS Release 12.2(33)SRC introduces the ability to specify MTU values 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.

Note

Configuring the MTU value in xconnect subinterface configuration mode has the following 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: Ethernet FastEthernet 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. >

1.    enable

2.    configure terminal

3.    interface gigabitethernet slot /interface

4.    mtu mtu-value

5.    interface gigabitethernet slot /interface.subinterface

6.    encapsulation dot1q vlan-id

7.    xconnect peer-router-id vcid encapsulation mpls

8.    mtu mtu-value

9.    end

10.    show mpls l2transport binding

1.    enable

2.    configure terminal

3.    frame-relay switching

4.    interface serial slot /port

5.    encapsulation frame-relay [cisco | ietf]

6.    frame-relay intf-type dce

7.    exit

8.    connect connection-name interface dlci l2transport

9.    xconnect peer-router-id vcid encapsulation mpls

10.    end