How to monitor your network with SNMP: Fundamentals

24/02/201624/02/2016 TechTrends

In Zambia, the Simple Network Management Protocol (SNMP) is one of the most under utilised protocols. This could be largely due to two things:

Most network administrators aren’t fully aware of its vast wealth of functionality
Most networks invest in equipment positioned for the SOHO market with little or no support for centralised monitoring

I started delving into the world of monitoring in 2009 when I got my first job that required me to closely keep track of dozens of devices at an educational network I was maintaining. With access points losing power and resetting themselves on a daily basis, I realised, I couldn’t wait for a user to report an issue. I had to have a means of automating the network to tell me when a failure occurs and where it has occurred. Having enterprise grade equipment meant everything on the network that could be managed has support for the SNMP protocol. Because, I couldn’t justify the cost of purchasing a full monitoring solution from Solarwinds, PRTG, ManageEngine, etc, I was forced to look into what solutions were available on the Open Source market. But before I get into what solutions are available out there, let’s start by breaking down how the protocol works. In this first part, I will outline the fundamental knowledge surrounding the SNMP protocol, and also reference RFCs that you can read to further your knowledge. In part 2, I will then look at how you can setup SNMP on your network, what you can manage, and what tools are available out there as Free, Demo or paid versions.

AN OVERVIEW

SNMP is defined in RFC 1157 of the Internet Engineering Task Force. It outlines how management information can be exchanged between network devices and a network management system (NMS). Network devices can be anything from a router, switch, printer, computer all the way to servers. A complete SNMP implementation is made up of 4 components; the Network Management System (NMS), managed devices, SNMP agents, and the Management Information Base (commonly called the MIB).

The Network Management System (NMS) is a central point of control where management devices forward data triggered by local events. When this data is collected, it can be sorted to create graphs, network topologies and generate reports. An NMS can have a read-only or read/write relationship with managed devices depending on the Object Identifier (OID). In read-only relationships, the NMS cannot alter the data it receives from the device, nor can it trigger any changes. However, in a read/write relationship, the NMS, can send configuration instructions to the managed devices. These relationships are set when the Management Information Base and its associated Object Identifiers are created. A Managed Device is any end host that supports the SNMP protocol

In order for the managed device to communicate with the NMS, they must be able to speak the same language, the SNMP Agent makes this conversation possible. An SNMP agent contains instructions of what can be monitored on an device along with the types of values that can be passed on to the NMS. For example, an agent running on a laptop, could have information about the CPU, memory and network utilisation that it can periodically sample and forward to the NMS. Every device in a network that can be managed on a network, will have an SNMP agent built into it. For servers and host devices that have some degree of intelligence, a proprietary SNMP agent can be installed. Most NMS vendors like ManageEngine offer these custom agents along with their solutions.

The Management Information Base (MIB), defined in RFC 1066 is a database containing a list of instructions an NMS and SNMP agent use to communicate. A MIB is a hierarchy or database of objects that form a MIB-tree. Every object in the MIB tree has a unique value assigned by either a standards organisation or by the respective vendor under whose management that aspect of the MIB tree is. The specific location of an object in this hierarchy is represented by an Object Identifiers (OID). The OID is a numerical value that traces from the root through to the actual object.

For example, the in the diagram below, if we wanted to find out the System Description (sysDescr) of a new switch we added to the network, we’d trace from: . ROOT >> ISO >> Org >> DOD >> Internet >> MGMT >> MIB-2 >> Sys >> SysDescr. This can be represented as .iso.org.dod.internet.mgmt.mib-2.sys.sysdescr or more commonly: 1.3.6.1.2.1.1.1. This numerical value is what is called the OID

In the MIB tree there are two Objects of importance to every network and systems administrator

MGMT (2): Everything defined within MGMT is a network standard and can be used by every vendor. The MGMT object contains the MIB-2 MIB, which contains management instructions for most Layer 2 and Layer 3 protocols of the OSI Protocols suite. Most NMS solutions have this MIB by default
Private (4): Everything in here is vendor specific. i.e. When Cisco or Brocade writes a custom MIB to monitor a specific aspect of their devices, these instruction are written to a private MIB that will be added under this object. These MIBs are available on vendor support sites and can be imported into the MIB database of the NMS.

SNMP VERSIONS

There are three versions of SNMP that have been defined. I will not delve into what each of them offers. I’ll leave that to you:

SNMPv1 is the original standard and is defined in RFC 1155 and 1157
SNMPv2c is a revision of SNMPv2 which was supposed to improve on SNMPv1, but had a few complexity issues that led to it being abandoned. SNMPv2c was later released to continue these improvements. It is defined in RFC 1901, 1905, 1906 and 2578.
SNMPv3 is known for introducing security functionality into SNMP like encryption that the previous versions did not have. This is defined in RFC 1905, 1906, 3411, 3412, 3414, and 3415

You can visit the IETF website and search for the each of the RFCs above.

HOW SNMP ENABLED DEVICES TALK

During an SNMP conversation between an NMS and the managed device, only 7 commands are used. Each of these commands, when issued are encapsulated with a UDP (User Datagram Protocol) datagram at the Transport layer, and an IP packet at the Network layer before being sent off across the network. All SNMP conversations initiated by the server use UDP port 161, while all TRAPs and INFORMs from the client use UDP port 162. The following diagram of the OSI (Open Systems Interconnect) Model illustrates this point:

The following are the 7 types of commands that are used in an SNMP conversation:

GET: When the NMS would like a piece of information from a specific OID, it sends a GET-REQUEST, which the managed device can respond to with the a GET-RESPONSE containing either the requested value or a null value
GET-NEXT: Because a MIB is a hierarchy, certain objects in the MIB tree are simply place holders that don’t return any value when queried. A typical GET request would return a null value. A GET-NEXT solves this by requesting the next value in the index in the event a GET request is null. This command allows the command to dig into the MIB tree until a value is returned
GET-BULK: The GETBULK operation is used to retrieve voluminous data from large MIB tables
SET: in a Read/Write relationship, the NMS uses the SET command to configure the managed device

snmp-get-response — Image Source: ManageEngine SNMP Get Response

TRAPS: Each of the above commands is initiated by the NMS, however, the client can also trigger a conversation with the NMS. In SNMPv1/v2 this is via a TRAP

INFORM: The INFORM is an improved trap in that the NMS must acknowledge receipt of the inform to complete the conversation. INFORMs are only supported in SNMPv3