You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we're able to use snmp contexts as part of the auths definition in snmp.yml which makes it quite hard to use them, especially whe you use one snmp context per vrf (for example). As the context is not security sensitive, we should allow to pass in the context via a url param
for example: /snmp?target=10.11.12.13&auth=mystrongauth&module=snmp_inventory&snmp_context=vrf-mgmt
The text was updated successfully, but these errors were encountered:
I think we talked about this in a previous issue. (of course I can't find that right now) I think you're right about contextName being not sensitive. I'm slightly confused by the RFC since it's talking about a requirement for a contextEngineID as part of the request. The contextEngineID is considered security sensitive.
If the param is not sensitive, it should be named context_name to match the config file format.
SNMP Context exists with snmpv3 and is often used to group various management informations together. (details can be found here: https://datatracker.ietf.org/doc/html/rfc5343#section-2)
Currently we're able to use snmp contexts as part of the
auths
definition in snmp.yml which makes it quite hard to use them, especially whe you use one snmp context per vrf (for example). As the context is not security sensitive, we should allow to pass in the context via a url paramfor example:
/snmp?target=10.11.12.13&auth=mystrongauth&module=snmp_inventory&snmp_context=vrf-mgmt
The text was updated successfully, but these errors were encountered: