SNMP v3 Issues

[Viks]

I once again read your log file and I did not like the following phrase:
the host "-PP" failed

Hostname "-PP"?

It looks like you have some sort of incorrect configuration.

Maybe you have DNS issues?

I recommend in the Zabbix Gui hosts configurating directly IP instead of DNS at SNMP interfaces.

I have a lot of different equipment, software that is monitored through SNMP v3 and also Authpriv - AES / SHA, everything works great.

I've seen all kinds of device side bugs when the authorization suddenly does not work after 5 minutes since the monitoring was started, when on the device side there is a buffer overflow or out of memory,
for example, with one of the 10 identical servers on the DELL iDRAC, after the BIOS / iDRAC, etc updates were applied, everything was resolved.

Other times, if the equipment has a particular bug'y SNMP or has a low memory, but SNMP data is too large at one time, it helps to change and disable the "Use bulk requests".

For me practically for all Switches "Use bulk requests" is turned on.

[steveroebuck]

We do connect to all SNMP hosts via IP we just use the name to identify the host in Zabbix.

We are running the entire Zabbix suite in Docker I beginning to wonder if that could be the cause of some of our issues.

Everything from this end is as high level firmware as we are comfortable going on our platform.

Would it be possible to have a look at your proxy configuration file, just to see if we are missing anything obvious in ours that could be causing the SNMP requests to fail/timeout etc.

[Viks]

> I recommend in the Zabbix Gui hosts configurating directly IP instead of DNS at SNMP interfaces.
IP vs DNS - I mean the option at the interface configuration in Zabbix host GUI....


It seems that something is wrong for you, Docker may interfere.

I highly recommend finding and fixing it why are there things in log files:
--> the host " -PP" failed <--
it looks like cut off parameters after space.
I would not want to see things like that in my Productions.

What I can say about my configs, I have the following values which might interest you:
GUI/Administration/General/Other configuration parameters:
"Refresh unsupported items" : 1m

proxy/server conf
UnavailableDelay=15
UnreachableDelay=20
UnreachablePeriod=20

agent/proxy/server conf
Timeout=30

But I have its own specifics, with long distances remote multiple datacenters,
with Zabbix remote commands between Europe and Asia and other continents,
so my values may differ from others, but in essence, nothing special,
because with SNMP and other devices, servers etc locally work Zabbix Proxy Cluster over a LAN network on the site.

[steveroebuck]

Thanks Viks, we do add via IP in the GUI so its not a DNS issue.

I am just adjusting our proxy config to similar to yours, I have noticed that once I get above 4 devices the CPU usage on the docker container starts to spike about 100% quite often I wonder If our hosts are not sufficiently powerful enough to process the extra traffic.

[DoubleP]

We are having the same issue. one poller, snmpv3 works like a champ. We run single device through one proxy. We are running net-snmp 5.7.2, Zabbix 4.0.0-80449. Also, we test running a single host through a dedicated proxy. ie, one host on the proxy. resulting in same, one poller configured, works great, multiple pollers configured and we experience gapping.
Error messages:
20198:20180702:101306.047 zbx_snmp_get_values() snmp_synch_response() status:1 s_snmp_errno:-35 errstat:-1 mapping_num:34
20198:20180702:101306.047 End of zbx_snmp_get_values():NOTSUPPORTED
20198:20180702:101306.047 End of zbx_snmp_process_standard():NOTSUPPORTED
20198:20180702:101306.047 In zbx_snmp_close_session()
20198:20180702:101306.047 End of zbx_snmp_close_session()
20198:20180702:101306.047 getting SNMP values failed: Cannot connect to "10.72.193.11:161": Authentication failure (incorrect password, community or key).
20198:20180702:101306.047 End of get_values_snmp()

*note* authentication and other snmp parameters are unchanged and will work 20 minutes later with no changes made.

[kloczek]

Authentication failure (incorrect password, community or key).

In this case all what is necessary is in this log line.
Try to confirm using snmpget/snmpwalk commands that you are using correct password.

[sfl]

Same issue here with zbx 3.4.11 and proxy.

Snmpwalk runs like a charm but debug log in zbx showing incorrect password or community string for sometimes like @DoubleP

Envoyé de mon SM-G950F en utilisant Tapatalk

[minfrin]

Was suffering a similar problem with collectd-snmp and some Routerboards.

Only one device would respond, while all other devices returned an authentication error as you describe above.

The fix in my case was to manually set the SNMPv3 engine-id on each routerboard to a unique string, instead of relying on default behaviour. The moment I did that, everything started working - all hosts starting returning data instead of just one.

In this case net-snmp (and I'm assuming zabbix depends on either net-snmp or collectd or both) cannot tell which engine-id goes with which router/host, and so uses one engine-id for all hosts.. This means one host works, all others do not.

[afifield]

For me, this was explicitly caused by a corruption in a Template export/import between environments. One Item Prototype had not imported with the correct AuthProto and PrivProto values. Once LLD occurred, there were multiple credential sets for the one EngineID, causing a corruption in the cache that passes credentials to the SNMP layer. This resulted in intermittent failure (about 70%) with credential errors.
Quite time consuming to fix (once the Template was fixed), and required multiple Proxy restarts and forcing LLD (check now) across 6 Hosts in-between restarts. I guess I could have waited for that component of the cache to expire, but I was getting impatient.

If the SNMP credential cache enforced uniqueness on SNMP EngineID, this could possibly be avoided, but would probably require some validation on successful SNMP auth/response before caching.

[londi]

Was suffering a similar problem with collectd-snmp and some Routerboards.

Only one device would respond, while all other devices returned an authentication error as you describe above.

The fix in my case was to manually set the SNMPv3 engine-id on each routerboard to a unique string, instead of relying on default behaviour. The moment I did that, everything started working - all hosts starting returning data instead of just one.

In this case net-snmp (and I'm assuming zabbix depends on either net-snmp or collectd or both) cannot tell which engine-id goes with which router/host, and so uses one engine-id for all hosts.. This means one host works, all others do not.

I can confirm that the problem can be resolved by manually setting the engine-id as suggested in this post, it does not matter what it is, just needs to be unique I guess.
Snmpwalk from command line works without it, tcpdump shows the packets being send and recived by zabbix server - first packet with GetRequests gets an answer, then zabbix server sends second packet with security name and this also gets an answer - but after that zabbix goes quiet and nothing happens, host gets red SNMP flag - so this issue must be related to how zabbix works with snmpv3.

[bonethugs]

What do you mean to "manuall setting the engine-id".. change it in the device to be unique or change in the zabbix host to be unique?

[cyber]

What do you mean to "manuall setting the engine-id".. change it in the device to be unique or change in the zabbix host to be unique?

engine-id in device has to be unique.
In Zabbix host config you do not have engine-id ...

[bonethugs]

in zabbix documentation says that engineid should be put in "context name" field of the host configuration. Do you leave that field empty or do you put the engineid there?

[cyber]

in zabbix documentation says that engineid should be put in "context name" field of the host configuration. Do you leave that field empty or do you put the engineid there?

Can you point to that statement?

I can find from here https://www.zabbix.com/documentation...es/snmp#step-2

Context name	Enter context name to identify item on SNMP subnet. Context name is supported for SNMPv3 items since Zabbix 2.2. User macros are resolved in this field.

Does not say a thing about engine-.id...

Mention of engine-id-s is here https://www.zabbix.com/documentation...nmp-monitoring
and says in red that

If monitoring SNMPv3 devices, make sure that msgAuthoritativeEngineID (also known as snmpEngineID or "Engine ID") is never shared by two devices. According to RFC 2571 (section 3.1.1.1) it must be unique for each device.

[bonethugs]

uuuhmmm, not sure but I think I read it somewhere.... anyway, in my case I can't see any duplicated engineID in our environment and snmpv3 is not working with more than 2 snmpv3 devices...

we have about 400 devices monitored in snmpv2 but only 7 in snmpv3 with AES/SHA cyphers, does we need to check engineID even for snmpv2 devices or that "issue" only affect devices with snmpv3?