SNMP Overview

SNMP Overview

 

The Simple Network Management Protocol (SNMP) is by far the dominant protocol in network management. This Protocol (SNMP) was designed to be an easily implementable, basic network management tool that could be used to meet network management needs.

 

It is named Simple Network Management Protocol as it is really easy to understand. A key reason for its widespread acceptance, besides being the chief Internet standard for network management, is its relative simplicity. There are different versions of SNMP, such as SNMP V1, SNMP V2c, and SNMP V3.

 

Implementing SNMP management in a networked device is far more straightforward than most other standard or non-standard approaches to network management. Despite that, SNMP application development has not been as simple as one would like it to be. It has required significant effort to develop management applications to manage a variety of networked devices to be managed. This situation is now changing for the better, as more SNMP tools become available. With improved tools, SNMP is poised to deliver end-to-end management for all areas of the growing inter-networking industry.

 

Thus SNMP has become the dominant standardized network management scheme in use today. The SNMP set of standards provides a framework for the definition of management information along with a protocol for the exchange of that information. The SNMP model assumes the existence of Managers and Agents.

 

What Is an Agent?

 

Just think of insurance agents. They are the ones who help both the insurance companies and customers to get smooth access. Suppose we want to take an insurance policy, we do not have to spend anytime in taking that policy. The agent himself, will take care of it and just inform us the status.

 

In the same manner, Agent is a program which communicates with the Manager on one side and with Device or Application on the other side. It forms a  part of the Device or Application so that it can know everything about the Device or Application regularly.

 

It is a software module in the device responsible for maintaining local management information and delivering that information to a manager via SNMP. A management information exchange can be initiated by the manager (via polling) or by the agent (via a trap). Agent functions as a device that gathers and sends data about the managed resource in response to a request from a manager. UDP ports, 161 and 162, are the default ports reserved for SNMP. The agent listens for requests and replies to them over port 161 and reports asynchronous traps on port 162, unless it is instructed to use different ports. SNMP accommodates resources that do not implement the SNMP software by means of proxies. A proxy is an SNMP agent that maintains information on behalf of one or more non-SNMP devices.

 

Who Is a Manager?

 

Just imagine a Manager, as an entity managing one or more agents from a remote place. For example, let's take an organization which has its office premises in 4 places with more than 200 PCs, 4 to 5 printers, and just 3 System Administrators. To manage all these machines and printers, the System Administrators have to keep moving around all offices. Instead, if they have the Managers installed in their machines and agents installed in all other machines then they can easily handle all machines from their place. They just have to query the agent from the manager to know the status of the machine. If the Agent automatically informs the Manager when a problem is likely to occur (say, the number of paper is becoming less than 100 or 50 in a printer ), then the System Administrator will do the necessary changes (insert papers in the printer) to prevent the problem from occurring. If we come to know that the printer is running out of paper after giving a print, we will definitely be upset with it. Instead, if the printer itself notifies (through the agent) the person concerned (System Administrator) about its paper level or ink level then it will be very useful for the Administrator.

 

Manager and Agent Relationship

 

SNMP facilitates communication between a managed device (a device with an SNMP agent, e.g., a router) and an SNMP Manager or management application (represents a user of network management). The SNMP agent on the managed device provides access to data (managed objects) stored on the managed device. The SNMP manager or management application uses this access to monitor and control the managed device.

 

Communication is via SNMP Protocol Data Units (PDUs) that are typically encapsulated in UDP packets, and five kinds of operations are permitted between managers and agents (managed device).

To specify to the SNMP agent which managed objects are of interest, the SNMP manager or management application, uses a well-defined naming syntax. Object names in this syntax are called object identifiers (object IDs, or OIDs), and are a series of numbers that uniquely identifies an object to an SNMP agent.

 

What Is a MIB (Management Information Base)?

 

MIB is a document about the device or the application. There are a lot of syntaxes defined for defining the MIB, but the purpose of the MIB is simple. For example, if a company wants to build an application and wants the application to be remotely managed, then while building the application itself, the architects of the application or the device will write a MIB which will have information, such as what are the variables that should be published outside (to the Manager), what is the use of each variable, what each value in the variable represents, and so on.

 

Each variable is assigned a unique identifier in SNMP that is called an object identifier (OID). Object identifier is a unique ID (like registration numbers), but the uniqueness is maintained all over the world. Let us see how this uniqueness is maintained. The format of OID is a sequence of numbers with dots in between. There are two roots for object identifiers, they are iso (which is .1) and ccit (which starts with .0). Most object identifiers start with .1.3.6.1 (where 1 = iso, 3 = org, 6 = dod, 1 = internet). From internet, there are two branches, mgmt and private.

 

snmp_mib1.jpg

 

All standard MIBs reside under mgmt (.1.3.6.1.2) in this diagram - for example, MIB II (.1.3.6.1.2.1). The distinction between the standard and private MIBs is that of control over the object definitions (that is, defining the variables ). Standard MIBs are those that have been approved by the Internet Activities Board (IAB). MIBs defined unilaterally by equipment and software vendors are initially defined as private MIBs under private.enterprises. A branch within the private.enterprises sub-tree is allocated to each vendor that registers for an enterprises object identifier. zoho has got the enterprise OID as 2162. So all the variables we define for our device or application should fall under .1.3.6.1.4.1.2162 (.iso.org.dod.internet.private.enterprise.zoho). Till the enterprise number (like 2162), the uniqueness is maintained by the committee, after this the uniqueness should be maintained by each enterprise.

 

For example,  if we are going to manufacture a printer, then we can think of displaying the variables, such as  noOfPapers, inkLevel etc., so that at anytime the system administrators will know how many papers are there in the printer without going to the printer. They will just install the Manager in these machines and will query the printer agent and get this information. There are standard MIBs available. For exaple, RFC1213-MIB is a standard MIB for managing the system that each operating system will implement. This MIB contains information about the system, number of interfaces, and so on. There is also a standard MIB for printer. SNMP agents for different types of devices provide access to objects that are specific to the type of device. In order to enable the SNMP manager or management application to operate intelligently on the data available on the device, the manager needs to know the names and types of objects on the managed device.

 

This is made possible by Management Information Base (MIB) modules, which are specified in MIB files usually provided with managed devices. For example, rfc1213-MIB(also known as MIB-II) is a MIB module which is typically supported by all SNMP agents on TCP/IP enabled devices or systems. This MIB file contains a description of the object hierarchy on the managed device, as well as the name (Object ID), syntax, and access privileges for each variable in the MIB. For example, when the MIB module is loaded in a MIB browser, the label of the variable, e.g., sysDescr, can be used to identify it, since the MIB browser can use the MIB module to translate this label to an Object ID.

 

One key aspect of MIBs is that only the types of objects on the managed device are specified by the MIB, and not the specific objects (or instances). For example, ifInOctets in rfc1213-MIB specifies a type of object for number of input octets on an interface, but the specific objects or instances of that type are specified as ifInOctets.1, ifInOctets.2, etc., depending on the number of interfaces. When specifying an object to the SNMP agent, a proper Object ID which includes the instance needs to be used by the manager. When not properly specified, the agent responds with a "No such variable" error.

 

What Are MIB Groups?

 

A MIB group is a collection of managed objects, and is itself represented by the name or OID of a node in the OID tree. Groups may contain other groups. For example, bea is a MIB group that is a member of the private.enterprises MIB group. The nodes in the OID tree that are not groups - the base level of the OID tree - are the "leaves" of the OID tree. For example, in the following diagram:

 

snmp_mib2.jpg

 

MIB Data types Available

 

Following are the MIB data types and constructs supported by Agent Toolkit.

 

SNMP V1 Data Types

 

Data Type Name Description

INTEGER

Used to specify a value whose range may include both positive and negative numbers. Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values for the range).

Examples: 

INTEGER(0..127) -- corresponds to an unsigned

8-bit int 

INTEGER(0..40 | 50 | 65 | 90..100) 

INTEGER(-2147483648..2147483647) -- corresponds to a signed 32-bit int

INTEGER (enumerated integer) 

Used to specify a list of labeled integer values. In SMIv1, the values should be greater than 0, whereas SMIv2 allows any values in the range (-2e31 to 2e31- 1).

Example:  INTEGER {true(1), false(2)}

Gauge

It represents a non-negative integer which may increase or decrease, but which holds at the maximum or minimum value specified in the range when the actual value goes over or below the range, respectively.

Counter

Used to specify a value which represents a count. The range is 0 to 4294967295. 

TimeTicks

Used to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1. 

OCTET STRING

Used to specify octets of binary or textual information. While SMIv1 doesn't limit the number of octets, SMIv2 specifies a limit of 65535 octets. A size may be specified which can be fixed, varying, or multiple ranges. 

Examples: 

OCTET STRING -- length can vary from 0 to 65535 bytes.  
OCTET STRING (SIZE(0..255))  
OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.  
OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes.

OBJECT IDENTIFIER

Used to identify a type that has an assigned object identifier value.

IpAddress

This type is used to specify an IPv4 address as a string of 4 octets.

NetworkAddress

This type was designed to allow a network address of any type to be specified. However, it is now obsolete. A value of this type is an IPv4 address. SMIv2 supports this type via the IpAddress type.

Opaque

Used to specify octets of binary information. SMIv2 specifies a limit of 65535 octets while there is no limit in SMIv1. A size may be specified which can be fixed, varying, or multiple ranges. A value of this type must be an encapsulation of ASN.1 BER encoded value. 

Examples: 

Opaque -- length can vary from 0 to 65535 bytes. 

Opaque (SIZE(0..255)) 

Opaque (SIZE(4)) -- fixed length of 4 bytes. 

Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes.

 

SNMP V2 Data Types

 

Data Type Name Description

Integer32

Used to specify a value whose range may include both positive and negative numbers. Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values for the range).

Examples: 

Integer32(0..127) -- corresponds to an unsigned 8-bit int 

Integer32 -- same as --

Integer32(-2147483648..2147483647) 

Integer32(0..40 | 50 | 65 | 90..100) 

INTEGER (enumerated integer)

Used to specify a list of labeled integer values. In SMIv1, the values should be greater than 0, whereas SMIv2 allows any values in the range (-2e31 to 2e31- 1).

Examples: 

INTEGER { true(1), false(2) }  
INTEGER { lessThan(-1), equal(0), greaterThan(1) }

Unsigned32

Used to specify a value whose range includes only non-negative integers (0 to 2e31 - 1). 

Examples: 

Unsigned32 -- same as Unsigned32(0..4294967295) 

Unsigned32(0..65535) -- corresponds to an unsigned 16 bit int 

Unsigned32(0..10 | 50 | 65 | 90..100) 

 Gauge32

It represents a non-negative integer which may increase or decrease, but which holds at the maximum or minimum value specified in the range when the actual value goes over or below the range, respectively.

Counter32

Used to specify a value which represents a count. The
 range is 0 to 4294967295. 

Counter64

Similar to Counter32, except the range is now (0 to 2e64  -1). This type may only be used when a 32-bit counter rollover could occur in less than an hour. Otherwise, the Counter32 type must be used. Since this type is not available in SNMPv1, it may only be used when backwards compatibility is not a requirement.

TimeTicks

Used to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1. 

OCTET STRING

Used to specify octets of binary or textual information.
While SMIv1 doesn't limit the number of octets, SMIv2 specifies a limit of 65535 octets. A size may be specified which can be fixed, varying, or multiple ranges.  
Examples:  
OCTET STRING -- length can vary from 0 to 65535 bytes.  
OCTET STRING (SIZE(0..255))  
OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.  
OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes 

OBJECT
 IDENTIFIER

Used to identify a type that has an assigned object identifier value 

IpAddress

This type is used to specify an IPv4 address as a string of 4 octets.

Opaque

Used to specify octets of binary information. SMIv2 specifies a limit of 65535 octets while there is no limit in SMIv1. A size may be specified which can be fixed, varying, or multiple ranges. A value of this type must be an encapsulation of ASN.1 BER encoded value. 

Examples: 

Opaque -- length can vary from 0 to 65535 bytes.  
Opaque (SIZE(0..255))  
Opaque (SIZE(4)) -- fixed length of 4 bytes.  
Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes 

BITS

Used to specify a collection of labeled bits. It provides a way to label individual bits in an octet (an extension of OCTET STRING type). 

Examples:  
BITS { 1 (TCP), 2(Netware), 3(NetBIOS) 

 

MIB Constructs Available

 

The following tables describe the constructs supported by Agent Toolkit and the mandatory elements that must be defined if the construct is created/edited.
 

SNMPv1 Constructs SMPv2 Constructs Constructs Used Both in SNMPv1 and SNMPv2

TRAP-TYPE

MODULE-IDENTITY  
TEXTUAL CONVENTION  
OBJECT-IDENTITY  
OBJECT-GROUP  
NOTIFICATION-TYPE  
NOTIFICATION-GROUP

OBJECT-IDENTIFIER  
OBJECT-TYPE (SCALAR) OBJECT-TYPE (TABLE)

 

The Mandatory and the Optional fields for the various constructs :
 

Construct Name Mandatory Fields Optional Fields

OBJECT-IDENTIFIER
 (v1 & v2 Construct)

--

COMMAND-TYP

OBJECT-TYPE  (SCALAR)
 (v1 & v2 Construct)

SYNTAX
MAX-ACCESS
STATUS

DESCRIPTION REFERENCE DEFVAL
COMMAND TYPE

OBJECT-TYPE (TABLE)
 (v1 & v2 Construct)

SYNTAX SEQUENCE OF MAX-ACCESS STATUS

DESCRIPTION
REFERENCE
COMMAND TYPE

MODULE-IDENTITY
 (v2 Construct)

LAST-UPDATED ORGANIZATION
CONTACT-INFO
DESCRIPTION

REVISION REV-DESCRIPTION

TEXTUAL-CONVENTION (v2 Construct)

STATUS
DESCRIPTION
SYNTAX

 

DISPLAY-HINT REFERENCE

OBJECT-IDENTITY
 (v2 Construct)

STATUS
DESCRIPTION

REFERENCE

OBJECT-GROUP
 (v2 Construct)

OBJECTS
STATUS
DESCRIPTION

REFERENCE

NOTIFICATION-TYPE
 (v2 Construct)

STATUS
DESCRIPTION

OBJECTS REFERENCE

NOTIFICATION-GROUP
 (v2 Construct)

 

NOTIFICATIONS
STATUS
DESCRIPTION

REFERENCE

TRAP-TYPE
 (v1 Construct)

ENTERPRISE

VARIABLES DESCRIPTION REFERENCE

 

Supported Textual Conventions

 

The set of SNMPv2 Textual Conventions supported by the Agent Compiler and embedded agent are

note_nc.jpg

Note: The Agent Compiler supports these textual conventions but the relevant functionalities are not handled in the SNMP API.

 

Nodes

 

Following are the nodes present in SNMPv2-SMI mib:

Object Identifiers

 

Relative and Absolute Object Identifiers

 

The examples on object identifiers discussed so far specifies the path to the variable always from the root of the OID tree. For example, the zoho object identifier .1.3.6.1.4.1.2162 specifies the path from the root of the tree. (The root does not have a name or a number, but the initial 1 in this OID is directly below root.) These are called absolute OIDs. However, a path to the variable may be specified relative to some node in the OID tree. For example, 2.1.1.7 specifies the sysContact object in the system group, relative to the internet (.1.3.6.1) node in the OID tree. This is called a relative OID.

 

Specifying Object Identifiers Symbolically

 

Until now, we have used only a series of integers separated by dots, called "dot-dot" notation, to describe OIDs. However, an OID can also be expressed symbolically, or by a combination of both integers and textual symbols. A symbolic OID uses mnemonic keywords to specify the managed object; for example:

 

mgmt.mib-2.system.sysDescr

 

The following numeric OID uses integers to specify the same managed object:

 

2.1.1.1

 

Note that this example is a relative OID. An OID may combine both symbolic and numeric representations of individual nodes of the OID tree; for example:

 

mgmt.mib-2.1.sysDescr

 

Absolute OID names always begin with a dot and must specify every node of the OID tree from the top-most node to the specific managed object:

 

.iso.org.dod.internet.mgmt.mib.system.sysDescr
.1.3.6.1.2.1.1.1
.iso.3.dod.1.mgmt.mib-2.1.sysDescr

 

Object Identifier with Instance Indexes

 

To obtain values of objects from the manager, it is necessary to specify the instance of the object. The instance of an object is specified by appending an instance index to the object identifier. For example, the last 0 in:

 

.iso.3.dod.1.mgmt.mib.1.sysUpTime.0

 

is the instance index. An instance index of "0" (zero) specifies the first instance, "1" specifies the second instance, and so on. Since sysUpTime is a scalar object, it has only one instance. Therefore, an instance index of zero is always specified when retrieving the value of a scalar object. An instance index higher than 0 can only be used in the case of columnar objects ( in table ), which can have multiple instances.

 

Suppose the employee table we saw above has the following data:

 

empNumber (index column) empName empAge

1

xxx

25

2

yyy

30

3

zzz

28

 

If a manager wants to do a snmpget and get the name of the 2nd employee then the manager will send a get request with the following OID:

 

.1.3.6.1.4.1.2162.1.1.2.2 (where 2 is the instance). So "yyy" will be returned from the agent as response to the manager.

 

Scalar and Tabular Objects

 

A managed object has both a type (defined in ASN.1) and a value. For example, the SNMP system group variable sysLocation ( this variable is defined in RFC1213-MIB ) has the type, DisplayString and may have the value, "WebNMS Velachery". So in our case, we can define noOfPapers or inkLevel of the printer as a scalar object in the MIB.

 

Managed objects, in SNMP, are of two types : scalar objects and tabular objects.

 

A managed object that always has a single instance is called a scalar object. Tabular objects, on the other hand, have multiple instances, such as the rows of a table. For example, the MIB II system group has seven "leaf" variables under it, as illustrated in Figure below. Each of these objects is a scalar object. For example, the value of sysUpTime is the duration of time since re-initialization of a system's network management software (SNMP agent), measured in hundredths of a second.

 

Tables in SNMP are two-dimensional objects defined as an ASN.1 type called SEQUENCE OF, which allows 0 or more members. Each element of the sequence is an entry (row) in the table, which itself is a sequence of scalar-valued objects. SNMP does not allow tables to be nested within tables.

 

For example, the MIB II at group contains simply one tabular object, the atTable, which contains one row for each of a system's physical interfaces. Each row in the table is an instance of the object atEntry. Each row contains instances of the scalar-valued leaf objects atIfIndex, atPhysAddress, and atNetAddress. The leaf objects are called columnar objects since the instances of each such object constitute one column in the table. Although these objects have scalar-valued instances, they are not scalar objects because they can have multiple instances.

 

Another example for a table is, consider an organization. Each organization will have Employees. Suppose we want to define it in a MIB, we cannot go for scalar objects. We can define it in table format only.

 

How an Agent Works

 

An agent communicates with an SNMP manager, on the one hand, and the device or application ( so called Managed resource ) on the other hand, in the following way:

 

The SNMP manager sends an SNMP PDU ( Protocol Data Unit ) to the agent. This PDU contains an encoded request (such as a request to GET the value, or SET the value, of a specific managed object).

 

When the agent receives the request, it parses the SNMP PDU (ASN.1 decoding) to determine the type of request (i.e., GET or SET) and the MIB group, and invokes the appropriate access function corresponding to the object within the MIB group.

 

The access function does the actual work of retrieving the object's current value (for a GET request) or modifying the object's value (for a SET request). The method used to perform the GET or SET depends on where the managed object resides (i.e., UNIX kernel, shared memory, file, or in another process) and does not involve SNMP. If the object resides in another process, you can use shared memory or a proprietary protocol, such as Sun RPC/XDR or DCE RPC.

 

Depending on the value received from the access function, the agent hook layer returns one of the following responses to the agent core:

The agent core receives the response from the agent hook and builds the SNMP PDU (ASN.1 encoding). It then sends the response PDU to the SNMP manager.

 

Traps

 

In addition to retrieving data from the managed resource in response to requests from a management station, agents also send unsolicited messages to managers when they detect some significant event. An unsolicited message of this sort is called a trap notification. The fields that comprise the SNMP trap PDU occur in the order shown below:

 

PDU type

enterprise

agent address

generic trap type

specific trap type

time stamp

variable bindings

 

The fields have the following meaning:

The interpretation of generic trap types is described below:

 

Generic Trap Number Name of Trap Type Interpretation

0

coldStart

The agent that sends this trap re-initializes itself due to a reboot.

1

warmStart

The agent that sends this trap re-initializes itself due to a normal restart.

2

linkDown

One of the communication links on the agent node has failed. The first element in the variable bindings contains the name and value of the ifIndex instance for the downed interface.

3

linkUp

One of the communication links on the agent node has come up. The first element in the variable bindings is the name and value of the ifIndex instance for the affected interface.

4

authenticationFailure

The agent is reporting that it has received a request with an invalid community specification or a community with insufficient permissions to complete the request.

5

egpNeighborLoss:

The agent is reporting that the peer
relationship between an External Gateway Protocol (EGP) neighbor and an EGP peer no longer exists.

6

enterpriseSpecific

The sending agent has detected an enterprise-specific event. The value of the specific trap type field indicates the nature of the event.

 

Basic Operations

 

The basic operations in SNMP are GET ( GET is an operation where the manager will request the agent for the value of a particular OID ). In our case, if the System Administrator likes to know the variable inkLevel of the printer, he will do a get with the OID of the variable inkLevel. The agent will send a response with the value.

 

Specifying SNMP Variables in Get Requests

 

To specify an object to an SNMP agent, both the Object Name or ID (which defines the type of object) and the instance (the specific object of the given type) need to be provided. From the MIB, you get the Object ID to which an instance needs to be added. For non-tabular (or scalar) objects, this is simply an instance of 0 (e.g., sysDescr.0). For tabular objects, the instance is defined by the MIB, and is a sequence of one or more variables (e.g., ifInOctets.2 or tcpConnState.179.74.15.126.1192.225.226.126.197.80).

 

In order to get and set SNMP variables, you will need to completely specify the Object ID plus instance. However, you can use getnext, specify just the Object ID from the MIB (e.g., sysDescr), and get the first instance of that type from the SNMP agent. This works for all types of objects.

 

When using WebNMS's MIB browser, select a MIB node of interest to you, and either select getnext, or add the instance you are interested in at the end of the OID and use get. You have to set up the WebNMS Extensible Agent to make available a custom SNMP agent, providing the SNMP data for a specific MIB that you choose or write. For this, you need to get a good understanding of your MIB and the instances of MIB objects to be made available from your agent.

 

SET (If you specify an OID and request the agent to set the value, the agent will process and set the value, otherwise throw an error). In our case, we should not allow the noOfPaper variable to be SET from the manager, since it is a variable maintained by the printer itself. So when a SET request is made for this OID, the agent will throw an "noAccessError". We will also define this variable as a read-only variable in the MIB.

 

GETNEXT (Suppose we are not aware of an OID of a variable, then we will traverse the agent by giving GETNEXT till we get the value of the variable  we are interested in). Suppose we give a GETNEXT with .1.3.6, then the agent will respond with the next immediate OID it implements.

 

TRAP : All the above are requests sent from a manager to the agent. There is something called TRAP which the agent will send to the manager if it detects some errors. In our example, whenever the paper level, that is, the noOfPaper variable is less than 100, Agent sends a trap, so that the manager (System Administrator) will know it.



Copyright © 2012, ZOHO Corp. All Rights Reserved.