We have some devices that require a specific context when using snmpv3. It would be very helpful to be able to provide a context to use for a device. Even better, if we could add a context for a device type or os (devices in power context get “aaaa” while devices with os procurve get “bbbb”)
I am running into the same issue. SNMPv3 for HP Color LaserJet MFP M477fdn, Color LaserJet Pro M478f-9f, and Color LaserJet M452dn have a hard-coded “Jetdirect” context.
1 Like
This would be a real improvment for us is this was implemented.
We have many Sharp MFD that have an embedded context that cannot be changed or removed.
Please consider adding this feature.
Here my use case would be with a proxy. Following net-snmp docs, the way to do the proxy is to have a context per device behind the proxy, thus the need to specify the context in LibreNMS
I also want to add HP printers using SNMPv3 and this requires setting a context.
FYI - Another user had proposed a fix for this a few years ago…
But this was rejected by the maintainers and apparently determined to not be important to fix.
Hi @polskikrol
This is not completely correct … It was rejected, yes, but because the proposed fix was not safe, as LibreNMS already makes use of context in current code. This makes this feature a little bit harder to implement than it was thought.
And of course, everybody is welcome to suggest a better fix.
I would very much like to see this as well. Specifically I would ask that an optional field be added to the Add Device SNMPv3 configuration screen to define the context on creation along and/or a new switch for lnms device:add. My desire for this stems from our use of Aruba-CX switches that when configured to use a context cannot be added but when configured to use a view can be added. As noted by others some devices cannot even be added due to using a hard-coded context. If it cannot be added to the Add Device screen then adding a configuration option via a field in the device settings SNMP tab would also work.
I would add this myself if I knew the files that this would need to be added to. My lack of in-depth PHP knowledge might break things but I would still try.
This would make my life much, much easier. This feature has been requested for years and years, but at this point, for whatever reason, but for some reason, they ignore/shut down any discussion regarding it. I am currently managing a campus network, and our distribution switches are Juniper, and they refuse to be polled if a context is not specified.
No one is shutting it down and we’d welcome a contribution from someone (yourself?) that adds the support in the correct way, that’s maintainable and works.
The main problem is there are conflicting uses of “context”.
Someone needs to come up with a way that we can satisfy both.
People often mention devices that have specific context strings hard coded, so forcing the user to know that they need to set that context for that device does not seem correct. Ideally, we would be able to use that context if those devices are detected automatically (for the specific MIBs that need the context)
(your mention of Juniper switches seems odd as I have access to some and do not use context in any way with them)
In our case, the behavior differs between access and distribution.
All access switches are in librenms because they are more or less single-table, management is in the default routing instance and there are no additional VRFs/IRBs that affect how we poll them. As a result, polling works without needing to deal with SNMP context/routing-instance semantics.
Our distribution switches (and edge routers) are different, multiple routing instances/VRFs and IRBs are in use, and from the librenms host the devices would not respond unless a routing-instance context was explicitly used (for example, SNMPv3 contextName like -n MANAGEMENT). But once you do that, junos scopes what you can see to that routing instance, so you do not get the full set of interfaces / L2 data you typically want for switch monitoring. Due to what was previously mentioned, v2 does not work either.
Note that some minor details might be wrong, as from the time of writing, my actual last attempt at trying to make it work was months ago.
For anyone reading this later: I eventually stopped trying to use librenms for our distribution switches and edge routers and moved those to Prometheus. I’m using a Juniper SSH based exporter/poller rather than the generic SNMP exporter, which has been faster & easier to deploy compared to the generic exporter. It has given me the the states and statistics state that we care about (LLDP neighbors, OSPF, BGP, general interface information etc etc.) without the SNMP context/VRF friction.
I would more than love to contribute, if I had the time, and or was able to work for a code solution during work hours.
The reason for writing “shut down”, is because (do not quote me on this), a faint memory where I on Github(?) read a developer call the need to specify contexts with something along the lines of “stupid”. But as I said, do not quote me on this, it was months ago I scrubbed the internet for a solution, and might’ve just got the contexts mixed up.
Honestly, it is a major project, because SNMP started coming apart at the wheels with context.
The lack of enforced standardization allowed flexibility to balloon into infinite configurations.
I feel like to implement context handling correctly, someone will need to study many different implementations. Figure out common trends AND importantly edge cases. Create a plan and figure out how to implement it. Then incrementally implement the plan.