This chapter describes the configuration of the Simple Network Management Protocol (SNMP) on Cisco Nexus 5000 Series switches and contains the following sections:
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.
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 5000 Series
switch 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
Note
Cisco NX-OS
does not support SNMP sets for Ethernet MIBs.
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. Traps are less reliable than informs
because the SNMP manager does not send any acknowledgment when it receives a
trap. The switch 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
Cisco Nexus 5000 Series switch never receives a
response, it can send the inform request again.
You can configure
Cisco NX-OS to send notifications
to multiple host receivers.
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.
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.
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.
User-Based Security Model
The following table identifies what the combinations of security
models and levels mean.
Table 1 SNMP Security Models and Levels
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
noAuthNoPriv
Username
No
Uses a username 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.
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 non-maliciously.
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 two 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 along with the
aes-128 token indicates 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 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 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 user
configuration in the following ways:
The
auth passphrase specified in the
snmp-server user command becomes the password
for the CLI user.
The password specified in the
username command becomes as the
auth and
priv passphrases for the SNMP user.
Deleting a user using either SNMP or the CLI results in the user
being deleted for both SNMP and the CLI.
User-role mapping changes are synchronized in SNMP and the CLI.
Note
When you configure passphrase/password in localized key/encrypted
format,
Cisco NX-OS does not synchronize
the password.
Group-Based SNMP Access
Note
Because
group is a standard SNMP term used industry-wide,
roles are referred to 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 three accesses:
read access, write access, and notification access. Each access can be enabled
or disabled within each group.
You can begin communicating with the agent once your user name is
created, your roles are set up by your administrator, and you are added to the
roles.
Configuration Guidelines and Limitations
SNMP has the following configuration guidelines and limitations:
Cisco NX-OS supports read-only access to Ethernet MIBs.
Configures an SNMP user with authentication and privacy
parameters.
Step 3
switch#
show snmp user
(Optional)
Displays information about one or more SNMP users.
Step 4
switch#
copy running-config startup-config
(Optional)
Saves this configuration change.
Enforcing SNMP Message Encryption
You can configure SNMP to require authentication or
encryption for incoming requests. By default the SNMP agent accepts SNMPv3
messages without authentication and encryption. When you enforce privacy,
Cisco NX-OS
responds with an authorization Error for any SNMPv3 PDU request using
securityLevel parameter of either noAuthNoPriv or authNoPriv.
You can enforce SNMP message encryption for a
specific user.
Command
Purpose
switch(config)#
snmp-server
usernameenforcePriv
Enforces SNMP message encryption for
this user.
You can enforce SNMP message encryption for all
users.
Command
Purpose
switch(config)#
snmp-server
globalEnforcePriv
Enforces SNMP message encryption for all
users.
Assigning SNMPv3 Users to Multiple Roles
After you configure an SNMP user, you can assign multiple roles for
the user.
Note
Only users belonging to a network-admin role can assign roles to
other users.
Command
Purpose
switch(config)#
snmp-server usernamegroup
Associates this SNMP user with the configured user role.
Creating SNMP Communities
You can create SNMP communities for SNMPv1 or SNMPv2c.
To create an SNMP community string in a global configuration mode,
perform this task:
You can configure
Cisco NX-OS to generate SNMP
notifications to multiple host receivers.
You can configure a host receiver for SNMPv1 traps in a global
configuration mode.
Command
Purpose
switch(config)#
snmp-server hostip-addresstraps version 1community [udp_portnumber]
Configures a host receiver for SNMPv1 traps. The community
can be any alphanumeric string up to 255 characters. The UDP port number range
is from 0 to 65535.
You can configure a host receiver for SNMPv2c traps or informs in a
global configuration mode.
Command
Purpose
switch(config)#
snmp-server hostip-address {traps |
informs}
version 2ccommunity [udp_portnumber]
Configures a host receiver for SNMPv2c traps or informs. The
community can be any alphanumeric string up to 255 characters. The UDP port
number range is from 0 to 65535.
You can configure a host receiver for SNMPv3 traps or informs in a
global configuration mode.
Configures a host receiver for SNMPv2c traps or informs. The
username can be any alphanumeric string up to 255 characters. The UDP port
number range is from 0 to 65535.
Note
The SNMP manager must know the user credentials (authKey/PrivKey)
based on the SNMP engineID of the
Cisco Nexus 5000 Series switch to
authenticate and decrypt the SNMPv3 messages.
The following example shows how to configure a host receiver for an
SNMPv1 trap:
switch(config)# snmp-server host 192.0.2.1 traps version 1 public
The following example shows how to configure a host receiver for an
SNMPv2 inform:
switch(config)# snmp-server host 192.0.2.1 informs version 2c public
The following example shows how to configure a host receiver for an
SNMPv3 inform:
switch(config)# snmp-server host 192.0.2.1 informs version 3 auth NMS
Configuring the Notification Target User
You must configure a notification target user on the device to send
SNMPv3 inform notifications to a notification host receiver.
The
Cisco Nexus 5000 Series switch uses the
credentials of the notification target user to encrypt the SNMPv3 inform
notification messages to the configured notification host receiver.
Note
For authenticating and decrypting the received INFORM PDU, The
notification host receiver should have the same user credentials as configured
in the
Cisco Nexus 5000 Series switch to
authenticate and decrypt the informs.
Configures the notification target user with the specified
engine ID for notification host receiver. The engineID format is a 12-digit
colon-separated hexadecimal number.
The following example shows how to configure a notification target
user:
You can configure which linkUp/linkDown notifications to enable on a
device. You can enable the following types of linkUp/linkDown notifications:
Cisco—Cisco NX-OS sends only the Cisco-defined notifications
(cieLinkUp, cieLinkDow in CISCO-IF-EXTENSION-MIB.my), if ifLinkUpDownTrapEnable
(defined in IF-MIB) is enabled for that interface.
IETF—Cisco NX-OS sends only the IETF-defined notifications
(linkUp, linkDown in IF-MIB) with only the defined varbinds, if
ifLinkUpDownTrapEnable (defined in IF-MIB) is enabled for that interface.
IEFT extended—Cisco NX-OS sends only the IETF-defined
notifications (linkUp, linkDown defined in IF-MIB), if ifLinkUpDownTrapEnable
(defined in IF-MIB) is enabled for that interface. Cisco NX-OS adds additional
varbinds specific to Cisco Systems in addition to the varbinds defined in the
IF-MIB. This is the default setting.
IEFT Cisco—Cisco NX-OS sends the notifications (linkUp, linkDown)
defined in IF-MIB and notifications (cieLinkUp, cieLinkDown) defined in
CISCO-IF-EXTENSION-MIB.my , if ifLinkUpDownTrapEnable (defined in IF-MIB) is
enabled for that interface. Cisco NX-OS sends only the varbinds defined in the
linkUp and linkDown notifications.
IEFT extended Cisco—Cisco NX-OS sends the notifications (linkUp,
linkDown) defined in IF-MIB and notifications (cieLinkUp, cieLinkDown) defined
in CISCO-IF-EXTENSION-MIB.my, if ifLinkUpDownTrapEnable (defined in IF-MIB) is
enabled for that interface. Cisco NX-OS adds additional varbinds specific to
Cisco Systems in addition to the varbinds defined in the IF-MIB for the linkUp
and linkDown notifications.
Procedure
Command or Action
Purpose
Step 1
switch#
configure terminal
Enters configuration mode.
Step 2
switch(config)#
snmp-server enable traps link [cisco]
[ietf |
ietf-extended]
Enables the link SNMP notifications.
Disabling Link Notifications on an Interface
You can disable linkUp and linkDown notifications on an individual
interface. You can use this limit notifications on flapping interface (an
interface that transitions between up and down repeatedly).
Procedure
Command or Action
Purpose
Step 1
switch#
configure terminal
Enters configuration mode.
Step 2
switch(config)#
interfacetypeslot/port
Specifies the interface to be changed.
Step 3
switch(config -if)#
no snmp trap link-status
Disables SNMP link-state traps for the interface. Enabled by
default.
Enabling One-Time Authentication for SNMP over TCP
You can enable a one-time authentication for SNMP over a TCP session.
Command
Purpose
switch(config)#
snmp-server tcp-session [auth]
Enables a one-time authentication for SNMP over a TCP
session. Default is disabled.
Assigning SNMP Switch Contact and Location Information
You can assign the switch contact information, which is limited to 32
characters (without spaces), and the switch location.
Procedure
Command or Action
Purpose
Step 1
switch#
configuration terminal
Enters configuration mode.
Step 2
switch(config)#
snmp-server contactname
Configures sysContact, the SNMP contact name.
Step 3
switch(config)#
snmp-server locationname
Configures sysLocation, the SNMP location.
Step 4
switch#
show snmp
(Optional)
Displays information about one or more destination profiles.
Step 5
switch#
copy running-config startup-config
(Optional)
Saves this configuration change.
Configuring the Context to Network Entity Mapping
You can configure an SNMP context to map to a logical network entity, such as a protocol instance or VRF.
Maps an SNMPv2c community to an SNMP context. The names can be any alphanumeric string up to 32 characters.
Step 4
switch(config)#
no snmp-server contextcontext-name [instanceinstance-name] [vrfvrf-name] [topologytopology-name]
(Optional)
Deletes the mapping between an SNMP context and a protocol instance, VRF, or topology. The names can be any alphanumeric string up to 32 characters.
Note
Do not enter an instance, VRF, or topology to delete a context mapping. If you use the instance, vrf, or topology keywords, you configure a mapping between the context and a zero-length string.
Verifying SNMP Configuration
To display SNMP configuration information, perform one of the
following tasks:
Command
Purpose
switch#
show snmp
Displays the SNMP status.
switch#
show snmp community
Displays the SNMP community strings.
switch#
show snmp engineID
Displays the SNMP engineID.
switch#
show snmp group
Displays SNMP roles.
switch#
show snmp sessions
Displays SNMP sessions.
switch#
show snmp trap
Displays the SNMP notifications enabled or disabled.
switch#
show snmp user
Displays SNMPv3 users.
Default SNMP Settings
The following table lists the default settings for SNMP parameters.