Arista EOS dBm power values are not calculated

When asking for help and support, please provide as much information as possible. This should include:

  • Steps to reproduce an issue.
  • The output of ./validate.php

If it’s an issue with the WebUI then please consider including a screenshot and the browser version you are using.

If you are having troubles with discovery/polling include the pastebin output of:

./discovery.php -h HOSTNAME -d | ./pbin.sh
./poller.php -h HOSTNAME -r -f -d | ./pbin.sh

If you need to post any text longer than a few lines, please use a pastebin service such as https://p.libren.ms using non-expiring pastes.

./validate.php:

===========================================

Component Version
LibreNMS 24.2.0 (2024-03-01T10:55:24+00:00)
DB Schema 2024_02_07_151845_custom_map_additions (290)
PHP 8.2.16
Python 3.11.8
Database MariaDB 10.5.24-MariaDB-1:10.5.24+maria~ubu2004
RRDTool 1.8.0
SNMP 5.9.4
===========================================

[OK] Installed from the official Docker image; no Composer required
[OK] Database connection successful
[OK] Database Schema is current
[OK] SQL Server meets minimum requirements
[OK] lower_case_table_names is enabled
[OK] MySQL engine is optimal
[OK] Database and column collations are correct
[OK] Database schema correct
[OK] MySQL and PHP time match
[OK] Active pollers found
[OK] Dispatcher Service is enabled
[OK] Locks are functional
[OK] No python wrapper pollers found
[OK] Redis is functional
[WARN] IPv6 is disabled on your server, you will not be able to add IPv6 devices.
[OK] rrd_dir is writable
[OK] rrdtool version ok
[WARN] Updates are managed through the official Docker image

RX/TX values for dBm don’t seem to be mapping correctly.
snmpwalk returns them as:
iso.3.6.1.2.1.99.1.1.1.4.100302213 = INTEGER: 4082

LibreNMS seems to agree:

“poller_type”: “snmp”,
“sensor_oid”: “.1.3.6.1.2.1.99.1.1.1.4.100302213”,
“sensor_index”: “100302213”,
“sensor_type”: “entity-sensor”,
“sensor_descr”: “DOM RX Power For Ethernet2”,
“group”: “SFPs”,
“sensor_divisor”: 1,
“sensor_multiplier”: 1,
“sensor_current”: 4082,
“sensor_limit”: 2.5,
“sensor_limit_warn”: 0.5,
“sensor_limit_low”: -16.4,
“sensor_limit_low_warn”: -14.4,
“sensor_alert”: 1"sensor_custom": “No”,
“entPhysicalIndex”: “100302213”,

However the conversion from reported values to expected dBm doesn’t seem to work. I am unsure if this is a scale error, or something else.
That “sensor_current” is populated pretty much as-is in the dBm:

DOM RX Power for Ethernet2;
Value: 4087 (dbm)

This causes alerts on all ports with transceiver details.
Limit values are pulled in correctly, but the actual power used is not.

                     High Alarm  High Warn   Low Alarm   Low Warn    
       Rx Power      Threshold   Threshold   Threshold   Threshold   

Port (dBm) (dBm) (dBm) (dBm) (dBm)


Et2 -3.89 2.50 0.50 -16.40 -14.40

Interestingly there is:
iso.3.6.1.2.1.99.1.1.1.6.100302213 = STRING: “mW”

Which maybe denotes the correct units for:
iso.3.6.1.2.1.99.1.1.1.4.100302213 = INTEGER: 4082

Hardware polled is: DCS-7280SR

Hi @ohai89
Seems that the mw2dbm function should be called on that device:

Please send me the resulting file of the commande below via direct message and I’ll check if I can find a way to call the conversion without breaking for other devices:
snmpbulkwalk -OUneb -v2c -c <COMMUNITY> <HOSTNAME> . > aristadbm.snmprec

I’m having this same problem I’m pretty sure. All of my graphs look like this for all of my Arista shelves.

Hi @cartel
Do you use Docker method as well ?

Paraphrasing from DM’s:

Sent snmp output to @PipoCanaja , who then checked it.
In the check the dBm conversion happens, so we currently don’t know why it doesn’t work when run from LibreNMS

Yes, I do. It worked fine in a VM installation (no Docker). Which was running Debian.

Another note, when I poll the device manually it shows the correct values until the dispatcher runs. Once it runs, the values go back to what they were. Not sure if that helps but I just wanted to mention it.

I can also replicate this.

lnms device:poll 1.2.3.4 -m sensors -vv

-3.11 dBm
RRD[update /data/rrd/1.2.3.4/sensor-dbm-entity-sensor-100301212.rrd N:-3.11]
SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [-3.11,4887,"dbm",161] 1.61ms]

-7.042 dBm
RRD[update /data/rrd/1.2.3.4/sensor-dbm-entity-sensor-100301213.rrd N:-7.042]
SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [-7.042,1981,"dbm",162] 0.85ms]

-2.857 dBm
RRD[update /data/rrd/1.2.3.4/sensor-dbm-entity-sensor-100302212.rrd N:-2.857]
SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [-2.857,5180,"dbm",166] 0.89ms]

-3.868 dBm
RRD[update /data/rrd/1.2.3.4/sensor-dbm-entity-sensor-100302213.rrd N:-3.868]
SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [-3.868,4099,"dbm",167] 1.08ms]

In here the values get calculated correctly, and are even updated in the device graphs to match.
Then (presumably) dispatcher runs and values turn incorrect again.

This is after I run the poller manually.

This is after the dispatcher runs.

If you need any more information please let me know. I’ll be happy to help. There was a bug fix they had for the non-docker install of Librenms that had to do with Arista light levels. I compared the fix to the code on the docker install and it’s the same.

Any updates on this?

Returning to this.

I ran poller (lnms device:poll 1 -m sensors -vvv)
and discovery (lnms poller:discovery 1 -m sensors -vvv)
manually and observed the following:

Discovery makes no attempt to (at least visibly) calculate the dBm, whereas poller does:

Discover sensor: .1.3.6.1.2.1.99.1.1.1.4.100301212, 100301212, entity-sensor, DOM TX Power  For Ethernet1, snmp, 1, 1, 100301212, -2.8, (limits: LL: -9.5, LW: -9, W: 2, H: 2.5), rrd_type = GAUGE  
SQL[SELECT COUNT(sensor_id) FROM `sensors` WHERE `poller_type`= ? AND `sensor_class` = ? AND `device_id` = ? AND sensor_type = ? AND `sensor_index` = ? ["snmp","dbm",1,"entity-sensor","100301212"] 1.24ms] 
  
SQL[SELECT * FROM `sensors` WHERE `sensor_class` = ? AND `device_id` = ? AND `sensor_type` = ? AND `sensor_index` = ? ["dbm",1,"entity-sensor","100301212"] 1.26ms] 

<cut for brevity>
>> Runtime for discovery module 'sensors': 2.8180 seconds with 1284296 bytes
>> SNMP: [8/2.09s] MySQL: [418/4.85s] RRD: [0/0.00s]  
#### Unload disco module sensors ####

SQL[update `devices` set `last_discovered_timetaken` = ?, `last_discovered` = NOW() where `device_id` = ? [3.946,1] 1.21ms] 
  
Discovered in 3.946 seconds

Poller output:

-2.816 dBm
RRD[update /data/rrd/1.2.3.4/sensor-dbm-entity-sensor-100301212.rrd N:-2.816]  
RRDtool Output: OK u:0.01 s:0.00 r:1.47
SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [-2.816,-2.819,"dbm",38] 2.23ms] 

Mind, the same -2.8 is also seen in the discover output, but it isn’t actually updated to the device in LibreNMS as discovery sets the incorrect values for dBm.

Maybe this would aid in pinpointing the issue?
I’m happy to share more details as needed.

If you run lnms device:poll in the dispatcher container without specifying the module sensors the incorrect values come up again, if you do the same in the app container (librenms) it seems to be fine. So it seems there is something different when running with and without specifying the module in the dispatcher container only.

EDIT: Actually I now cannot reproduce this and I’m getting the correct values consistently. Will test again once I see the incorrect values come up again.

EDIT2: I randomly got an incorrect reading while manually running lnms device:poll specifying module sensors on the app container. Comparing the logs between the runs with incorrect and correct values there is no difference other than the dBm value. Please see below.

Log for incorrect value

SQL[SELECT * FROM `sensors` WHERE `sensor_class` = ? AND `device_id` = ? ["dbm",300] 0.66ms]

SNMP['/usr/bin/snmpget' '-v2c' '-c' 'COMMUNITY' '-OUQntea' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/arista' 'udp:HOSTNAME:161' '.1.3.6.1.2.1.99.1.1.1.4.100349212' '.1.3.6.1.2.1.99.1.1.1.4.100349213' '.1.3.6.1.2.1.99.1.1.1.4.100350212' '.1.3.6.1.2.1.99.1.1.1.4.100350213' '.1.3.6.1.2.1.99.1.1.1.4.100351212' '.1.3.6.1.2.1.99.1.1.1.4.100351213' '.1.3.6.1.2.1.99.1.1.1.4.100352212' '.1.3.6.1.2.1.99.1.1.1.4.100352213']
.*.*.*349212 = 6739
.*.*.*349213 = 7501
.*.*.*350212 = -1000000000
.*.*.*350213 = 1
.*.*.*351212 = 6696
.*.*.*351213 = 6503
.*.*.*352212 = 7140
.*.*.*352213 = 6651

Checking (snmp) dbm DOM TX Power  For Ethernet49...
Checking (snmp) dbm DOM RX Power  For Ethernet49...
Checking (snmp) dbm DOM TX Power  For Ethernet50...
Checking (snmp) dbm DOM RX Power  For Ethernet50...
Checking (snmp) dbm DOM TX Power  For Ethernet51...
Checking (snmp) dbm DOM RX Power  For Ethernet51...
Checking (snmp) dbm DOM TX Power  For Ethernet52...
Checking (snmp) dbm DOM RX Power  For Ethernet52...
6739 dBm
RRD[last al01.cbc/sensor-dbm-entity-sensor-100349212.rrd  --daemon rrdcached.:42217]
RRD[update al01.cbc/sensor-dbm-entity-sensor-100349212.rrd N:6739 --daemon rrdcached.:42217]
Alerting for al01.cbc DOM TX Power  For Ethernet49
SQL[insert into `eventlog` (`reference`, `type`, `datetime`, `severity`, `message`, `username`, `device_id`) values (?, ?, ?, ?, ?, ?, ?) [84911,"dbm","2024-09-23 07:43:32",4,"Dbm above threshold: 6739 dBm (> 2.5 dBm)","",300] 1.1ms]

SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [6739,-1.704,"dbm",84911] 1.19ms]

Log for correct value

SQL[SELECT * FROM `sensors` WHERE `sensor_class` = ? AND `device_id` = ? ["dbm",300] 0.68ms]

SNMP['/usr/bin/snmpget' '-v2c' '-c' 'COMMUNITY' '-OUQntea' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/arista' 'udp:HOSTNAME:161' '.1.3.6.1.2.1.99.1.1.1.4.100349212' '.1.3.6.1.2.1.99.1.1.1.4.100349213' '.1.3.6.1.2.1.99.1.1.1.4.100350212' '.1.3.6.1.2.1.99.1.1.1.4.100350213' '.1.3.6.1.2.1.99.1.1.1.4.100351212' '.1.3.6.1.2.1.99.1.1.1.4.100351213' '.1.3.6.1.2.1.99.1.1.1.4.100352212' '.1.3.6.1.2.1.99.1.1.1.4.100352213']
.*.*.*349212 = 6739
.*.*.*349213 = 7490
.*.*.*350212 = -1000000000
.*.*.*350213 = 1
.*.*.*351212 = 6681
.*.*.*351213 = 6550
.*.*.*352212 = 7140
.*.*.*352213 = 6624

Checking (snmp) dbm DOM TX Power  For Ethernet49...
Checking (snmp) dbm DOM RX Power  For Ethernet49...
Checking (snmp) dbm DOM TX Power  For Ethernet50...
Checking (snmp) dbm DOM RX Power  For Ethernet50...
Checking (snmp) dbm DOM TX Power  For Ethernet51...
Checking (snmp) dbm DOM RX Power  For Ethernet51...
Checking (snmp) dbm DOM TX Power  For Ethernet52...
Checking (snmp) dbm DOM RX Power  For Ethernet52...
-1.714 dBm
RRD[last al01.cbc/sensor-dbm-entity-sensor-100349212.rrd  --daemon rrdcached.:42217]
RRD[update al01.cbc/sensor-dbm-entity-sensor-100349212.rrd N:-1.714 --daemon rrdcached.:42217]
SQL[UPDATE `sensors` set `sensor_current`=?,`sensor_prev`=?,`lastupdate`=NOW() WHERE `sensor_class` = ? AND `sensor_id` = ? [-1.714,-1.704,"dbm",84911] 1.23ms]

Okay I have managed to figure this out and fix it.

Tagging @PipoCanaja as he seems to be across this issue.

The parameters in the file_exists and require calls in includes/polling/functions.inc.php are not prepended with Config::get(‘install_dir’). I presume this causes an issue in the Docker dispatcher container as the cwd is different (in my environment it’s /run/s6/services/dispatcher) and so the file_exists returns false and so the custom conversion for Arista doesn’t get applied.

Do you need me to submit a PR?

@zippanto since you have a fix, I’d submit that in a PR.

1 Like

Applied the PR manually into librenms_dispatcher, it fixes the issue as advertised.

Now waiting for it to get merged :slight_smile:

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.