What is SNMP?

 

What is SNMP?

SNMP stands for Simple Network Monitoring Protocol. It is a protocol for management information transfer in networks, for use in LANs especially, depending on the chosen version.

 

 

 

Its usefulness in network administration comes from the fact that it allows information about network-connected devices to be collected in a standardized way across a large variety of hardware and software types.

Hardly any network admin renounces SNMP. Rather, most of them confidently rely on it because nearly all kinds of devices from many different manufacturers support SNMP, which helps them achieve comprehensive monitoring thanks to the SNMP technology.

 

Versions

Currently, there are three major versions of SNMP. The first version was developed rather quickly in the late ´80s when network administration lacked suitable network administration tools that were not dependent on hardware manufacturers.

SNMP v1 was defined in 1988 and was based on SGMP (RFC 1028). Then, it was broadly accepted and used. It is still used today, almost 30 years later, which is nearly an eternity in IT. SNMP v1 provides the basic functionalities for data polling and is relatively easy to use. It doesn't create much overhead because it doesn't include any encryption algorithms. So, for security reasons, use SNMP v1 in LANs only. Its biggest limitation is its 32-bit counter architecture, which is not enough for today’s gigabyte networks or larger.

If users want to manage networks in a WAN, the CMISE/CMIP protocol is the right protocol to go for.

SNMP v2 supports 64-bit counters but still sends critical data as clear text, so it does not really enhance security. And if users come across SNMP v2, it is mostly "SNMP v2c" that manufacturers or networkers are talking about, with the "c" standing for "community". Two other SNMP v2 versions exist, SNMP v2p and SNMP v2u, but they are only implemented in rare cases.

Credentials for SNMP devices

Defined in 2002, SNMP v3 includes the advantages of SNMP v2c and adds security solutions like user accounts, authentication, and optional encryption of data packages. This enhances security and makes SNMP v3 the recommended SNMP version when it comes to security. However, it also makes configuration more difficult, specifically user management. Therefore, much more processing power is needed, especially with short monitoring intervals that create a great number of SNMP messages.

SNMP v3 has three different security levels:

·         NoAuthNoPriv – Stands for No Authentication, No Privacy. No authentication is required and messages are not encrypted. For obvious reasons, this should only be used in closed, secure networks.

·         AuthNoPriv – Stands for Authentication, No Privacy. Messages must be authenticated to be acted upon; however, they are not encrypted during transmission. Theoretically, a malicious actor could still intercept data that was sent between agent and manager during authorized transmissions but could not introduce additional Get or Set requests.

·         AuthPriv – Stands for Authentication and Privacy. This is the most secure implementation of SNMPv3. SNMP messages must be authenticated and all data is encrypted during transmission. This way, a malicious actor is prevented from sending their own Get or Set requests and from seeing the data generated by legitimate requests.

How does SNMP work?

A network normally has at least one computer or server running monitoring software. It is the managing entity. A network will also most probably have a few, or many, or even really many, other devices: switches, routers, workstations, server racks, printers, coffee machines, or anything else that needs to be monitored. They are the managed devices.

SNMP messages are sent and received between so-called managers and agents. Usually, the SNMP manager in the network is installed on the managing entity and the SNMP agents are installed on the managed devices.

 

 

Basically, the transfer of SNMP messages can be compared to the typical communication between a client and a server, offering both pull and push technologies. The pull (or poll) technology is the most common communication type where a client, like the network management software on the managing entity, sends out a request to solicit a response from a server, or managed device. Its counterpart, the push technology, allows the managed device to “speak” and send out an SNMP message upon an event.

In SNMP terminology, for example, a GET request from an SNMP manager (client) follows the pull model, whereas an SNMP trap is "pushed out" by an SNMP agent (server) without any previous request.

SNMP message types

There are different types of SNMP messages that can be used to set up network monitoring via SNMP:

·         GetRequest – This is the most common SNMP message that an SNMP manager sends out to request data. The targeted device returns the requested value with a Response message.

·         GetNextRequest – The SNMP manager can send this message type to discover what information is available from the device. By starting at OID 0, the manager can continue to send a request for the next available data until there is no more “next” data. This way, users can discover all of the available data on a certain device even though they might not have had any prior knowledge of the responding system or device.

·         GetBulkRequest – Added in SNMP Version 2, this is a newer, optimized version of GetNextRequest. The solicited Response will contain as much data as allowed by the request. Essentially, this is a way to do several GetNextRequests at once, which enables users to create a list of all available data and parameters.

·         SetRequest – This is a manager-initiated command to set or change the value of a parameter via SNMP on the agent device or system. This message type can be used to manage or update configuration settings or other parameters. But be careful! An incorrect SetRequest may seriously damage systems and network setups.

·         Response – The Response is the message that a device agent sends upon a Request from the manager. When sent in response to a GetRequest type, the packet contains the requested data or values. In the case of a SetRequest, the packet responds with the newly set value as a confirmation that the SetRequest has been completed successfully.

·         Trap(v2) – A trap is sent (“pushed out”) by the SNMP agent without having been requested by the manager. Rather, traps are sent upon determined conditions, such as in the event of an error, or upon crossing a preset threshold. If users want to benefit from traps for monitoring, which is an excellent idea in terms of proactive monitoring, they might have to configure traps first with the help of the SNMP manager.

·         InformRequest – This message type was added in SNMP v2 to give the manager the possibility to confirm that it received an agent’s trap message. Some agents are configured to continue to send a trap until an inform message is received.

·         Report – SNMP v3 is needed to use Report messages. They allow an SNMP manager to determine what kind of problem was detected by the remote SNMP agent. Based on the detected error, the SNMP engine may try to send a corrected SNMP message. If that is not possible, it may pass an indication of the error to the application on whose behalf the failed SNMP request was issued.

SNMP message transfer

The Simple Network Management Protocol is part of the Internet Protocol Suite as an application layer (layer 7) protocol of the OSI model.

SNMP uses the User Datagram Protocol (UDP) to transfer messages. It is necessary that UDP packets can make it from the agent to the manager for monitoring to be successful. This typically works by default on a local network but additional router configuration is needed to allow such packets to traverse wider networks.

SNMP agents receive UDP requests on port 161. Requests sent from an SNMP manager may be sent from any port. Usually, it’s 161. Agents send traps via port 162. The SNMP manager also receives traps on port 162.

What are OIDs and MIBs?

OID

OID stands for Object Identifier. OIDs uniquely identify managed objects that are defined in MIB files.

Example:

On a printer, the typical objects to monitor are the different cartridge states and maybe the number of printed files. On a switch, the typical objects of interest are the incoming and outgoing traffic as well as the rate of package loss or the number of packets addressed to a broadcast address.

The object (OID) hierarchy is generally depicted as a tree with different levels from the root to the single leaves. Each OID has an address that follows the levels of the OID tree.

Sample:

Here is a sample structure of an OID:

Iso(1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4)

.card(1).slotCps(2)-cpsSlotSummary(1).cpsModuleTable(1).cpsModuleEntry(1)

.cpsModuleModel(3).3562.3

or just:

1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

 

Top level and general MIB object IDs are asssigned by different standard organizations like ISO. Vendors define OIDs for their own products in private branches of the OID tree.

There are two types of objects: scalar and tabular ones. Scalar objects define a single object instance whereas tabular objects define multiple related object instances grouped in MIB tables.

MIB

MIB stands for Management Information Base, and refers to an independent format for the definition of management information. In other words, MIBs contain OIDs in a well-defined way. In an MIB, every object gets its definition that defines its properties within the device to be managed. The objects are accessed using the SNMP protocol.

Why OIDs and MIBs are needed

Every piece of management information that can be obtained via SNMP – be it the memory usage of a server, the traffic on a switch, or the queued files on a printer – is individually addressed by its OID. This property is the reason why OIDs are needed. They help admins to identify and monitor the objects that they have in their network and thus make monitoring meaningful.

For the managing entity and a managed device in networks to communicate successfully, both of them need to know which OIDs are available.

This is the reason why MIBs exist and why system admins need them. Every object that has to be monitored on a device has to be provided by the device's MIB(s). Therefore, admins have to make sure that all necessary MIBs are stored on SNMP agent devices as well as on the managing entity system. An MIB file can be easily recognized via the extensions .my or .mib.

 

 

Device manufacturers normally deliver the necessary MIBs along with their SNMP-supporting products. Depending on the monitoring solution used, one might have to convert MIBs to product specific MIB versions.

Why SNMP is so universal: SMI

There are various factors that make SNMP so universal. Structure of Management Information (SMI) provides a commonly understood and standardized structure for the data types and for the transfer of them. Please also consider this link to get to the bottom of why SMI is also inextricably tied to OIDs and MIBs.

Value added by SNMP

 

Why would someone use SNMP? Well, as its name Simple Network Management Protocol says, it can be used for network management. In order to manage a network, admins need information about it. This is where SNMP has its greatest value. It gathers all the data from many devices and allows to put this data into context, which again allows to track issues, to make decisions based on real data, and to take control wherever necessary. That's what network management is all about. And that's why sysadmins will profit from using SNMP to monitor networks.

But there is more to it. A suitable monitoring tool, for example PRTG, will also help to get the most out of the data that admins receive thanks to SNMP and empower every network admin to monitor and manage their networks on time and proactively.

Being well organized

 

It can be an adventure to keep track of the vast quantity of network devices that modern networks comprise. Ideally, monitoring solutions support admins by offering a suitable way to structure and group devices and by presenting a clear overview that allows to go into detail whenever needed to ensure overall system health.

 

Alerting & notifying

Thanks to monitoring tools, sysadmins know exactly where to take action when a problem arises, and sometimes they even know before it occurs. Being informed on time is absolutely critical, so monitoring solutions should offer enough ways to notify the admin – like email, push notifications, SMS text messages (to be on the safe side when there’s no internet, for example), execution of a program, or even alerts on a smartwatch.

Reporting & statistics

Network monitoring will result in a lot of data in monitoring database. Let the numbers speak for themselves and use them to create reports and statistics. Analysis will not only provide insight into networks, but also help justify IT needs to the accounting or managing board. Visual dashboards will also help to be more successful.

Planning ahead

Data analysis will show the trends for individual networks and allow to plan ahead. The results: reliability, speed, and efficiency.

Comfortable setup

Setting up monitoring for large networks can be very tedious and time-consuming. Monitoring tools will automate and speed that up for the users and provide, for example, flexible network auto-discoveries or default templates for widely used network infrastructure products. And who would have thought? These technologies most probably use SNMP, too!

 

How PTRG can assist you monitor your network!

SNMP consists of three key components: managed devices, agents, and the network management station (NMS).

A managed device is a node that has an SNMP agent and resides on a managed network. These devices can be routers and access servers, switches, hubs, computer hosts, IP telephones, printers etc.

An agent is a software module residing within a device; it is executed at all times. This agent reports the information via SNMP to the managing systems. A network management station runs the network management protocol and the monitoring applications which provide the bulk of processing and memory resources required for network monitoring. An SNMP network can have more than one network management station.