Simple Network Management Protocol

Print version

1. Simple Network Management Protocol

SNMP is a simple, widely used and useful standardised protocol typically used by Network Management Software (NMS) to read values from devices. Values can be obtained at regular intervals or on requests, saved to a database and then displayed as graphs or tables.

SNMP also enables devices to generate (trigger) the alarms by themselves and notify the NMS explicitly (SNMP traps/informs).

1.1. How does SNMP work?

SNMP requires two parties for communication:

  1. SNMP “manager” (software installed at your computer)

    • You can use commercial software or free software such as Zabbix, Zenoss, Nagios, Cacti, etc. If you want to read values manually, you can use tools such as snmpwalk, snmpget or Mibbrowser software.

  2. SNMP “agent” (a part of firmware in remote devices such as RipEX)

    • The agent receives SNMP requests to query information and responds to the manager. Several managers may read values at once and they can send their requests at any time. Alternatively, the agent sends SNMP traps/informs whenever the monitored values (watched values in RipEX, e.g. temperature) are outside the threshold range. RipEX is capable of sending SNMP traps/informs to up to three SNMP managers (since the firmware release 1.3).

1.2. SNMP communication

In SNMP, each value is uniquely identified using Object Identifier (OID). Standard communication starts by sending a request and then the response is returned. Alternatively, an agent can send an SNMP trap or inform (acknowledged trap).

The standard SNMPv1/v2c communication starts by sending a request and then the response is returned. Alternatively, an agent can send an SNMP trap or inform.

SNMPv3 shall be used if the higher security of the monitoring traffic is required. SNMPv3 provides security with authentication and privacy. The manager is required to know an authentication and encryption methods and common secrets to authenticate itself and decrypt SNMP packets.

A request is sent

the manager sets message-type to GET, includes OID for the required value and sets this value to NULL.

A response is returned

the agent sets message-type to RESPONSE and sends the requested value along with its OID back to the manager.

A trap is sent

to the manager without its request.

An inform is sent

to the manager without its request and the manager acknowledges its successful delivery.

1.2.1. Basic Message Types

GetRequest

returns a single value.

GetNextRequest

returns the next value (using the next OID).

GetBulkRequest

returns several values in a single packet (for example, temperature, voltage, number of transmitted messages or bytes per second, etc.).

Trap/Inform

sent from the agent to the manager whenever any monitored value is beyond its thresholds.

SetRequest

used to set various parameters (unsupported by RipEX).

1.3. MIB database – Management Information Base

The MIB is a virtual database used for managing the entities in a communications network.

The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. “Higher-level” MIB OIDs belong to different standards organizations, while “lower-level” OIDs are allocated by associated organizations (e.g. RACOM).

OID example:

RIPEX::serialNumber
serialNumber OBJECT-TYPE
-- FROM RIPEX
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Product serial number."
::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) racom(33555) ripex(2) station(1) device(1) 4 }

As you can see, numbers 1.3.6.1.4.1.33555 are the “higher-level” OIDs. The “lower-level” OIDs are .2.1.1.4 which are allocated by RACOM.