Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change multi-SNMP profile behavior to allow write-enabled profiles also for reading when nothing else is available #2735

Closed
Tracked by #1177
lunkwill42 opened this issue Nov 13, 2023 · 0 comments · Fixed by #2751
Labels
CNaaS Related to the CNaaS activity enhancement snmpv3

Comments

@lunkwill42
Copy link
Member

lunkwill42 commented Nov 13, 2023

Is your feature request related to a problem? Please describe.

As discussed internally with our network engineering team while updating PortAdmin to support SNMPv3 profiles:

PortAdmin's SNMPHandler will use read access SNMP profiles for reading data from switches, and will only every use write-enabled profiles for actual SNMP SET operations.

I believe the original intent may have been to send as few non-private SNMP PDUs containing write community strings in them as possible.

However:

The most common convention is to have one read-only community and read-write community. The write profile will, under normal circumstances, also provide read access to the device, which means that it isn't strictly necessary to switch between two separate profiles to accomplish PortAdmin functionality.

When setting up an SNMPv3 profile, one needs to add a lot more details than a community string. Since communication can be private under SNMPv3, it makes even more sense to want to have a single profile for both read and write operations. With the current state of the SNMPv3 implementation, having an SNMPv3 user with write access still means that you need to add two identical SNMPv3 profiles for read and write, and just checking the "write" button on one of them. This is tedious.

The behavior is mostly caused by Netbox.get_preferred_snmp_management_profile(), which takes a an optional writeable parameter. If set to false, only read-only profiles will be returned. If set to True, only writable profiles will be returned. If omitted, all SNMP profiles are considered.

Describe the solution you'd like

When a device only has a read-write SNMP profile and no read-only profiles, PortAdmin should still be able to utilize the read-write profile for read operations.

I'm thinking the best approach here would be to change the signature and implementation of Netbox.get_preferred_snmp_management_profile(): A require_write=True should always return a write profile, while a require_write=False should return any profile, but prefer a read-only profiles if multiple exist.

Describe alternatives you've considered

Adding a clone button to the SeedDB management profile section to easily duplicate existing profiles to add a read-write version of a profile?

@lunkwill42 lunkwill42 added CNaaS Related to the CNaaS activity snmpv3 enhancement and removed CNaaS Related to the CNaaS activity labels Nov 13, 2023
@lunkwill42 lunkwill42 changed the title Change PortAdmin behavior to use write-enabled profiles also for reading Change multi-SNMP profile behavior to allow write-enabled profiles also for reading when nothing else is available Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CNaaS Related to the CNaaS activity enhancement snmpv3
Projects
None yet
1 participant