SNMP is a protocol developed to manage network devices. Initially, it was designed to configure devices, monitor them, and receive push alerts. SNMP was first conceived in 1988 and has evolved over time.

SNMP aimed to be a standard interface to devices, regardless of the vendor. It partially succeeded by formalizing a set of interfaces, but it also failed because each vendor was allowed to extend the data structure by adding interfaces necessary to characterize their specific devices.

SNMP security was a problem for several years, to the extent that the implementation of device configuration functionalities was significantly limited.

Although SNMP has been a vital protocol for network monitoring, its complexity, initial insecurity, and centralized architecture led to the development of alternative solutions.

In this post, we review the SNMP ecosystem and how to implement and use it in versions 2 and 3.

MIB

MIB is the modeling language that defines the data structure used by SNMP. MIB (Management Information Base) defines a tree-structured data format that includes all objects manageable via SNMP. Each object has a unique OID (Object Identifier): through the OID, it is possible to access a specific object.

The tree consists of a standard part and a custom part. Each company can define its own objects by attaching them to the enterprises branch. Since each object must be unique, any company that needs to define its own objects should request a free Private Enterprise Number  from IANA. To date, more than 6000 companies  have customized the use of SNMP. There are two dangerous consequences:

• it is difficult to find a repository that contains all the updated MIBs;
• some MIBs may be incompatible with others because they are based on different versions.

If we want to retrieve the hostname of a system via SNMP, we can use the sysName object defined in the SNMPv2-MIB . sysName has ID 5, starting from system, which has ID 1. system attaches to mib-2 , which has ID 1 and is part of mgmt. Moving up the tree, we find that the OID for sysName is: iso.org.dod.internet.mgmt.mib-2.system.5, translated to 1.3.6.1.2.1.1.5.

sysName is defined as a string that can be accessed in both read and write modes.

Read/Write are the only two permissions possible in SNMP. Security in the first two versions of SNMP was quite weak, so the write operation was disabled on almost all devices. The introduction of SNMPv3 corrected security issues, but SNMP remained a monitoring protocol rather than a configuration one.

On Linux, we can download MIBs using the download-mibs command, included in the snmp-mibs-downloader package:

apt-get -y install snmp snmp-mibs-downloader
download-mibs

At this point, we should be able to translate OIDs correctly between textual and numeric formats:

snmptranslate -m ALL -TB sysNa
snmptranslate -m ALL .1.3.6.1.2.1.1.5
snmptranslate -m ALL -On SNMPv2-MIB::sysName
snmptranslate -m ALL -Os .1.3.6.1.2.1.1.5
snmptranslate -m ALL -Of .1.3.6.1.2.1.1.5

The snmptranslate command converts a numeric OID into a textual OID. The options used in the commands above are:

• -m ALL to use all available MIBs
• -TB to search for an OID using a keyword
• -On to print a textual OID in numeric form
• -Os to print only the last element of the OID in textual form
• -Of to print the full textual OID

Query

A query allows us to read the value of one or more objects. The device must be configured to allow us to read that specific value. Here are some examples for SNMPv2 and SNMPv3.

Configuration for SNMPv2 is quite simple: it requires setting a community and the type of access. In the example below, we use the community public, knowing that in a production environment, a much more complex string should be used:

snmp-server community public RO

We can further enrich the configuration by setting the location and contact fields:

snmp-server location Calisota
snmp-server contact Andrea Dainese
snmp-server ifindex persist

Continue reading the post on Patreon .