All types of router interfaces, from serial to Ethernet to ATM, can
report a large number of input drops in the output of the show
interface atm command. The following sample output shows that a
PA-A3 ATM port adapter has experienced 675 input drops since the counters were
last cleared.

Users typically report input drops as slow performance. Since meeting
user expectations of network response time is an important design goal,
understanding the reasons for input drops is an important troubleshooting goal.
This document provides the information you need to understand and troubleshoot
input drops on ATM interfaces.

Cisco IOS® Software switching methods define how the router forwards a
packet from an ingress (incoming) interface to an egress (exiting)
interface.

The least-preferred method of Cisco IOS Software switching is process
switching. In this, the central CPU performs a complete routing-table lookup
based on the destination IP address. Process switching means that the router
cannot use a preferable route-cache method, such as fast switching or Cisco
Express Forwarding (CEF), to handle the forwarding decision. As a result, the
router is forced to copy the packet from an input/output (I/O) buffer in static
random-access memory (SRAM), also known as MEMD on 7xxx platforms, to a system
buffer in dynamic random-access memory (DRAM). This is where Cisco IOS Software
code, data structures, and dynamic tables are stored.

On ATM and non-ATM interfaces, the system may count input queue drops
if the number of packet buffers allocated to the interface is exhausted or
reaches its maximum threshold. When using a route-cache method, the system
stores a packet in SRAM or packet memory. When using process switching, it
stores a packet in DRAM.

The output of the show interface atm command
might display a high number of throttles along with input queue drops. Input
queue drops occur when a packet is being process switched. The throttles
counter increments when a system buffer is available, but the interface already
has the maximum number of packets waiting to be processed in the input hold
queue The router temporarily disables the interface to give the interface time
to catch up and process the already enqueued packets.

You can troubleshoot throttles by determining the root cause of why a
high number of packets are being process switched.

The flushes counter in the show interface
atm command output increments as part of selective packet discard
(SPD), which implements a selective packet drop policy on the router's IP
process queue. Therefore, it applies to only process switched traffic.

The purpose of SPD is to ensure that important control packets, such as
routing updates and keepalives, are not dropped when the IP input queue is
full. When the size of the IP input queue is between the minimum and maximum
thresholds, normal IP packets are dropped based a certain drop probability.
These random drops are called SPD flushes.

In LAN Emulation (LANE) environments, the flush counter increments only
for process switched traffic. LANE is supported by CEF. To troubleshoot
incrementing flushes, determine how packets are being IOS switched by issuing
the show ip interface atm command. In addition,
confirm that LANE Data Direct VCs are forming. Capture the output of the
show lane client output command.

While input queue drops on an interface point to a high number of
process switched packets, a non-zero value for the InPktDrops of a VC counter
suggests that the ATM interface is running out of packet buffers for an
individual virtual circuit (VC), or is exceeding the total number of VC buffers
that can be shared by the VCs. For the PA-A3, such drops occur as a result of
the PA-A3 driver implementing one of two throttling mechanisms:

The PA-A3 places a quota on the number of packet buffers that a VC
can use from the receive segmentation and reassembly (SAR) common pool. This
quota equates to a "receive credits" value which varies based on the configured
traffic shaping rate. In addition, it prevents one aggressive or overloaded VC
from exhausting all buffer resources. When the PA-A3 driver receives a packet
and forwards it to either the processor or to an egress interface, it deducts
one buffer credit. It restores a credit when either the processor or the egress
interface returns the packet buffer to the VC's pool. If the VC experiences
congestion and runs out of credits, the PA-A3 must drop subsequent packets and
increments the InPktDrops counter.

The PA-A3 throttles an ATM VC when the adapter itself runs out of
packet buffers. On an ATM interface with a large number of congested VCs, the
adapter can run out of packet buffers quite easily since the per-VC quotas
overlap and are not exclusive. In other words, the total number of buffers
specified in the per-VC quotas exceeds the total number of buffers actually
available on the PA-A3. When all of the PA-A3's buffers are in use, the
framer's FIFO queue hold incoming cells. These can lead to overruns if
congestion persists. Once such a backpressure condition occurs, the framer FIFO
may drop cells, causing cyclic redundancy check (CRC)
errors.

InPktDrops counts the number of times a packet was dropped before it
reached the host interface. Packets are not registered in the interface
statistics until the host interface receives it from the SAR buffer. Thus, you
may see drops with the show atm vc command, but see
few, if any, drops with the show interface atm
command.

The show controllers atm command displays
three useful counters for determining whether the ATM interface is running out
of onboard reassembly buffers. These are highlighted in bold below.

Maximum number of receive particles that the PA-A3 driver or
egress port adapter can hold without regulating receive particle usage among
the configured VCs. To prevent any VC from allocating too many packet buffers
and inhibiting other VCs from receiving packets, the PA-A3 uses a receive
packet buffer regulating mechanism. When the total number of receive particles
held by the PA-A3 driver or the egress interface exceeds this threshold, the
next packet received by the PA-A3 is checked to see if one VC occupies too many
packet buffers. If so, the PA-A3 discards incoming packets until the total
number of receive particles held by this violating VC falls below the
quota.

Rx_max_spins

Internally, the PA-A3 microcode notifies the PA-A3 driver of the
arrival of incoming packets by asserting receive interrupts. The PA-A3 driver
catches the receive interrupt and then drains as many particles from the
receive ring as it can. This counter records the maximum number of receive
particles ever drained by the PA-A3 driver in a single interrupt.

Rx_count

Total number of receive or reassembly particles currently held by
the driver.

In addition to exceeding a VC's reassembly buffer credit, an ATM
interface may drop packets because:

No route to destination prefix

Incomplete ARP entry

Configured policy of an ACL

In certain versions of Cisco IOS Software, the PA-A3 driver is counting
these drops as VC input packet drops and incrementing the per-VC InPktDrop
counter. This problem is cosmetic only and has no performance impact. It is
resolved via bug ID CSCdu23066 for the PA-A3-OC3/T3 and via bug ID CSCdw78297
for the PA-A3-OC12.

Cisco DDTS CSCdm54053 resolves a problem in which the output of show
interface displays negative packet input and output counters on a subinterface.
A fix is implemented in various versions of Cisco IOS Software Version 12.0(6)
as well as 12.0(7)XE2.