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?