Information About SNMP Security
SNMP is an application layer protocol that facilitates the exchange of management information between network devices. In all Cisco MDS 9000 Family switches, three SNMP versions are available: SNMPv1, SNMPv2c, and SNMPv3 (see #con_1242951__).
SNMP Version 1 and Version 2c
SNMP Version 1 (SNMPv1) and SNMP Version 2c (SNMPv2c) use a community string match for user authentication. Community strings provided a weak form of access control in earlier versions of SNMP. SNMPv3 provides much improved access control using strong authentication and should be preferred over SNMPv1 and SNMPv2c wherever it is supported.
SNMP Version 3
Note |
From Cisco MDS NX-OS Release 8.5(1), AES-128 is the recommended encryption algorithm because it is a strong encryption algorithm. However, DES encryption is also supported. In-Service System Downgrade (ISSD) using the install all command is aborted if users with DES privacy protocol are present in the SNMP database. Users need to be reconfigured using the default AES-128 or deleted. This behavior is seen in Cisco MDS NX-OS Release 8.5(1). DES user support in ISSD cases will be added in future releases. However, in case of a cold reboot, the SNMP users with DES privacy protocol are deleted. |
SNMP Version 3 (SNMPv3) is an interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices by a combination of authenticating and encrypting frames over the network. The security features provided in SNMPv3 are:
-
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.
SNMPv3 CLI User Management and AAA Integration
The Cisco NX-OS software implements RFC 3414 and RFC 3415, including user-based security model (USM) and role-based access control. While SNMP and the CLI have common role management and share the same credentials and access privileges, the local user database was not synchronized in earlier releases.
SNMPv3 user management can be centralized at the AAA server level. This centralized user management allows the SNMP agent running on the Cisco MDS switch to leverage the user authentication service of the AAA server. Once user authentication is verified, the SNMP PDUs are processed further. The AAA server also is used to store user group names. SNMP uses the group names to apply the access/role policy that is locally available in the switch.
CLI and SNMP User Synchronization
Any configuration changes made to the user group, role, or password results in database synchronization for both SNMP and AAA.
To create an SNMP or CLI user, use either the username or snmp-server user commands.
- The auth passphrase specified in the snmp-server user command is synchronized as the password for the CLI user.
- The password specified in the username command is synchronized as the auth and priv passphrases for the SNMP user.
Users are synchronized as follows:
- Deleting a user using either command 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 the passphrase/password is specified in localized key/encrypted format, the password is not synchronized. |
- Existing SNMP users continue to retain the auth and priv passphrases without any changes.
- If the management station creates an SNMP user in the usmUserTable, the corresponding CLI user is created without any password (login is disabled) and will have the network-operator role.
AAA Exclusive Behavior in SNMPv3 Servers
The AAA exclusive behavior feature enables you to authenticate users based on location.
A unique SNMPv3 user is not authenticated if the user is not a local user or a remote AAA user. If the user exists in both the local and remote database, the user will be authenticated or rejected based on whether AAA exclusive behavior is enabled or not.
User Location |
AAA Server |
AAA Exclusive Behavior |
User Authentication |
Local user database |
Disabled |
Enabled |
User is authenticated. |
Local user database |
Enabled |
Enabled |
User is not authenticated. |
Local user database |
Enabled |
Disabled |
User is authenticated. |
Local user database |
Disabled |
Disabled |
User is authenticated. |
Remote and local user databases (same username) |
Enabled |
Enabled |
Remote user is authenticated, but the local user is not authenticated. |
Remote and local user databases (same username) |
Disabled |
Enabled |
Local user is authenticated, but the remote user is not authenticated. |
Remote and local user databases (same username) |
Disabled |
Disabled |
Local user is authenticated, but the remote user is not authenticated. |
Remote and local user databases (same username) |
Enabled |
Disabled |
Local user is authenticated, but the remote user is not authenticated. |
Note |
When AAA servers are unreachable, a fallback option can be configured on the server so that a user is validated against the local user database. The SNMPv3 server returns an error if the user is not available in the local database or in the remote user database. The SNMPv3 server returns an “Unknown user” message without checking the availability of AAA servers when a user is not available in the remote user database. |
Restricting Switch Access
You can restrict access to a Cisco MDS 9000 Family switch using IP access control lists (IP-ACLs).
Group-Based SNMP Access
Note |
Because group is a standard SNMP term used industry-wide, we refer to role(s) as group(s) 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.
Creating and Modifying Users
You can create users or modify existing users using SNMP, DCNM-SAN, or the CLI.
- SNMP—Create a user as a clone of an existing user in the usmUserTable on the switch. Once you have created the user, change the cloned secret key before activating the user. Refer to RFC 2574.
- DCNM-SAN.
- CLI—Create a user or modify an existing user using the snmp-server user command.
A network-operator and network-admin roles are available in a Cisco MDS 9000 Family switch. There is also a default-role if you want to use the GUI (DCNM-SAN and Device Manager). You can also use any role that is configured in the Common Roles database.
Tip |
All updates to the CLI security database and the SNMP user database are synchronized. You can use the SNMP password to log into either DCNM-SAN or Device Manager. However, after you use the CLI password to log into DCNM-SAN or Device Manager, you must use the CLI password for all future logins. If a user exists in both the SNMP database and the CLI database before upgrading to Cisco MDS SAN-OS Release 2.0(1b), then the set of roles assigned to the user becomes the union of both sets of roles after the upgrade. |
AES Encryption-Based Privacy
The Advanced Encryption Standard (AES) is the symmetric cipher algorithm. The Cisco NX-OS software uses AES as one of the privacy protocols for SNMP message encryption and conforms with RFC 3826.
The priv option offers a choice of DES or 128-bit AES encryption for SNMP security encryption. Prior to Cisco MDS NX-OS Release 8.5(1), the priv option along with the aes-128 token indicates that this privacy password is for generating a 128-bit AES key. AES-128 has been made the default privacy option from Cisco MDS NX-OS Release 8.5(1). This indicates that any user configured or modified from Cisco MDS NX-OS Release 8.5(1) will use aes-128 as the privacy option. 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, user configurations in the external AAA server require AES to be the privacy protocol to use SNMP PDU encryption. |
Traps, Notifications, and Informs
A trap is an unacknowledged message sent from an SNMP agent to SNMP managers in SNMPv1. It is known as a notification in SNMPv2 and SNMPv3. An inform is an acknowledged message sent from an SNMP agent to an SNMP manager. If the response is not received by the agent, it sends the inform request again.
An inform consumes more resources in the agent and in the network. Unlike a trap or notification, which is discarded by the agent as soon as it is sent, an inform request must be held in memory until a response is received, or the request times out. Traps and notifications can be sent only once, while informs can be sent multiple times. Resending informs increases traffic and contributes to a higher overhead on the network. The same traps, notifications, and informs can be sent to multiple host receivers.
Note |
For SNMPv3 informs to work, you must configure the Network Management Server (NMS) engineID with the SNMP user using the snmp-server user name engineID command. To get a Linux engineID from an NMS, start the snmptarpd and look for the lcd_set_enginetime string in the output.
|
EngineID
An SNMP engineID is used to identify an entity independent of its source address. The entity consists of an SNMP engine and SNMP applications. The engineID is important when protocol data units (PDUs) must traverse proxies or Network Address Translator (NAT), or when the source entity itself has a dynamically assigned transport address or multiple source addresses.
In SNMPv3, engineIDs are also used for encoding and decoding secure PDUs. This is a requirement of the SNMPv3 user-based security model (USM).
There are two types of engineIDs, local and remote. On Cisco MDS 9000 Series switches, only remote engineIDs can be configured. The local engineID is automatically generated by the switch based on the MAC address and does not change.
LinkUp/LinkDown Notifications for Switches
You can configure which LinkUp/LinkDown notifications to enable on switches. You can enable the following types of LinkUp/LinkDown notifications:
- Cisco—Only notifications (cieLinkUp, cieLinkDown) defined in CISCO-IF-EXTENSION-MIB.my are sent for an interface, if ifLinkUpDownTrapEnable (defined in IF-MIB) is enabled for that interface.
- IETF—Only notifications (LinkUp, LinkDown) defined in IF-MIB are sent for an interface, if ifLinkUpDownTrapEnable (defined in IF-MIB) is enabled for that interface. Only the varbinds defined in the notification definition are sent with the notifications.
- IEFT extended—Only notifications (LinkUp, LinkDown) defined in IF-MIB are sent for an interface, if ifLinkUpDownTrapEnable (defined in IF-MIB) is enabled for that interface. In addition to the varbinds defined in the notification definition, varbinds defined in the IF-MIB specific to the Cisco Systems implementation are sent. This is the default setting.
- IEFT Cisco—Only notifications (LinkUp, LinkDown) defined in IF-MIB and notifications (cieLinkUp, cieLinkDown) defined in CISCO-IF-EXTENSION-MIB.my are sent for an interface, if ifLinkUpDownTrapEnable (defined in IF-MIB) is enabled for that interface. Only the varbinds defined in the notification definition are sent with the linkUp and linkDown notifications.
- IEFT extended Cisco—Only notifications (LinkUp, LinkDown) defined in IF-MIB and notifications (cieLinkUp, cieLinkDown) defined in CISCO-IF-EXTENSION-MIB.my are sent for an interface, if ifLinkUpDownTrapEnable (defined in IF-MIB) is enabled for that interface. In addition to the varbinds defined in linkUp and linkDown notification definition, varbinds defined in the IF-MIB specific to the Cisco Systems implementation are sent with the LinkUp and LinkDown notifications.
Note |
For more information on the varbinds defined in the IF-MIB specific to the Cisco Systems implementation, refer to the Cisco MDS 9000 Family MIB Quick Reference. |
Scope of LinkUp and LinkDown Trap Settings
The LinkUp and LinkDown trap settings for the interfaces generate traps based on the following scope:
Switch-level Trap Setting |
Interface-level Trap Setting |
Trap Generated for Interface Links? |
---|---|---|
Enabled (default) |
Enabled (default) |
Yes |
Enabled |
Disabled |
No |
Disabled |
Enabled |
No |
Disabled |
Disabled |
No |