Troubleshooting IP over ATM PVC Connectivity

Introduction

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

Prerequisites

Requirements

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.

Components Used

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.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Point-to-Point versus Multipoint Interfaces

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.

Inverse ARP on ATM Connections

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 2.2.2.1 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 2.2.2.2

7500-1# show atm map

Map list ATM1/1/0.100_ATM_INARP : DYNAMIC
ip 1.1.1.2 maps to VC 19, VPI 2, VCI 100, ATM1/1/0.100

Map list ATM1/1/0.200_ATM_INARP : DYNAMIC
ip 2.2.2.2 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 2.2.2.2
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#

LLC and SNAP Encapsulation Using RFC 1483

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:

DSAP

SSAP

Ctrl

An LLC header value of 0xAA-AA-03 indicates a SNAP header. This header has this format:

OUI

PID

PDU

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:

LLC 0xAA-AA-03

OUI 0x00-00-00

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 IP to ATM VC Mappings

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.

Note: Static map lists do not relate to RFC 1483 or RFC 1577 .

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 2.2.2.1, with 2.2.2.2 at the other end of the connection.

interface ATM1/1/0.200 multipoint
 ip address 2.2.2.1 255.255.255.0
 no ip directed-broadcast
 pvc 2/200
  inarp 5
  protocol ip 2.2.2.2 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 1.1.1.2 maps to VC 19, VPI 2, VCI 100, ATM1/1/0.100 

Map list ATM1/1/0.200pvc20 : PERMANENT 
ip 2.2.2.2 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 131.108.168.1 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 131.108.168.2

Troubleshooting Steps

If you encounter problems with IP over ATM connectivity, use these troubleshooting steps:

Step 1

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.

Step 2

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.

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

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

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

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

5. 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:

   • Using OAM for PVC Management

   • Troubleshooting PVC Failures When Using OAM Cells and PVC Management.

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

Step 3

Confirm that the remote end receives pings when you ping out by issuing the debug ip icmp command on the remote end.

Step 4

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:

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

2. Use loopbacks on both ends.

   For more information, refer to Understanding Loopback Modes on Cisco Routers.

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

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

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

Related Information

• 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