Devices may experience constant reindexing #2380
In the update_reindex_cache function within lib/poller.php if the reindex method is Index Count we get the number of indexes from a query against host_snmp_cache but the logic is slightly flawed, at least for some devices I have.
Now this query returns more values than <oid_num_indexes> or by an snmpwalk for indexes.
All 33, but using the function it gets 34.
MariaDB [cacti]> select snmp_index from host_snmp_cache where host_id=6961 AND snmp_query_id=1 group by snmp_index;
If I add a bit more info, the cause can be seen, we are getting an index for an ifIP entry as well
MariaDB [cacti]> select snmp_index, field_name from host_snmp_cache where host_id=6961 AND snmp_query_id=1 group by snmp_index;
Suggested fix is to tweak the query to use the sort_field from host_snmp_query as well? Might not be the most elegant solution, I'm sure someone could come up with something better.
MariaDB [cacti]> select snmp_index from host_snmp_cache WHERE host_id=6961 AND snmp_query_id=1 and field_name=(SELECT sort_field from host_snmp_query where host_id=6961 and snmp_query_id=1) group by snmp_index;
Correct values now returned.
The text was updated successfully, but these errors were encountered:
This gives exactly the same result as earlier.
MariaDB [cacti]> select distinct snmp_index from host_snmp_cache where host_id=6961 and snmp_query_id=1 and snmp_index != "";
It still has an snmp_index value for ifIP query so it's still 34 instead of 33.
Well, there is another problem then, you should not be getting an IP address returned for an index that does not exist. Do a verbose query of the device. If you can post the output here. You can copy the entire verbose query contents by clicking the copy link at the top of the verbose query output. Obfuscate as you feel appropriate.
Full output is pasted below, but to summarise, it returns an ifIP entry for 127.0.0.1 with an index of 128. It doesn't spit out that index in a walk for anything else such as ifIndex as it's "not interesting", but does respond if you directly query the snmp_index.
I'd say this is probably because it's an old outdated switch so might not happen for many people. I'm just lucky that way.
Okay, we've established a few things here:
Can you open a ticket with them and try to get them to fix their snmp agent? If not, I guess we can introduce a new feature to cleans bad data. It would be very subjective though.
Let us know what you find. We will keep this open. Preserve your workaround for now.