22-5
Ethernet Card Software Feature and Configuration Guide, R7.2
January 2009
Chapter 22 Configuring SNMP
Supported MIBs
Supported MIBs
The complete list of supported MIBs for the ML-Series card is found in the MIBsREADME .txt file on
the ONS Software CD for your release. This software CD also includes the needed MIB modules and
information on loading MIBs.
You c an al s o locate and download MIBs for Cisco platforms, Cisco IOS releases, and feature sets, using
the Cisco MIB Locator found at the following URL:
http://www.cisco.com/go/mibs
Some of the important MIBs supported include:
• Spanning Tree Protocol (STP) traps from Bridge-MIB (RFC 1493)
• Authentication traps from RFC 1157
• Link-up and link-down traps for Ethernet ports from IF-MIB (RFC 157 3)
• Export of quality of service (QoS) statistics through the CISCO-PORT-QOS-MIB extension
Note The ML-Series card CISCO-PORT-QOS-MIB extension includes support for QoS indexing based on
cost of service (CoS). It does not support configuration objects.
SNMP Notifications
SNMP allows the ML-Series card to send notifications to SNMP managers when particular events occur.
SNMP notifications can be sent as traps or as inform requests. In command syntax, unless there is an
option in the command to select either traps or inform requests, the keyword traps refers to either traps
or inform requests, or both. Use the snmp-server host command to specify whether to send SNMP
notifications as traps or inform requests.
Note SNMPv1 does not support inform requests.
Traps are unreliable because the receiver does not send an acknowledgment when it receives a trap, so
the sender cannot determine if the trap was received. When an SNMP manager receives an inform
request, it acknowledges the message with an SNMP response protocol data unit (PDU). If the sender
does not receive a response, the inform request can be sent again. Because they can be re-sent, inform
requests are more likely than traps to reach their intended destination.
The characteristics that make informs more reliable th an traps also consume more resources in the
ML-Series card and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform
request is held in memory until a response is received or the request times out. Traps are sent only once,
but an inform might be re-sent or retried several times. The retries increase traffic and contribute to a
higher overhead on the network. Therefore, traps and informs require a trade-off between reliability and
resources. If it is important that the SNMP manager receive every notification, use inform requests. If
traffic on the network or memory in the ML-Series card is a concern and notification is not required, use
traps.