Use SNMPv3 contexts for collecting logical BRIDGE-MIB instances (primarily Cisco)#3668
Conversation
e870583 to
0feea79
Compare
0feea79 to
6c555bb
Compare
|
Test results 21 files 21 suites 24m 26s ⏱️ Results for commit bf6cf88. ♻️ This comment has been updated with latest results. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3668 +/- ##
==========================================
+ Coverage 63.04% 63.16% +0.11%
==========================================
Files 614 615 +1
Lines 45438 45484 +46
Branches 43 43
==========================================
+ Hits 28648 28728 +80
+ Misses 16780 16746 -34
Partials 10 10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Henceforth, a logical MIB instance identifier may also include an optional SNMPv3 context name, and an optional context engine ID, if such things were discovered. Since a community value makes no sense for SNMPv3 communication, the community field should also be optional.
Some code still expected a BRIDGE-MIB instance descriptor to be a two-tuple value, but should really produce LogicalMibInstance named tuples.
We need to fetch context name and context engine ID values from logical MIB instances to know how to configure our SNMPv3 requests to fetch these logical instances.
In order to support SNMPv3 contexts, this adds `context_name` and `context_engine_id` as optional attributes on SNMPParameters objects, and ensures the correct Net-SNMP command line arguments are generated for them.
Making alternate agent proxy instances need to consider which SNMP version is represented, as changing the community makes no sense on SNMPv3 sessions, while changing context name (and optionally adding a context engine id) does. It's also easier and more portable to manipulate parameters selectively by modifying the `snmp_parameters` of the existing session: That way, all other parameters of the session are carried through to the alternate agent proxies.
Only care about debug logging that we got results from alternate agent proxies, as timeouts would be silently ignored.
6c555bb to
35ff230
Compare
Some tests broke from the introduction of the new namedtuple
Adds test coverage for functionality added or changed in this branch.
Also noticed there was no mention of SNMPv3 profiles in management profiles docs, so this was a suitable place to add and mention potential issues.
This code was changed enough by this branch that it provoked coverage complaints from CodeCov.
python/nav/ipdevpoll/utils.py
Outdated
| # | ||
| """Utility functions for ipdevpoll.""" | ||
|
|
||
| from __future__ import annotations |
There was a problem hiding this comment.
This __future__ import will be removed (add link)
| community = self.agent_proxy.community | ||
| return [("vlan%s" % vlan, "%s@%s" % (community, vlan)) for vlan in vlans] | ||
| return [ | ||
| LogicalMibInstance(f"vlan{vlan}", f"{community}@{vlan}") for vlan in vlans |
There was a problem hiding this comment.
Agreed this is a good idea, but I will be adding it as a separate refactoring PR
|
I might add that although @hmpf did not actually push the approve-button, the team did approve this PR as is in an F2F review session yesterday. |
|



Scope and purpose
Fixes #2811. Dependent on #3664 (merged a long time ago by now)
I have been able to preliminarily verify this against actual Cisco switches now, but the need for configuring the proper context access for accessing VLAN contexts using SNMPv3 on a Cisco switch is not intuitive and may need a FAQ or some supporting documentation in NAV.
So, things still potentially missing from this PR:
vlan-prefix, as these are added dynamically by the switch. References used:Decide whether we need special handling of authentication failuresI think I recall seeing nasty errors on Cisco switches that were incorrectly configured, but currently, when simulating the issue, I am only able to see nondescript errors from pynetsnmp like[ERROR zen.pynetsnmp.callback] Unknown operation: 7, while for the multimib-implementation this seems to be handled just like a "no response" from that particular instance.Contributor Checklist
Every pull request should have this checklist filled out, no matter how small it is.
More information about contributing to NAV can be found in the
Hacker's guide to NAV.
<major>.<minor>.x). For a new feature or other additions, it should be based onmaster.If applicable: Created new issues if this PR does not fix the issue completely/there is further work to be doneIf it's not obvious from a linked issue, described how to interact with NAV in order for a reviewer to observe the effects of this change first-hand (commands, URLs, UI interactions)If this results in changes in the UI: Added screenshots of the before and after