Part 2: A SNMP introduction
Part 2: A SNMP introduction

Part 2: A SNMP introduction

Wednesday, 07 September 2016

In my previous blog post I introduced a problem that exists with some implementations of asynchronous programming. In Oversight we extensively use async programming, especially for retrieving values with snmp. This article is a brief introduction to snmp and pysnmp and serves together with my previous post as background for for my next post.

A SNMP Introduction


Let's start with snmp and put in the obligatory (not really) Wikipedia quote:

Simple Network Management Protocol (SNMP) is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks and more

In Oversight one of our main monitoring methods is snmp. If you do monitoring, especially with infrastructures, sooner rather than later you'll be looking into snmp. It's rather low tech and "early days". You can find a pretty good description of its history here. Go read it, I'll be waiting here.

In case you remained here I wouldn't want you to miss this part:

SNMP was initially thought as an interim solution to fill the need for network management tool while a more theoretically sound system was being developed by the ISO. Anticipating the transition to the new network management system, SNMP designers made SNMP modular. Although that transition never occurred, the modularity of SNMP help it evolving through three major versions and found widespread use and acceptance.

So the basic concepts in snmp is that you'll have to understand there are OID's and MIB's. The new pySnmp explains them nicely. You can think of an OID as a tree structure where every vendor has its own subtree. Every table and every metric has its own number. There's quite some stuff that's common across vendors. Those are managed by the IETF you can find a few examples here on wikipedia

Example of an oid

You can find the system uptime at

1.3.6.1.2.1.1.3

[1] iso
 |-- [3] identified-organization
      |-- [6] dod
           |-- [1] internet
                 |-- [2] mgmt
                       |-- [1] mib-2
                             |-- [1] system
                                   |-- [3] sysUpTime

Traps

Snmp also supports traps. Traps are triggers that can be set up that should alert you when something is wrong. I'm focussing on polling right now because that's what I want to talk about in my next article.

Snmpwalk

If you have multiple items in a table each instance has its own index. With netsnmp you can do a walk over this tree:

snmpwalk -v 2c -c public 1.2.3.4 1.3.6.1.4.1.232

iso.3.6.1.4.1.232.1.1.1.0 = INTEGER: 1
iso.3.6.1.4.1.232.1.1.2.0 = INTEGER: 31
iso.3.6.1.4.1.232.1.1.3.0 = INTEGER: 2
iso.3.6.1.4.1.232.1.2.1.4.1.0 = INTEGER: 0
iso.3.6.1.4.1.232.1.2.2.1.1.1.0 = INTEGER: 0
iso.3.6.1.4.1.232.1.2.2.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.232.1.2.2.1.1.2.0 = INTEGER: 0
iso.3.6.1.4.1.232.1.2.2.1.1.2.1 = INTEGER: 0
iso.3.6.1.4.1.232.1.2.2.1.1.3.0 = STRING: "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz"
iso.3.6.1.4.1.232.1.2.2.1.1.3.1 = STRING: "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz"
iso.3.6.1.4.1.232.1.2.2.1.1.4.0 = INTEGER: 2300
iso.3.6.1.4.1.232.1.2.2.1.1.4.1 = INTEGER: 2300
iso.3.6.1.4.1.232.1.2.2.1.1.5.0 = INTEGER: 2
iso.3.6.1.4.1.232.1.2.2.1.1.5.1 = INTEGER: 2
iso.3.6.1.4.1.232.1.2.2.1.1.6.0 = INTEGER: 2
iso.3.6.1.4.1.232.1.2.2.1.1.6.1 = INTEGER: 2
iso.3.6.1.4.1.232.1.2.2.1.1.7.0 = INTEGER: 100

The command line arguments are described here. You'll also want to read up about snmp versions and community strings

As you can see everything under iso.3.6.1.4.1.232.1.2.2.1.1 ends either with a .0 for the first cpu socket and .1 for the second cpu socket.

In my next blog I'll use this information to collect the data we need, so stay tuned for my next post!