what is the full oid for the value for "Front Top Blower" ?

1.3.6.1.4.1.2636.3.1.13.1.5.4.1.0.0

hmm, no, that's the description. what's the one for the value ?

1.3.6.1.4.1.263.3.1.13.1.7 + 4.1.0.0 = 1.3.6.1.4.1.263.3.1.13.1.7.4.1.0.0
which dynamic index should detect 4.1.0.0 as INDEX but now it detect only last 0 of 4.1.0.0 and add it to 1.3.6.1.4.1.263.3.1.13.1.7

ok, so the request is to detect & use a longer string as an index, not just the last number

if it use STRING for the values like 4.1.0.0, it should use a longer string as an index

Hi, I was wondering if this issue will be fixed by the next minor update for 1.8? It would be very helpful. As far as I am concerned, this is the only real issue I have with Zabbix after using it for a while. It would be great to have a fix for it!

Related issue: ZBX-4816

I've got the same problem here on Zabbix 1.8.10 server :
http://www.zabbix.com/forum/showthread.php?t=25850

Such cisco items has two indexes :
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cHsrpGrpStandbyState

I can't manage it with Zabbix : NOT SUPPORTED item too.

i don't know if this is normalized or not or if there should exist "triple dynamic indexes" too..!

Is it possible to develop this feature?

Thank you,
JC.

I've discovered another type of double indexes.

On Dell Equallogic, you can have one group of equallogic with multiple members (multiple boxes of storage).

In a two members group, for the following OID "This variable specifies controller battery status." , I've got two batteries by members :
.1.3.6.1.4.1.12740.4.1.1.1.5

Snmpwalk will report me things like it :

iso.3.6.1.4.1.12740.4.1.1.1.5.1.315444693.1 = INTEGER: 1
iso.3.6.1.4.1.12740.4.1.1.1.5.1.315444693.2 = INTEGER: 1
iso.3.6.1.4.1.12740.4.1.1.1.5.1.690330181.1 = INTEGER: 1
iso.3.6.1.4.1.12740.4.1.1.1.5.1.690330181.2 = INTEGER: 1

315444693 is the dynamic index of the member 1
315444693.1 represent its first battery
315444693.2 represent its second battery
690330181 is the dynamic index of the member 2
690330181.1 represent its first battery
...

We have the same case with disk status, with many more than two ( up to 48 disks by member I think, it depends of equallogic models).

I don't figure how to manage it with dynamic indexes too...

Can you add this in an extra features?

Thank you.

I have attached a simple patch for Zabbix 2.0.2 (running without any issue on my production environment).

Why this issue is still unassigned? It's a major bug in the discovery proces!

I have the same issue with Cisco ASes: E1 ports has base OID CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s (.1.3.6.1.4.1.9.10.19.1.1.9.1.3) and the ".slot.port", so there is two-part index:

$ snmpwalk -c … -v2c … CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.0 = Gauge32: 9
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.1 = Gauge32: 7
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.2 = Gauge32: 12
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.3 = Gauge32: 15
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.4 = Gauge32: 5
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.5 = Gauge32: 8
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.6 = Gauge32: 14
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.7 = Gauge32: 3
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.0 = Gauge32: 8
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.1 = Gauge32: 7
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.2 = Gauge32: 12
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.3 = Gauge32: 8
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.4 = Gauge32: 7
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.5 = Gauge32: 10
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.6 = Gauge32: 15
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.7 = Gauge32: 10

16E1s in this case, from 6.0 to 6.7 and 7.0-7.7. Now I have indexes 0-7 and LLD stops with error like "Cannot create item.["0"], already exist".

To solve this issue in a more generic way, I think that it should be possible to set something like "Index depth" which will set MIB branch (0 for unlimited).
So me and issue reporter could set "0" and have index-till-end-of-OID, Jc Duss can set "1" for Dell Equallogic and have just 315444693 & 690330181 (don't know what

should be in this case though).

It would also solve ZBXNEXT-808 (which is AFAICS duplicate).

It should be noted that there is other cases like

$ snmpwalk -c … -v2c 10.10.10.10 SNMPv2-SMI::enterprises.9.2.6
OLD-CISCO-TCP-MIB::loctcpConnInBytes.10.10.10.10.23.10.10.10.20.1879 = INTEGER: 185
OLD-CISCO-TCP-MIB::loctcpConnOutBytes.10.10.10.10.23.10.10.10.20.1879 = INTEGER: 2868
OLD-CISCO-TCP-MIB::loctcpConnInPkts.10.10.10.10.23.10.10.10.20.1879 = INTEGER: 98
OLD-CISCO-TCP-MIB::loctcpConnOutPkts.10.10.10.10.23.10.10.10.20.1879 = INTEGER: 110
OLD-CISCO-TCP-MIB::loctcpConnElapsed.10.10.10.10.23.10.10.10.20.1879 = Timeticks: (3009448) 8:21:34.48

(Please note that OLD-CISCO-TCP-MIB::loctcpConnElapsed.10.10.10.10.23.10.10.10.20.1879 [.1.3.6.1.4.1.9.2.6.1.1.5.10.10.10.10.23.10.10.10.20.1879] actually means tcp connection from IP 10.10.10.20 port 1879 to IP 10.10.10.10 port 23.)
which also should be processed somehow. Maybe it should be ability to set something like "Index start depth", so we can set "Index start depth" = "17" (Index starts after .1.3.6.1.4.1.9.2.6.1.1.5.10.10.10.10.23) and "Index depth" = "4" in order to catch "10.10.10.20".

Can we please bump the ticket priority? This isn't just an annoyance, but severely cripples monitoring F5 devices via SNMP

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-3449

Can somebody help to test the fix ? We have no F5 or advanced Cisco here

I'll try to test it, if I can find some time

For us it still doesn't really work for F5 devices, we're getting:
Value should be a JSON object

But the values are:

{
"{#SNMPINDEX}":"57.109.97.114.107.101.116.105.110.103.45.99.122.121.106.97.114.97.115.122.115.105.101.112.111.108.115.107.97.46.97.100.109.105.110.46.109.97.114.107.101.116.105.110.103.46.111.102.102.105.99.101.45.104.116.116.112.115",
"{#SNMPVALUE}":"xxxxxxxx-xxxxxxxxxxxxxxxxxx.xxxxx.xxxxxxxxx.xxxxxx-xxxxx"
}

At least when testing the ZBX-3449 branch

Thanks, Łukasz, for your help!
Can you test it with indexes shorter than 100 characters to find out whether ZBX-3449 is fixed correctly ? (There is other reopened ZBX-5497 for indexes longer than 100 characters).

Well, for shorter indexes it was working in 2.0.2 anyway. I've hoped this would also fix ZBX-5497, but it seems it doesn't

Available in version pre-2.1.0 (trunk) r30934.

if "configurable index depth" is still needed, a new feature request should be opened about it

I have the same problem with Cisco ME-3800X-24FS-M

-----SNMP query started-----
1: ipMRouteHCOctets.239.195.10.14.10.239.1.32.255.255.255.255 336634609626
-----SNMP query finished-----

Where instance = Ip_Multicast+Ip_source+Mask

Ip_Multicast = 239.195.10.14
Ip_source = 10.239.1.32
Mask = 255.255.255.255

Hello, I still have the issue with the 2.1 version from this september. (and 2.0.6)

Does this mean I have to get the trunk to have this fix? (from oct 2012)

It is mentionned as a 2.2 change (ticket ZBX-6965), but 2.1 is alpha.

The patch doesn't apply anymore.

Thank you.

Can you describe some details (Zabbix logs, snmpwalk output) of what is expected and how it does not work ?

I know understand better how it works.

It works when I set up rightly the discovery rule first time, no edition.

Thanks

I think there is no issue on edition, actually.

Here were not explicitly mentioned that it actually has fixed also LLD with multiple SNMP indexes (although ojab mentioned it as an issue).
ZBX-5474 as an example.