Latest snmp cleanup might have affected polling of Lenovo enos network switches

Help
1

  • Description of issue
    It seems that when I did an update on Thursday 5/10/2023 0000 CEST, there were some updates that made my graph output of lenovo switches not show anything after the update. On closer inspection, it was found that snmp gathering and polling of these devices stopped functioning properly. The symptoms are similar to what’s reported here Graphs stopped. I’ve reverted the code back to the 23.9.1 release and everything works again. Note that it’s only the Lenovo switches that were affected, I’ve no issues with other branded switches like Mellanox on my network, their graphs show as normal. If it is required that I post screenshots of this, let me know.

  • The output of ./validate.php when the error occured

===========================================
Component | Version
--------- | -------
LibreNMS  | 23.9.1-44-g9fca018 (2023-10-05T10:32:21+02:00)
DB Schema | 2023_08_30_105156_add_applications_soft_deleted (259)
PHP       | 8.1.24
Python    | 3.6.8
Database  | MariaDB 10.11.5-MariaDB-1:10.11.5+maria~ubu2204
RRDTool   | 1.8.0
SNMP      | 5.7.2
===========================================

[OK]    Composer Version: 2.6.4
[OK]    Dependencies up-to-date.
[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 not detected
[OK]    Locks are functional
[OK]    Python poller wrapper is polling
[OK]    Redis is unavailable
[OK]    rrdtool version ok
[OK]    Connected to rrdcached
2

Can you tell me exactly which OS? Because it looks like one is defining multiple mib_dir and I can’t find which one it is.

3

It is Lenovo’s ENOS. It is likely due to some changes that were made in the last 2 weeks.

4

I don’t see a Lenovo ENOS os. Are you sure it isn’t a locally defined one?

If it is, mib_dir cannot be an array. There are validation rules to enforce that in the main tree, but not for any local modifications.

5

Apologies, you are right, it is a locally defined one. (Although Lenovo ENOS in itself does exist and it is indeed the OS of the switches I have)

That said, I’m still curious why it worked with the version 2 weeks ago and broke on this one. Perhaps some new rules were introduced, old ones removed and so on. And if so, is there a way or plans to help integrate hardware that are not predefined in Librenms inside? Like to generate the discovery yaml and so on.

I don’t think it is really a problem of having something local, it has always worked in previous versions of Librenms until now. I’m not pointing fingers, I’m sure there’s a reason for the changes in the last 2 weeks but if something new is introduced, perhaps there can be some documentation or thought to point to how locally defined stuff could work and eventually make it upstream?

6

The code expects mib_dir to be a string (not an array) so if it worked before it was unintended. LibreNMS project can only consider things that exist in the upstream repository.

Following the documentation will help you if you would like to send your change upstream:

Also, asking in Discord can help a lot.

If you want to fix your issue, update your local yaml file from:

mib_dir:
  - directoryone
  - directorytwo

to

mib_dir: directory
7

Thank you so much, I’ll try that out. And a good job you are doing with librenms there :).

1 Like
8

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