SNMP for dummies: The data

After reviewing what is SNMP and what is for (check SNMP for Dummies: The protocol for related info), the aim of this article is showing how SNMP agents manage data they store, and thus, how that data might be addressed from the Network Management Systems to retrieve it, a matter that will be covered in the thirth and last article of this series.

Describing the scene, again

When dealing with the task of defining a protocol as SNMP, responsibles might face this challenge: designing an information management schema to give support -in a solid, coherent way- to a heterogeneous set of data from a heterogeneous and growing set of devices... Moreover: Having in mind that more of these devices share common features. Let's put names to the previous actors:

• The set of devices is composed by all existing and coming devices that can be attached to a network and are suitable of being remotely managed: UPSs, servers, switches, firewalls, IP cameras, alarm centrals, storage and backup devices... nowadays almost any device is suitable of being attached and managed.
• The set of data is composed for all data, of any kind, that one single device can expose. Taking a server, from the CPU fan status to the network interface CRC errors.
• Finally common features from different devices: both an UPS and a IP camera share common data types, for instance the network interface related data.

Object: The data itself

As introduced in the first part of this series of articles, Network Managed Systems (NMS) store and share their data through an entity called object. Tracing analogies, an SNMP object can be considered similar to a programming language variable in these ways:

• It has an unique identifier that, in the case of SNMP objects, is called OID (from Object IDentifier)
• It stores data of a basic and user-defined type. Concerning to SNMP, basic types are defined in RFC 1155: INTEGER, OCTET STRING, OBJECT IDENTIFIER and NULL. Some common used-defined types are: NetworkAddress, IpAddress, Counter, Gauge, TimeTicks and Opaque.

Additionally SNMP protocol manages object access rules, so an object can be accessed as read-only, read-write, write-only or can be defined but not published, what is called not-accesible.


Management: The MIB model.
Defined the object, ie, the basic item that stores data, now the question is how to arrange them having in mind that:

• Each object identifier must be unique,
• The model must be expandable for giving support to new devices.

SNMP protocol uses MIB as database model to storea data. MIB, from Management Information Base, is a jerarquical, tree-structured database where:

• Each node has two identifiers: One numerical and one alphanumerical.
• Data is stored in leaves (terminal nodes)
• Each node can be uniquely identified concatening all node identifiers from the root node.

In the above example, data relies on leaves, drawed as squared nodes. As part of the database, each node name is uniquely identified combining node identifiers (both numerical, alphanumerical or a combination): The unique identifier of NodeE is .NodeC.NodeE, or .3.1, or .NodeC.1

Network Managed Systems (NMS) don't define the tree schema from scratch. Instead, RFC 1155 defines a common framework that must be, fully or partially, used by all NMSs:

Finally, the MIB model is expandable: Any subtree can be added by definning it in what's called a MIB object definition. For instance, any company whose devices were SNMP compliant can add its subtree, ie, its MIB object definition under the OID .ISO.organization.DoD.internet.private.enterprises (.1.3.6.1.4.1). Obviously the world under enterprises is not chaos: IANA regulates what identifier (formely PEN or Private Enterprise Number) is asigned to each company, and each company must organize all its information under that identifier. These are some known company PENs:

• Cisco uses PEN 9, so all Cisco information must be located under .1.3.6.1.4.1.9
• HP uses PEN 11, so all HP information can be accessed through .1.3.6.1.4.1.11

You can find all PENs here.


An example
If you read the 3Com OfficeConnect Managed Switch 9 family datasheet you can see that they support the SNMP protocol. If you continue reading you'll see that they support these MIBs:

• MIB-II
• Bridge
• RMON
• MAU

What datasheet is saying is that these switches can act as SNMP Network Managed Systems (NMS) and that they store info about bridging, remote monitoring and mau using the MIBs located in the MIB tree structure next picture shows:

Information about supported MIBs, ie, what info they store and how they structure it, can be obtained from the manufacturer site or from generic MIB SNMP repositories as MibDepot. So for instance, if we surf the RMON MIB structure we can see it stores info about:

• Octects counters for each interface in the OID 1.3.6.1.2.1.16.1.1.1.4
• An alarm trable in the OID 1.3.6.1.2.1.16.3.1 or .iso.organization.DoD.internet.management.MIB2.bridge.alarm.alarmtable

You must have in mind that, even saying that a given Network Managed System supports a given MIB, it doesn't have to fully support it. In fact many times only part of a MIB is supported.

Interesting links

• SNMP for Dummies: The protocol
• The Cuddletech Guide to SNMP Programming. MIBs & OIDs
• Internet Engineering Tasking Force. RFC 1155
• Internet Engineering Tasking Force. RFC 1157

Tweet