As system administrators, due diligence is understanding and maintaining the health of your servers and underlying infrastructure. The ever-evolving tech-ecosystem provides a myriad of tools for managing this information. SNMP or Simple Network Management Protocol, is one such fundamental technology these tools are often built upon.
SNMP operates as a conduit for servers to share real-time information about their internal states, while also facilitating system administrators to modify preset values. Despite its inherently basic structure, the programs deploying SNMP can be rather intricate.
This guide will demystify the nuts and bolts of SNMP, drawing parallels between its various usages, the way it’s typically used in a network, the differences between its protocol versions, and more.
Decoding SNMP
SNMP runs on the application layer of the networking stack (learn more about [networking layers](https://www.digitalocean.com/community/tutorials/an-introduction-to-networking-terminology-interfaces-and-protocols#NetworkLayers)). The protocol is designed to gather information from diverse systems in a standardized format. Though used across a myriad of systems, the method of obtaining information and routes to relevant information are universal.
There are multiple versions of SNMP at play, with a majority of networked hardware devices using some version of SNMP access. Despite SNMPv1 being the most popular owing to its widespread use and longevity, it tends to be insecure. Thus, unless there are compelling reasons not to, SNMPv3 with its advanced security features is highly recommended.
An SNMP-profiled network primarily comprises devices with embedded SNMP agents. An agent is a program that collects information about a hardware piece, organizes it into predefined entries, and responds to queries using SNMP.
An SNMP manager is responsible for querying agents for information. These machines usually have a comprehensive idea about all SNMP-enabled devices in their network and can request information and set certain properties.
SNMP Managers
An SNMP manager is a device configured for polling SNMP agents for data. The management component is considerably less complicated than the client configuration; it simply requests data. It can be any machine capable of sending query requests to SNMP agents with the correct credentials. This mechanism can be a part of a broader monitoring suite, or an administrator might use basic utilities to make quick requests.
Nearly all SNMP protocol commands are designed to occur via a manager component. These include GetRequest, GetNextRequest, GetBulkRequest, SetRequest, InformRequest, and Response. In addition, a manager is also designed to respond to Trap, and Response messages.
SNMP Agents
SNMP agents execute most of the heavy-lifting. They are tasked with collecting local system information and cataloging it into a database known as the Management Information Base (MIB) that can be queried.
The MIB is a hierarchical, predefined structure that stores accessible and mutable information subject to well-formatted SNMP requests. An SNMP agent configures which managers should have access to its information. It also acts as an intermediary reporting information on devices it can connect to that are not configured for SNMP traffic. This level of flexibility proves useful when getting components online and making them SNMP accessible.
SNMP agents can reply to most protocol commands such as GetRequest, GetNextRequest, GetBulkRequest and others. They are also designed to send Trap messages.
The Management Information Base (MIB) is potentially the most complex part of the SNMP system. The MIB is a database that subscribes to a standard adhered to by both the manager and the agents. It’s a flexible hierarchical structure — globally standardized in numerous areas, yet versatile to enable vendor-specific additions.
The MIB structure is akin to a top-down hierarchical tree, with each branch bifurcating and possessing a unique identifying number and an identifying string. These identifiers can be used interchangeably.
Referencing a specific node demands tracing the path from the unnamed root of the tree to the node in question. The parent IDs are strung together to form an address, each hierarchical junction represented by a dot. This entire address is commonly referred to as an Object Identifier or OID.
Hardware vendors often implement custom branches with their specific fields and data points. However, some well-defined standard MIB branches can be used by any device.
We’ll be discussing standard branches, all under the same parent branch structure, further down this tutorial. This branch defines information that complies with the MIB-2 specification, which is a revised standard for compliant devices.
The base path to this branch is either: 1.3.6.1.2.1 or can be represented as: iso.org.dod.internet.mgmt.mib-2.
Resources like [this](http://www.alvestrand.no/objectid/1.3.6.1.2.1.html) can help understand the MIB tree better. You may even find similar tools provided by both [Cisco](http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&substep=2&translate=Translate&tree=NO) and [SolarWinds](https://support.ipmonitor.com/mibs_byoidtree.aspx) useful.
In order to query our devices for information, most of the paths will begin with 1.3.6.1.2.1. You can explore these tree interfaces to understand the type of available information to query and set.
SNMP Protocol Commands
A significant reason for SNMP’s widespread adoption is the simplicity of the commands. Very few operations are needed to implement or remember, yet they excel at addressing the utility requirements of the protocol. The message types permitted by the protocol are called PDUs – Protocol Data Units:
1. Get: A manager sends a Get message to an agent to request specific OID value. The agent responds with the data.
2. GetNext: A GetNext message facilitates the manager to request the next sequential object in the MIB, allowing exploration of the MIB structure without specifying OIDs.
3. Set: Using a Set message, a manager can change an agent’s held variable value.
4. GetBulk: This manager-to-agent request acts as multiple GetNext requests. The respondent manager will provide as much data within the request constraints as possible.
5. Response: An agent sends this message to return any requested information to the manager. If the requested data cannot be returned, the response contains error fields with additional details.
6. Trap: A trap message is generally sent to the manager by an agent. These unsolicited, asynchronous notifications are mainly for managers to understand the events happening on their managed devices.
7. Inform: To assure the receipt of a trap, a manager sends an Inform message back to the agent. If not received, the agent may resend the Trap message.
Equipped with these seven data units, SNMP seamlessly fetches information about networked devices.
The SNMP protocol has evolved since it was first launched in 1988, starting from RFC 1065, 1066, and 1067. This version is still supported due to its long-standing history but it has many security issues containing plain text authentication and is thus not recommended for unprotected networks.
In 1993, work began on the second version of the protocol. It added several improvements over the previous version and included a new “party-based” security model developed to address prior security issues. However, the new model wasn’t popular due to its complexity. Consequently, version 2 spin-offs were created, which retained most version 2 improvements but changed the security model.
SNMPv2c reintroduced community-based authentication that was similar to v1. This version became popular among the SNMPv2 protocols. Another version, SNMPv2u, involved user-based security allowing per-user authentication settings, but it never garnered much adoption.
In 1998, the current version of SNMP protocol was introduced as a spec proposal. This version required a user-based security system allowing user’s authentication requirements to be set. The access control mechanism implemented permitted nuanced control over a user’s access to branches. Version 3 also provided the ability to enhance security provided by transport protocols like SSH or TLS.
Armed with the fundamental basics of SNMP, you’re now prepared to implement this protocol within your infrastructure. Our [next guide](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-an-snmp-daemon-and-client-on-ubuntu-14-04) will explore how you can install and configure SNMP on your system.
Paul Balo is the founder of TechBooky and a highly skilled wireless communications professional with a strong background in cloud computing, offering extensive experience in designing, implementing, and managing wireless communication systems.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
