This document provides an overview of the address resolution and packet encapsulation methods used on ATM networks. It also provides troubleshooting steps to use if you are unable to ping across an ATM cloud when enabling a new permanent virtual circuit (PVC).
When using routed RFC 1483 , you can think of ATM as a layer 2 protocol used to transmit IP and other layer 3 packets over a physical wire. In fact, ATM is very similar to Ethernet technology. These two rules are necessary for successful communication on Ethernet networks:
Address resolution—You must resolve the destination IP address to the destination MAC address. IP uses the address resolution protocol (ARP) to discover this mapping dynamically. You can also configure static ARP entries on a router or a host.
Packet encapsulation—You must include a header that tells the receiver what the next higher-layer protocol or header is. Ethernet typically uses an Logical Link Control (LLC) or Subnetwork Access Protocol (SNAP) header. For example, a destination service access point (DSAP) or source service access point (SSAP) value of “AA” in an LLC header indicates that a SNAP header follows. A SNAP header includes an Organizational Unique Identifier (OUI)—or an OUI field—and a Protocol Identifier (PID) field. A PID of “0800” indicates that the data part of the Ethernet frame contains an IP packet.
This document is not restricted to specific software or hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Like Frame Relay, ATM supports two types of interface: point-to-point and multipoint. The one you choose determines whether you need to use the configuration commands that ensure IP-to-ATM mappings. After configuring the PVC itself, you must tell the router which PVC to use in order to reach a specific destination. Consider these options:
Point-to-point subinterface—With point-to-point subinterfaces, each pair of routers has its own subnet. If you put the PVC on a point-to-point subinterface, the router assumes that there is only one point-to-point PVC configured on the subinterface. Therefore, any IP packets with a destination IP address in the same subnet are forwarded on this virtual circuit (VC). This is the simplest way to configure the mapping and is therefore the recommended method.
Multipoint networks—Multipoint networks have three or more routers in the same subnet. If you put the PVC in a point-to-multipoint subinterface or in the main interface (which is multipoint by default), you need to either configure a static mapping or enable inverse Address Resolution Protocol (ARP) for dynamic mapping.
On Ethernet networks, IP-based network devices use ARP when they know the destination layer 3 address and need to discover the destination MAC address. Layer 2 network devices use inverse ARP (InARP) when they know the destination MAC address and need to discover the destination layer 3 address.
On ATM networks, RFC 1577, Classical IP and ARP over ATM, specifies mechanisms for address resolution and defines the Inverse ATM Address Resolution Protocol (InATMARP).
With InATMARP, the ATM interface knows the layer 2 address. This is the PVC’s virtual path identifier (VPI) or virtual channel identifier (VCI). However, it still needs to discover which IP address is reachable at the remote end of a connection. To do this, the router sends an InATMARP request over a virtual connection for the address of the other end.
Note: InATMARP is the same protocol as Ethernet InARP. This is defined in RFC 1293 , with additional extensions to support ARP in an ATM network.
Neither a static mapping nor InARP are required on a point-to-point subinterface since there is a single VC and a single path for the traffic. The router simply consults the routing table and makes a forwarding decision.
As of Cisco IOS® Software Release 12.2(4) and 12.1(11), a point-to-point subinterface only responds to InATMARP requests and does not generate such requests (CSCdu53060). Previously, depending on the version of Cisco IOS Software, a point-to-point subinterface initiated an ARP request or, in some versions, failed to respond to ARP requests. On a point-to-point subinterface, InARP remains enabled by default to support hub and spoke topologies with a multipoint hub and a point-to-point stub. The stub must respond to the hub’s InARP request if the hub is not configured with a static map. In this case, the show atm map command (which used to display the dynamic or static mapping through InARP of point-to-point interfaces) does not show static entries on point-to-point links anymore, as this sample output shows:
Luke# show run int a2/0.3 Building configuration... ! interface ATM2/0.3 point-to-point ip address 192.168.3.1 255.255.255.252 no ip route-cache no ip mroute-cache pvc 0/300 ! Luke# show atm map Luke#
InARP is enabled on multipoint links by default. In the next example, a multipoint sub-interface is created. By using the debug atm arp command, you can see that InATMARP builds a dynamic mapping between the layer 3 IP address and the layer 2 VPI or VCI:
7500-1# show running-config !--- Output suppressed. interface ATM1/1/0.200 multipoint ip address 184.108.40.206 255.255.255.0 no ip directed-broadcast pvc 2/200 !--- Output suppressed. 5d10h: ATMARP:Sending first PVC INARP 5d10h: ATMARP(ATM1/1/0.200)O: INARP_REQ to VCD#20 2/200 for link 7(IP) 5d10h: ATMARP(ATM1/1/0.200)I: INARP Reply VCD#20 2/200 from 220.127.116.11 7500-1# show atm map Map list ATM1/1/0.100_ATM_INARP : DYNAMIC ip 18.104.22.168 maps to VC 19, VPI 2, VCI 100, ATM1/1/0.100 Map list ATM1/1/0.200_ATM_INARP : DYNAMIC ip 22.214.171.124 maps to VC 20, VPI 2, VCI 200, ATM1/1/0.200
You can use the inarp command to change the frequency of transmitting a new InATMARP packet in order to reconfirm the mapping:
7500-1(config-subif)# pvc 2/200 7500-1(config-if-atm-vc)# inarp ? <1-60> InARP Frequency in minutes <cr> 7500-1(config-if-atm-vc)# inarp 5 7500-1(config-if-atm-vc)# end 7500-1# show atm vc 5d10h: ATMARP:Sending first PVC INARP 5d10h: ATMARP(ATM1/1/0.200)O: INARP_REQ to VCD#20 2/200 for link 7(IP) 5d10h: ATMARP(ATM1/1/0.200)I: INARP Reply VCD#20 2/200 from 126.96.36.199 ATM1/1/0.200: VCD: 20, VPI: 2, VCI: 200 UBR, PeakRate: 44209 AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 OAM frequency: 0 second(s) InARP frequency: 5 minutes(s) Transmit priority 4 InPkts: 10, OutPkts: 11, InBytes: 680, OutBytes: 708 InPRoc: 10, OutPRoc: 5, Broadcasts: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 6 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 OAM cells received: 0 OAM cells sent: 0 Status: UP
The show atm map command displays the dynamic mapping through InATMARP, while the show arp and show atm arp commands do not. You can see this by viewing this output:
7500-1# show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.81.82 2 0010.7be8.674b ARPA FastEthernet1/0/0 Internet 172.16.81.15 - 0030.71d3.1020 ARPA FastEthernet1/0/0 Internet 172.16.81.10 2 0000.0c45.419a ARPA FastEthernet1/0/0 7500-1# show atm arp 7500-1#
RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5, defines how various types of protocol data units (PDUs) are encapsulated for transport over ATM. RFC 1483 specifies two methods for doing so.
The most common method is LLC or SNAP encapsulation, in which multiple protocols can be carried over the same virtual connection. A standard LLC or SNAP header identifies the type of encapsulated packet. LLC encapsulation supports both routed and bridged protocols. The packet’s SNAP header identifies the type of protocol.
The LLC header consists of three one-octet fields:
An LLC header value of 0xAA-AA-03 indicates a SNAP header. This header has this format:
The three-octet OUI identifies the organization administering the meaning of the two-octet PID. Together, these identify a distinct routed or bridged protocol. This is the format of the ATM adaptation layer 5 (AAL5) common part convergence sublayer (CPCS) PDU Payload field for routed PDUs:
|EtherType (2 octets)|
|PDU (up to 216 – 9 octets)|
The next example output is generated using the debug atm packet command.
Caution: Before issuing debug commands, refer to Important Information on Debug Commands.
router# debug atm packet !--- These timestamped lines of output appear on one line. Dec 7 10:21:16 CST: ATM2/IMA0.294(O): VCD:0x5 VPI:0x7 VCI:0xC0 DM:0x100 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70 Dec 7 10:21:16 CST: 4500 0064 0032 0000 FF01 7643 0A90 9801 0A90 9802 0800 BAA2 0031 0EB1 0000 Dec 7 10:21:16 CST: 0000 5A75 5A50 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD Dec 7 10:21:16 CST: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD Dec 7 10:21:16 CST: ABCD ABCD ABCD ABCD ABCD Dec 7 10:21:16 CST: ..
Consider these meanings of that output:
ATM2/IMA0.294(O)—The packet is an output packet.
VCD:0x5 VPI:0x7 VCI:0xC0—The packet is being transmitted on VPI 7 and VCI 192 (0xC0). These values are provided in hexadecimal format. Convert them to decimal to ensure that the router is using the correct PVC values in the ATM five-byte header. In this example, the VCI hexadecimal value of 0xC0 converts to 192 in decimal.
DM:0100—The packet is using AAL5 encapsulation. This value is set by a higher software layer so that the driver on the specific ATM hardware can handle special cases of packets. For example, this value can instruct the driver to place Operation, Administration, and Maintenance (OAM) packets on a special OAM virtual circuit descriptor (VCD), such as VCD 0 for the PA-A3 and VCD 4096 for the PA-A2. Other values include:
AAL5 packet: 0x4000
AAL1 cell : 0x2000
AAL1 packet: 0x8000
If application has put its own CRC: 0x0400
AAL3 or AAL4 packet: 0x0000
OAM packet: 0x0300
SAP:AAAA—A SNAP header follows.
OUI:000000—The following PID is an EtherType.
TYPE: 0800—The “well-known” EtherType value for IP.
ABCD ABCD ABCD—The default payload pattern of a ping packet.
Static map lists are a Cisco IOS Software feature that offers an alternative to using the ATMARP and InATMARP mechanisms. Using static maps, you can associate a protocol address with an ATM address on a switched virtual circuit (SVC), or with a VPI or VCI on a PVC.
While static mappings are simple for a few nodes, the complexity of configuration and the possibility of error increases with the number of devices that you have to configure.
Cisco IOS Software Release 11.3T introduced the ATM VC command mode which, in turn, introduced several new ATM commands that allow you to configure ATM parameters more easily. The new VC configuration mode uses the protocol ip and other statements (replace ip with ipx, decnet, and so on) to configure static mappings. The protocol statement takes the place of the map-list and map-group statements used in Cisco IOS Software Releases earlier than 11.3T.
The next example shows how to create a PVC 2/200 on ATM interface 1/1/0.200. It uses the global default LLC or SNAP encapsulation over AAL5. The interface is at IP address 188.8.131.52, with 184.108.40.206 at the other end of the connection.
interface ATM1/1/0.200 multipoint ip address 220.127.116.11 255.255.255.0 no ip directed-broadcast pvc 2/200 inarp 5 protocol ip 18.104.22.168 broadcast
You can check the mapping using the show atm map command. As you can see, the mapping of layer 3 to layer 2 addresses is permanent rather than dynamic, as it was when you used InARP.
7500-1# show atm map Map list ATM1/1/0.100_ATM_INARP : DYNAMIC ip 22.214.171.124 maps to VC 19, VPI 2, VCI 100, ATM1/1/0.100 Map list ATM1/1/0.200pvc20 : PERMANENT ip 126.96.36.199 maps to VC 20, VPI 2, VCI 200, ATM1/1/0.200, broadcast
Note: Avoid using static maps with point-to-point subinterfaces. Previously, configuring two protocol ip statements and then removing one statement led to a router reload under rare circumstances (CSCdk58757, CSCdr43838).
If you are running Cisco IOS Software Release 11.3 (non-T train) or earlier, then the ATM VC configuration command mode is not available, so you should use the old syntax instead. As you can see, the whole PVC configuration is done in only one line, seriously limiting the configuration possibilities. Refer to the “atm pvc” section of ATM Commands for more information on the ATM PVC commands that are available.
interface ATM3/0.1 multipoint no ip directed-broadcast map-group MyMap atm pvc 4 0 36 aal5snap 2000 1000 32 ! map-list MyMap ip 10.2.1.1 atm-vc 4 broadcast ip 10.2.1.2 atm-vc 4 broadcast Medina# show atm map Map list ATM3/0.1pvc4 : PERMANENT ip 10.2.1.1 maps to VC 4, VPI 0, VCI 36, ATM3/0.1, broadcast ip 10.2.1.2 maps to VC 4, VPI 0, VCI 36, ATM3/0.1, broadcast
Static maps also apply to SVCs. To set up a connection to a destination protocol address, the ATM interface locates the ATM network service access point (NSAP) address that corresponds to the protocol address in the map list, then sets up an SVC to that ATM address.
interface atm 4/0 ip address 188.8.131.52 255.255.255.0 atm nsap-address AB.CDEF.01.234567.890A.BCDE.F012.3456.7890.1234.12 atm maxvc 1024 pvc 0/5 qsaal ! svc svc-1 nsap BC.CDEF.01.234567.890A.BCDE.F012.3456.7890.1334.13 protocol ip 184.108.40.206
If you encounter problems with IP over ATM connectivity, use these troubleshooting steps:
Ensure that the router knows which VC to use to reach the remote destination. Issue the debug atm errors command on the interface. This debug command is unintrusive and it only produces output if there are a lot of ATM errors.
Note: If you are using InATMARP, issue the debug atm arp command instead.
Caution: Before issuing debug commands, refer to Important Information on Debug Commands.
You might see a line similar to this one:
Jul 12 05:01:26.161: ATM(ATM6/0): Encapsulation error1, link=7, host=B010117
If so, then the problem may be that you have incorrectly configured the ATM mapping. Refer to Troubleshooting Encapsulation Failures with the debug atm errors Command for instructions on how to troubleshoot this problem.
If issuing the debug atm errors command does not produce any output, try issuing the debug atm packet interface atm command.
Caution: The debug atm packet command prints one log message for each packet that passes through the VC. Before enabling this debug, ensure that you control the amount of debug output by removing general traffic and allowing only pings or keepalives to pass through the VC.
This next example is trying to ping 10.144.152.2. A point-to-point subinterface is used with a single PVC, so that the router automatically sends all pings destined for the same IP subnet out from this PVC.
Issue the show running-config command and confirm the configuration and IP address that you are trying to ping.
interface ATM2/IMA0.294 point-to-point ip address 10.144.152.1 255.255.255.252 no ip directed-broadcast pvc test 7/192 vbr-nrt 500 500 10
Issue the debug atm packet interface atm command.
Take care to limit the effect on the router by being as specific as possible with the debug configuration.
cisco# debug atm packet interface atm2/im0.294 vc ? <0-255> VPI/VCI value(slash required) <0-65535> VCI WORD Connection Name cisco# debug atm packet interface atm2/im0.294 vc 7/192 ATM packets debugging is on Displaying packets on interface ATM2/IMA0.294 VPI 7, VCI 192 only
Issue the terminal monitor command to ensure that you are able to view the debug output if you use the telnet command to reach the router.
To display debug command output and system error messages for the current terminal and session, issue the terminal monitor EXEC command. Also, consider directing all debug output to the buffer rather than the console. To do so, issue the logging buffered and no logging console commands in global configuration mode. Confirm your changes by issuing the show logging command.
Remember that all terminal parameter-setting commands are set locally and do not remain in effect after the session has ended.
cisco# terminal monitor % Console already monitors
Note the current value of outgoing packets (OutPkts) and incoming packets (InPkts) for the PVC.
cisco# show atm pvc test ATM2/IMA0.294: VCD: 5, VPI: 7, VCI: 192, Connection Name: test VBR-NRT, PeakRate: 500, Average Rate: 500, Burst Cells: 100 AAL5-LLC/SNAP, etype:0x0, Flags: 0x20, VCmode: 0x0 OAM frequency: 0 second(s), OAM retry frequency: 10 second(s), OAM retry frequency: 10 second(s) OAM up retry count: 2, OAM down retry count: 2 OAM Loopback status: OAM Disabled OAM VC state: Not Managed ILMI VC state: Not Managed InARP frequency: 15 minutes(s) Transmit priority 2 InPkts: 0, OutPkts: 2920, InBytes: 0, OutBytes: 163784 InPRoc: 0, OutPRoc: 6 InFast: 0, OutFast: 4, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 OAM cells received: 0 F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0 F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0 OAM cells sent: 2901 F5 OutEndloop: 2901, F5 OutSegloop: 0, F5 OutRDI: 0 F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0 OAM cell drops: 0 Status: UP
Ping the remote end and ensure that the router displays five-packet increments for both InPkts and OutPkts.
Look for the ABCD payload pattern to ensure that the packets are pings and not other packets’ OAM cells. See also:
Issue the show atm pvc vcd_number command again, and ensure that the OutPkts counter increments by at least five packets.
Note: You must be running Cisco IOS Software Release 11.3(2)T or later; if not, then issue the show atm vc command instead.
Compare the OutPkts value with the value that you recorded before doing the ping. In the next sample output, the OutPkts counter increments by 10 because two sets of five pings were sent. Notice that this interface still does not log any InPkts. This output suggests that the router is sending packets, but the remote device is not receiving them. A value of 0 for InPkts suggests that the end-to-end path in the ATM switch cloud is not properly provisioned.
cisco# show atm pvc test ATM2/IMA0.294: VCD: 5, VPI: 7, VCI: 192, Connection Name: test VBR-NRT, PeakRate: 500, Average Rate: 500, Burst Cells: 100 AAL5-LLC/SNAP, etype:0x0, Flags: 0x20, VCmode: 0x0 OAM frequency: 0 second(s), OAM retry frequency: 10 second(s), OAM retry frequency: 10 second(s) OAM up retry count: 2, OAM down retry count: 2 OAM Loopback status: OAM Disabled OAM VC state: Not Managed ILMI VC state: Not Managed InARP frequency: 15 minutes(s) Transmit priority 2 InPkts: 0, OutPkts: 2930, InBytes: 0, OutBytes: 164904 InPRoc: 0, OutPRoc: 16 InFast: 0, OutFast: 4, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 OAM cells received: 0 F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0 F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0 OAM cells sent: 2901 F5 OutEndloop: 2901, F5 OutSegloop: 0, F5 OutRDI: 0 F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0 OAM cell drops: 0 Status: UP
Note: The output varies depending on the card that you are using.
Confirm that the remote end receives pings when you ping out by issuing the debug ip icmp command on the remote end.
Once you have determined that both sides are sending packets, you need to determine why there is no end-to-end connectivity. To do so, follow these steps:
Check the output of the show interface command for non-zero input or output error counters, such as cyclic redundancy check (CRC) errors or input queue drops.
Check whether these counters increment when you ping. For more information, refer to the CRC Troubleshooting Guide for ATM Interfaces.
Use loopbacks on both ends.
For more information, refer to Understanding Loopback Modes on Cisco Routers.
Conduct loopback tests in the provider’s cloud to check whether the provider can send packets through the end-to-end path of the link.
Determine whether payload scrambling is enabled or disabled on both terminating ends.
A high number of CRC errors on one interface may suggest that one side has scrambling enabled and the other does not.
Conduct ping tests of various sizes up to the maximum transmission unit (MTU) to check whether pings only fail at certain sizes.
Check that you are not encountering policing issues. For more information, refer to Troubleshooting ATM PVCs in a WAN Environment.
- Troubleshooting ATM PVCs in a WAN Environment
- RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5
- CRC Troubleshooting Guide for ATM Interfaces
- Troubleshooting PVC Failures When Using OAM Cells and PVC Management
- Troubleshooting Encapsulation Failures with the debug atm errors Command
- RFC 1577, Classical IP and ARP over ATM
- ATM Technology Support Pages
- Technical Support - Cisco Systems
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.