About SNMP
The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.
SNMP Functional Overview
The SNMP framework consists of three parts:
-
An SNMP manager—The system used to control and monitor the activities of network devices using SNMP.
-
An SNMP agent—The software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The Cisco Nexus device supports the agent and MIB. To enable the SNMP agent, you must define the relationship between the manager and the agent.
-
A managed information base (MIB)—The collection of managed objects on the SNMP agent
SNMP is defined in RFCs 3411 to 3418.
The device supports SNMPv1, SNMPv2c, and SNMPv3. Both SNMPv1 and SNMPv2c use a community-based form of security.
Cisco NX-OS supports SNMP over IPv6.
SNMP Notifications
A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.
Cisco NX-OS generates SNMP notifications as either traps or informs. A trap is an asynchronous, unacknowledged message sent from the agent to the SNMP managers listed in the host receiver table. Informs are asynchronous messages sent from the SNMP agent to the SNMP manager which the manager must acknowledge receipt of.
Traps are less reliable than informs because the SNMP manager does not send any acknowledgment when it receives a trap. The device cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the device never receives a response, it can send the inform request again.
You can configure Cisco NX-OS to send notifications to multiple host receivers.
The following table lists the SNMP traps that are enabled by default.
Trap Type | Description |
---|---|
generic | : coldStart |
entity | : entity_fan_status_change |
entity | : entity_mib_change |
entity | : entity_module_status_change |
entity | : entity_module_inserted |
entity | : entity_module_removed |
entity | : entity_power_out_change |
entity | : entity_power_status_change |
entity | : entity_unrecognised_module |
link | : cErrDisableInterfaceEventRev1 |
link | : cieLinkDown |
link | : cieLinkUp |
link | : cmn-mac-move-notification |
link | : delayed-link-state-change |
link | : extended-linkDown |
link | : extended-linkUp |
link | : linkDown |
link | : linkUp |
rf | : redundancy_framework |
license | : notify-license-expiry |
license | : notify-no-license-for-feature |
license | : notify-licensefile-missing |
license | : notify-license-expiry-warning |
upgrade | : UpgradeOpNotifyOnCompletion |
upgrade | : UpgradeJobStatusNotify |
entity | : entity_sensor |
rmon | : fallingAlarm |
rmon | : hcRisingAlarm |
rmon | : hcFallingAlarm |
rmon | : risingAlarm |
SNMPv3
SNMPv3 provides secure access to devices by a combination of authenticating and encrypting frames over the network. The security features provided in SNMPv3 are the following:
-
Message integrity—Ensures that a packet has not been tampered with in-transit.
-
Authentication—Determines the message is from a valid source.
-
Encryption—Scrambles the packet contents to prevent it from being seen by unauthorized sources.
SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user and the role in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.
Security Models and Levels for SNMPv1, v2, v3
The security level determines if an SNMP message needs to be protected from disclosure and if the message needs to be authenticated. The various security levels that exist within a security model are as follows:
-
noAuthNoPriv—Security level that does not provide authentication or encryption. This level is not supported for SNMPv3.
-
authNoPriv—Security level that provides authentication but does not provide encryption.
-
authPriv—Security level that provides both authentication and encryption.
Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. The security model combined with the security level determine the security mechanism applied when the SNMP message is processed. The following table identifies what the combinations of security models and levels mean.
Model |
Level |
Authentication |
Encryption |
What Happens |
---|---|---|---|---|
v1 |
noAuthNoPriv |
Community string |
No |
Uses a community string match for authentication. |
v2c |
noAuthNoPriv |
Community string |
No |
Uses a community string match for authentication. |
v3 |
authNoPriv |
HMAC-MD5, or HMAC-SHA |
No |
Provides authentication based on the Hash-Based Message Authentication Code (HMAC) Message Digest 5 (MD5) algorithm or the HMAC Secure Hash Algorithm (SHA). |
v3 |
authPriv |
HMAC-MD5, or HMAC-SHA |
DES |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encryption Standard (DES) 56-bit encryption in addition to authentication based on the Cipher Block Chaining (CBC) DES (DES-56) standard. |
User-Based Security Model
The SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the following services:
-
Message integrity—Ensures that messages have not been altered or destroyed in an unauthorized manner and that data sequences have not been altered to an extent greater than can occur nonmaliciously.
-
Message origin authentication—Ensures that the claimed identity of the user on whose behalf received data was originated is confirmed.
-
Message confidentiality—Ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes.
SNMPv3 authorizes management operations only by configured users and encrypts SNMP messages.
Cisco NX-OS uses three authentication protocols for SNMPv3:
-
HMAC-MD5-96 authentication protocol
-
HMAC-SHA-96 authentication protocol
Cisco NX-OS uses Advanced Encryption Standard (AES) as one of the privacy protocols for SNMPv3 message encryption and conforms with RFC 3826.
The priv option offers a choice of DES or 128-bit AES encryption for SNMP security encryption. The priv option and the aes-128 token indicate that this privacy password is for generating a 128-bit AES key. The AES priv password can have a minimum of eight characters. If the passphrases are specified in clear text, you can specify a maximum of 64 case-sensitive, alphanumeric characters. If you use the localized key, you can specify a maximum of 130 characters.
Note |
For an SNMPv3 operation using the external AAA server, you must use AES for the privacy protocol in the user configuration on the external AAA server. |
CLI and SNMP User Synchronization
SNMPv3 user management can be centralized at the Access Authentication and Accounting (AAA) server level. This centralized user management allows the SNMP agent in Cisco NX-OS to leverage the user authentication service of the AAA server. Once user authentication is verified, the SNMP PDUs are processed further. Additionally, the AAA server is also used to store user group names. SNMP uses the group names to apply the access/role policy that is locally available in the switch.
Any configuration changes made to the user group, role, or password results in database synchronization for both SNMP and AAA.
Cisco NX-OS synchronizes the user configuration in the following ways:
-
The authentication passphrase specified in the snmp-server user command becomes the password for the CLI user.
-
The password specified in the username command becomes the authentication and privacy passphrases for the SNMP user.
-
If you create or delete a user using either SNMP or the CLI, the user is created or deleted for both SNMP and the CLI.
-
User-role mapping changes are synchronized in SNMP and the CLI.
-
Role changes (deletions or modifications) from the CLI are synchronized to SNMP.
Note |
When you configure a passphrase/password in localized key/encrypted format, Cisco NX-OS does not synchronize the user information (passwords, roles, and so on). Cisco NX-OS holds the synchronized user configuration for 60 minutes by default. |
Group-Based SNMP Access
Note |
Because group is a standard SNMP term used industry-wide, we refer to roles as groups in this SNMP section. |
SNMP access rights are organized by groups. Each group in SNMP is similar to a role through the CLI. Each group is defined with read access or read-write access.
You can begin communicating with the agent once your username is created, your roles are set up by your administrator, and you are added to the roles.
SNMP and Embedded Event Manager
The Embedded Event Manager (EEM) feature monitors events, including SNMP MIB objects, and triggers an action based on these events. One of the actions could be to send an SNMP notification. EEM sends the cEventMgrPolicyEvent of CISCO-EMBEDDED-EVENT-MGR-MIB as the SNMP notification.
Multiple Instance Support
A device can support multiple instances of a logical network entity, such as protocol instances or virtual routing and forwarding (VRF) instances. Most existing MIBs cannot distinguish between these multiple logical network entities. For example, the original OSPF-MIB assumes a single protocol instance on a device, but you can now configure multiple OSPF instances on a device.
SNMPv3 uses contexts to distinguish between these multiple instances. An SNMP context is a collection of management information that you can access through the SNMP agent. A device can support multiple contexts for different logical network entities. An SNMP context allows the SNMP manager to access one of the multiple instances of a MIB module supported on the device for the different logical network entities.
Cisco NX-OS supports the CISCO-CONTEXT-MAPPING-MIB to map between SNMP contexts and logical network entities. You can associate an SNMP context to a VRF, protocol instance, or topology.
SNMPv3 supports contexts with the contextName field of the SNMPv3 PDU. You can map this contextName field to a particular protocol instance or VRF.
For SNMPv2c, you can map the SNMP community to a context using the snmpCommunityContextName MIB object in the SNMP-COMMUNITY-MIB (RFC 3584). You can then map this snmpCommunityContextName to a particular protocol instance or VRF using the CISCO-CONTEXT-MAPPING-MIB or the CLI.
High Availability for SNMP
Cisco NX-OS supports stateless restarts for SNMP. After a reboot or supervisor switchover, Cisco NX-OS applies the running configuration.
Virtualization Support for SNMP
Cisco NX-OS supports one instance of the SNMP. SNMP supports multiple MIB module instances and maps them to logical network entities.
SNMP is also VRF aware. You can configure SNMP to use a particular VRF to reach the SNMP notification host receiver. You can also configure SNMP to filter notifications to an SNMP host receiver based on the VRF where the notification occurred.