Multiprotocol Label Switching over ATM (MPLS over ATM)

Understanding Multiprotocol Label Switching (MPLS) Label Imposition in an ATM Environment

Document ID: 10477

Updated: Jun 05, 2005



This document describes the path used by an IP packet when it travels through an MPLS-enabled ATM core and describes the major show commands.

Note: The routers in this document are from the Cisco 3600 series that run Cisco IOS® Version 12.0(7)T and use OC-3 interfaces. The ATM LSR is an 8540MSR.



There are no specific requirements for this document.


Refer to Cisco Technical Tips Conventions for more information on document conventions.

Network Diagram

The scenarios in this document are based on this setup. In order to view the configurations for these devices, refer to this sample configuration.


Show Commands


Guilder is an interesting router in this setup since it imposes labels to the IP packets that come from the Ethernet side. Since we work on an ATM interface that is connected to an MPLS-enabled ATM core, the imposed label means a forwarded IP packet on a Tag VC (TVC).

In this scenario, Pound sends IP packets to Lira. For example, if you ping from Pound, it works as expected:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

From Guilder's routing table, we can easily see that the destination can be reached through the ATM cloud:

Guilder#show ip route
Routing entry for
  Known via "ospf 1", distance 110, metric 12, type inter area
  Redistributing via ospf 1
  Last update from on ATM1/0.1, 01:15:26 ago
  Routing Descriptor Blocks:
  *, from, 01:15:26 ago, via ATM1/0.1
      Route metric is 12, traffic share count is 1

We have configured the ATM subinterface 1/0.1 to label the outbound IP packets, so we can receive more details through the Tag forwarding table:

Guilder#show tag-switching forwarding-table detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
30     2/36    0          AT1/0.1    point2point
        MAC/Encaps=4/8, MTU=4470, Tag Stack{2/36(vcd=299)}
        012B0900 0012B000

We see now that Guilder imposes the outbound TVC VPI 2, VCI 36, which corresponds to VCD 299. This information is saved in the CEF forwarding table:

Guilder#show ip cef detail, version 143, cached adjacency to ATM1/0.1
0 packets, 0 bytes
  tag information set
    local tag: 30
    fast tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}
  via, ATM1/0.1, 0 dependencies
    next hop, ATM1/0.1
    valid cached adjacency
    tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}

The IP packets are indeed sent on the right VC:

Guilder#show atm vc 299
ATM1/0.1: VCD: 299, VPI: 2, VCI: 36
UBR, PeakRate: 155000
AAL5-MUX, etype:0x8847, Flags: 0x40C84, VCmode: 0x0
OAM frequency: 0 second(s)
Transmit priority 0
InPkts: 0, OutPkts: 5, InBytes: 0, OutBytes: 540
InPRoc: 0, OutPRoc: 0
InFast: 0, OutFast: 5, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 
0OAM cells received: 
0OAM cells sent: 0
Status: UP
Tag VC: local tag: 0

As you see, only five IP packets have been sent. This is synchronized with the simple ping that we initiated. At the same time, you can wonder why we do not see five input packets. In other words, why are the outbound and inbound paths different? This is normal since there is one VC per route entry (per prefix), and, as a result, the TVCs are unidirectional.


Surprisingly, there is not much we can get from the switch when all routes/VCs are stable; it merely switches ATM cells. See this example:

Capri#show tag atm-tdp bindings 16
    Transit ATM3/0/3 2/36 Active -> ATM3/0/0 2/38 Active

Some details must be pointed out. Examine this output:

Capri#show atm vc conn-type tvc int atm 3/0/3
Interface         VPI  VCI   Type   X-Interface      X-VPI X-VCI Encap  Status 
ATM3/0/3          2    33    TVC(I) ATM3/0/0          2    36           UP
ATM3/0/3          2    33    TVC(O) ATM3/0/0          2    53           UP
ATM3/0/3          2    34    TVC(I) ATM0              0    317   MUX    UP
ATM3/0/3          2    34    TVC(O) ATM3/0/0          2    54           UP
ATM3/0/3          2    35    TVC(I) ATM3/0/0          2    37           UP
ATM3/0/3          2    35    TVC(O) ATM3/0/0          2    55           UP
ATM3/0/3          2    36    TVC(I) ATM3/0/0          2    38           UP
ATM3/0/3          2    37    TVC(I) ATM0              0    318   MUX    UP

As we can see, some TVCs end on the interface ATM0. On a 8540MSR, the interface ATM0 corresponds to the CPU. Those TVCs correspond to IP addresses local to the 8540MSR, such as a local loopback.

We know that Guilder sends IP packets with destination on TVC 2/36. On the LSR side, this TVC is an inbound (I) TVC only.


In order to reach, we expect the IP packets to be sent to the Fast Ethernet interface 0/0 in accordance with the network diagram. We know we have not configured Label Switching on this Fast Ethernet interface. This is the result:

damme#show tag-switching forwarding-table detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface

As a result, there is no label to add. Only the information of the routing table is used:

damme#show ip route
 Routing entry for
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 1
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/0
      Route metric is 0, traffic share count is 1

This information is saved once again in the CEF switching table:

damme#show ip cef detail, version 62, connected, cached adjacency
0 packets, 0 bytes
  via, FastEthernet0/0, 0 dependencies
    next hop, FastEthernet0/0
    valid cached adjacency 

Related Information

Updated: Jun 05, 2005
Document ID: 10477