Table Of Contents
Implementing SNMP on Cisco IOS XR Software
Contents
Prerequisites for Implementing SNMP on Cisco IOS XR Software
Information About Implementing SNMP on Cisco IOS XR Software
SNMP Functional Overview
SNMP Manager
SNMP Agent
MIB
SNMP Notifications
SNMP Versions
Comparison of SNMPv1, v2c, and v3
Security Models and Levels for SNMPv1, v2, v3
SNMPv3 Benefits
SNMPv3 Costs
User-Based Security Model
View-Based Access Control Model
How to Implement SNMP on Cisco IOS XR Software
Configuring SNMPv3
Configuring SNMP Trap Notifications
Setting the Contact, Location, and Serial Number of the SNMP Agent
Defining the Maximum SNMP Agent Packet Size
Changing Notification Operation Values
Configuration Examples for Implementing SNMP on Cisco IOS XR Software
Configuring SNMPv3: Example
Configuring Trap Notifications: Example
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Implementing SNMP on Cisco IOS XR Software
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.
This module describes the new and revised tasks you need to implement SNMP on your Cisco IOS XR network.
Note 
For detailed conceptual information about SNMP on the Cisco IOS XR software and complete descriptions of the SNMP commands listed in this module, refer to the "Related Documents" section of this module. To locate documentation for other commands that might appear in the course of performing a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing SNMP on Cisco IOS XR Software
Release
|
Modification
|
Release 2.0
|
This feature was introduced on the Cisco CRS-1.
|
Release 3.0
|
No modification
|
Release 3.2
|
Support was added for the Cisco XR 12000 Series Router.
|
Release 3.3.0
|
No modification.
|
Release 3.4.0
|
No modification.
|
Release 3.5.0
|
No modification.
|
Contents
•Prerequisites for Implementing SNMP on Cisco IOS XR Software
•Information About Implementing SNMP on Cisco IOS XR Software
•How to Implement SNMP on Cisco IOS XR Software
•Configuration Examples for Implementing SNMP on Cisco IOS XR Software
•Additional References
Prerequisites for Implementing SNMP on Cisco IOS XR Software
You must be in a user group associated with a task group that includes the proper task IDs for SNMP commands. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
Information About Implementing SNMP on Cisco IOS XR Software
To implement SNMP, you need to understand the following concepts:
•SNMP Functional Overview
•SNMP Notifications
•SNMP Versions
•SNMPv3 Benefits
•SNMPv3 Costs
SNMP Functional Overview
The SNMP framework consists of three parts:
•An SNMP manager
•An SNMP agent
•A MIB
SNMP Manager
The SNMP manager is the system used to control and monitor the activities of network hosts using SNMP. The most common managing system is called a network management system (NMS). The term NMS can be applied to either a dedicated device used for network management, or the applications used on such a device. A variety of network management applications are available for use with SNMP. These features range from simple command-line applications to feature-rich graphical user interfaces (such as the CiscoWorks2000 line of products).
SNMP Agent
The SNMP agent is the software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The agent and MIB reside on the router. To enable the SNMP agent, you must define the relationship between the manager and the agent.
MIB
The MIB is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB there are collections of related objects, defined in MIB modules. MIB modules are written in the SNMP MIB module language, as defined in STD 58, RFC 2578, RFC 2579, and RFC 2580. Note that individual MIB modules are also referred to as MIBs; for example, the Interfaces Group MIB (IF-MIB) is a MIB module within the MIB on your system.
The SNMP agent contains MIB variables whose values the SNMP manager can request or change through Get or Set operations. A manager can get a value from an agent or store a value into that agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to manager requests to get or set data.
Figure 1 illustrates the communications relationship between the SNMP manager and agent. A manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited notifications (traps) to the manager to notify the manager of network conditions.
Figure 1 Communication Between an SNMP Agent and Manager
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. On the Cisco IOS XR software, unsolicited (asynchronous) notifications can be generated only as traps. Traps are messages alerting the SNMP manager to a condition on the network. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.
Note Inform requests (inform operations) are not supported on the Cisco IOS XR software.
Traps are less reliable than informs because the receiver does not send any acknowledgment when it receives a trap. The sender 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 manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.
However, traps are often preferred because informs consume more resources in the router and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, and an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network. Thus, traps and inform requests provide a trade-off between reliability and resources.
In Figure 2, the agent router sends a trap to the SNMP manager. Although the manager receives the trap, it does not send any acknowledgment to the agent. The agent has no way of knowing that the trap reached its destination.
Figure 2 Trap Received by the SNMP Manager
In Figure 3, the agent sends a trap to the manager, but the trap does not reach the manager. Because the agent has no way of knowing that the trap did not reach its destination, the trap is not sent again. The manager never receives the trap.
Figure 3 Trap Not Received by the SNMP Manager
SNMP Versions
The Cisco IOS XR software supports the following versions of SNMP:
•Simple Network Management Protocol Version 1 (SNMPv1)
•Simple Network Management Protocol Version 2c (SNMPv2c)
•Simple Network Management Protocol Version 3 (SNMPv3)
Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers able to access the agent MIB is defined by an IP address access control list and password.
SNMPv2c support includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2c improved error handling support 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 now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions.
SNMPv3 is a security model. A security model is an authentication strategy that is set up for a user and the group 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 will determine which security mechanism is employed when an SNMP packet is handled. See Table 2 for a list of security levels available in SNMPv3. The SNMPv3 feature supports RFCs 3411 to 3418.
You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS XR software to support communications with one management station using the SNMPv1 protocol, one using the SNMPv2c protocol, and another using SMNPv3.
Comparison of SNMPv1, v2c, and v3
SNMP v1, v2c, and v3 all support the following operations:
•get-request—Retrieves a value from a specific variable.
•get-next-request—Retrieves the value following the named variable; this operation is often used to retrieve variables from within a table. With this operation, an SNMP manager does not need to know the exact variable name. The SNMP manager searches sequentially to find the needed variable from within the MIB.
•get-response—An operation that replies to a get-request, get-next-request, and set-request sent by an NMS.
•set-request—An operation that 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.
Table 1 identifies other key SNMP features supported by the SNMP v1, v2c, and v3.
Table 1 SNMPv1, v2c, and v3 Feature Support
Feature
|
SNMP v1
|
SNMP v2c
|
SNMP v3
|
Get-Bulk Operation
|
No
|
Yes
|
Yes
|
Inform Operation
|
No
|
Yes (no on the Cisco IOS XR software)
|
Yes (no on the Cisco IOS XR software)
|
64 Bit Counter
|
No
|
Yes
|
Yes
|
Textual Conventions
|
No
|
Yes
|
Yes
|
Authentication
|
No
|
No
|
Yes
|
Privacy (Encryption)
|
No
|
No
|
Yes
|
Authorization and Access Controls (Views)
|
No
|
No
|
Yes
|
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.
•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.
Table 2 identifies what the combinations of security models and levels mean.
Table 2 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 Benefits
SNMPv3 provides secure access to devices by providing authentication, encryption and access control. These added security benefits secure SNMP against the following security threats:
•masquerade—The threat that an SNMP user may assume the identity of another SNMP user to perform management operations for which that SNMP user does not have authorization.
•message stream modification—The threat that messages may be maliciously reordered, delayed, or replayed (to an extent that is greater than can occur through the natural operation of a subnetwork service) to cause SNMP to perform unauthorized management operations.
•disclosure—The threat that exchanges between SNMP engines could be eavesdropped. Protecting against this threat may be required as a matter of local policy.
In addition, SNMPv3 provides access control over protocol operations on SNMP managed objects.
SNMPv3 Costs
SNMPv3 authentication and encryption contribute to a slight increase in the response time when SNMP operations on MIB objects are performed. This cost is far outweighed by the security advantages provided by SNMP v3.
Table 3 shows the order of response time (from least to greatest) for the various security model and security level combinations.
Table 3 Order of Response Times from Least to Greatest
Security Model
|
Security Level
|
SNMPv2c
|
noAuthNoPriv
|
SNMPv3
|
noAuthNoPriv
|
SNMPv3
|
authNoPriv
|
SNMPv3
|
authPriv
|
User-Based Security Model
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.
USM uses two authentication protocols:
•HMAC-MD5-96 authentication protocol
•HMAC-SHA-96 authentication protocol
USM uses CBC-DES (DES-56) as the privacy protocol for message encryption.
View-Based Access Control Model
The View-Based Access Control Model (VACM) enables SNMP users to control access to SNMP managed objects by supplying read, write, or notify access to SNMP objects. It prevents access to objects restricted by views. These access policies can be set when user groups are configured with the snmp-server group command.
MIB Views
For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a subset of the management information within the management domain. To provide this capability, access to a management objects is controlled through MIB views, which contain the set of managed object types (and, optionally, the specific instances of object types) that can be viewed.
Access Policy
Access policy determines the access rights of a group. The three types of access rights are as follows:
•read-view access—The set of object instances authorized for the group when objects are read.
•write-view access—The set of object instances authorized for the group when objects are written.
•notify-view access—The set of object instances authorized for the group when objects are sent in a notification.
How to Implement SNMP on Cisco IOS XR Software
This section contains the following procedures:
•Configuring SNMPv3 (required)
•Configuring SNMP Trap Notifications (required)
•Setting the Contact, Location, and Serial Number of the SNMP Agent (optional)
•Defining the Maximum SNMP Agent Packet Size (optional)
•Changing Notification Operation Values (optional)
Note The snmp-server commands enable SNMP on Management Ethernet interfaces by default. For information on how to enable SNMP server support on other inband interfaces, refer to the Implementing Management Plane Protection on Cisco IOS XR Software module in Cisco IOS XR System Security Configuration Guide, Release 3.5.
Configuring SNMPv3
This task explains how to configure SNMPv3 for network management and monitoring.
Note No specific command enables SNMPv3; the first snmp-server global configuration command that you issue enables SNMPv3. Therefore, the sequence in which you issue the snmp-server commands for this task does not matter.
SUMMARY STEPS
1. configure
2. snmp-server engineid local engine-id
3. snmp-server view view-name oid-tree {included | excluded}
4. snmp-server group name {v1 | v2c | v3 {auth | noauth | priv}} [read view] [write view] [notify view] [access-list-name]
5. snmp-server user username groupname {v1 | v2c | v3 [auth {md5 | sha} {clear | encrypted} auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name]
6. end
or
commit
7. show snmp
8. show snmp engineid
9. show snmp group
10. show snmp users
11. show snmp view
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
snmp-server engineid local engine-id
Example:
RP/0/RP0/CPU0:router(config)# snmp-server engineID
local 00:00:00:09:00:00:00:a1:61:6c:20:61
|
(Optional) Specifies the identification number of the local SNMP engine.
|
Step 3
|
snmp-server view view-name oid-tree {included |
excluded}
Example:
RP/0/RP0/CPU0:router(config)# snmp-server view
view_name 1.3.6.1.2.1.1.5 included
|
Creates or modifies a view record.
|
Step 4
|
snmp-server group name {v1 | v2c | v3 {auth |
noauth | priv}} [read view] [write view] [notify
view] [access-list-name]
Example:
RP/0/RP0/CPU0:router(config)# snmp-server group
group_name v3 noauth read view_name1 write
view_name2
|
Configures a new SNMP group, or a table that maps SNMP users to SNMP views.
|
Step 5
|
snmp-server user username groupname
{v1 | v2c | v3 [auth {md5 | sha} {clear |
encrypted} auth-password [priv des56 {clear |
encrypted} priv-password]]} [access-list-name]
Example:
RP/0/RP0/CPU0:router(config)# snmp-server user
noauthuser group_name v3
|
Configures a new user to an SNMP group.
|
Step 6
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 7
|
show snmp
Example:
RP/0/RP0/CPU0:router# show snmp
|
(Optional) Displays information about the status of SNMP.
|
Step 8
|
show snmp engineid
Example:
RP/0/RP0/CPU0:router# show snmp engineid
|
(Optional) Displays information about the local SNMP engine.
|
Step 9
|
show snmp group
Example:
RP/0/RP0/CPU0:router# show snmp group
|
(Optional) Displays information about each SNMP group on the network.
|
Step 10
|
show snmp users
Example:
RP/0/RP0/CPU0:router# show snmp users
|
(Optional) Displays information about each SNMP username in the SNMP users table.
|
Step 11
|
show snmp view
Example:
RP/0/RP0/CPU0:router# show snmp view
|
(Optional) Displays information about the configured views, including the associated MIB view family name, storage type, and status.
|
Configuring SNMP Trap Notifications
This task explains how to configure the router to send SNMP trap notifications.
Note You can omit steps 2 to 4 if you have already completed the steps documented under the "Configuring SNMPv3" task.
SUMMARY STEPS
1. configure
2. snmp-server engineid local engine-id
3. snmp-server group name {v1 | v2c | v3 {auth | noauth | priv}} [read view] [write view] [notify view] [access-list-name]
4. snmp-server user username groupname {v1 | v2c | v3 [auth {md5 | sha} {clear | encrypted} auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name]
5. snmp-server host address [traps] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port]
6. snmp-server traps [notification-type]
7. end
or
commit
8. show snmp host
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
snmp-server engineid local engine-id
Example:
RP/0/RP0/CPU0:router(config)# snmp-server engineID
local 00:00:00:09:00:00:00:a1:61:6c:20:61
|
(Optional) Specifies the identification number of the local SNMP engine.
|
Step 3
|
snmp-server group name {v1 | v2c | v3 {auth |
noauth | priv}} [read view] [write view] [notify
view] [access-list-name]
Example:
RP/0/RP0/CPU0:router(config)# snmp-server group
group_name v3 noauth read view_name1 write
view_name2
|
Configures a new SNMP group, or a table that maps SNMP users to SNMP views.
|
Step 4
|
snmp-server user username groupname
{v1 | v2c | v3 [auth {md5 | sha} {clear |
encrypted} auth-password [priv des56 {clear |
encrypted} priv-password]]} [access-list-name]
Example:
RP/0/RP0/CPU0:router(config)# snmp-server user
noauthuser group_name v3
|
Configures a new user to an SNMP group.
|
Step 5
|
snmp-server host address [traps] [version {1 | 2c |
3 [auth | noauth | priv]}] community-string
[udp-port port]
Example:
RP/0/RP0/CPU0:router(config)# snmp-server host
12.26.25.61 traps version 3 noauth userV3noauth
|
Specifies SNMP trap notifications, the version of SNMP to use, the security level of the notifications, and the recipient (host) of the notifications.
|
Step 6
|
snmp-server traps [notification-type]
Example:
RP/0/RP0/CPU0:router(config)# snmp-server traps bgp
|
Enables the sending of trap notifications and specifies the type of trap notifications to be sent.
•If a trap is not specified with the notification-type argument, all supported trap notifications are enabled on the router. To display which trap notifications are available on your router, enter the snmp-server traps ? command.
|
Step 7
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 8
|
show snmp host
Example:
RP/0/RP0/CPU0:router# show snmp host
|
(Optional) Displays information about the configured SNMP notification recipient (host), port number and security model.
|
Setting the Contact, Location, and Serial Number of the SNMP Agent
This task explains how to set the system contact string, system location string, and system serial number of the SNMP agent.
Note The sequence in which you issue the snmp-server commands for this task does not matter.
SUMMARY STEPS
1. configure
2. snmp-server contact system-contact-string
3. snmp-server location system-location
4. snmp-server chassis-id serial-number
5. end
or
commit
DETAILED STEPS
| |
Command or Actions
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
snmp-server contact system-contact-string
Example:
RP/0/RP0/CPU0:router(config)# snmp-server contact Dial System Operator at beeper # 27345
|
(Optional) Sets the system contact string.
|
Step 3
|
snmp-server location system-location
Example:
RP/0/RP0/CPU0:router(config)# snmp-server location
Building 3/Room 214
|
(Optional) Sets the system location string.
|
Step 4
|
snmp-server chassis-id serial-number
Example:
RP/0/RP0/CPU0:router(config)# snmp-server
chassis-id 1234456
|
(Optional) Sets the system serial number.
|
Step 5
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Defining the Maximum SNMP Agent Packet Size
This task shows how to configure the largest SNMP packet size permitted when the SNMP server is receiving a request or generating a reply.
Note The sequence in which you issue the snmp-server commands for this task does not matter.
SUMMARY STEPS
1. configure
2. snmp-server packetsize byte-count
3. end
or
commit
DETAILED STEPS
| |
Command or Actions
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
snmp-server packetsize byte-count
Example:
RP/0/RP0/CPU0:router(config)# snmp-server
packetsize 1024
|
(Optional) Sets the maximum packet size.
|
Step 3
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Changing Notification Operation Values
Once SNMP notifications have been enabled, you can specify a value other than the default for the source interface, message queue length, or retransmission interval.
This task explains how to specify a source interface for trap notifications, the message queue length for each host, and the retransmission interval.
Note The sequence in which you issue the snmp-server commands for this task does not matter.
SUMMARY STEPS
1. configure
2. snmp-server trap-source interface-type interface-number
3. snmp-server queue-length length
4. snmp-server trap-timeout seconds
5. end
or
commit
DETAILED STEPS
| |
Command or Actions
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
snmp-server trap-source interface-type
interface-number
Example:
RP/0/RP0/CPU0:router(config)# snmp-server
trap-source POS 0/0/1/0
|
(Optional) Specifies a source interface for trap notifications.
|
Step 3
|
snmp-server queue-length length
Example:
RP/0/RP0/CPU0:router(config)# snmp-server
queue-length 20
|
(Optional) Establishes the message queue length for each notification.
|
Step 4
|
snmp-server trap-timeout seconds
Example:
RP/0/RP0/CPU0:router(config)# snmp-server
trap-timeout 20
|
(Optional) Defines how often to resend notifications on the retransmission queue.
|
Step 5
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuration Examples for Implementing SNMP on Cisco IOS XR Software
This section provides the following configuration examples:
•Configuring SNMPv3: Example
•Configuring Trap Notifications: Example
Configuring SNMPv3: Example
Setting an Engine ID
This example shows how to set the identification of the local SNMP engine:
RP/0/RP0/CPU0:MiniQ(config)# snmp-server engineID local
00:00:00:09:00:00:00:a1:61:6c:20:61
Note Once the engine ID has been configured, the SNMP agent restarts.
Verifying the Identification of the Local SNMP Engines
This example shows how to verify the identification of the local SNMP engine:
RP/0/RP0/CPU0:router(config)# show snmp engineid
SNMP engineID 00000009000000a1ffffffff
Creating a View
There are two ways to create a view:
•You can include the object identifier (OID) of an ASN.1 subtree of a MIB family from a view by using the included keyword of the snmp-server view command.
•You can exclude the OID subtree of the ASN.1 subtree of a MIB family from a view by using the excluded keyword of the snmp-server view command.
This example shows how to create a view that includes the sysName (1.3.6.1.2.1.1.5) object:
RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 included
This example shows how to create a view that includes all the OIDs of a system group:
RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1 included
This example shows how to create a view that includes all the OIDs under the system group except the sysName object (1.3.6.1.2.1.1.5), which has been excluded:
RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1 included
RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 excluded
Verifying Configured Views
This example shows how to display information about the configured views:
RP/0/RP0/CPU0:router# show snmp view
v1default 1.3.6.1 - included nonVolatile active
view_name 1.3.6.1.2.1.1 - included nonVolatile active
view_name 1.3.6.1.2.1.1.5 - excluded nonVolatile active
Creating Groups
If you do not explicitly specify a notify, read, or write view, the Cisco IOS XR software uses the v1 default (1.3.6.1). This example shows how to create a group that utilizes the default view:
RP/0/RP0/CPU0:router(config)# snmp-server group group-name v3 auth
The following configuration example shows how to create a group that has read access to all the OIDs in the system except the sysUpTime object (1.3.6.1.2.1.1.3), which has been excluded from the view applied to the group, but write access only to the sysName object (1.3.6.1.2.1.1.5):
snmp-server view view_name1 1.3.6.1.2.1.1 included
snmp-server view view_name1 1.3.6.1.2.1.1.3 excluded
snmp-server view view_name2 1.3.6.1.2.1.1.5 included
snmp-server group group_name v3 auth read view_name1 write view_name2
Verifying Groups
This example shows how to verify the attributes of configured groups:
RP/0/RP0/CPU0:router# show snmp group
groupname: group_name security model:usm
readview : view_name1 writeview: view_name2
Creating and Verifying Users
Given the following SNMPv3 view and SNMPv3 group configuration:
snmp-server view view_name1 1.3.6.1.2.1.1 included
snmp-server group group_name v3 noauth read view_name write view-name
This example shows how to create a noAuthNoPriv user with read and write view access to a system group:
RP/0/RP0/CPU0:router(config)# snmp-server user noauthuser group_name v3
Note The user must belong to a noauth group before a noAuthNoPriv user can be created.
This example shows how to verify the attributes that apply to the SNMP user:
RP/0/RP0/CPU0:router# show snmp user
storage-type: nonvolatile active
Given the following SNMPv3 view and SNMPv3 group configuration:
snmp-server view view_name 1.3.6.1.2.1.1 included
snmp group group_name v3 priv read view_name write view_name
This example shows how to create authNoPriv user with read and write view access to a system group:
RP/0/RP0/CPU0:router(config)# snmp-server user authuser group_name v3 auth md5 clear
auth_passwd
Note Because the group is configured at a security level of Auth, the user must be configured as auth at a minimum to access this group (priv users could also access this group). The authNoPriv user configured in this group, authuser, must supply an authentication password to access the view. In the example, auth_passwd is set as the authentication password string. Note that clear keyword is specified before the auth_passwd password string. The clear keyword indicates that the password string being supplied is unencrypted.
This example shows how to verify the attributes that apply to SNMP user:
RP/0/RP0/CPU0:router# show snmp user
storage-type: nonvolatile active
Given the following SNMPv3 view and SNMPv3 group configuration:
snmp view view_name 1.3.6.1.2.1.1 included
snmp group group_name v3 priv read view_name write view_name
This example shows how to create an authPriv user with read and write view access to a system group:
RP/0/RP0/CPU0:router(config)# snmp-server user privuser group_name v3 auth md5 clear
auth_passwd priv des56 clear priv_passwd
Note Because the group has a security level of Priv, the user must be configured as a priv user to access this group. In this example, the user, privuser, must supply both an authentication password and privacy password to access the OIDs in the view.
This example shows how to verify the attributes that apply to the SNMP user:
RP/0/RP0/CPU0:router# show snmp user
storage-type: nonvolatile active
Configuring Trap Notifications: Example
The following example configures an SNMP agent to send out different types of traps. The configuration includes a v2c user, a noAuthNoPriv user, anauthNoPriv user, and an AuthPriv user:
Note The default User Datagram Protocol (UDP) port is 161. If you do not a specify a UDP port with the udp-port keyword and port argument, then the configured SNMP trap notifications are sent to port 161.
snmp-server host 10.50.32.170 version 2c userv2c udp-port 2345
snmp-server host 10.50.32.170 version 3 auth userV3auth udp-port 2345
snmp-server host 10.50.32.170 version 3 priv userV3priv udp-port 2345
snmp-server host 10.50.32.170 version 3 noauth userV3noauth udp-port 2345
snmp-server user userv2c groupv2c v2c
snmp-server user userV3auth groupV3auth v3 auth md5 encrypted 140F0A13
snmp-server user userV3priv groupV3priv v3 auth md5 encrypted 021E1C43 priv des56
encrypted 1110001C
snmp-server user userV3noauth groupV3noauth v3 LROwner
snmp-server view view_name 1.3 included
snmp-server community public RW
snmp-server group groupv2c v2c read view_name
snmp-server group groupV3auth v3 auth read view_name
snmp-server group groupV3priv v3 priv read view_name
snmp-server group groupV3noauth v3 noauth read view_name
This example shows how to verify the configuration SNMP trap notification recipients host, the recipients of SNMP trap notifications. The output displays the following information:
•The IP address of the configured notification host
•The UDP port where SNMP notification messages are sent
•The type of trap configured
•The security level of the configured user
•The security model configured
RP/0/RP0/CPU0:router(config)# show snmp host
Notification host: 10.50.32.170 udp-port: 2345 type: trap
user: userV3auth security model: v3 auth
Notification host: 10.50.32.170 udp-port: 2345 type: trap
user: userV3noauth security model: v3 noauth
Notification host: 10.50.32.170 udp-port: 2345 type: trap
user: userV3priv security model: v3 priv
Notification host: 10.50.32.170 udp-port: 2345 type: trap
user: userv2c security model: v2c
Additional References
The following sections provide references related to Implementing SNMP on Cisco IOS XRsoftware.
Related Documents
Related Topic
|
Document Title
|
Cisco IOS XR SNMP commands
|
SNMP Server Commands on Cisco IOS XR Software module of Cisco IOS XR System Management Command Reference, Release 3.5
|
Cisco IOS XR master command index
|
Cisco IOS XR Commands Master List, Release 3.5
|
Cisco IOS XR getting started material
|
Cisco IOS XR Getting Started Guide, Release 3.5
|
Information about user groups and task IDs
|
Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.5
|
Standards
Standards
|
Title
|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
|
—
|
MIBs
RFCs
RFCs
|
Title
|
RFC 3411
|
An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
|
RFC 3412
|
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
|
RFC 3413
|
Simple Network Management Protocol (SNMP) Applications
|
RFC 3414
|
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
|
RFC 3415
|
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
|
RFC 3416
|
Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
|
RFC 3417
|
Transport Mappings for the Simple Network Management Protocol (SNMP)
|
RFC 3418
|
Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
|
Technical Assistance
Description
|
Link
|
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
|
http://www.cisco.com/techsupport
|
