NetXMS Support Forum

Hello,
recently we noticed this occuring more and more. Without any human intervention some nodes change their SNMP version from v2c to v1.
Unfortunately that breaks most of the data collection, since i suppose some of the OIDs, or maybe 64-bit counters, are not supported over v1.

My question is - are there any normal circumstances where this change is expected to occur or that sounds like a bug?

I've seen some devices that it is easy to reproduce - every configuration poll changes v2c to v1, even though polling over v2c works fine.

For others the issue is not reproducible, but anyways we find them at some point changed to v1.

Thanks in advance!
Regards,

I see weird things like this as well.

I have windows devices discovered and set to v1 even though all windows devices have been 2c supported since 2000

https://docs.microsoft.com/en-us/windows/desktop/snmp/supported-versions

It gets tricky when considering traps. NetXMS assumes V2c and takes out the first varbinds as time as per v2c - but if a trap is v1 - first varbinds is now inaccessible if mapping by position.

As to your original question, when would you back version from 2c to 1 automatically? - other than receiving a v1 trap and deciding that the device must be v1 (incorrect assumption), I cannot imagine when this would occur. If a V1 trap was received and you have enable discovery from traps, then NetXMS "might" treat that as a new device and then merge it with your existing device - changing v2c back to v1.

I have a W2K16 server that NetXMS decided was V1. No idea why - no trap ever received - just weird.

Traps will state which version SNMP they are sent in, but that is not the same as what version you are expecting snmp get to be responded with.

http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat.htm
http://www.tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats-3.htm

As to why v2 is v2 and not v2c:
http://www.tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats.htm

So, in a nutshell - the version as seen in the snmp Version in the Capabilities I expect should not change - but there is no setting such as "allowdynamicsnmpverchange" which appears to be set to yes - allowing the version to be changed dynamically.

I did test doing a configuration poll based on manually setting v1 and then v2c and back to v1  - configuration polling did not change the version - it happily polled and returned SNMP active and the version it used - so it is not that. Configuration poll(Full) also did not change version.

I recall seeing that a while ago and opening a bug report for it: https://track.radensolutions.com/issue/NX-1502
While the issue is marked as resolved as a feature was added to prevent automatic SNMP version changes during configuration polls, Victor's comment might shed some light as to when this change can happen. Basically, if the device doesn't respond to an SNMPv2 request, it'll try SNMPv1. I guess if the device is slow in responding (Lenovo/IBM Integrated Management Modules come to mind), it might switch back to v1 simply because the device doesn't respond to the v2c request in time. Increasing the default SNMP timeout might work around that?

I had a look at that "fix" and noticed the setting I had mentioned "allow version change" was implemented with that fix - but it is not part of the default settings.

If anybody knows how "prevent automatic SNMP configuration changes" was implemented, this might be enough just to set that to yes, increase the timeout, and just move on

Hi,

there is an option in node communication settings called "Prevent automatic SNMP configuration changes".

Best regards,
Victor

OK - I can see that setting - which is off by default. Can we have this added as a server default setting - enabled or disabled by default at initial discovery (node addition).

I have 4322 devices so doing this one-by-one is off the table. I assume this is about 3 or 4 lines of script to update all to have this ticked?

+1 Vote for global server setting