HP Cisco Nexus 5000 Cisco Nexus 5000 Series and Cisco Nexus 2000 Series MIB Qu - Page 3

SNMP Traps and Informs, Interpreting the MIB Structure

Page 3 highlights

MIBs and Network Management Send documentation comments to [email protected] Table 1 SNMP Operations (continued) Operation Description set-request response Stores a value in a specific variable. Replies to the commands (get-request, get-next-request, get-bulk3, and set-request) sent by an NMS and to the informs sent by an agent. trap inform2 Sends an unsolicited message by an SNMP agent to an SNMP manager indicating that some event has occurred. Sends an unsolicited message by an SNMP agent to an SNMP manager indicating that some event has occurred. An inform differs from a trap in that an acknowledgement is required from the manager. 1. With this operation, an SNMP manager does not need to know the exact variable name. A sequential search finds the next variable from within the MIB. 2. The get-bulk and inform commands are not a part of SNMPv1. 3. The get-bulk and inform commands are not a part of SNMPv1. SNMPv1 was the initial version of the protocol. SNMPv2 added support for 64-bit counters, and SNMPv3 added increased security for access, authentication, and encryption of managed data. SNMP Traps and Informs You can configure Cisco Nexus 5000 Series switches to send notifications to SNMP managers when particular events occur. You can send these notifications as traps or inform requests. Traps are unreliable because the receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the trap was received. However, an SNMP manager that receives an inform request acknowledges the message with an SNMP response. If the sender never receives a response, the inform request can be sent again. Informs are more likely to reach their intended destinations than traps. Notifications may contain a list of MIB variables (varbinds) that clarify the status that is relayed by the notification. The list of varbinds associated with a notification is included in the notification definition in the MIB. In the case of standard MIBs, Cisco has enhanced some notifications with additional varbinds that further clarify the cause of the notification. See the "Extending the IF-MIB" section on page 9 for an example of these extensions in the IF-MIB. Use the SNMP-TARGET-MIB to obtain more information on trap destinations and inform requests. See the Cisco Nexus 5000 CLI Configuration Guide for more information on configuring traps and informs. Note You must enable most notifications through the CLI. For more information, see the Cisco Nexus 5000 Series CLI Configuration Guide, Release 4.0. Interpreting the MIB Structure A MIB presents the managed data in a logical tree hierarchy, using an IETF standard syntax called the Structure of Management Information (SMI). Branches of this MIB tree are organized into individual tables, which contain the managed data as leaf objects. This section includes the following topics: • Object Identifiers, page 4 OL-16784-01 Cisco Nexus 5000 Series and CiscoNexus 2000 Series MIB Quick Reference 3

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

Send documentation comments to [email protected]
3
Cisco Nexus 5000 Series and CiscoNexus 2000 Series MIB Quick Reference
OL-16784-01
MIBs and Network Management
SNMPv1 was the initial version of the protocol. SNMPv2 added support for 64-bit counters, and
SNMPv3 added increased security for access, authentication, and encryption of managed data.
SNMP Traps and Informs
You can configure Cisco Nexus 5000 Series switches to send notifications to SNMP managers when
particular events occur. You can send these notifications as traps or inform requests. Traps are unreliable
because the receiver does not send any acknowledgment when it receives a trap. The sender cannot
determine if the trap was received. However, an SNMP manager that receives an inform request
acknowledges the message with an SNMP response. If the sender never receives a response, the inform
request can be sent again. Informs are more likely to reach their intended destinations than traps.
Notifications may contain a list of MIB variables (varbinds) that clarify the status that is relayed by the
notification. The list of varbinds associated with a notification is included in the notification definition
in the MIB. In the case of standard MIBs, Cisco has enhanced some notifications with additional
varbinds that further clarify the cause of the notification. See the
“Extending the IF-MIB” section on
page 9
for an example of these extensions in the IF-MIB.
Use the SNMP-TARGET-MIB to obtain more information on trap destinations and inform requests. See
the
Cisco Nexus 5000 CLI Configuration Guide
for more information on configuring traps and informs.
Note
You must enable most notifications through the CLI. For more information, see the
Cisco Nexus 5000
Series CLI Configuration Guide, Release 4.0.
Interpreting the MIB Structure
A MIB presents the managed data in a logical tree hierarchy, using an IETF standard syntax called the
Structure of Management Information (SMI). Branches of this MIB tree are organized into individual
tables, which contain the managed data as leaf objects.
This section includes the following topics:
Object Identifiers, page 4
set-request
Stores a value in a specific variable.
response
Replies to the commands (get-request, get-next-request, get-bulk
3
, and
set-request) sent by an NMS and to the informs sent by an agent.
trap
Sends an unsolicited message by an SNMP agent to an SNMP manager indicating
that some event has occurred.
inform
2
Sends an unsolicited message by an SNMP agent to an SNMP manager indicating
that some event has occurred. An inform differs from a trap in that an
acknowledgement is required from the manager.
1.
With this operation, an SNMP manager does not need to know the exact variable name. A sequential search finds the next
variable from within the MIB.
2.
The
get-bulk
and
inform
commands
are not a part of SNMPv1.
3.
The
get-bulk
and
inform
commands
are not a part of SNMPv1.
Table 1
SNMP Operations (continued)
Operation
Description