SNMPv1, v2c and v3 are supported by RipEX2. Both can be configured separately for
the SNMP agent and for SNMP notifications (traps and informs). The communication is operated on standard UDP ports 161 (SNMP agent) and 162
(notifications). RipEX2 supports read-only regime only, i.e., it is not possible to “set” values via
SNMPSET commands. USM Security model is supported with AES-192 and AES-256 encryption
extension. SNMPv3 security is solved by a combination of USM (User-based Security Model) and
VACM (View Access Control Model). SNMPv3 can be configured with or without Encryption
and Authentication methods. When using SNMP over radio channel, we recommend setting RipEX2 to the Router mode.
From the point of radio network, SNMP is typically a standalone application sharing the
radio channel with others. Thus, it causes collisions, which are automatically resolved
by the radio channel protocol in the Flexible Router protocol, or handled optimally in
the Base Driven Router protocol (no collisions at all). The radio channel uses no
anti-collision protocol in the Bridge mode, meaning two competing applications can only
be run at a great risk of collisions and with the knowledge that packets from both
applications may be irretrievably lost.
MIB can be read via any text editor, but it might be better to browse it in some special SNMP browser such as MIBbrowser from iReasoning. The following section explains some details about RipEX2 MIB for firmware version 2.0.10.0. MIB consists of “revision history” information so you can quickly find out what has been changed.
![[Note]](/images/radost/images/icons/note.png){kind=icon} | Note |
|---|---|
SMS counters were added in the 2.0.10.0 firmware. |
The RipEX2 MIB module complies with the highest Severity level validation (level 6).
Supported MIBs and its OIDs:
Values from general MIBs such as SNMPv2-MIB, IF-MIB, IP-MIB, TCP-MIB, UDP-MIB or MIB-II
Proprietary MIB – RACOM-RA2-MIB
Statistics – complete Statistics are readable via SNMP – i.e., all the tables displayed in RipEX2 web interface Statistics menu are readable via SNMP as well (radio, Ethernet, cellular and serial statistics)
Notifications – traps and informs based on status of RipEX2 events
Station information – values such as product code, serial number, radio or CPU temperature, input voltage, …
Events – reading status, severities etc. about all supported Events
And some other values – e.g., Hardware capabilities, SNMP Update period
RipEX2 MIB utilizes custom types declaration so that SNMP reply is numeric, but each number corresponds to a particular meaning. E.g., type for Event severities:
EventSeverity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION “Severity of event – based on syslog”
SYNTAX INTEGER {
emergency (1),
alert (2),
critical (3),
error (4),
warning (5),
notice (6),
informational (7),
debug (8)
}
Make sure your NMS is configured to translate numeric values to their meaning correctly (Value mapping in Zabbix).
Some of the returned values are in decimal notations. E.g., CPU temperature returned as 487 means 48.7. If a particular value requires it, it also has a predefined unit such as degrees of Celsius, Volts, decibels, percent, … Again, make sure you utilize your NMS with correct unit.
Current MIB can always be downloaded from RACOM website together with Zabbix templates, see https://www.racom.eu/eng/products/radio-modem-ripex-detail#dnl_fwr2.
SNMP is primarily designed for Ethernet networks, where generally, bandwidth capacity is not an issue. By contrast, radio bandwidth capacity is very limited and RipEX2 mostly works over the radio channel. For this reason, special care is recommended while configuring NMS. If badly configured, NMS can take a significant portion of the network capacity or can even overload the network completely.
It is important to realize that getting all RACOM specific OIDs from a single RipEX2 with one neighbouring unit can be approximately 100 kilobytes using SNMPv2. With encrypted and authenticated SNMPv3, this data volume can be doubled.
| Note |
|---|---|
Number of values which can be obtained from each RipEX2 highly depends on number of neighbouring units, configured features (Protocols on RS232/Terminal servers, …) and HW capabilities (LTE, …). |
We recommend to query most of the values from units connected via Ethernet and query only carefully selected OIDs over the radio channel and not all possible data. Set SNMP query time intervals in your NMS as long as possible. The shortest recommended interval ranges from several minutes to tens of minutes.
It is also recommended to utilize SNMP BULK requests which significantly reduce amount of data being exchanged between RipEX2 and NMS, because it is possible to query multiple OIDs within a single packet, as well as reply to such multiple requests within just one SNMP reply packet.
| Note |
|---|---|
There are many Network Management Systems available on the market. Whichever you choose, keep in mind the described limitations. E.g., never use NMS, which can download only the entire remote device MIB and not single OIDs. |
Complete set of Statistic tables can be downloaded via SNMP. There are multiple principles which must be taken into account while getting such values from RipEX2 units.
Discovery procedure
Each unit can have different number of RipEX2 neighbours, different functionalities configured or different HW options, such as presence of LTE module. SNMP mechanism needs to discover such indexes to every supported table and then, query for currently enabled/supported values within these tables.
Typical mechanism in static RipEX2 network is to run Discovery procedure once and then just query values based on found indexes until there is any change in the network topology or configured functionalities in RipEX2 units. In such situation, it is required that this Discovery procedure updates all the indexes – i.e., adds new lines/indexes and removes those which are no longer supported.
Tables requiring Discovery:
Radio interface statistics, Radio protocol statistics and Radio signal statistics
Both tables consist of lines for each neighbouring RipEX2 unit, indexes which are discovered are unique MAC or Link addresses. You can use IP addresses in your NMS for better understanding (see more details in Zabbix NMS section).
You need to re-run Discovery every time you add a new unit into the network. Removing of such unit can usually be automatic (after specified time of inaccessibility).
Serial protocols statistics
This table consist of enabled COM and TS ports
Re-run the discovery every time you enable a new COM or TS port
Ethernet statistics
This table consist of enabled ETH ports
Re-run the discovery every time you enable another Ethernet port or e.g., install the SFP port (ETH5)
Statistics Update Period
In general, we have two types of Statistics tables.
Tables consisting counters – The Counter64 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^64-1 (18446744073709551615 decimal), when it wraps around and starts increasing again from zero.
Every time you read any value from these tables, you read a current counter value – it is usually suggested to re-calculate this value to either changes per second or to simple changes (difference between two readings)
List of tables: Radio interface statistics, Radio protocol statistics, Radio protocol non-addressable statistics, Serial protocols statistics, Ethernet statistics, Cellular interface statistics
Tables consisting Statistics based on “Update period” parameter
Tables are periodically updated with this period
Default value is 15 minutes (see the Advanced menu and set “Statistics table update period” variable to different value, if required
If you use a default value equal to 15 minutes, the values within these tables are updated every 15 minutes
Values are not changed within this period (no matter how many times you query for particular values)
Once 15 minutes pass, a new update to tables is done and you can read new values from these last 15 minutes (e.g., average RSS value).
You cannot read current values from the period which is not yet “closed/finished”
Your NMS interval for querying these values should equal to this Update period
List of tables: Radio signal statistics, Radio signal non-addressable statistics, Cellular signal statistics, Cellular state statistics
Basic SNMP parameters are described in RipEX2 user manual and can be configured in SETTINGS – Device – SNMP menu. The following section highlights some important parameters or explains something in more details.
Make sure that your NMS supports Authentication and Encryption algorithms you choose in RipEX2. For example, since Zabbix 6.0 LTS, SHA224 and higher are supported, but in previous versions, Zabbix could only select MD5 or SHA1 from the Authentication listbox.
Another not very common option is “Engine ID”. This option is valid for SNMPv3 only. It serves for unambiguous SNMP instance identification. Every SNMPv3 enabled device within a network must have a unique Engine ID.
By default, Engine ID is generated automatically based on RipEX2 MAC address (ETH1 interface). If it is set to “UserDefined” option, you can set or generate your own Engine ID.
Example of default Engine ID: 80 008313 03 00 02 a9 20 06 ef
80 – engine ID as described in RFC3411 – engine ID must start with standard identification
008313 – enterprise OID – 33555 – RACOM s.r.o.
03 – engine ID assembled according to MAC address
00 02 a9 XX XX XX – ETH1 MAC address
Example of own Engine ID:
80 008313 04
61494F6730346743574A31376970386345305A6D456C4B2D697059
04 – Engine ID is assembled according to user defined string
61494F6730346743574A31376970386345305A6D456C4B2D697059 – HEX string from configuration
The differentiated part of the Engine ID can be entered as ASCII characters or
generated (e.g., aIOg04gCWJ17ip8cE0ZmElK-ipY). This string is converted into HEX
number (i.e., 61 49 4F 67 30 34 67 43 57 4A 31 37 69 70 38 63 45 30 5A 6D 45 6C 4B 2D
69 70 59). Notifications are being sent based on Events.
Select events for which you want notifications to be sent in SETTINGS – Device –
Events menu. Check the particular check-box “SNMP notification”. You can also Enable
SNMP notifications for all supported Events with one button “Enable SNMP trap for
all”. Current EngineID can be checked by capturing the SNMP data in Wireshark. It can
also be obtained by SNMP request for .1.3.6.1.6.3.10.2.1.1 OID (implemented in newer
firmware versions than 2.0.10.0).
If required, you can change severities for some of the Events, others are fixed to a particular level.
Several Events can be configured with Thresholds – temperatures and voltage. Set the required values if not satisfied with default limits.
Radio board temperature severity is set to “Error”, because too low/high temperatures can corrupt radio transmission. Others are set to “Warning”.
Another difference in Events is that some Events are just informational – such as that a new user was created, or Recovery restart has been triggered. Other events consist of “Status” so that if the Event happens, a “Raise” SNMP notification is sent causing a unit and eventually the NMS to display some “error” state. Once the Event is no longer active, the “Clear” notifications is sent and the particular “error” state is also cleared. E.g., CPU temperature goes to too high value (110°C) and raises the alarm. Once the temperature is below the limit again (for example 90°C), RipEX2 clears this event and sends a corresponding notification as well. Your NMS should be configured for both types.
| Note |
|---|---|
The SNMPv3 Inform is not supported in 2.0.10.0 firmware and older. There is an opened issue in SNMP daemon and we wait for that fix. Once done, we will enable this option again. |
The last parameter is only accessible via Advanced menu – Statistics table update period. If you require different value than default 15 minutes, do it via the Advanced menu.