As shown in the figure, the SNMP agent gathers data from the MIB. The agent can send traps, or notification
of certain events, to the SNMP manager, which receives and processes the traps. Traps alert the SNMP manager
to a condition on the network such as improper user authentication, restarts, link status (up or down), MAC
address tracking, and so forth. The SNMP agent also responds to MIB-related queries sent by the SNMP
manager in
get-request
,
get-next-request
, and
set-request
format.
Figure 44: SNMP Network
SNMP Notifications
SNMP allows the switch to send notifications to SNMP managers when particular events occur. SNMP
notifications can be sent as traps or inform requests. In command syntax, unless there is an option in the
command to select either traps or informs, the keyword traps refers to either traps or informs, or both. Use
the
snmp-server host
command to specify whether to send SNMP notifications as traps or informs.
SNMPv1 does not support informs.
Note
Traps are unreliable because the receiver does not send an acknowledgment when it receives a trap, and 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 resent, informs are more likely than
traps to reach their intended destination.
The characteristics that make informs more reliable than traps also consume more resources in the switch 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 resent
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
switch is a concern and notification is not required, use traps.
Related Topics
Configuring SNMP Notifications, on page 459
Monitoring SNMP Status, on page 467
SNMP ifIndex MIB Object Values
In an NMS, the IF-MIB generates and assigns an interface index (ifIndex) object value that is a unique number
greater than zero to identify a physical or a logical interface. When the switch reboots or the switch software
is upgraded, the switch uses this same value for the interface. For example, if the switch assigns a port 2 an
ifIndex value of 10003, this value is the same after the switch reboots.
The switch uses one of the values in the following table to assign an ifIndex value to an interface:
Consolidated Platform Configuration Guide, Cisco IOS Release 15.2(4)E (Catalyst 2960-X Switches)
450
Information About SNMP
Summary of Contents for Catalyst 2960 Series
Page 96: ......
Page 196: ......
Page 250: ......
Page 292: ......
Page 488: ......
Page 589: ...P A R T VI Cisco Flexible NetFlow Configuring NetFlow Lite page 509 ...
Page 590: ......
Page 619: ...P A R T VII QoS Configuring QoS page 539 Configuring Auto QoS page 645 ...
Page 620: ......
Page 750: ......
Page 1604: ......
Page 1740: ......
Page 2105: ...P A R T XII Configuring Cisco IOS IP SLAs Configuring Cisco IP SLAs page 2025 ...
Page 2106: ......
Page 2118: ......
Page 2164: ......