CONFIGURING SNMPv2c and SNMPv3

Simple Network Management Protocol (SNMP)

SNMP is an open standard protocol for collecting information about managed devices and modifying configuration on the managed devices. SNMP is an application layer protocol that supports message exchange in a specific format between SNMP managers and agents. It is used for monitoring and managing devices on a network. SNMP is able to retrieve data, modify SNMP object variables of managed devices on IP networks and send notifications to Network Management Stations (NMS). Some devices that support SNMP include routers, switches, servers, workstations, printers etc.

SNMP components include; SNMP manager (NMS), SNMP agent and SNMP MIB.

• SNMP manager: controls and monitors the operation of network hosts using SNMP. The manager receives unsolicited notifications from agents running on monitored devices. Additionally, the manager polls SNMP agents running on the network devices for information. The manager runs as software on a computer/server.
• SNMP Agent: is a software component that runs on the managed device. It collects and stores information on the device. The agent responds to manager requests for information. The agent can send unsolicited notifications (traps or informs) to notify the manager about conditions on the managed device.
• MIB: is a database of objects (information variables) that lists various attributes of the managed device that can be monitored. An SNMP agent contains MIB variables, whose values the SNMP manager can request for or change through the Get or Set operations. A manager can retrieve a value from an agent or store a value from that agent. The agent gathers data from the SNMP MIB. The MIB uses read and write community strings for controlling access. Object Identifier (OID) is an ID for the various components in the MIB of a managed device.

SNMP operations involve SNMP agents running on the managed devices sending monitoring data to the SNMP manager. SNMP uses the following operations to retrieve and modify objects on managed/monitored devices:

• SNMP Get: A Get operation is performed by the SNMP manager to retrieve SNMP object variables from the agent. There are three types of GET operations;
  • Get: Retrieves exact object instance identified by OID or name.
  • GetNext: Retrieves next object variable (successor) to the specified variable.
  • GetBulk: Retrieves large amount of object variable data without repeated GetNext operations.
• SNMP Set: An NMS carries out a SET operation to modify the value of the object variable on a managed device.
• SNMP Notifications: Traps and informs are unsolicited (asynchronous) notifications sent by an agent to an NMS.

Traps, Informs, and Polls

Traps are unsolicited messages alerting the NMS to a condition on the managed device. Traps are discarded as soon as they are sent. Traps are sent once and do not require acknowledgement by the manager.

Informs are traps that include a request for confirmation of receipt from the SNMP manager. The SNMP manager sends a confirmation using SNMP response PDU. If the Agent did not receive a response for an inform, the inform can be sent again. Informs may be sent many times hence traps are usually preferred. An inform is held in memory until a response is received or times out. Traps are usually preferred because they consume less resources than informs which are held in memory until a response is received.

Polls are probes where the SNMP manager sends an SNMP request to the agent and receives an SNMP reply to this request. The SNMP GetRequest(poll) is sent using UDP port 161 and the SNMP GetResponse(trap) sent using UDP port 162.

SNMP Versions

SNMP comes in three major versions: SNMPv1, v2c and v3. In SNMP v1, security is based on community strings. SNMPv1 is not recommended to be used in today's networks and many network device vendors do not support it. In SNMP v2c, security is also based on community strings. In SNMPv3, security is based on message integrity, authentication, encryption algorithms.

Security with SNMP can be refined by implementing the following:

• Configuration of an ACL of managers permitted to access the agent
• Defining MIB view: subset of all MIB objects accessible to the community. Where multiple views with the same OID are entered, the latest entry takes precedence.
• Read-Write or Read-only permission for MIB objects accessible to the community.

SNMPv2c

SNMPv2c is defined by RFC 1441 and RFC 1452 with improvements to SNMPv1 in areas of performance, security and manager-to-device communications. It introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large amounts of management data in a single request. SNMPv2c sends the community strings in clear text.

SNMPv2c includes detailed error reporting; this minimizes the number of round trips. It includes expanded error codes that distinguish different types of errors. SNMPv2c uses community strings for security. An agent can communicate with multiple managers using the appropriate version for each manager.

Configuring views for SNMPv2c is optional. It limits which MIB objects an SNMP manager can access.

Configuration of SNMPv2c

To configure SNMPv2 on a managed device, follow these steps:

1. Configure SNMP Community: configure the read-only or read-write community string using the command snmp-server community <string> <ro | rw > <ipv6 nacl> <acl>. The ACL is an optional parameter but is recommended to be configured as it adds a layer of security to SNMPv2. The community string has to match on both the manager and the agent.
   R1(config)#snmp-server community ciscolab ro

2. Enable sending of traps; SNMPv2c is able to send traps using the command snmp-server enable traps. This enables the sending of all available traps. To define specific traps, add the type of traps to the above command:
   R1(config)#snmp-server enable traps cpu threshold
R1(config)#snmp-server enable traps vlancreate
R1(config)#snmp-server enable traps vlandelete
R1(config)#snmp-server enable traps memory bufferpeak
R1(config)#snmp-server enable traps power-ethernet group 1 threshold 80
R1(config)#snmp-server enable traps power-ethernet police


   Link up/down notifications are controlled by snmp trap link-status interface command.

3. Configure the SNMP manager address: The SNMP manager to which the notifications will be sent is configured using the command snmp-server host <ip-address> [traps | informs] version [1 | 2c | 3 [auth | noauth | priv]] <community-string> udp-port <port-number> <notification-type>. By default,traps are sent. With this command, the following confurations are made:
   • the SNMP manager address
   • the type of notifications sent i.e., informs or traps.
   • the version of SNMP
R1(config)#snmp-server host 192.168.5.2 traps version 2c ciscolab

Without the snmp-server host command on a managed device, no notifications are sent. Each succeeding snmp-server host command overwrites the previous command. Entering the snmp-server host command without keywords enables all trap types for the host.

4. System information: The first snmp-server command entered enables SNMP on the device. Configuring SNMP system information is optional, however, the information configured can be valuable when troubleshooting SNMP. System information includes; chassis-id, location and contact information of the device.
   1. System Serial Number: snmp-server chassis-id 0123456AB
   2. System Contact: snmp-server contact example@example.com
   3. System Location: snmp-server location Floor01_Rm02

Security using Access Control Lists

An additional layer of security can be introduced by applying an Access Control List (ACL).

1. Configure Access Control for an SNMP Community: The ACL controls the SNMP managers that are permitted to access the agent on the managed device based on their IP address or the subnet they reside in.
   R1(config)#ip access-list standard ACL_SNMP_MANAGER
R1(config-std-nacl)#10 permit host 192.168.5.1


2. Add the ACL to the configuration of the community string: configure the read only or read-write community string that references the ACL snmp-server community <string> view <view-name> <ro | rw > <ipv6 nacl> <acl>. The view and the ACL are optional parameters. The community string has to match on both the manager and the agent.
   R1(config)#snmp-server community ciscolab rw ACL_SNMP_MANAGER

Index Shuffling

MIB indexes sometimes experience "index shuffling" where the indexes of router components change after reboots or firmware upgrades. Index shuffling can be stopped using the command snmp-server ifindex persist. This command shows up in the running configuration as snmp ifmib ifindex persist. This command ensures that the mapping between the ifDescr object values and the ifIndex object values (generated from the IF_MIB) will be retained across reboots.

Verification

show snmp

R1#show snmp


show snmp host

show snmp community

show snmp chassis

show snmp contact

show snmp location

Troubleshooting SNMPv2

When troubleshooting SNMPv2, verify the following:

• Traps are enabled by default (traps are unsolicited)
• Specify correct traps if all are not desired.
• Traps or informs is correctly configured.
• Verify that the correct community string is specified
• Verify that the correct NMS IP address is specified
• Verify that the required SNMP version is configured
• SNMP uses UDP port 161 for general messages and 162 for traps and informs. Verify that an access control list is not blocking traffic to these ports.

SNMPv3

The main improvement of SNMPv3 over SNMPv2c is the added security with authentication and encryption. Poll messages for example GetRequest are sent still sent using UDP port 161 and traps (GetResponse) on UDP 162.

SNMPv3 defines three security levels:

1. NoAuthNoPriv: no authentication, no privacy. Uses a username for authentication and does not use encryption.
2. AuthNoPriv: uses a hash for authentication (MD5 or SHA1) but does not use encryption.
3. AuthPriv: uses a hash for authentication and uses encryption for privacy (DES, 3DES, AES).

When configuring SNMPv3, in order to utilize the security mechanisms that it supports, groups and users must be configured.

SNMPv3 Features

With the added security features, SNMPv3 structures its configuration into three main sections:

1. SNMP View: Restricts the OIDs visible to the NMS. It defines what the manager is able to access/view on the device. This restriction can include access to interfaces or particular interface. The view can be associated with a group.
2. SNMP Group: Used to associate a view with a group to specify the type of access i.e., whether read or write, as well as the type of security enabled for that.
3. SNMP User: User credentials required to access a view based on a group.

Configuration

When configuring SNMPv3, three steps are followed;

1. Create an SNMP view to define the list of features or attributes on the managed device that are to be monitored.
2. Associate the view with the group which defines the type of access (whether read-only or read-write) as well as the security type enabled for this access.
3. Associate the group with a user. The user defines the username, password, levels of encryption and authentication that is to be used.

The order of configuration of SNMPv3:

1. Configuration of SNMP Views:

   SNMP Views can be configured to limit the number of MIB objects that an SNMP manager has access to. SNMP views can be predefined or custom configured. Create the view record using the command snmp-server view <view-name> <oid-tree> | <object-name> <included | excluded>.
   Caution: If an MIB name is defined for a view, MIB names are case-sensitive. Use the SNMP Object Navigator for the correct object names or OID values.

   To the mib2 view includes all objects in the MIB-II subtree.

   R2(config)#snmp-server view mib2 mib-2 included
R2(config)#snmp-server view mib2 ifEntry included
R2(config)#snmp-server view int-access ifEntry included

   The MIB value for access to all interfaces and their features is ifIndex.

2. Creating SNMP Groups

   An SNMP group maps users to views. Configure the SNMP server group to enable authentication for members permitted by the configured ACL. snmp-server group <group-name> [v1 | v2c | v3] [auth | noauth | priv] [read <read-view>] [write <write-view>] [notify <notify-view>] [access <acl>] .

   R2(config)#snmp-server group group1 v3 auth read mib2

3. Configuring Users

   To configure a remote user, specify the IP address of the remote SNMP agent of the device where the user resides. Before you configure remote users for a particular agent, configure the SNMP engine ID using the command snmp-server engineID with remote option. The remote agent’s SNMP engine ID is required when computing the authentication and privacy digests from the password. EngineID (remote) should be configured first before sending requests and informs to it.

   SNMP passwords are localised using engineID of the authoritative SNMP engine. For informs, the authoritative SNMP agent is the remote agent. You must configure the remote agent’s SNMP engine ID in the SNMP database before sending proxy requests or informs to it. Changing the engine ID after configuring the SNMP user doesn’t allow the removal of the user. To remove the configuration, you need to first reconfigure all SNMP configurations.

   1. Step 1: Define the remote system engineID; snmp-server engineID <local engineID | remote ip-address <udp-port port-number> <vrf name> <engineID-string>
      R2(config)#snmp-server engineID remote 192.168.3.10 800000090300CA0305F30006

   2. Step 2: Add a new user to a defined SNMP group; snmp-server user <username> <group-name> <remote ip_address> [udp-port <port-number>] [v1 | v2c | v3] encrypted> [auth [md5 | sha]] <auth-password> [priv [des56|3des|aes] <shared-secret-key>] <access-acl>

      Creating an SNMP user user1

      R2(config)#snmp-server user user1 group1 v3 auth sha complexcomplex priv aes 256 priv_password access ACL_SNMP

Security

To use SNMP version 3 security mechanisms, groups and users with passwords must b e configured. No default values exist for authentication or privacy algorithms when you configure snmp-server group.

Configuration of Access Control Lists

R2(config)#ip access-list standard ACL_SNMP
R2(config-std-nacl)#10 PERMIT 192.168.3.10 ?
A.B.C.D Wildcard bits
log Log matches against this entry
<cr>

R2(config-std-nacl)#10 PERMIT 192.168.3.10
R2(config-std-nacl)#exit

Verification

show snmp user

SNMP users do not appear in the running-configuration. However, to view SNMP users, use the command show snmp user.

To verify the SNMPv3 view created;

R2#show snmp view

show snmp host

SNMPv3 Groups

Verification of SNMPv3 groups

R2(config)#do show snmp group


R2(config)#do show snmp engineID


Troubleshooting SNMPv3

• Correct security level specified?
• Correct OIDs specified in the view
• Is the notification configured?
• Index shuffling
• Correct security level specified
• Correct hashing algorithm, encryption algorithm, or passwords