SNMP(simple network management protocol)

SNMP defines how management information is exchanged between network management applications and management agents. SNMP uses UDP, port number 162, to retrieve and send management information.

The SNMP system consists of three elements:

  • SNMP manager:The SNMP manager is part of a network management system (NMS). The SNMP manager runs SNMP management software.
    The SNMP manager can collect information from an SNMP agent using the “get” action and can change configurations on an agent using the “set” action. In addition, SNMP agents can forward information directly to an NMS using “traps”.
  • SNMP agents (managed node): The SNMP agent and MIB reside on networking device clients. Network devices that must be managed, such as switches, routers, servers, firewalls, and workstations, are equipped with an SMNP agent software module.  The SNMP agent is responsible for providing access to the local MIB of objects that reflects resources and activity.
  • Management Information Base (MIB): MIBs store data about the device operation and are meant to be available to authenticated remote users.

SNMP agents that reside on managed devices collect and store information about the device and its operation. This information is stored by the agent locally in the MIB. The SNMP manager then uses the SNMP agent to access information within the MIB.

SNMP operation

There are two primary SNMP manager requests, get and set.

  1. A get request is used by the NMS to query the device for data.
  2. A set request is used by the NMS to change configuration variables in the agent device. A set request can also initiate actions within a device. For example, a set can cause a router to reboot, send a configuration file, or receive a configuration file. The SNMP manager uses the get and set actions to perform the operations described in the table:
Operation Description
get-request retrieves a value from a specific variable
get-next-request retrieves a value from a variable within a table; the SNMP manager does not need to know the exact variable name. A sequential search is performed to find the needed variable from within a table
get-bulk-request retrieves large blocks of data, such as multiple rows in a table, that would otherwise require the transmission of many small blocks of data.( only work with SNMPv2 or later)
get-response Replies to a get-request, get-next-request, and set-request sent by a NMS
set-request stores a value in a specific variable

The SNMP agent responds to SNMP manager requests as follows:

  • Get an MIB variable – The SNMP agent performs this function in response to a GetRequest-PDU from the NMS. The agent retrieves the value of the requested MIB variable and responds to the NMS with that value.
  • Set an MIB variable – The SNMP agent performs this function in response to a SetRequest-PDU from the NMS. The SNMP agent changes the value of the MIB variable to the value specified by the NMS. An SNMP agent reply to a set request includes the new settings in the device.
SNMP agent traps

An NMS periodically polls the SNMP agents residing on managed devices, by querying the device for data using the get request. Using this process, a network management application can collect information to monitor traffic loads and to verify device configurations of managed devices. The information can be displayed via GUI on the NMS. Averages, minimums, or maximums can be calculated, the data can be graphed, or thresholds can be set to trigger a notification process when the thresholds are exceeded.

Periodic SNMP polling does have disadvantages.

  • First, there is a delay between the time that an event occurs and the time that it is noticed (via polling) by the NMS.
  • Second, there is a trade-off between polling frequency and bandwidth usage.

Examples of trap conditions include, improper user authentication, restarts, link status (up or down), MAC address tracking, closing of a TCP connection, loss of connection to a neighbor, or other significant events.

SNMP operation

SNMP versions

 

There are several versions of SNMP, including:

  • SNMPv1 – The Simple Network Management Protocol, a Full Internet Standard, defined in RFC 1157.
  • SNMPv2c – Defined in RFCs 1901 to 1908; utilizes community-string-based Administrative Framework.
  • SNMPv3 – Interoperable standards-based protocol originally defined in RFCs 2273 to 2275; provides secure access to devices by authenticating and encrypting packets over the network. It includes these security features: message integrity to ensure that a packet was not tampered with in transit; authentication to determine that the message is from a valid source, and encryption to prevent the contents of a message from being read by an unauthorized source.

All versions use SNMP managers, agents, and MIBs.

Cisco IOS software supports the above three versions. Version 1 is a legacy solution and not often encountered in networks today; therefore, this course focuses on versions 2c and 3.

Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers able to access the agent’s MIB is defined by an ACL and password.

Unlike SNMPv1, SNMPv2c includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism retrieves tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2c improved error-handling 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 in SNMPv2c include the error type.

Note: SNMPv1 and SNMPv2c offer minimal security features. Specifically, SNMPv1 and SNMPv2c can neither authenticate the source of a management message nor provide encryption.

SNMPv3 is most currently described in RFCs 3410 to 3415. It adds methods to ensure the secure transmission of critical data between managed devices.

SNMPv3 provides for both security models and security levels.

  • A security model is an authentication strategy set up for a user and the group within which the user resides. Available security models are SNMPv1, SNMPv2c, and SNMPv3.
  • A security level is the permitted level of security within a security model. A combination of the security level and the security model determine which security mechanism is used when handling an SNMP packet.
Model Level Authentication Encryption Result
SNMPv1 noAuthNoPriv Community String No Uses a community string match for authentication
SNMPv2c NoAuthNoPriv Community String No Uses a community String match for authentication
SNMPv3 NoAuthNoPriv Username No Uses a username match for authentication (improvement over SNMPv2c)
AuthNoPriv MD5 or SHA No Provides authentication based on the HMAC-MD5 or HMAC-SHA
AuthPriv

(requires the

Cryptographic
software image)

 MD5 or SHA DES or AES Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Allows specifying the user-based security Model(USM) with these encryption algorithms:

  • DES 56-bit encryption in addition to authentication based on the CBC-DES(DES-56)standard.
  • 3DES 168-bit encryption
  • AES 128-bit, 192-bit,256-bit encryption

Community Strings

SNMPv1 and SNMPv2c use community strings that control access to the MIB. Community strings are plaintext passwords. SNMP community strings authenticate access to MIB objects.

There are two types of community strings:

  • Read-only (ro) – Provides access to the MIB variables, but does not allow these variables to be changed, only read. Because security is minimal in version 2c, many organizations use SNMPv2c in read-only mode.
  • Read-write (rw) – Provides read and write access to all objects in the MIB.

To view or set MIB variables, the user must specify the appropriate community string for read or write access.

Note: Plaintext passwords are not considered a security mechanism. This is because plaintext passwords are highly vulnerable to man-in-the-middle attacks, in which they are compromised through the capture of packets.

Management Information Base Object ID

The MIB organizes variables hierarchically. MIB variables enable the management software to monitor and control the network device. Formally, the MIB defines each variable as an object ID (OID). OIDs uniquely identify managed objects in the MIB hierarchy. The MIB organizes the OIDs based on RFC standards into a hierarchy of OIDs, usually shown as a tree.

The MIB tree for any given device includes some branches with variables common to many networking devices and some branches with variables specific to that device or vendor.

RFCs define some common public variables. Most devices implement these MIB variables. In addition, networking equipment vendors, like Cisco, can define their own private branches of the tree to accommodate new variables specific to their devices. Figure ablove shows portions of the MIB structure defined by Cisco Systems, Inc. Note how the OID can be described in words or numbers to help locate a particular variable in the tree. OIDs belonging to Cisco, as shown in Figure bellow, are numbered as follows: .iso (1).org (3).dod (6).internet (1).private (4).enterprises (1).cisco (9). This is displayed as 1.3.6.1.4.1.9.

Management_Information_base_object_ID

The data is retrieved via the snmpget utility, issued on the NMS. Using the snmpget utility, one can manually obtain values for the average of the CPU busy percentage. The snmpget utility requires that the SNMP version, the correct community, the IP address of the network device to query, and the OID number are set. Figure bellow demonstrates the use of the freeware snmpget utility, which allows quick retrieval of information from the MIB.

SNMPget_utility

Figure shows a rather long command with several parameters, including:

  • -v2c – version of SNMP
  • -c community – SNMP password, called a community string
  • 10.250.250.14 – IP address of monitored device
  • 1.3.6.1.4.1.9.2.1.58.0 – OID of MIB variable

The last line shows the response. The output shows a shortened version of the MIB variable. It then lists the actual value in the MIB location. In this case, the 5-minute exponential moving average of the CPU busy percentage is 11 percent. The utility gives some insight into the basic mechanics of how SNMP works.

However, working with long MIB variable names like 1.3.6.1.4.1.9.2.1.58.0 can be problematic for the average user. More commonly, the network operations staff uses a network management product with an easy-to-use GUI, with the entire MIB data variable naming transparent to the user.

The Cisco SNMP Navigator website allows a network administrator to research details about a particular OID. Figure bellow displays an example associated with a configuration change on a Cisco 2960 switch.

Cisco_SNMP_navigator

Configure SNMP

The basic steps to configuring SNMP are all in global configuration mode.

Step 1. (Required)

Configure the community string and access level (read-only or read-write) with the snmp-server community string ro |rw command.

Step 2. (Optional) Document the location of the device using the snmp-server location text  command.

Step 3. (Optional) Document the system contact using the snmp-server contact text command.

Step 4. (Optional) Restrict SNMP access to NMS hosts (SNMP managers) that are permitted by an ACL: define the ACL and then reference the ACL with the snmp-server community string access-list-number-or-name  command. This command can be used both to specify a community string and to restrict SNMP access via ACLs.

Step 1 and Step 4 can be combined into one step, if desired; the Cisco networking device combines the two commands into one if they are entered separately.

Step 5. (Optional) Specify the recipient of the SNMP trap operations with the snmp-server host host-id(Or IP) [version{1| 2c | 3 [auth | noauth | priv]}] community-string command.

By default, no trap manager is defined.

Step 6. (Optional) Enable traps on an SNMP agent with the snmp-server enable traps notification-types command. If no trap notification types are specified in this command, then all trap types are sent. Repeated use of this command is required if a particular subset of trap types is desired.

Note: By default, SNMP does not have any traps set. Without this command, SNMP managers must poll for all relevant information.

There are a number of other global configuration mode commands that a network administrator can implement to take advantage of the authentication and encryption support in SNMPv3:

  • The snmp-server group groupname {v1 | v2c | v3 {auth | noauth | priv}} command creates a new SNMP group on the device.
  • The snmp-server user username groupname v3 [encrypted] [auth {md5 | sha} auth-password] [priv {des | 3des | aes {128 | 192 | 256}} priv-password] command is used to add a new user to the SNMP group specified in the snmp-server group groupname command.

Example:

configure SNMP

As shown in Figure, PC1 is assigned the IP address 192.168.1.3/24. The Kiwi Syslog Server is installed on PC1.

After R1 is configured, whenever an event occurs which qualifies as a trap, the SNMP traps are sent to the SNMP manager. For instance, if an interface comes up, a trap is sent to the server. Configuration changes on the router also trigger SNMP traps to be sent to the SNMP manager. A list of over 60 trap notification types can be seen with the snmp-server enable traps ? command. In the configuration of R1, no trap notification types are specified in the snmp-server enable traps notification-types command, so all traps are sent.

KiwiSyslogServerSetupA check box is checked in the Setup menu to indicate that the network administrator wants SNMP manager software to listen for SNMP traps on UDP port 162.

To verify the SNMP configuration, use any of the variations of the show snmp privileged EXEC mode command.

To display the SNMP community string and ACL information, using the show snmp community command.

Best practice
  1. Both SNMPv1 and SNMPv2c rely on SNMP community strings in plaintext to authenticate access to MIB objects. These community strings, as with all passwords, should be carefully chosen to ensure that they are not too easy to crack. Additionally, community strings should be changed at regular intervals and in accordance with network security policies.
  2. Least privilege: If SNMP is used only to monitor devices, use read-only communities.
  3. Ensure that SNMP messages do not spread beyond the management consoles. ACLs should be used to prevent SNMP messages from going beyond the required devices. ACL should also be used on the monitored devices to limit access for management systems only.
  4. SNMPv3 is recommended because it provides security authentication and encryption.
Secure SNMPv3 ccna security

SNMPv3 can be secured with only a few commands.

Step 1. Configure an ACL that will permit access to authorized SNMP managers.

r1(config)# ip access-list standard acl_name

r1(config-std-nacl)# permit source_net

eg.

r1(config)# ip access-list standard permit-admin

r1(config-std-nacl)# permit 192.168.1.0 0.0.0.255

r1(config-std-nacl)# exit

Step 2. Configure an SNMP view with the snmp-server view command to identify the MIB OIDs that the SNMP manager will be able to read. Configuring a view is required to limit SNMP messages to read-only access.

r1(config)# snmp-server view view-name oid-tree

eg. r1(config)# snmp-server view SNMP-RO iso included

Step 3. Configure SNMP group features with the snmp-server group command:

  • Configure a name for the group.
  • Set the SNMP version to 3 with the v3 keyword.
  • Require authentication and encryption with the priv keyword.
  • Associate a view to the group and give it read only access with the read command.
  • Specify the ACL configured in Step 1.

r1(config)# snmp-server group group_name v3 priv read view-name access [acl_number | acl_name]

eg. r1(config)# snmp-server group admin v3 priv read snmp-ro access permit-admin

Step 4. Configure SNMP group user features with the snmp-server user command:

  • Configure a username and associate the user with the group name configured in Step 3.
  • Set the SNMP version to 3 with the v3 keyword.
  • Set the authentication type to either md5 or sha and configure an authentication password. SHA is preferred and should be supported by the SNMP management software.
  • Require encryption with the priv keyword and configure an encryption password.

r1(config)# snmp-server user username group_name v3 auth {md5| sha} auth_password priv {des | 3des | aes {128 | 192 | 256} } privpassword

eg. r1(config)# snmp-server user BOB admin v3 auth sha cisco12345 priv aes 128 cisco54321

Reference:

http://docwiki.cisco.com/wiki/Simple_Network_Management_Protocol

Simple Network Management Protocol SNMP Tutorial

configure and verify SNMPv3:

Free SNMP MIB browser: https://www.manageengine.com/products/mibbrowser-free-tool/