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).
SNMP requires two parties for communication:
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.
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 are outside the threshold range (RipEX alarm management). RipEX is capable of sending SNMP traps/informs to up to three SNMP managers.
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. |
GetRequest | returns a single value. |
GetNextRequest | returns the next value (using the next OID). |
GetBulkRequest | returns several values in a single packet (useful for data bandwidth optimization) |
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). |
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:
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.1 which are allocated by RACOM.