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).
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 RAy3)
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 whenever the monitored values are outside the threshold range (RAy3 alarm management). RAy3 is capable of sending SNMP traps to one SNMP manager.
In SNMP, each value is uniquely identified using Object Identifier (OID).
The standard SNMPv1/v2c communication starts by sending a request and then the response is returned. Alternatively, an agent can send an SNMP trap.
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. |
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 | sent from the agent to the manager whenever any monitored value is beyond its thresholds. |
SetRequest | used to set various parameters (unsupported by RAy3). |
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 .4.1.1.1 which are allocated by RACOM.