Suppose we have the following SNMP item with dynamic index:

ifInOctets["index","ifDescr","GigabitEthernet0/1"]

What a poller does when it encounters this item for the first time, is it walks "ifDescr" tree, remembering at which index each value resides. In this case, suppose "GigabitEthernet0/1" resides at index 5, so it remembers that and returns the value of "ifInOctets.5" as the value of the item.

When it encounters this item for the second time, the poller queries the cache and gets 5 as the index for "GigabitEthernet0/1", asks the device for "ifDescr.5" to see whether cache entry is still valid. If it is, it proceeds with "ifInOctets.5". Otherwise, it rebuilds the cache as described above.

The problem is that this caching is done using (hostid, port, OID, value) tuples. In the case above, it will cache 5 for key (hostid, port, "ifDescr", "GigabitEthernet0/1"). Usually this works OK, but breaks when a host has multiple interfaces with the same port, but different IP addresses, as we have seen people use in practice.

In Zabbix 2.0, we introduced multiple interfaces per host, but, apparently, the way this cache works was not updated.

The practical implication is significantly increased CPU usage, because on a large number of occasions the cache has to be rebuilt.