Simple Network Management Protocol (SNMP) is a widely used management protocol and defined set of standards for communications with devices connected to an IP network. SNMP provides a means to monitor and control network devices. Additionally, SNMP is used to manage device configurations, collect statistics, and monitor device performance such as CPU, memory, and interface utilization, for example. SNMP is an Application Layer (Layer 7) protocol that facilitates the exchange of management information between network devices using UDP ports 161 and 162.
SNMP Components
An SNMP-managed network consists of the following three core elements:
- A Management System
- SNMP Agents
- Managed Devices
The SNMP management system executes monitoring applications and controls the managed SNMP devices. The management systems execute most of the management processes and provide the bulk of memory resources used for network management. A network might be managed by one or more management systems. The management system is also commonly referred to as an SNMP server or as a Network Management System (NMS).
An SNMP agent resides on each managed device and translates local management information data, such as performance information or event and error information caught in software traps, into a readable form for the management system. An SNMP server can collect or store information on the SNMP agent using Get and Set operations. These, along with additional SNMP operations, are described in the following sections.
A managed device is accessed through the SNMP agent. Managed devices collect and store management information, making it available through SNMP to other management systems having the same protocol compatibility. SNMP itself does not define which information a managed device should offer. Instead, SNMP uses an extensible design, where the available information is defined by Management Information Bases.
Management Information Base
The SNMP agent gathers data from the Management Information Base (MIB), which is simply a virtual information storage area for network management information and is used to describe the structure of the management data of a device subsystem. The MIB consists of a collection of managed objects. The SNMP server can request or change the MIB variables on the SNMP agent via Get or Set operations. Additionally, the SNMP server can get or store values within the agent. MIBs are comprised of the following two components:
- Managed Objects
- Object Identifiers
A managed object is comprised of one or more object instances and can be one of any number of specific characteristics of a managed device. Managed objects are therefore considered variables. Managed objects can be either scalar or tabular. Scalar objects are used to define a single object instance, while tabular objects define multiple related object instances that are grouped in MIB tables.
NOTE: A managed object is also sometimes referred to as an MIB object, an object, or an MIB
MIBs use a hierarchical namespace containing Object Identifiers (OIDs). Each OID identifies a variable that can be read or set via SNMP. An OID uniquely identifies a managed object in the MIB hierarchy, which can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. In Cisco IOS software, access to the MIB is controlled using SNMP community strings. SNMP community strings are described in the sections that follow.
There are three versions of SNMP, which are SNMP versions 1, 2, and 3. These three versions and their characteristics are described in the following sections.
SNMPv1
SNMPv1 is the initial implementation of the SNMP protocol. SNMPv1 is widely used and is the default version when SNMP is enabled in Cisco IOS software. SNMPv1 supports the following four protocol operations:
- Get
- GetNext
- Set
- Trap
The SNMP management station uses Get operations to retrieve the value of one or more object instances from the SNMP agent. If the agent responding to the Get operation cannot provide values for all the object instances in a list, it does not provide any values. The SNMP server uses the GetNext operation to retrieve the value of the next object instance in a table or a list within an agent. The Set operation is used by the SNMP server to set the values of object instances in an agent. Finally, the Trap operation is used by SNMP agents to inform the SNMP server of a significant event.
SNMPv2
SNMPv2 revises the SNMPv1 standard and includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications. The Get, GetNext, and Set operations used in SNMPv2 function in the same manner as those used in SNMPv1. While the Trap operation still performs the same basic function, SNMPv2 uses a different message format and is designed to replace the SNMPv1 Trap. SNMPv2 also defines the following two new operations:
- GetBulk
- Inform
The GetBulk operation is used to retrieve large blocks of data efficiently. The GetBulk operation fills a response message with as much of the requested data as will fit, for example, multiple rows in a table. The Inform operation allows one NMS to send Trap information to another NMS and then to receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results, whereas in SNMPv1, if the agent responding to the Get operation cannot provide values for all the object instances in a list, it does not provide any values.
SNMPv2 also provides detailed error message reporting to management stations. Additionally, SNMPv2 has improved error handling support that includes expanded error codes that distinguish different types of errors. In SNMPv1, these conditions are reported through a single error code. Finally, SNMPv2 also reports on no such object, no such instance, and end of MIB view exceptions.
NOTE: In current Cisco IOS software, it is important to know that only SNMPv2c is supported. SNMPv2c replaces the original SNMPv2 Classic (SNMPv2p) version, which was supported in earlier IOS releases. The primary difference between SNMPv2c and SNMPv2p is that SNMPv2c uses a Community-based Administrative Framework, while SNMPv2p uses a Party-based Administrative and Security Framework. Both versions support the same bulk retrieval and error handling capabilities.
SNMPv3
SNMPv3 provides three additional security services that are not available in previous versions of SNMP. The additional security features provided in SNMPv3 are as follows:
- Message Integrity
- Authentication
- Message Encryption
SNMPv3 uses message integrity to ensure that a packet has not been tampered with in-transit. Authentication is used to determine if the message is from a valid source. Finally, encryption is used to scramble SNMP messages to prevent them from being seen or viewed by unauthorized sources.
SNMP Security
Both SNMPv1 and SNMPv2 use a community-based form of security. This community string is used to allow access to the SNMP agent and can be defined by an IP ACL and password. By default, an SNMP community string permits read-only access to all objects. To configure a community string to permit access to SNMP on Cisco IOS software, the snmp-server community [string] [view <name>] [ro|rw] [acl] global configuration command must be used. The [string] keyword is the case-sensitive community string that acts as a password and permits access to the SNMP protocol.
The [view <name>] keyword is used to reference a previously configured view. The view is used to define the objects available to the community. The ro keyword specifies read-only access. Authorized management stations are able to retrieve MIB objects only if this is configured. The rw keyword specifies read-write access. Authorized management stations are able to retrieve and modify MIB objects if this is configured. Finally, the [acl] keyword is used to specify a standard IP-numbered ACL (i.e., 1- 99) that includes the IP addresses or subnets that are allowed to use the community string to gain access to the SNMP agent.
Example 8-78 below illustrates how to configure two SNMP community strings. The first community string will be named READONLY and will permit read-only access for all objects for hosts residing on the 10.1.1.0/24 subnet. The second SNMP community string is named READWRITE and will permit read-write access for all objects only to host 10.1.2.254:
Example 8-78: Configuring Two SNMP Community Strings
| Sw1(config)#access-list 10 permit 10.1.1.0 0.0.0.255 Sw1(config)#access-list 20 permit host 10.1.2.254 Sw1(config)#snmp-server community READONLY ro 10 Sw1(config)#snmp-server community READWRITE rw 20 |
Unlike SNMPv1 and SNMPv2c, SNMPv3 is a security model that is an authentication strategy set up for a user and the group in which the user resides. Therefore, when implementing SNMPv 3, using the SNMPv3 security mechanism for handling SNMP packets, you must establish SNMP groups and users with passwords.
SNMP groups are configured using the snmp-server group [<name> v1 | v2c | v3 [auth | noauth | priv]] [read<name>] [write <name>] [notify <name>] [access <acl>] router configuration command. The auth keyword is used to specify authentication of packets without encrypting them. The noauth keyword specifies that the packets should not be authenticated. The priv keyword specifies that packets should be authenticated and encrypted.
The read <name> keyword is used to specify a read view for the SNMP group. A read view allows only read-only access. The write <name> keyword is used to specify a write view for the SNMP group. This view enables you to enter data and configure the contents of the agent. The notify <name> keyword is used to specify a notify view for the SNMP group. This view enables you to specify an Inform, a Notify, or a Trap.
Before configuring SNMP users, you must first configure an SNMP engine ID using the snmp-server engineID [local <engine-id> | remote ][ip-address] [udp-port <number>] engine-id-string router configuration command. The local <engine-id> keyword is used to configure an SNMP engine ID on the local device. Theremote] [ip-address] [udp-port <number>] engine-id-string keywords are used to specify the SNMP engine ID of a remote SNMP device. This includes the IPv4 or IPv6 address of the device that contains the remote copy of the SNMP, the UDP port of the host to use, and the engine ID itself. The engine ID is described below.
Each individual SNMPv3 agent has an engine ID that uniquely identifies the SNMP agent in the device. This engine ID may be set by the network administrator and is unique to that internal network. However, the engine ID may also be pre-configured by the device manufacturer. Each SNMPv3 packet contains two engine IDs. One is used to identify security information (i.e., the username), and the other specifies where the packet payload is coming from and going to.
SNMP passwords are localized using the SNMP engine ID 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 you can send proxy requests or Informs to it because the remote agent’s SNMP engine ID is required when computing the authentication and privacy digests from the password. If the remote engine ID is not configured first, user configuration will fail.
SNMP users are configured using the snmp-server user [username] [group] [remote ip-address [udp-port port]] [v1 | v2c | v3 [encrypted]] [auth <md5 | sha> [auth-password]] [access acl] router configuration command.
The encrypted keyword is used to specify that the password should BE in encrypted format. The auth <md5 | sha> [auth-password] keyword is used to specify the authentication level, which can be MD5 or SHA, and the authentication password, which enables the agent to receive packets from the host.
NOTE: When configuring SNMPv3, it is recommended that you also configure views using the snmp-server view [name] [oid-tree] [included | excluded] global configuration command. SNMP views are used to restrict MIB access and function in a manner similar to ACLs used in SNMPv1 and SNMPv2. By default, no views are configured; however, Cisco IOS software allows two standard predefined views to be used, instead of explicitly configuring one. The first view is ‘everything,’ which indicates that the user can see all objects. The second view is ‘restricted,’ which indicates that the user can see the following three groups:
- snmpStats
- system
- snmpParties
These predefined views are described in RFC 1447. When configuring the view, the oid-tree keyword is used to specify the OID of the ASN.1 subtree to be included or excluded from the view. The OID can either be a string of numbers, such as 1.3.6.1.2.1.1, or be a word, such as ‘system.’ You are not required to memorize OIDs for the SWITCH exam. Example 8-79 below illustrates how to configure SNMPv3 as follows:
- Using a view named NOC that includes all MIB objects within the system group
- A group named SWITCH that uses no authentication and has read-only access
- A remote engine ID of 1a2b3c4d5e for host 10.1.1.254
- A user named PASS in group SWITCH using MD5 AND with a password of h@rd!
Example 8-79: Configuring SNMPv3
| Sw1(config)#snmp-server view NOC system included Sw1(config)#snmp-server group SWITCH v3 noauth read NOC Sw1(config)#snmp-server engineID remote 10.1.1.254 1a2b3c4d5e Sw1(config)#snmp-server user PASS SWITCH v3 auth md5 h@rd! |
Example 8-80 below shows how the show snmp command can be used to validate this configuration.
Example 8-80: Validating SNMPv3 Configuration
| Sw1#show snmp ? context show snmp contexts engineID show local and remote SNMP engine IDs group show SNMPv3 groups mib show mib objects pending snmp manager pending requests sessions snmp manager sessions user show SNMPv3 users | Output modifiers <cr> |
Example 8-81 below shows the output of the show snmp engineID command.
Example 8-81: Output of the show snmp engineID Command
Sw1#show snmp engineID Local SNMP engineID: 80000009030000055E2DC9C0 Remote Engine ID IP-addr Port 1A2B3C4D5E remote 10.1.1.254 162 |
In summation, Table 8-2 below lists the default SNMP security models and levels.
Table 8-2: Default SNMP Security Models and Levels
|
Type |
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: Because SNMPv1 and SNMPv2c cannot authenticate the message source or protect the contents of the message using encryption, it is considered good practice to use these for read-only access. SNMPv3, which offers better security, should be used for read-write access.
SNMP Notifications
SNMP notifications can be sent by SNMP agents as either Traps or Inform requests. Traps are messages that alert the SNMP manager of a condition on the network. Examples of SNMP Traps could include an interface transitioning from an up state to a down state. The primary issue with Traps is that they are unacknowledged. This means that the sending device is incapable of determining if the Trap was received by the NMS.
SNMP Informs are SNMP Traps that include a confirmation of receipt from the SNMP manager. These messages can be used to indicate failed authentication attempts or the loss of a connection to a neighbor router, for example. 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.
While Informs are more reliable than Traps, the downside is that they consume more resources on both 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, while an Inform may be resent several times if a response is not received from the SNMP server (NMS).
The router or switch can be configured to send Traps to the specified NMS using the snmp-server host [hostname | ip-address] [traps | informs] [version <1 | 2c | 3> [auth | noauth | priv]] <community-string> [udp-port <port>] [notification-type] global configuration command. While the other options in this command have been described in previous sections, the notification type can and will vary by platform. The snmp-server enable traps [notification-type] global configuration command can be used to enable all SNMP notification types (i.e., Traps and Informs) that are available on the system. Optionally, the [notification-type] keyword can be used to specify the SNMP notification to send.
Example 8-82 below shows how to configure the switch to send all notification types to host 10.1.1.254 (NMS) using a community string of READONLY.
Example 8-82: Configuration Using a Community String of READONLY
| Sw1(config)#snmp-server enable traps Sw1(config)#snmp-server host 10.1.1.254 READONLY |
Example 8-83 below shows how to configure the switch to send HSRP Informs to host 10.1.1.254 using SNMPv2c and a community string of ACKD.
Example 8-83: Configuration Using SNMPv2 and a Community String of
ACKD for HSRP Informs
| Sw1(config)#snmp-server enable traps hsrp Sw1(config)#snmp-server host 10.1.1.254 informs version 2c ACKD hsrp |
Finally, Example 8-84 below shows how to configure the switch to send all Informs to host 10.1.1.254 using SNMP v2c and the community string ACKD.
Example 8-84: Configuration Using SNMPv2 and a Community String of
ACKD for All Informs
| Sw1(config)#snmp-server enable traps Sw1(config)#snmp-server host 10.1.1.254 informs version 2c ACKD |