Administrator Handbook Table of contents version française

SNMP Objects

SNMP object index

When the SNMP SNMPmanager send a requests for an object to a SNMP agent this one should include an index. The index with a value of 0 is required for non indexed object.

But if the object is defined in a snmp table then an index is mandatory.

In the example below, the MIB tree window of LoriotPro with two objects, ifnumber which is not indexed (this one give the number of interfaces of the host ann the number of entries in the iftable) the second one ifdescr is an indexed object of the iftable.

indexed snmp object

When using SNMP OID (Object IDentifier) in the SNMP request and response packet the last values should specify the instance of the object. Instance is particularly useful to select a element among a group of similar element. This is the case when using network switches. Switches are made of a chassis containing multiple boards, sometimes daughter boards, each of them having ports.

Example : the following SNMP OID (Object IDentifier) is used to get the number of incoming octets on the port 3 located on the daughter board 2 of the board 2 of this device switch.

oid instance

The zero value points the object itself (here the chassis) and is the default one.

snmp v1 trap and snmp v2 notification

SNMP Agent has the ability of sending packets on his own called TRAPs. The initial configuration of the agent specify an IP address where to send it, normally the management station run a trap receiver process.

About TRAPs and LoriotPro: Loriot Pro manages SNMP V1 traps and notifications of informs from SNMP v2c and v3 (subset only). Traps are displayed in the windows trap manager. Filters allow the administrator to select the traps to display and to trigger and action.

SNMP notifications can be sent as traps (SNMP V1) or inform requests (SNMP V2c). Traps are unreliable because the receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the trap was received. However, an SNMP manager that receives an inform request acknowledges the message with an SNMP response PDU. If the manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.

Because they are more reliable, informs consume more resources in the SNMP device and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, while an Inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network. Thus, snmp trap and snmp nform requests provide a trade-off between reliability and resources. If it is important that the SNMP manager receives every notification, use Inform requests. On the other hand, if you are concerned about traffic on your network or memory in the router and you do not need to receive every notification, use traps.

SNMPv1 traps were defined in RFC 1157, with the following fields:

Enterprise Identifies the type of managed object generating the snmp v1 trap. Enterprise field contains value of sysObjectID of the device sending trap.For vendor specific snmp v1 traps, Generic snmp v1 trap type field is set to enterpriseSpecific(6).
Agent address Provides the address of the managed object generating the snmp v1 trap.
Generic trap type Indicates one of a number of generic snmp v1 trap types.
Specific trap code Indicates one of a number of specific trap codes.
Time stamp Provides the amount of time that has elapsed between the last network reinitialization and generation of the snmp v1 trap.
Variable bindings The data field of trap containing PDU. Each variable binding associates a particular MIB object instance with its current value.

The standard snmp v1 generic traps are:

0 coldStart The snmp device perform a power on
1 warmStart The snmp device perform a sofwtare reload or ipl
2 linkDown One of the interface od the snmp device went down
3 linkUp One of the interface od the snmp device went up
4 authenticationFailure A snmp manager try to acces an snmp agent with a wrong community or wrong user rights
5 egpNeighborLoss Exterior gateway protocol loss a neighbor router
6 enterprise specific Entreprise proprietary traps

In SNMPv2c trap is defined as NOTIFICATION and formatted differently comparing to SNMPv1. It has the following parameters:

sysUpTime Same as Time stamp in SNMPv1 trap
snmpTrapOID Trap identification field. For generic traps, values are defined in RFC 1907, for vendor specific traps snmpTrapOID is essentially a concatenation of the SNMPv1 Enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 Specific trap code parameter.
VarBindList A list of variable-bindings

 

Security and community

The security is became an unavoidable constrain in the contemporary information system. The initial security mechanisms designed in SNMP version 1 are now not enough secured to protect effectively access to devices. SNMP V2 and especially V3 added strong authentication between agents and the manager.

SNMP defines a kind of password protection by the concept of Communities. A community is given to a group of devices under the control of an authorized administrator. Without the community it is impossible to make SNMP request to devices.

Meanwhile it is impossible to affect rights to identified administrators and have access granularity on managed objects.

SNMP Community

There are three communities in SNMP v1 and V2c. Communities are set up when configuring the device

  1. Read only community : This community allows a read access only to any objects of a device. The common default value is “public”.
  1. Read write community: This community allows read and write access to any objects of a devices. The common default value is “private”.
  1. Trap community: the agent when sending traps to the manager uses this community.

A manager should know the devices communities of a device to read or write objects. The lack of security comes from the fact that the password is sent in clear text in SNMP packets on the network and a hacker could easily capture it.

Another common level of protection is to specify in the agent configuration the IP address of the manager that could send SNMP request. However, this address is easy to mystify.

The version 3 of SNMP allows multiple methods of protection against hacking based on identification, strong authentication and encryption.

LoriotPro supports authentication with a named profile and a password, using the algorithm HMAC-MD5-96.

Structureof Management Information

The SMI - Structure of Management Information specify the rules that should be followed when creating objects in MIB files. It is a subset of ASN1 – Abstract Syntax Notation from the OSI model. The objects are defined in a hierarchical tree structure. This global naming tree ensures that all object names are unique and gives a unique way for finding them.

The RFC1155 defines the rules to apply in version 1. The version 2 of the SMI is also available and MIB files could use either the SMI v1 or the SMI v2.

The following graph shows a part of the SMI tree:

MIB tree

Tree structure of SNMP objects

Each object is identified by is OID (Object Identifier). L’OID has two display formats (nominal and numeric). In PDU the numeric format is used by the protocol. Programs use the nominal format, easier to manipulate by human brain. The SNMP manager established the relation through the compiled MIB.

Example

Nominal

iso.org.dod.internet.mgmt.mib-2.ip.ipInReceives

Numeric

1.3.6.1.2.1.4.3

Here after the SMI v1 structure defining the top objects in the tree.

-- RFC1155 MIB
RFC1155-SMI DEFINITIONS ::= BEGIN
-- the path to the root
org OBJECT IDENTIFIER ::= { iso 3 }
dod OBJECT IDENTIFIER ::= { org 6 }
internet OBJECT IDENTIFIER ::= { dod 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private1 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
END

The SMI V2 notation is quite different from v1 in the construction of the logical structure of MIB files and of the global naming tree. The RFC 1902 describes these enhancements.

-- RFC 1902
SNMPv2-SMI DEFINITIONS ::= BEGIN
-- the path to the root
org OBJECT IDENTIFIER ::= { iso 3 }
dod OBJECT IDENTIFIER ::= { org 6 }
internet OBJECT IDENTIFIER ::= { dod 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
experimentalOBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
security OBJECT IDENTIFIER ::= { internet 5 }
snmpV2 OBJECT IDENTIFIER ::= { internet 6 }
-- transport domains
snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }
-- transport proxies
snmpProxysOBJECT IDENTIFIER ::= { snmpV2 2 }
-- module identities
snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }
-- definitions for information modules
END

The first sublevel under root is the iso object followed by the org object and so on. Each object has a number in the tree.

Here is an example for the object “sysname” and how you can see it with the LoriotPro MIB browser

The nominal format:

iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysname(5).0.

or the numerical format  : 1.3.6.1.2.1.1.5.0

mib tree to sysname
Example of an SNMP object sysname in the mib tree

Object types

Objects are from different types.

Scalar. A scalar object can be assigned values without structures

Table. Table objects are structured arrays and could be indexed.

The following unstructured data types could also be used :

Counter: A non-negative Integer that is incremented until it reaches a maximum value. When the maximum value is reached the counter wrapper (reset to 0)

Gauge: A non-negative Integer that could oscillate between 0 and a maximum value.

IpAddress: A 32 bits address in dotted octet format (Example: F1:01:45:56)

NetworkAddress: Used to store network address.

Opaque: Used to encapsulate non-formatted data

TimeTicks: A non-negative integer used to keep track of time in 100th of seconds.

Examples of object

Example of table object:

sysDescr 

Describe the model and the mark of the equipment.

IfEntry

This object contains a synthesis table of equipment’s network interfaces.

ipRouteTable

This object contains the IP routing table of the host.

The following text is an extract of the MIB file and describes the table object AtEntry :

AtEntry ::=
SEQUENCE {
atIfIndex
INTEGER,
atPhysAddress
PhysAddress,
atNetAddress
NetworkAddress
}

Example of scalar :

We use the the ‘MIB Query’ tool from LoriotPro to query the scalar object sysDescr  from 10.33.10.121 agent, its current value is displayed in the Result window. This is string type data.


Query on 10.33.10.121 agent for its sysdescr objet

Example of table query :

The ifentry object displayed hereafter on its table format contains a set of scalar objects.

mib table
Query on 10.33.10.121 agent for ifentry table

Example of snmp object of Counter type viewed from the LoriotPro Wizard

snmp counter mib object
snmp counter object

Example of snmp object of Gauge type from the LoriotPro Wizard

snmp gauge mib definition
snmp gauge

Example of snmp object of IP address entry type from the LoriotPro Wizard

snmp paddress mib object type
snmp IpAddress

Example of snmp object of TimeTicks type from the LoriotPro Wizard

snmp timeticks

snmp timeticks

 


www.loriotpro.com