Skip to content

Conversation

@bminnix
Copy link
Contributor

@bminnix bminnix commented Nov 10, 2025

Adding a mapping for LibreNMS values to network_driver values for the initial values in use.

@@ -1,4 +1,5 @@
"""Dictionary object to store OUI information."""

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not be needed, and will likely get reverted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes to this file are coming from ruff rules. I was just following ruff --fix after I realized there was an issue called out by ruff.

@itdependsnetworks
Copy link
Contributor

Can you link source of this information for ease of future findings?

@bminnix
Copy link
Contributor Author

bminnix commented Nov 10, 2025

Can you link source of this information for ease of future findings?

I'm not sure the best way to go about doing this since there really isn't a great summarized source, suggestions welcomed.

In the current state this is all coming about as follows:

  1. The "constants.py" file is created with "os_manufacturer_map" and "manufacturer_os_map" (both manually created (by @bile0026) after inspecting the files/contents) with the intent to create those specific mappings. All values from the LibreNMS code/base are in this os/manufacturer mapping.

  2. The non-driver values being added to the LIBRENMS_LIB_MAPPING/REVERSE are ones coming in directly from the devices themselves and being used to map to/from the nautobot network drivers. I believe these device values obtained are all SNMP value based (and how LibreNMS is obtaining device data).

  3. The values in LIB_MAPPER dictionaries are just added after seeing the values that were provided by the devices, and any that throw "Manufacturer mapping not found for OS" get added to the mapping then.

We could go through and try to add a mapping entry for each of the os/manufacturer entries, but there really isn't any great source of info for future findings/requirements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants