This document provides a single reference on how to gather network
management data on an ATM interface through the use of Simple Network
Management Protocol (SNMP). It focuses specifically on Cisco router ATM
interfaces.

ATM comprises a three-layer stack: an ATM adaptation layer (AAL), an
ATM layer, and a physical layer, such as Sonet or T1. Each layer counts packets
and octets in a slightly different way. Correspondingly, an ATM interface
appears multiple times in the ifTable, with these entries:

Physical layer, such as Sonet

ATM cell layer

AAL5 layer

Any sub-interfaces (depending on the Cisco IOS Software
level)

Here is an example of ifTable data that illustrates these multiple
layers:

Variable-length padding is used to make the total AAL5 PDU size a
multiple of 48 bytes. Octets at the AAL5 layer count only bytes of the original
Layer 3 packet and the eight bytes of the RFC1483 header. Packets at this level
count the number of AAL5 PDUs. Use the show ATM vc
and show interface ATM command-line interface (CLI)
counters or use SNMP to look at the AAL5 layer information to see this
output:

AAL5 PDUs are further segmented into multiple 48-byte blocks, and then
each block is provided with a five-byte cell header to form a 53-byte ATM cell
at the ATM layer.

On Cisco Campus ATM switches, octets at the ATM layer count the total
bytes of the ATM cell, while packets count the number of cells.

On Cisco routers, ATM cell-layer SNMP counters are not maintained
because of limitations in the drivers of most ATM interfaces. ATM cell layer
for ATM subinterfaces on the router inherits this limitation. For more details
on cell counters, refer to
Measuring
the Utilization of ATM PVCs.

At the physical layer (with, for example, SONET or T1), SNMP counters
for the main interface still represent AAL5 PDUs, the same as in the
show interface ATM command output. In this case,
these are ifTable/ifXTable counters for:

Technologies such as ATM, Frame Relay, and virtual LANs (VLANs)
introduced a different type of interface: the virtual interface, or
subinterface. On an ATM interface, for example, you may have several permanent
virtual circuits (PVCs). Although the overall utilization of the main interface
is important, the amount of traffic on individual subinterfaces is of interest
as well. RFC 1573 (later superseded by
RFC 2233)
introduced the concept of sparse tables for subinterfaces. Sparse tables means
that a row in the ifTable for a subinterface may not have values in columns
where the objects do not apply to the subinterface.

Cisco IOS Software implemented support for subinterfaces in the ifTable
in release 11.1. Frame Relay and ATM LAN emulation (LANE) subinterface support
was added in Cisco IOS Software release 11.1. Support of other ATM
subinterfaces was added in 12.0(1)T for Cisco 12000, 4x00/M, 72xx, and 75xx
platforms. Each subinterface is represented with two ifTable entries: one for
the atmSubInterface layer (ATM layer) and one for the AAL5 layer. As for the
main interface, packet and octet counters are available only for the AAL5 layer
entities, because most ATM router interfaces do not support cell-layer
counts.

The ifType atmSubInterface (Internet Assigned Numbers Authority [IANA]
ifType number = 134) is defined for an ATM subinterface. The atmSubinterface
layer is a virtual ATM layer. The Interface MIB variables that correspond to
the atmSubInterface layer have the same semantics as those of the ATM layer on
a main (physical) interface.

These conformance groups apply to the atmSubInterface layer:

ifGeneralInformationGroup

ifFixedLengthGroup

ifHCFixedLengthGroup

The values of these variables are set for both atmSubInterface and AAL5
layers when the ATM subinterface is created:

ifIndex

ifDescr

ifName

ifType

The values of these variables are updated identically for the
atmSubInterface and AAL5 layers:

ifSpeed, ifHighSpeed—These variables are updated
during an SNMP GET request using the bandwidth configured on
the ATM subinterface. If there is no separate bandwidth configured on the
subinterface, the bandwidth of the main interface is used.

ifPhysAddress—This variable is is updated with the
network service access point (NSAP) address for the subinterface, during every
SNMP GET request to account for the possibility of NSAP
address removal.

ifAdminStatus, ifOperStatus—These variables reflect
administrative and operational status of the subinterface, and the values are
determined from states available in Cisco IOS Software and hardware interface
descriptor blocks (IDBs).

ifLastChange—This variable is updated with the
sysUpTime at the time the subinterface enters its current
operational state.

These variables are not maintained for the atmSubInterface layer due to
the lack of cell-layer counters in the drivers of current interfaces:

ifInOctets, ifOutOctets

ifHCInOctets, ifHCOutOctets

The counters may be implemented if the drivers of new ATM Port Adapters
(PAs) provide cell-layer counters.

These variables are not maintained for the atmSubInterface layer
because they are not maintained at the ATM layer:

ifInUcastPkts, ifInNUcastPkts

ifOutUcastPkts, ifOutNUcastPkts

ifInBroadcastPkts, ifOutBroadcastPkts

ifInMulticastPkts, ifOutMulticastPkts

ifInDiscards

ifHCInUcastPkts, ifHCInMulticastPkts,
ifHCInBroadcastPkts,

ifHCOutUcastPkts, ifHCOutMulticastPkts,
ifHCOutBroadcastPkts

These variables are not updated at the atmSubInterface layer because it
is not possible to gather these statistics on a per-VC basis:

For counters for each AAL5 VC, use
CISCO-AAL5-MIB and refer to
Measuring
the Utilization of ATM PVCs for more details. If your AAL5 VC is the
only VC configured on an ATM subinterface, then you can get correspondent AAL5
counters for it through SNMP by using AAL5-layer entries for
that subinterface in the ifTable/ifXTable. Absolute values of the
AAL5-layer subinterface counters may reflect past states for
VCs that were previously configured on this subinterface and were later deleted
or replaced. Generally, this is not a concern, as you normally use delta (the
difference between two counter polls) in a calculation.

ATM interfaces support the generic link up and down traps defined in
MIB II. This sample output was captured on an ATM inverse multiplexing over an
ATM (IMA) network module. It used the debug snmp
packet command to view the contents of the traps.

Prior to Cisco IOS Software Release 12.2, the output of the
debug snmp packet command displays a value of
NO_SUCH_INSTANCE_EXCEPTION for the locIfReason object on an
ATM subinterface. In other words, for an ATM subinterface, the router generates
a trap that contains this information by default:

This exception occurs because the
OLD-CISCO-INTERFACES-MIB does not support
subinterfaces. Cisco bug ID
CSCdp41317
(registered customers only)
resolves this problem through the
snmp-server trap link ietf command. This output is
now expected and complies with RFC 2233:

Cisco IOS Software Releases 11.2 and later provide a standard ATM-MIB
instrumentation for many of the counters already provided in the ATM interfaces
of the router. ATM-MIB provides some capabilities to change ATM configuration
on the device by supporting a number of SNMP SET operations
(refer to
Configuration of ATM Virtual Connections with SNMP for more
details). This ATM-MIB snmp set functionality is not
supported on Cisco routers with ATM interfaces, but you can use it for Cisco
ATM switches. There are still some limitations. For example, ATM-MIB is not
supported for cross-connection of VC/VPs to pseudo ATM interfaces (ATM-P) for
circuit emulation service (CES) port adapters.

To locate other ATM-related MIBs supported by each product, use
Cisco IOS MIB
Tools, as well as data sheets and configuration guides for the specific
ATM port adapter or module.