Catalyst 4500 Series Software Configuration Guide, 7.5 - Configuring SNMP [Support]

Table Of Contents

Configuring SNMP

SNMP Terminology

Understanding How SNMP Works

Security Models and Levels

SNMP ifindex Persistence Feature

Understanding How SNMPv1 and SNMPv2c Work

SNMPv1 and SNMPv2c Default Configuration

Configuring SNMPv1 and SNMPv2c from an NMS

Configuring SNMPv1 and SNMPv2c from the CLI

SNMPv1 and SNMPv2c Enhancements in Software Release 7.5(1)

Setting Multiple SNMP Community Strings

Clearing SNMP Community Strings

Specifying Access Numbers for Hosts

Clearing IP Addresses Associated with Access Numbers

Specifying and Displaying an Interface Alias

Understanding SNMPv3

Benefits of SNMPv3

SNMP Entity

Dispatcher

Message Processing Subsystem

Security Subsystem

Access Control Subsystem

Applications

Configuring SNMPv3 from an NMS

Configuring SNMPv3 from the CLI

Using CiscoWorks2000

Configuring SNMP

This chapter describes how to configure Simple Network Management Protocol (SNMP) on Catalyst enterprise LAN switches.

Note For complete syntax and usage information for the commands used in this chapter, refer to the Command Reference—Catalyst 4000 Family, Catalyst 2948G, and Catalyst 2980G Switches.

This chapter consists of these major sections:

•SNMP Terminology

•Understanding How SNMP Works

•Understanding How SNMPv1 and SNMPv2c Work

•SNMPv1 and SNMPv2c Default Configuration

•Configuring SNMPv1 and SNMPv2c from an NMS

•Configuring SNMPv1 and SNMPv2c from the CLI

•Understanding SNMPv3

•Configuring SNMPv3 from an NMS

•Configuring SNMPv3 from the CLI

•Using CiscoWorks2000

SNMP Terminology

The following SNMP terminology is used in this chapter.

authentication—The process of ensuring message integrity and protection against message replays, including data integrity and data origin authentication.

authoritative SNMP engine—One of the SNMP copies used in network communication is designated the allowed SNMP engine which protects against message replay, delay, and redirection. The security keys used for authenticating and encrypting SNMPv3 packets are generated as a function of the authoritative SNMP engine's engine ID and user passwords. When an SNMP message expects a response (for example, get exact, get next, set request), the receiver of these messages is authoritative. When an SNMP message does not expect a response, the sender is authoritative.

community string—A text string used to authenticate messages between a management station and an SNMPv1 or SNMPv2c engine.

data integrity—A condition or state of data in which a message packet has not been altered or destroyed in an unauthorized manner.

data origin authentication—The ability to verify the identity of a user on whose behalf the message is supposedly sent. This ability protects users against both message capture and replay by a different SNMP engine, and against packets received or sent to a particular user that uses an incorrect password or security level.

encryption—A method of hiding data from an unauthorized user by scrambling the contents of an SNMP packet.

group—A set of users belonging to a particular security model. A group defines the access rights for all the users belonging to it. Access rights define the SNMP objects that can be read, written to, or created. In addition, the group defines the notifications that a user is allowed to receive.

notification host—An SNMP entity to which notifications (traps) are to be sent.

notify view—A view name (not to exceed 64 characters) for each group; the view name defines the list of notifications that can be sent to each user in the group.

privacy—An encrypted state of the contents of an SNMP packet; in this state the contents are prevented from being disclosed on a network. Encryption is performed with an algorithm called CBC-DES (DES-56).

read view—A view name (not to exceed 64 characters) for each group; the view name defines the list of object identifiers (OIDs) that can be read by users belonging to the group.

security level—A type of security algorithm performed on each SNMP packet. There are three levels: noauth, auth, and priv. The noauth level authenticates a packet by a string match of the username. The auth level authenticates a packet by using either the HMAC MD5 or SHA algorithms. The priv level authenticates a packet by using either the HMAC MD5 or SHA algorithms and encrypts the packet using the CBC-DES (DES-56) algorithm.

security model—The security strategy used by the SNMP agent. Currently, software supports three security models: SNMPv1, SNMPv2c, and SNMPv3.

Simple Network Management Protocol (SNMP)—A network management protocol that provides a means to monitor and control network devices, and to manage configurations, statistics collection, performance, and security.

Simple Network Management Protocol Version 2c (SNMPv2c)—This second version of SNMP supports centralized and distributed network management strategies and includes improvements in the Structure of Management Information (SMI), protocol operations, management architecture, and security.

SNMP engine—A copy of SNMP that can reside on the local or remote device.

SNMP group—A collection of SNMP users that belong to a common SNMP list that defines an access policy, in which object identification numbers (OIDs) are both read-accessible and write-accessible. Users belonging to a particular SNMP group inherit all of these attributes defined by the group.

SNMP user—A person for which an SNMP management operation is performed. For informs, the user is the person on a remote SNMP engine who receives the informs.

SNMP view—A mapping between SNMP objects and the access rights available for those objects. An object can have different access rights in each view. Access rights indicate whether the object is accessible by either a community string or a user.

trap—A message sent by an SNMP agent to a console or terminal indicates a significant event occurred.

write view—A view name (not to exceed 64 characters) for each group; the view name defines the list of object identifiers (OIDs) that are able to be created or modified by users of the group.

Understanding How SNMP Works

SNMP is an application-layer protocol that facilitates the exchange of management information between network devices. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth.

There are three versions of SNMP:

•Version 1 (SNMPv1)—This is the initial implementation of SNMP. Refer to RFC 1157 for a full description of functionality. See the "Understanding How SNMPv1 and SNMPv2c Work" section for more information on SNMPv1.

•Version 2 (SNMPv2c)—The second release of SNMP, described in RFC 1902, has additions and enhancements to data types, counter size, and protocol operations. See the "Understanding How SNMPv1 and SNMPv2c Work" section for more information on SNMPv2.

•Version 3 (SNMPv3)—This is the most recent version of SNMP and is fully described in RFC 2571, RFC 2572, RFC 2573, RFC 2574, and RFC 2575. The SNMP functionality on the Catalyst enterprise LAN switches for SNMPv1 and SNMPv2c remain intact; however, SNMPv3 has significant enhancements to administration and security. See the "Understanding SNMPv3" section for more information on SNMPv3.

Security Models and Levels

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 handling an SNMP packet. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. Table 24-1 identifies what the combinations of security models and levels mean.

Table 24-1 Security Model Combinations

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

MD5 or SHA

No

Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms.

v3

authPriv

MD5 or SHA

DES

Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard.

Note the following about SNMPv3 objects:

•Each user belongs to a group.

•A group defines the access policy for a set of users.

•SNMP objects refer to an access policy for reading, writing, and creating.

•A group determines the list of notifications its users can receive.

•A group also defines the security model and security level for its users.

SNMP ifindex Persistence Feature

The SNMP ifIndex persistence feature is always enabled. With the ifIndex persistence feature, the ifIndex value of the port and VLAN is always retained and used after the following occurrences:

•Switch reboot

•High-availability switchover

•Software upgrade

•Module reset

•Module removal and insertion of the same type of module

For Fast EtherChannel and Gigabit EtherChannel interfaces, the ifIndex value is only retained and used after a high-availability switchover.

Understanding How SNMPv1 and SNMPv2c Work

The components of SNMPv1 and SNMPv2c network management fall into three categories:

•Managed devices (such as a switch)

•SNMP agents and MIBs, including Remote Monitoring (RMON) MIBs, which run on managed devices

•SNMP management applications, such as CiscoWorks2000, which communicate with agents to get statistics and alerts from the managed devices

Note An SNMP management application, together with the computer it runs on, is called a network management system (NMS).

SNMP network management uses these SNMP agent functions:

•Accessing a MIB variable—This function is initiated by the SNMP agent 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.

•Setting a MIB variable—This function is also initiated by the SNMP agent in response to an NMS message. The SNMP agent changes the MIB variable value to the value requested by the NMS.

•SNMP trap—This function is used to notify an NMS that a significant event has occurred at an agent. When a trap condition occurs, the SNMP agent sends an SNMP trap message to any NMSs specified as the trap receivers, under the following conditions:

–When a port or module goes up or down

–When temperature limitations are exceeded

–When there are spanning tree topology changes

–When there are authentication failures

–When power supply errors occur

•SNMP community strings—SNMP community strings authenticate access to MIB objects and function as embedded passwords:

–Read-only—Gives only read access to all objects in the MIB except the community strings

–Read-write—Gives read and write access to all objects in the MIB; does not allow access to community strings

–Read-write-all—Gives read and write access to all objects in MIB, including community strings

Note The community string definitions on your NMS must match at least one of the three community string definitions on the switch.

Catalyst enterprise LAN switches are managed devices that support SNMP network management with the following features:

•SNMP traps (see the "Configuring SNMPv1 and SNMPv2c from the CLI" section)

•RMON in the supervisor engine module software (see "Configuring RMON")

•RMON and RMON2 on an external SwitchProbe device

Note For information about MIBs, refer to this URL: http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

SNMPv1 and SNMPv2c Default Configuration

Table 24-2 describes the SNMP default configuration.

Table 24-2 SNMP Default Configuration

Feature

Default Setting

SNMP community strings

•Read-Only: Public

•Read-Write: Private

•Read-Write-all: Secret

SNMP trap receiver

None configured

SNMP traps

None enabled

Configuring SNMPv1 and SNMPv2c from an NMS

To configure SNMP from a Network Management System (NMS), refer to the NMS documentation (see the "Using CiscoWorks2000" section).

The switch supports up to 20 trap receivers through the RMON2 trap destination table. Configure the RMON2 trap destination table from the NMS.

Configuring SNMPv1 and SNMPv2c from the CLI

Note This section provides basic SNMPv1 and SNMPv2c configuration information. For detailed information on the SNMP commands supported by the Catalyst enterprise LAN switches, refer to the Command Reference—Catalyst 4000 Family, Catalyst 2948G, and Catalyst 2980G Switches.

Note For enhanced SNMP features in software release 7.5(1), see the "SNMPv1 and SNMPv2c Enhancements in Software Release 7.5(1)" section.

To configure SNMPv1 and SNMPv2c from the command-line interface (CLI), perform this task in privileged mode:

Task

Command

Step 1

Define the SNMP community strings for each access type.

set snmp community read-only community_string
set snmp community read-write community_string
set snmp community read-write-all community_string

Step 2

Assign a trap receiver and community. You can specify up to ten trap receivers.

set snmp trap rcvr_address rcvr_community [port rcvr_port] [owner rcvr_owner] [index rcvr_index]

Step 3

Specify the SNMP traps to send to the trap receiver.

set snmp trap enable [all | auth | bridge | chassis | config | entity | entityfru | envfan | envpower | envshutdown | envtemp | flashinsert | flashremove | ippermit | module | stpx | syslog | system | vlancreate | vlandelete | vmps | vtp]

Step 4

Verify the SNMP configuration.

show snmp

This example shows how to define community strings, assign a trap receiver, and specify which traps to send to the trap receiver:
Console> (enable) set snmp community read-only Everyone
SNMP read-only community string set to 'Everyone'.
Console> (enable) set snmp community read-write Administrators
SNMP read-write community string set to 'Administrators'.
Console> (enable) set snmp community read-write-all Root
SNMP read-write-all community string set to 'Root'.
Console> (enable) set snmp trap 172.16.10.10 read-write
SNMP trap receiver added.
Console> (enable) set snmp trap 172.16.10.20 read-write-all
SNMP trap receiver added.
Console> (enable) set snmp trap enable all
All SNMP traps enabled.
Console> (enable) show snmp
RMON:                       Disabled
Extended RMON:              Extended RMON module is not present
Traps Enabled: 
Port,Module,Chassis,Bridge,Repeater,Vtp,Auth,ippermit,Vmps,config,entity,stpx
Port Traps Enabled: 1/1-2,4/1-48,5/1
Community-Access     Community-String    
----------------     --------------------
read-only            Everyone
read-write           Administrators
read-write-all       Root
Trap-Rec-Address                           Trap-Rec-Community
----------------------------------------   --------------------
172.16.10.10                               read-write
172.16.10.20                               read-write-all
Console> (enable)
Note To disable access for an SNMP community, set the community string for that community to the null string (do not enter a value for the community string).

SNMPv1 and SNMPv2c Enhancements in Software Release 7.5(1)

These sections describe enhancements added to software release 7.5(1):

•Setting Multiple SNMP Community Strings

•Clearing SNMP Community Strings

•Specifying Access Numbers for Hosts

•Clearing IP Addresses Associated with Access Numbers

•Specifying and Displaying an Interface Alias

Setting Multiple SNMP Community Strings

You can set multiple SNMP community strings using the community-ext keyword. Community strings defined with the community-ext keyword cannot be duplicates of existing community strings. When you add a new community string using the community-ext keyword, appropriate entries are created in the vacmAccessTable (if a view is specified), snmpCommunityTable, and the vacmSecurityToGroup table.

To set multiple SNMP community strings from the CLI, perform this task in privileged mode:

Task

Command

Step 1

Set multiple SNMP community strings.

set snmp community-ext community_string {read-only | read-write | read-write-all}

[view view_oid] [access access_number]

Step 2

Verify the SNMP configuration.

show snmp

This example shows how to set an additional SNMP community string:
Console> (enable) set snmp community-ext public1 read-only 
Community string public1 is created with access type as read-only 
Console> (enable)
This example shows how to restrict the community string to an access number:
Console> (enable) set snmp community-ext private1 read-write access 2 
Community string private1 is created with access type as read-write access number 2 
Console> (enable)
This example shows how to change the access number to the community string:
Console> (enable) set snmp community-ext private1 read-write access 3 
Community string private1 is updated with access type as read-write access 
number 3 
Console> (enable)
This example shows how to display the SNMP configuration:
Console> (enable) show snmp 
SNMP:Enabled 
RMON:Disabled 
Extended RMON Netflow Enabled :None. 
Memory usage limit for new RMON entries:85 percent 
Traps Enabled:None 
Port Traps Enabled:None 
Community-Access Community-String 
---------------- -------------------- 
read-only        public 
read-write       private 
read-write-all   secret 
Additional-                         Access- 
Community-String     Access-Type    Number  View 
-------------------- -------------- ------- ----------------------------------- 
public1              read-only 
public2              read-only      1 
private1             read-write     2       1.3.6 
secret1              read-write-all 500     1.3.6.1.4.1.9.9 
Trap-Rec-Address Trap-Rec-Community Trap-Rec-Port Trap-Rec-Owner Trap-Rec-Index
---------------- ------------------ ------------- -------------- --------------
Console> (enable) 
Clearing SNMP Community Strings

You can clear community strings using the clear snmp community-ext command. When you use this command to clear a community string, corresponding entries in the vacmAccessTable and vacmSecurityToGroup tables are also removed.

To clear an SNMP community string from the CLI, perform this task in privileged mode:

Task

Command

Step 1

Clear an SNMP community string.

clear snmp community-ext community-string

Step 2

Verify the SNMP configuration.

show snmp

This example shows how to clear an SNMP community string:
Console> (enable) clear snmp community-ext public1
Community string public1 has been removed
Console> (enable)
Specifying Access Numbers for Hosts

You can specify a list of access numbers associated with one or more hosts to limit which hosts can use a specific community string to access the system. You can specify more than one IP address associated with an access number by separating each IP address with a space. If the new IP address uses an existing access number, the switch addes the new IP addresses to the list.

To specify an access number for a host from the CLI, perform this task in privileged mode:

Task

Command

Step 1

Specify an access number for a host.

set snmp access-list access_number IP_address [ipmask maskaddr]

Step 2

Verify the SNMP configuration.

show snmp access-list

These examples show how to specify an access number for a host:
Console> (enable) set snmp access-list 1 172.20.60.100 
Access number 1 has been created with new IP Address 172.20.60.100 
Console> (enable) set snmp access-list 2 172.20.60.100 mask 255.0.0.0 
Access number 2 has been created with new IP Address 172.20.60.100 mask 255.0.0.0 
Console> (enable) set snmp access-list 2 172.20.60.7 
Access number 2 has been updated with new IP Address 172.20.60.7 
Console> (enable) set snmp access-list 2 172.20.60.7 mask 255.255.255.0 
Access number 2 has been updated with existing IP Address 172.20.60.7 mask 255.255.255.0 
Console> (enable)
This example shows how to display the SNMP configuration:
Console> (enable) show snmp access-list
Access-Number   IP-Addresses/IP-Mask 
-------------   ------------------------- 
1               172.20.60.100/255.0.0.0 
                1.1.1.1/- 
2               172.20.60.7/- 
                2.2.2.2/- 
3               2.2.2.2/155.0.0.0 
4               1.1.1.1/2.1.2.4 
                2.2.2.2/- 
                2.2.2.5/- 
Console> (enable)
Clearing IP Addresses Associated with Access Numbers

To clear IP addresses associated with access numbers from the CLI, perform this task in privileged mode:

Task

Command

Step 1

Clear IP addresses associated with access numbers.

clear snmp access-list access_number IP_address [[IP_address] ...]

Step 2

Verify the SNMP configuration.

show snmp access-list

These examples show how to clear IP addresses associated with access numbers:
Console> (enable) clear snmp access-list 101
All IP addresses associated with access-number 101 have been cleared.
Console> (enable)
Console> (enable) clear snmp access-list 2 172.20.60.8
Access number 2 no longer associated with 172.20.60.8
Console> (enable)
Specifying and Displaying an Interface Alias

You can specify and display an interface alias. The length of the alias can be up to 64 characters.

To specify and display an interface alias, perform this task in privileged mode:

Task

Command

Step 1

Specify an interface alias.

set snmp ifalias {ifIndex} [ifAlias]

Step 2

Display the interface alias.

show snmp ifalias [ifIndex]

These examples show how to specify and display an interface alias:
Console> (enable) set snmp ifalias 1 Inband port
ifIndex 1 alias set
Console> (enable)
Console> (enable) show snmp ifalias 1
ifIndex    ifName               ifAlias
---------- -------------------- ---------------------------------
1          sc0                  Inband port
Console> (enable) 
Understanding SNMPv3

SNMPv3 contains all the functionality of SNMPv1 and SNMPv2, but SNMPv3 has significant enhancements to administration and security. SNMPv3 is an interoperable standards-based protocol. SNMPv3 provides secure access to devices by authenticating and encrypting packets over the network. The security features provided in SNMPv3 are as follows:

•Message integrity—Ensuring that a packet has not been tampered with in transit

•Authentication—Determining that the message is from a valid source

•Encryption—Scrambling contents of packet to prevent it from being seen by an unauthorized source

Benefits of SNMPv3

SNMPv3 provides the following benefits for managing your network:

•SNMP devices can collect data securely without being tampered with or corrupted.

•You can encrypt confidential information (such as SNMP set commands that change a router's configuration) to prevent the contents from being exposed on the network.

SNMP Entity

In SNMPv3, the terms SNMP Agents and SNMP Managers are no longer used. These concepts have been combined into what is called an SNMP entity. An SNMP entity is made up of an SNMP engine and SNMP applications. An SNMP engine is made up of these four components (Figure 24-1):

•Dispatcher

•Message Processing Subsystem

•Security Subsystem

•Access Control Subsystem

Figure 24-1 SNMP Entity for Traditional SNMP Agents

Dispatcher

The Dispatcher is a simple traffic manager that sends and receives messages. After receiving a message, the Dispatcher tries to determine the version number of the message and then passes the message to the appropriate Message Processing Model. The Dispatcher is also responsible for dispatching PDUs to applications and for selecting the appropriate transports for sending messages.

Message Processing Subsystem

The Message Processing Subsystem accepts outgoing PDUs from the Dispatcher and prepares them for transmission by wrapping them in a message header and returning them to the Dispatcher. The Message Processing Subsystem also accepts incoming messages from the Dispatcher, processes each message header, and returns the enclosed PDU to the Dispatcher. An implementation of the Message Processing Subsystem may support a single message format corresponding to a single version of SNMP (SNMPv1, SNMPv2c, SNMPv3), or it may contain a number of modules, each supporting a different version of SNMP.

Security Subsystem

The Security Subsystem authenticates and encrypts messages. Each outgoing message is passed to the Security Subsystem from the Message Processing Subsystem. Depending on the services required, the Security Subsystem may encrypt the enclosed PDU and some fields in the message header. In addition, the Security Subsystem may generate an authentication code and insert it into the message header. After encryption, the message is returned to the Message Processing Subsystem.

Each incoming message is passed to the Security Subsystem from the Message Processing Subsystem. If required, the Security Subsystem checks the authentication code and performs decryption. The processed message is returned to the Message Processing Subsystem. An implementation of the Security Subsystem may support one or more distinct security models. So far, the only defined security model is the User-Based Security Model (USM) for SNMPv3, specified in RFC 2274.

The USM protects SNMPv3 messages from the following potential security threats:

•An authorized user sending a message that gets modified in transit by an unauthorized SNMP entity

•An unauthorized user trying to masquerade as an authorized user

•Anyone modifying the message stream

•Anyone eavesdropping

The USM currently defines the use of HMAC-MD5-96 and HMAC-SHA-96 as the possible authentication protocols and CBC-DES as the privacy protocol.

SNMPv1 and SNMPv2c security models provide only weak authentication (community names) and no privacy.

Access Control Subsystem

The responsibility of the Access Control Subsystem is straightforward. It determines whether access to a managed object should be allowed. Currently, one access control model, the View-Based Access Control Model (VACM), has been defined. With VACM, you can control which users and which operations can have access to which managed objects.

Applications

SNMPv3 applications refer to internal applications within an SNMP entity. These internal applications can generate SNMP messages, respond to received SNMP messages, generate notifications, receive notifications, and forward messages between SNMP entities. Currently, there are five types of applications:

•Command generators—generate SNMP commands to collect or set management data.

•Command responders—provide access to management data. For example, processing get, get-next, get-bulk and set pdus are used in a command responder application.

•Notification originators—initiate Trap or Inform messages.

•Notification receivers—receive and process Trap or Inform messages.

•Proxy forwarders—forward messages between SNMP entities.

Configuring SNMPv3 from an NMS

To configure SNMP from a Network Management System (NMS), refer to your NMS documentation (also see the "Using CiscoWorks2000" section).

The switch supports up to 20 trap receivers through the RMON2 trap destination table. Configure the RMON2 trap destination table from the NMS.

Configuring SNMPv3 from the CLI

Note This section provides very basic SNMP v3 configuration information. For detailed information on the SNMP commands supported by the Catalyst enterprise LAN switches, refer to the Command Reference—Catalyst 4000 Family, Catalyst 2948G, and Catalyst 2980G Switches.

To configure SNMPv3 from the command-line interface (CLI), perform this task in privileged mode:

Task

Command

Step 1

Set the SNMP-Server EngineID name for the local SNMP engine.

set snmp engineid engineid

Step 2

Configure the MIB views.

set snmp view [-hex] {viewname} {subtree} [mask] [included | excluded] [volatile | nonvolatile]

Step 3

Set the access rights for a group with a certain security model in different security levels.

set snmp access [-hex] {groupname} {security-model v3} {noauthentication | authentication | privacy} [read [-hex] {readview}] [write [-hex] {writeview}] [notify [-hex] {notifyview}] [context [-hex] {contextname} [exact | prefix]] [volatile | nonvolatile]

Step 4

Specify the target addresses for notifications.

set snmp notify [-hex] {notifyname} tag [-hex] {notifytag} [trap | inform] [volatile | nonvolatile]

Step 5

Set the snmpTargetAddrEntry in the target address table.

set snmp targetaddr [-hex] {addrname} param [-hex] {paramsname} {ipaddr} [udpport {port}] [timeout {value}] [retries {value}] [volatile | nonvolatile] [taglist {[-hex] tag} [[-hex] tag]]

Step 6

Set the SNMP parameters used to generate a message to a target.

set snmp targetparams [-hex] {paramsname} user [-hex] {username} {security-model v3} {message-processing v3} {noauthentication | authentication | privacy} [volatile | nonvolatile]

Step 7

Configure a new user.

set snmp user [-hex] {username} [remote {engineid}] [{authentication [md5 | sha] {authpassword}] [privacy {privpassword}] [volatile | nonvolatile]

Step 8

Relate a user to a group using a specified security model.

set snmp group [-hex] {groupname} user [-hex] {username} {security-model v1 | v2 | v3} [volatile | nonvolatile]

Step 9

Configure the community table for the system default part, which maps community strings of previous versions of SNMP to SNMPv3.

set snmp community {access_type} [community_string] (access_type = read-only | read-write | read-write-all)

Step 10

Configure the community table for mappings between different community strings and security models with full permissions.

set snmp community index {index_name} name [community_string] security {security_name} context {context_name} transporttag {tag_value} [volatile | nonvolatile]

Step 11

Verify the SNMP configuration.

show snmp

This example shows how to set a MIB view name to interfacesMibView:
Console> (enable) set snmp view interfacesMibView 1.3.6.1.2.1.2 included 
Snmp view name was set to interfacesMibView with subtree 1.3.6.1.2.1.2 included, 
nonvolatile. 
This example shows how to set the access rights for a group called guestgroup to SNMPv3 authentication read mode:
Console> (enable) set snmp access guestgroup security-model v3 authentication read 
interfacesMibView 
Snmp access group was set to guestgroup version v3 level authentication, 
readview interfacesMibView, context match:exact, nonvolatile. 
This example shows how to specify the target addresses:
Console> (enable) set snmp notify notifytable1 tag routers trap 
Snmp notify name was set to notifytable1 with tag routers notifyType trap, and storageType 
nonvolatile. 
These examples show how to set the snmpTargetAddrEntry in the target address table:
Console> (enable) set snmp targetaddr router_1 param p1 172.20.21.1 
Snmp targetaddr name was set to router_1 with param p1 
ipAddr 172.20.21.1, udpport 162, timeout 1500, retries 3, storageType nonvolatile. 
Console> (enable) set snmp targetaddr router_2 param p2 172.20.30.1 
Snmp targetaddr name was set to router_2 with param p2 
ipAddr 172.20.30.1, udpport 162, timeout 1500, retries 3, storageType nonvolatile. 
These examples show how to set SNMP target parameters:
Console> (enable) set snmp targetparams p1 user guestuser1 security-model v3 
message-processing v3 authentication 
Snmp target params was set to p1 v3 authentication, message-processing v3, 
user guestuser1 nonvolatile. 
Console> (enable) set snmp targetparams p2 user guestuser2 security-model v3 
message-processing v3 privacy 
Snmp target params was set to p2 v3 privacy, message-processing v3, 
user guestuser2 nonvolatile. 
These examples show how to configure guestuser1 and guestuser2 as users:
Console> (enable) set snmp user guestuser1 authentication md5 guestuser1password privacy 
privacypasswd1 
Snmp user was set to guestuser1 authProt md5 authPasswd guestuser1password privProt des 
privPasswd 
privacypasswd1 with engineid 00:00:00:09:00:10:7b:f2:82:00:00:00 nonvolatile. 
Console> (enable) set snmp user guestuser2 authentication sha guestuser2password 
Snmp user was set to guestuser2 authProt sha authPasswd guestuser2password privProt 
no-priv with engineid 
00:00:00:09:00:10:7b:f2:82:00:00:00 nonvolatile. 
These examples show how to set guestuser1 and guestuser2 as members of the groups guestgroup and mygroup:
Console> (enable) set snmp group guestgroup user guestuser1 security-model v3 
Snmp group was set to guestgroup user guestuser1 and version v3, nonvolatile. 
Console> (enable) set snmp group mygroup user guestuser1 security-model v3 
Snmp group was set to mygroup user guestuser1 and version v3, nonvolatile. 
Console> (enable) set snmp group mygroup user guestuser2 security-model v3 
Snmp group was set to mygroup user guestuser2 and version v3, nonvolatile. 
This example shows how to verify the SNMPv3 setup for guestuser1 from a workstation:
workstation% getnext -v3 10.6.4.201 guestuser1 ifDescr.0 
Enter Authentication password :guestuser1password 
Enter Privacy password        :privacypasswd1 
ifDescr.1 = sc0 
This example shows how to verify the SNMPv3 setup for guestuser1 in the snmpEngineID MIB from a workstation:
workstation% getnext -v3 10.6.4.201 guestuser1 snmpEngineID 
Enter Authentication password :guestuser1pasword 
Enter Privacy password        :privacypasswd1 
snmpEngineID = END_OF_MIB_VIEW_EXCEPTION 
This example shows how to verify the SNMPv2c setup for public access from a workstation:
workstation% getnext -v2c 10.6.4.201 public snmpEngineID 
snmpEngineID.0 = 
00 00  00 09   00 10  7b f2    82 00  00 00 
This example shows how to increase guestgroup's access right to read privileges for snmpEngineMibView:
Console> (enable) set snmp view snmpEngineMibView 1.3.6.1.6.3.10.2.1 included 
Snmp view name was set to snmpEngineMibView with subtree 1.3.6.1.6.3.10.2.1 included, 
nonvolatile 
Console> (enable) set snmp access guestgroup security-model v3 authentication read 
snmpEngineMibView 
Snmp access group was set to guestgroup version v3 level authentication, 
readview snmpEngineMibView, nonvolatile. 
This example shows how to verify the SNMPv3 access for guestuser1 from a workstation:
% getnext -v3 10.6.4.201 guestuser1 snmpEngineID 
Enter Authentication password :guestuser1password 
Enter Privacy password        :privacypasswd1 
snmpEngineID.0 = 
00 00  00 09   00 10  7b f2    82 00  00 00 
This example shows how to remove access for guestgroup:
Console> (enable) clear snmp acc guestgroup security-model v3 authentication 
Cleared snmp access guestgroup version v3 level authentication. 
This example shows how to verify that the access for guestuser1 has been removed from a workstation:
% getnext -v3 10.6.4.201 guestuser1 ifDescr.1 
Enter Authentication password :guestuser1password 
Enter Privacy password        :privacypasswd1 
Error code set in packet - AUTHORIZATION_ERROR:1. 
This example shows how to verify the access for guestuser2 from a workstation:
% getnext -v3 10.6.4.201 guestuser2 ifDescr.1 
Enter Authentication password :guestuser2password 
Enter Privacy password        :privacypasswd2 
REPORT received, cannot recover:
usmStatsUnsupportedSecLevels.0 = 1 
Using CiscoWorks2000

CiscoWorks2000 is a family of web-based and management platform-independent products for managing Cisco enterprise networks and devices. CiscoWorks2000 includes Resource Manager Essentials and CWSI Campus, which allow you to deploy, configure, monitor, manage, and troubleshoot a switched internetwork. For more information, refer to the following publications:

•Getting Started with Resource Manager Essentials

•Getting Started with CWSI Campus