SNMP Protocol Explained

What is SNMP:

Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

SNMP exposes management data in the form of variables on the managed systems organized in a management information base (MIB) which describes the system status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by managing applications.

Three significant versions of SNMP have been developed and deployed. SNMPv1 is the original version of the protocol. More recent versions, SNMPv2c and SNMPv3, feature improvements in performance, flexibility, and security.

SNMP Components:

In typical uses of SNMP, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes a software component called an agent which reports information via SNMP to the manager.

An SNMP-managed network consists of three key components:

• Managed devices
• Agent – software which runs on managed devices
• Network management station (NMS) – software which runs on the SNMP manager
  
  

Use case example:

Say we want to know the System Uptime of a Device.

The NMS will send a Request to the Agent requesting the the System Uptime – the request is sent as a number with the MIB and the Object of Interest, along with something called theInstance.

OID = 1.3.6.1.2.1.1.3.0

Breakdown of OID Number

The first 2 parts of the number sent to the Agent (MIB and Object of Interest, which in this case is System Uptime) is called the Object Identifier or OID.

Management Information Database (MIB):

Each of the SNMP agents maintains the information database for the managed devices, which explains the parameters of the devices.

The SNMP manager utilizes this database to ask the agent for information about the particular device for NMS. Thus this shared information among the agent and the manager is known as a Management Information Database (MIB).

Structure of MIB:

• It is a group of information that comprises the variables that reside the values relevant to the parameters of the network element in its stores. These variables are known as managed objects and identified by an Object Identifier (OID).
• MIB is a collection of object identifiers in a hierarchical format, and each can identify a variable that can be set or read by the SNMP.

As mentioned above, MIB’s are Standard values that a Network Management System already knows about and can poll/request Network Devices about for information.

OID (Object Identifier):

OID, Object Identifier is a simply a number made up by the MIB, Object of Interest and the Instance. Each identifier is Unique to the device, and when queried will provide information on what has OID has been requested.

• The OIDs are of two kinds, scalar and tabular. The scalar one report only a single event instance means that the result is only one. Example: text or number.
• The Tabular object is a table which is a pool of all related OIDs and thus gives multiple results for one object value. For example: For the dual processor of the CPU, it will result in two values

SNMP traps enable an agent to notify the management station of significant events by way of an unsolicited SNMP message.

Why SNMP Traps are needed:

Traps are used when the Device needs to alert the Network Management software of an event without being polled.

Traps ensure that the NMS gets information if a certain event occurs on the device that needs to be recorded without being Polled by the NMS first.

Managed network devices will have Trap MIBs with pre-defined conditions built into them.

SNMPv1 (Simple Network Management Protocol) and SNMPv2c, along with the associated Management Information Base (MIB), encourage trap-directed notification.

The idea behind trap-directed notification is that if a manager is responsible for a large number of devices, and each device has a large number of objects, it is impractical for the manager to poll or request information from every object on every device. The solution is for each agent on the managed device to notify the manager without solicitation. It does this by sending a message known as a trap of the event.

After the manager receives the event, the manager displays it and can choose to take an action based on the event. For instance, the manager can poll the agent directly, or poll other associated device agents to get a better understanding of the event.

Trap-directed notification can result in substantial savings of network and agent resources by eliminating the need for frivolous SNMP requests. However, it is not possible to totally eliminate SNMP polling. SNMP requests are required for discovery and topology changes. In addition, a managed device agent can not send a trap, if the device has had a catastrophic outage.

SNMP Community Strings

SNMP community strings authenticate access to MIB objects and function as embedded passwords. In order for the NMS to access the switch, the community string definitions on the NMS must match at least one of the three community string definitions on the switch.

A community string can have one of these attributes:

• Read-only (RO): Gives read access to authorized management stations to all objects in the MIB except the community strings, but does not allow write access
• Read-write (RW): Gives read and write access to authorized management stations to all objects in the MIB, but does not allow access to the community strings

SNMP Versions:

SNMPv1:

SNMPv1 can best be described as a simple request/response model protocol. This version of the protocol introduced the GetRequest and GetResponse message types and established the initial framework where the NMS issues requests and the managed devices supplied responses. So in its simplest form SNMP only supported five PDU types, where each describes the nature and purpose of the message being encapsulated:

• PDU Type 0 – GetRequest
• PDU Type 1 – GetNextRequest
• PDU Type 2 – GetResponse
• PDU Type 3 – SetRequest
• PDU Type 4 – Trap

SNMPv1 utilizes the concept of community strings that operate via plain text. The issue with this method is the fact that plain text security methods more often than not are actually worse than using no security protocols at all. The approach to security in SNMPv1 relies on community strings but no matter how many communities we have defined on a managed device they will be one of two types. Read Only (RO) and Read-Write (RW) where a RO community only allows information to be gathered from the designated SNMP agent, and RW community accomplishes the same as the RO but adds the ability to set values and implement control.

Additionally, SNMPv1 allows us to use an access-list to define what hosts can query or control the managed device. But no matter how you slice it SNMPv1 still operates with the plain text model of security. This approach has led the industry at large to jokingly refer to SNMP as “security’s not my problem” rather than by its actual name: simple network management protocol.

SNMPv2

Because of glaring issues related to security and inefficient protocol operation it was necessary to make modifications to the initial offering of SNMP. SNMPv2 was the result of that effort. The GetRequest, GetNextRequest, and SetRequest operations found in SNMPv1 are exactly the same as those used in SNMPv2.

SNMPv2 did however expand some of the protocol’s operational mechanisms. Not the least of which was an enhancement to the basic trap operation whereby SNMPv2 uses a different message format and type that was designed to replace the previous SNMPv1 Trap message. This single enhancement allowed SNMPv2 to define a new trap operation. This operation is called a GetInform, which allows an NMS to send trap information to another NMS that it has received from an agent. This new exchange of Inform messages requires packet acknowledgment as part of its operation.

SNMPv2 also defines the GetBulk operation. GetBulk allows the NMS to efficiently retrieve large blocks of data from a particular agent rather than doing so in a sequential fashion. To prevent the possibility of lost information, should an agent responding to a GetBulk message not be able to provide values for all the variables in a given GetBulk list the agent will provide partial results rather than withholding all information in the list from the NMS.

As a result of the significant modifications made to SNMPv1, SNMPv2 now contains 9 PDU Types, two of which are not utilized:

• PDU Type 0 – GetRequest
• PDU Type 1 – GetNextRequest
• PDU Type 2 – GetResponse
• PDU Type 3 – SetRequest
• PDU Type 4 – Obsolete
• PDU Type 5 – GetBulkRequest
• PDU Type 6 – InformRequest
• PDU Type 7 – SNMPv2-Trap
• PDU Type 8 – SNMPReport  (defined in the RFC but not deployed in Cisco IOS)

SNMPv2 still relies on the concept of community strings and password security but now the protocol will support encrypted passwords (not to be confused with packet encryption). This is a definite improvement over the security offering of SNMPv1, but still far from ideal due to the fact that none of the operational data subsequent to the community-string comparison is encrypted. SNMPv2 still relies on the RO and RW community structures defined in SNMPv1. So the solution was better security than SNMPv1 but far from something we could consider as truly secure.

SNMPv3

The most significant change in SNMPv3 was the introduction of the User-based Security Model (USM) that governs message security and the view-based access control model (VACM). These changes culminated in a new operational architecture that allows SNMPv3 protocol to support different security methods, access control, and information processing mechanisms simultaneously.

SNMP Security Models and Levels:

You must configure the SNMP agent to use the SNMP version supported by the management station. Because an agent can communicate with multiple managers, you can configure the software to support communications using SNMPv1, SNMPv2C, or SNMPv3.

Simple Network Management Protocol SNMP Port Numbers:

SNMP operates in the application layer of the Internet protocol suite. All SNMP messages are transported via User Datagram Protocol (UDP).

The SNMP data packets use UDP for communication and are having two default port numbers, i.e. port 161 and port 162.

• The SNMP agent (Device to query from) receives requests on UDP port 161.

• The manager may send requests from any available source port to port 161 in the agent.

• The agent response is sent back to the source port on the manager. The manager receives notifications (Traps and InformRequests) on port 162.

Related Article: SNMP Configuration on Cisco Switches / Routers

References:

1- https://www.pcwdld.com/what-is-snmp-and-tutorial

2- https://itknowledgebasenote.wordpress.com/2015/02/08/snmp-basic-2nd-part/

3- https://www.softwaretestinghelp.com/snmp-protocol/

4-https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_55_se/configuration/guide/scg_2960/swsnmp.html

5- https://www.keil.com/pack/doc/mw/Network/html/group__net_s_n_m_p___func.html

6- https://www.tp-link.com/us/configuration-guides/configuring_snmp_rmon/?configurationId=18105