Ubuntu 12.04 x64, Zabbix from official repo

Could you please describe how exactly older devices fail to respond properly to bulk requests? Does the failure manifest itself in exactly the same way as ZBX-8145?

In my case - only one (seems to be random) OID is returned to zabbix (according to traffic in wireshark), all over returned as "noSuchInstance". But I can get them one-by-one via snmpwalk. Yes, it' very similar to 8145, seems to be duplicate, sorry.

Thank you for the quick response! For completeness, could you please post a *.pcap file with a tcpdump of Zabbix to device communication so that we can see raw packets?

Sorry, I cannot post raw packets due security, but here is screenshots of request and responce:

request

responce

Of course, it's device problem - but previous versions of Zabbix, without bulk requests, was fine with this device. A possibility to choice method of request will be the best solution, I think...

It is interesting to note that in the screenshots above not only the device answers with one value out of five, but it also replaces the first variable with another.

Yes. It's seems to be device have really buggy SNMP implementation in bulk part, but.. older version of zabbix and snmpwalk works fine

I shall quote myself from https://www.zabbix.com/forum/showthread.php?t=45200 to describe the reason we do not have a solution for this yet:

Zabbix is under no obligation to support such [non-conformant] devices, but it may provide a workaround. Currently, we see two options: (a) improve the AI to detect such cases and (b) provide a way to disable SNMP bulk for each interface. For (a), we need to understand how widespread such behavior is to warrant a workaround in Zabbix. It might be that a better solution would be to write to SNMP authors on this device to make it standard-conformant. For (b), we can only do this in 2.4 (which is feature complete already, so probably 2.6), because it requires database changes and database changes can only be done in major versions. Introducing a global configuration parameter for disabling SNMP bulk is not an option, because it would disable SNMP bulk globally, even for devices that are OK with it.

Personally, I am not in favor of (a), because we would need to create a (potentially vast) collection of workarounds for every possible way that a device would fail to conform to SNMP standard.

Option (b), as noted above, is possible in 2.6 the nearest.

Maybe there is an SNMP proxy that would split bulk requests to single requests? Something similar is described at http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#Proxy_agents , where it says that "GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent", but it is not the same.

So the only viable solution actually is to stick to 2.2.2 until 2.6 is out?

Well...

Is it safe to downgrade to 2.2.2 in deb-based systems? Database, configs etc..?

It seems that I scared a lot of people.

If we do not find any other solution, we will of course implement workarounds in Zabbix 2.2.4 until a better solution is possible.

Ray, you only posted one request-response sequence. Could you please check whether it is safe to rely on the fact that the first variable in the response packets is not sensible?

Cristian, what case do you have? Does your device also fail to conform to SNMP standard? If so, then how does it manifest?

Aleksandrs, this device is always set Object Name to 0.0.0 in response. It's looks like this:

1) zabbix trying to get multiple values
2) device answers with single 0.0.0 answer (but with correct value) and other "noSuchInstance"
3) zabbix continues to request this single value until next attempt to retrive multiple values
4) device answer with single 0.0.0 (usually other, then previuos OID) etc..

like this

Thank you for the info, Ray! What is the name of this device?

MERA MVTS 3G, VoIP softswitch.

Aleksandrs, all the details about my environment are on ZBX-8096. But I'm not sure if me and the op are facing the same problem

Ty

I have the same problem with the Mikrotik devices after upgrading to 2.2.3.

In zabbix server logs a lot of errors like this:
31634:20140509:201018.068 item [smr-rb750g-n2:.1.3.6.1.2.1.2.2.1.8.["6"]] became supported
31645:20140509:202012.338 item [smr-rb750g-n2:.1.3.6.1.2.1.2.2.1.8.["6"]] became not supported: SNMP error: (noSuchName) There is no such variable name in this MIB.

Rascal, could you please check the traffic to determine whether your MikroTik device behaves the same as Cristian's "patton2291" device in ZBX-8096?

about mikrotik monitoring:

I've created a Template with SNMP LLD for ALL network interfaces.
It is supposed to get standard values as in image (and create graphs based on LLD):
http://i.imgur.com/JwT9VRG.png

Working as expected since 2.0.1 (first time I set up this template).
After I upgraded to v 2.2.3 it started to loose data and my graphs have holes like this:
http://i.imgur.com/Taojsoe.png

red = while running zabbix-server 2.2.3
green = after rollback to zabbix-server 2.2.2 (today)

I cannot debug CPU usage while those holes appear while using zabbix 2.2.3, because I cannot (obviously) get data via SNMP, and I don't have direct access to the router, [B]BUT[/B] in the past I had problems with IPSec VPN on Mikrotik routers and cipher, caused by CPU usage, so reading posts about SNMP bulk in zabbix 2.2.3 I supposed this feature is stressing CPU too much to get all the data.

Any problem has been detected after rolling back to simple SNMP get as per version 2.2.2 .

Sergio, your issue looks similar to ZBX-8191. Could you please post some tcpdump of the packets between Zabbix and MikroTik?

In Zabbix 2.4, which is soon to be released, we shall try to provide a way to enable and disable SNMP bulk for each interface. Please follow progress in ZBXNEXT-2301.

I see update to 2.2.4, but this feature is still broken.... Progress in 2301 is not showing anything about solution. So-called auto-detection (1, 2, 3, 4, 6, 9, 13, 19, 28 etc requests) is not working in practice, because it's checking ability to get bulk, but problem devices just reports, that they are no more have such OID's. I think, that's a reason of autodetection failures. All the same behaviour, as described above.