The SNMP driver of the Core Server includes server-side functionality. This means that existing Server Items can be mapped to SNMP data points. These SNMP data points can be accessed by SNMP clients via their SNMP Object Identifies (OID).
Our SNMP driver is supporting all three version of SNMP i.e. V1, V2 and V3. For V3, the mandatory security functionality is available to.
SNMP Server Configuration
The general configuration settings are done within the SNMP server configuration .
Here the version (V1, V2, V3) can be selected. For V1 and V2 the SNMP secret (SNMP community string) must be defined. For V3, a security user has to be defined.
Each SNMP device has some basic SNMP data points available. The values of these data points (sysName, sysDescription, sysContact and sysLocation) can also be set in the SNMP server configuration .
SNMP data points are accessible via its Object Identifier (OID). OIDs are ordered in a tree structure. This tree structure and the OIDs are defined by the SNMP standard. An OID consists of numbers separated by dots. E.g. the OID of sysLocation is 1.3.6.1.2.1.1.6.
To give these OIDs a meaning meaningful name, the Management Information Base (MIB) defines unique names for them. While these names are not exposed via the network, the information is provided by so called MIB files. E.g. the full name of the data point sysLocation is iso(1).identified-organization(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysLocation(6). All registered OIDs and their MIBs can found at http://oid-info.com/.
For application specific data, enterprises can request their own OID sub-tree. These sub tree are located in 1.3.6.1.4.1 (iso(1).identified-organization(3).dod(6).internet(1).private(4).enterprise(1)) - each enterprise with its own number. The assigned sub tree of NETxAutomation is 1.3.6.1.4.1.58651.
Each mapped SNMP data point needs an OID too. As default, all mapped SNMP data points are located in a sub tree. This sub tree can be specified within the SNMP server configuration . The default is the sub tree assigned to NETxAutomation (1.3.6.1.4.1.58651).
All configuration settings of the SNMP driver are “live”. This means the server does not need to be restarted after changing the configuration. It is sufficient to the save the corresponding files. The file content is reloaded automatically.
SNMP mapping definitions
As next, the server items that shall be mapped to SNMP data points must be specified. This is done within the SNMP mapping definitions .
The first column specifies the Item ID that shall be mapped. The second one the OID suffix that is added to base OID defined in the SNMP server configuration . If OID is left empty, the Core Server will used an auto increment to generate the OIDs. E.g. if the default base OID is used (e.g. 1.3.6.1.4.1.58651), the first mapped data point will get the OID 1.3.6.1.4.1.58651.1, the second one 1.3.6.1.4.1.58651.2, …
As an alternative, OID suffix can also be set manually. E.g. is 1.10 is chosen as OID suffix, the final OID will be 1.3.6.1.4.1.58651.1.10.
Please keep in mind that the OID must be kept unique within the server.
In addition to the OID, the SNMP data type and the access rights for the SNMP side can be specified too.
In the last column, the MIB name can be defined. The MIB name parts must be equal to the parts of the OID – the parts are separated by “.”. E.g. if there is an auto generated OID (OID is left empty), the MIB name is a single entry (e.g. sensor1). If the OID suffix is 1.10, the MIB name must contain two parts. E.g. device1.sensor1).
Keep in mind that the MIB names must be consistent and unique. Check the server logs for warnings or errors after loading the configuration.
The Core Server automatically generates an MIB file. This file can be give to the SNMP clients to show the correct names. The location of the MIB file is:
<WorkspaceFolder>\LogFiles\NETx.mib
An example
Consider the following SNMP mapping definitions:
The OID of the first data point is generated automatically. Assuming that the default base OID is used, the full OID of definition 1 is 1.3.6.1.4.1.58651.1. The MIB name is iso(1).identified-organization(3).dod(6).internet(1).private(4).enterprise(1).netxautomation(58651).sensor1(1).
The second data point uses a specific OID suffix. Assuming that the default base OID is used, the full OID of definition 2 is 1.3.6.1.4.1.58651.2.1 The MIB name is iso(1).identified-organization(3).dod(6).internet(1).private(4).enterprise(1).netxautomation(58651).device1(2).value1(1)
Note that a suffix of 1.10 for definition is not valid. This would result in an OID of 1.3.6.1.4.1.58651.1.1 which is not allowed since the first definition already uses 1.3.6.1.4.1.58651.1.
The result MIB file looks as follows:
-- NETx MIB 1.00
--
NETX-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter64, Counter32, Gauge32, TimeTicks, IpAddress, enterprises FROM SNMPv2-SMI
OBJECT-GROUP FROM SNMPv2-CONF;
netx MODULE-IDENTITY
LAST-UPDATED "202207120101Z"
ORGANIZATION "NETxAutomation"
CONTACT-INFO
"www.netxautomation.com"
DESCRIPTION
"The MIB module for NETx BMS Platform / NETx MP Server"
::= { netxautomation 3 }
--
-- Node Definitions
--
netxautomation OBJECT IDENTIFIER ::= { enterprises 58651 }
netxGroup OBJECT-GROUP
OBJECTS { sensor1,value1 }
STATUS current
DESCRIPTION
"NETx Group"
::= { netxautomation 4 }
sensor1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Variable 1 (Numeric)"
::= { netxautomation 1 }
device1 OBJECT IDENTIFIER ::= { netxautomation 2 }
value1 OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Variable 2 (Numeric)"
::= { device1 10 }
END