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.
The scenarios in this document are based on this setup. In order to view the configurations for these devices, refer to this sample configuration.
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 125.125.0.2 from Pound, it works as expected:
Pound#ping 125.125.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 125.125.0.2, 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 125.125.0.2 Routing entry for 125.125.0.0/16 Known via "ospf 1", distance 110, metric 12, type inter area Redistributing via ospf 1 Last update from 129.129.0.2 on ATM1/0.1, 01:15:26 ago Routing Descriptor Blocks: * 129.129.0.2, from 120.120.0.1, 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 125.125.0.2 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 30 2/36 125.125.0.0/16 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 125.125.0.2 detail 125.125.0.0/16, 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 129.129.0.2, ATM1/0.1, 0 dependencies next hop 129.129.0.2, 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) InARP DISABLED 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 125.125.0.0 16 Destination: 125.125.0.0/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 125.125.0.2 on TVC 2/36. On the LSR side, this TVC is an inbound (I) TVC only.
In order to reach 125.125.0.2, 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 125.125.0.2 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface damme#
As a result, there is no label to add. Only the information of the routing table is used:
damme#show ip route 125.125.0.2 Routing entry for 125.125.0.0/16 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 125.125.0.2 detail 125.125.0.2/32, version 62, connected, cached adjacency 125.125.0.2 0 packets, 0 bytes via 125.125.0.2, FastEthernet0/0, 0 dependencies next hop 125.125.0.2, FastEthernet0/0 valid cached adjacency
Revision | Publish Date | Comments |
---|---|---|
1.0 |
05-Jun-2005 |
Initial Release |