Since the creation of the first computer network, called ARPANET, which was used for military purposes, computer networks and their use have grown globally. As a consequence of this fact, there was an increase not only in scale, but also in its complexity. In this sense, over time, it became increasingly necessary to implement a standardized and open protocol that managed the network in order to have greater control of everything that involved the functional structure of computer networks.

In April 1988, the Internet Architecture Board (IAB) published very important documentation, RFC 1052, the Request For Comments, which set out the paradigms related to network management and their respective requirements.

In 1991, the first version of the original SNMP protocol, The SNMPv1, was published with some improvements in relation to its initial operating structure, yet before that, in the 80s, two different management protocols emerged that used the original SNMP as a basis, but with some improvements, they were large potential management protocols, we are talking about the Common Management Information Protocol (CMIP) and SNMPv2.

The SNMPv2 (1993) was very well received in the market, even more so its upgrade to the SNMPv2c which is the most used nowadays, while CMIP, despite being much more detailed than SNMPv1 and even than SNMPv2, was not. And it is not widely used for some reasons such as:

  • Despite being derived from SNMP, it uses much more system resources because it is more complex than SNMP and uses TCP as a transport protocol;
  • It is very difficult to program, as it has a diverse number of variables;
  • It has many more operations than SNMP;

So, the big problem with CMIP is that it has become a huge and complex system, that is, few networks can support it satisfactorily.

The SNMP then became widely used from the 90s with several improvements, such as the implementation of MIB RMON modules, and the most secure version of SNMP was officially approved in 1998, the SNMPv3.

Below are links to some RFCs that document SNMP versions:

SNMPv1: RFC 1157 of 1990;

SNMPv2: Its main RFCs 3416, 3417 and 3418;

SNMPv3: RFC 3410 to 3418 and 2576;

SNMP PROTOCOL DEFINITION

Simple Network Management Protocol is an open, application-layer protocol that establishes the exchange of management information by collecting and demonstrating network management data as variables (fetch-store paradigm).

SNMP uses the UDP protocol as a transport (standard port UDP 161), where messages are encapsulated in IP datagrams. Through its use, a network management system requests information (pooling) to network assets (agents), alters or searches for consulted values and obtains answers according to their respective requests.

By using a non-connection-oriented transport protocol, SNMP itself assumes the role of checking unreceived messages to avoid unlimited retransmissions, it uses a timeout, where the number of attempts is set by the network’s operational infrastructure manager.

We can represent through a rudimentary way the interaction between these elements according to the image below:

Rudimentary scheme of SNMP operation
Rudimentary scheme of SNMP operation

SMI – STRUCTURE OF MANAGEMENT INFORMATION

The network management information requested and collected via SNMP must be standardized depending on your organization, nomenclature, rules, and procedures. The processing and modeling of management information is usually done from concepts related to object orientation. This concept abstracts the behavior of network assets, they will represent a concrete reality or aspect of network devices, such as the description of each of the interfaces of a router in an object called ifdescr.

Several objects are hierarchically organized within a logical database called MIB (Management Information Base), all this standardization of MIBs files is done by the Structure Management Information (SMI) by a template (MIB II). In addition, another important function of SMI is to indicate how the ASN.1 data description language will be used for defining objects and the types of data associated with each of the objects.

The description of the MIB shows the formalization of its structure, each object belonging to it and its characteristics. The description of MIB is important due to its standardization and universal use, regardless of the Manufacturer.

Let’s cite some important data types in SNMP and give some examples:

  • INTEGER
  • STRING
  • OCTETSTRING
  • COUNTER (couter32, couter64)
  • OBJECTIDENTIFIER
  • NULL
  • SEQUENCE
  • SEQUENCE OF
  • IPADDRESS
  • NETWORKADDRESS
  • GAUGE (gauge32, gauge64)
  • TIMETICKS
  • OPAQUE

Each object is associated with a data type, for example, ifdescr is typically associated with the STRING data type.

OID – OBJECT IDENTIFIER

One of SNMP data type that we would like to give a special highlight is the OID. The Object Identifier is a string composed of integers separated by dots, since the MIB can be viewed as a tree that follows a template. Typically, in the MIB II, each node is represented by a number, so the OID is the path through which a given object is within an MIB.

So, when the manager requests information from the agent, it is usually indicated in the search, the OID of the searched object. Talking about requesting information, let’s take a closer look at the types of SNMP operations.

TYPES OF SNMP OPERATIONS

The manager can request information in different ways:

  • GET-REQUEST: It is a query from the manager to the agent to capture the value of a variable;
  • SET-REQUEST: It is a request from the manager to the agent to change the value of a variable.  Example: Change hostname;
  • GET-NEXT-REQUEST: It is a request from the manager to the agent to capture the value of the next variable;
  • GET-BULK-REQUEST: Implemented in SNMPv2, it improves variable retrieval considerably. This operation efficiently requests as much data as an agent can send in a single response.

The agent can communicate with the manager in the following ways:

  • RESPONSE: Response by the agent to the manager’s request;
  • TRAP: Notification sent by the agent to the manager;
  • INFORM-REQUEST: New type of TRAP implemented in SNMPv2, this operation works with checking for sending and receiving notifications, unlike a traditional TRAP.

Each operation is performed according to what information is wanted, for example, there are commands that are based on these operations, the Linux NET-SNMP package has SNMP commands.

The SNMP WALK command is based on the GET-NEXT-REQUEST operation, which means that when it runs, multiple requests are made to each row (variable or index) of the object-related table, each information of each row of the object table comes in a different response package.

The image below shows SLAview’s MIB browser in an SNMP query to the IF-MIB MIB on the ifdescr object, this first one gives details of the object:

Ifdescr - SLAview MIB browser
Ifdescr – SLAview MIB browser

It is worth noting that the access item refers to the object’s permission, as it is with the letter R, so this object only allows a read operation, that is, does not allow the SET-REQUEST operation.

Now, this image below shows the effective result of querying a Cisco router:

SNMP WALK - MIB SLAview browser
SNMP WALK – MIB SLAview browser

The SNMP PROTOCOL AND THE MANAGEMENT OF THE IT ENVIRONMENT

Typically, monitoring systems are used so that areas of FCAPS can be served. Commonly, the SNMP protocol is used within these systems to ddress the areas of performance and failures.

Currently, the SNMP protocol is the most widely used in the world when it comes to network monitoring. In the network, there are several devices manageable via SNMP in addition to the more traditional devices such as routers and switches. Sensors, printers, nobreaks, generators, raspberry, PABX are some examples of devices that can also be monitored today.

When it comes to fault and performance management, any of these devices that respond to the SNMP protocol can be monitored, either by using open MIBs or even proprietary MIB extensions provided by the manufacturer to optimize the detailing of information of these devices.

In addition, with SLAview these devices can be monitored via script using custom collections to generate a customization of standard collections on more useful and specific data.

FINAL CONSIDERATIONS

Therefore, the importance of the SNMP protocol for the management and monitoring of every IT environment is undeniable. That’s why Telcomanager brings to market the SLAview, a system based on SNMP, ICMP and scripted collection, a robust performance and performance analysis system for your entire IT environment.

With this in mind, Telcomanager, Latin  America’s leader in the network management software industry, in the market since 2002, with a unique and innovative methodology, provides intelligent solutions for monitoring data to provide a complete visibility of your IT infrastructure, allowing your company to monitor the main aspects of its network.

Posted on 07/25/2022