Information About SNMP
SNMP
The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between managers and agents. The SNMP system consists of an SNMP manager, an SNMP agent, and a MIB. The SNMP manager can be part of a network management system (NMS) such as CiscoWorks. The agent and MIB reside on the switch. To configure SNMP on the switch, you define the relationship between the manager and the agent.
The SNMP agent contains MIB variables whose values the SNMP manager can request or change. A manager can get a value from an agent or store a value into the agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to a manager’s requests to get or set data.
An agent can send unsolicited traps to the manager. Traps are messages alerting the SNMP manager to a condition on the network. Traps can mean improper user authentication, restarts, link status (up or down), MAC address tracking, closing of a TCP connection, loss of connection to a neighbor, or other significant events.
SNMP Versions
This software release supports these SNMP versions:
- SNMPv1—The Simple Network Management Protocol, a Full Internet Standard, defined in RFC 1157.
- SNMPv2C replaces the Party-based Administrative and Security Framework of SNMPv2Classic with the community-string-based Administrative Framework of SNMPv2C while retaining the bulk retrieval and improved error handling of SNMPv2Classic. It has these features:
– SNMPv2—Version 2 of the Simple Network Management Protocol, a Draft Internet Standard, defined in RFCs 1902 through 1907.
– SNMPv2C—The community-string-based Administrative Framework for SNMPv2, an Experimental Internet Protocol defined in RFC 1901.
- SNMPv3—Version 3 of the SNMP is an interoperable standards-based protocol defined in RFCs 2273 to 2275. SNMPv3 provides secure access to devices by authenticating and encrypting packets over the network and includes these security features:
– Message integrity—Ensures that a packet was not tampered with in transit.
– Authentication—Determines that the message is from a valid source.
– Encryption—Mixes the contents of a package to prevent it from being read by an unauthorized source.
Note To select encryption, enter the priv keyword. This keyword is available only when the cryptographic (encrypted) software image is installed.
Both SNMPv1 and SNMPv2C use a community-based form of security. The community of managers able to access the agent’s MIB is defined by an IP address access control list and password.
SNMPv2C includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism retrieves tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2C improved error-handling includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes in SNMPv2C report the error type.
SNMPv3 provides for both security models and security levels. A security model is an authentication strategy set up for a user and the group within which the user resides. A security level is the permitted level of security within a security model. A combination of the security level and the security model determine which security mechanism is used when handling an SNMP packet. Available security models are SNMPv1, SNMPv2C, and SNMPv3.
Table 37-1 identifies the characteristics of the different combinations of security models and levels.
Table 37-1 SNMP Security Models and Levels
|
|
|
|
|
SNMPv1 |
noAuthNoPriv |
Community string |
No |
Uses a community string match for authentication. |
SNMPv2C |
noAuthNoPriv |
Community string |
No |
Uses a community string match for authentication. |
SNMPv3 |
noAuthNoPriv (requires the LAN Base image) |
Username |
No |
Uses a username match for authentication. |
SNMPv3 |
authNoPriv (requires the LAN Base image) |
Message Digest 5 (MD5) or Secure Hash Algorithm (SHA) |
No |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. |
SNMPv3 |
authPriv (requires the LAN Base image) |
MD5 or SHA |
Data Encryption Standard (DES) or Advanced Encryption Standard (AES) |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Allows specifying the User-based Security Model (USM) with these encryption algorithms:
- DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard.
- 3DES 168-bit encryption
- AES 128-bit, 192-bit, or 256-bit encryption
|
You must configure the SNMP agent to use the SNMP version supported by the management station. Because an agent can communicate with multiple managers, you can configure the software to support communications using SNMPv1, SNMPv2C, or SNMPv3.
SNMP Manager Functions
The SNMP manager uses information in the MIB to perform the operations described in Table 37-2 .
Table 37-2 SNMP Operations
|
|
get-request |
Retrieves a value from a specific variable. |
get-next-request |
Retrieves a value from a variable within a table. |
get-bulk-request |
Retrieves large blocks of data, such as multiple rows in a table, that would otherwise require the transmission of many small blocks of data. |
get-response |
Replies to a get-request, get-next-request, and set-request sent by an NMS. |
set-request |
Stores a value in a specific variable. |
trap |
An unsolicited message sent by an SNMP agent to an SNMP manager when some event has occurred. |
SNMP Agent Functions
The SNMP agent responds to SNMP manager requests as follows:
- Get a MIB variable—The SNMP agent begins this function in response to a request from the NMS. The agent retrieves the value of the requested MIB variable and responds to the NMS with that value.
- Set a MIB variable—The SNMP agent begins this function in response to a message from the NMS. The SNMP agent changes the value of the MIB variable to the value requested by the NMS.
The SNMP agent also sends unsolicited trap messages to notify an NMS that a significant event has occurred on the agent. Examples of trap conditions include, but are not limited to, when a port or module goes up or down, when spanning-tree topology changes occur, and when authentication failures occur.
SNMP Community Strings
SNMP community strings authenticate access to MIB objects and function as embedded passwords. In order for the NMS to access the switch, the community string definitions on the NMS must match at least one of the three community string definitions on the switch.
A community string can have one of these attributes:
- Read-only (RO)—Gives read access to authorized management stations to all objects in the MIB except the community strings, but does not allow write access.
- Read-write (RW)—Gives read and write access to authorized management stations to all objects in the MIB, but does not allow access to the community strings.
When a cluster is created, the command switch manages the exchange of messages among member switches and the SNMP application. If you are using CNA, it appends the member switch number ( @esN, where N is the switch number) to the first configured RW and RO community strings on the command switch and propagates them to the member switches. For more information, see Chapter 6, “Configuring Switch Clusters” and see Getting Started with Cisco Network Assistant, available on Cisco.com.
Using SNMP to Access MIB Variables
An example of an NMS is the CiscoWorks network management software. CiscoWorks 2000 software uses the switch MIB variables to set device variables and to poll devices on the network for specific information. The results of a poll can be displayed as a graph and analyzed to troubleshoot internetworking problems, increase network performance, verify the configuration of devices, monitor traffic loads, and more.
As shown in Figure 37-1, 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 37-1 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.
Note SNMPv1 does not support informs.
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.
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 Table 37-3 to assign an ifIndex value to an interface.
Table 37-3 ifIndex Values
|
|
SVI |
1–4999 |
EtherChannel |
5001–5048 |
Physical (such as Gigabit Ethernet or SFP-module interfaces) based on type and port numbers |
10000–14500 |
Null |
10501 |
Loopback and Tunnel |
24567 + |
Note The switch might not use sequential values within a range.
Community Strings
You use the SNMP community string to define the relationship between the SNMP manager and the agent. The community string acts like a password to permit access to the agent on the switch. Optionally, you can specify one or more of these characteristics associated with the string:
- An access list of IP addresses of the SNMP managers that are permitted to use the community string to gain access to the agent
- A MIB view, which defines the subset of all MIB objects accessible to the given community
- Read and write or read-only permission for the MIB objects accessible to the community
SNMP Notifications
A trap manager is a management station that receives and processes traps. Traps are system alerts that the switch generates when certain events occur. By default, no trap manager is defined, and no traps are sent. Switches running this Cisco IOS release can have an unlimited number of trap managers.
Note Many commands use the word traps in the command syntax. Unless there is an option in the command to select either traps or informs, the keyword traps refers to traps, informs, or both. Use the snmp-server host global configuration command to specify whether to send SNMP notifications as traps or informs.
This table describes the supported switch traps (notification types). You can enable any or all of these traps and configure a trap manager to receive them. To enable the sending of SNMP inform notifications, use the snmp-server enable traps global configuration command combined with the snmp-server host host-addr informs global configuration command.
Table 37-4 Switch Notification Types
Notification Type Keyword
|
|
bridge |
Generates STP bridge MIB traps. |
config |
Generates a trap for SNMP configuration changes. |
copy-config |
Generates a trap for SNMP copy configuration changes. |
entity |
Generates a trap for SNMP entity changes. |
cpu threshold |
Allows CPU-related traps. |
envmon |
Generates environmental monitor traps. You can enable any or all of these environmental traps: fan, shutdown, status, supply, temperature. |
errdisable |
Generates a trap for an error-disabled VLAN port. You can also set a maximum trap rate per minute. The range is from 0 to 10000; the default is 0, which means there is no rate limit. |
flash |
Generates SNMP FLASH notifications. |
hsrp |
Generates a trap for Hot Standby Router Protocol (HSRP) changes. |
ipmulticast |
Generates a trap for IP multicast routing changes. |
mac-notification |
Generates a trap for MAC address notifications. |
msdp |
Generates a trap for Multicast Source Discovery Protocol (MSDP) changes. |
ospf |
Generates a trap for Open Shortest Path First (OSPF) changes. You can enable any or all of these traps: Cisco specific, errors, link-state advertisement, rate limit, retransmit, and state changes. |
pim |
Generates a trap for Protocol-Independent Multicast (PIM) changes. You can enable any or all of these traps: invalid PIM messages, neighbor changes, and rendezvous point (RP)-mapping changes. |
port-security |
Generates SNMP port security traps. You can also set a maximum trap rate per second. The range is from 0 to 1000; the default is 0, which means that there is no rate limit. Note When you configure a trap by using the notification type port-security, configure the port security trap first, and then configure the port security trap rate:
- snmp-server enable traps port-security
- snmp-server enable traps port-security trap-rate rate
|
rtr |
Generates a trap for the SNMP Response Time Reporter (RTR). |
snmp |
Generates a trap for SNMP-type notifications for authentication, cold start, warm start, link up or link down. |
storm-control |
Generates a trap for SNMP storm control. You can also set a maximum trap rate per minute. The range is from 0 to 1000; the default is 0 (no limit is imposed; a trap is sent at every occurrence). |
stpx |
Generates SNMP STP Extended MIB traps. |
syslog |
Generates SNMP syslog traps. |
tty |
Generates a trap for TCP connections. This trap is enabled by default. |
vlan-membership |
Generates a trap for SNMP VLAN membership changes. |
vlancreate |
Generates SNMP VLAN created traps. |
vlandelete |
Generates SNMP VLAN deleted traps. |
vtp |
Generates a trap for VLAN Trunking Protocol (VTP) changes. |
Note Though visible in the command-line help strings, the fru-ctrl, insertion, and removal keywords are not supported.
You can use the snmp-server host global configuration command to a specific host to receive the notification types listed in Table 37-4 .
Default SNMP Settings
Table 37-5 Default SNMP Settings
|
|
SNMP agent |
Disabled. |
SNMP trap receiver |
None configured. |
SNMP traps |
None enabled except the trap for TCP connections (tty). |
SNMP version |
If no version keyword is present, the default is Version 1. |
SNMPv3 authentication |
If no keyword is entered, the default is the noauth (noAuthNoPriv) security level. |
SNMP notification type |
If no type is specified, all notifications are sent. |