[ZBX-12259] LLD: Multiple OIDs SNMP discovery : Issues if not all OIDs are available on the device Created: 2016 Feb 12  Updated: 2024 Apr 10  Resolved: 2017 Oct 18

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: None
Fix Version/s: 3.0.13rc1, 3.2.10rc1, 3.4.4rc1, 4.0.0alpha1, 4.0 (plan)

Type: Problem report Priority: Trivial
Reporter: Vitaly Zhuravlev Assignee: Viktors Tjarve
Resolution: Fixed Votes: 1
Labels: lld, snmp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 1.png     JPEG File 2.jpg     JPEG File 3.jpg     PNG File filter.png    
Team: Team A
Sprint: Sprint 5, Sprint 6, Sprint 7, Sprint 9, Sprint 10, Sprint 11, Sprint 12, Sprint 13, Sprint 14, Sprint 15, Sprint 16, Sprint 17, Sprint 18, Sprint 19
Story Points: 5

 Description   

I met the following problem.

First, I create a LLD discovery with the following OID:

 
discovery[{#SNMPVALUE},ifOperStatus,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFNAME},1.3.6.1.2.1.31.1.1.1.1,{#IFDESCR},.1.3.6.1.2.1.2.2.1.2,{#IFTYPE},ifType]

And at first it works just fine

Hovewer, If the following filter is applied:

Then there is a problem rises: It means that if devices dont' have 1.3.6.1.2.1.31.1.1.1(ifXtable) then they don't have any values for macroses {#IFNAME},{#IFALIAS} neither.

And such devices could not be discovered! Reason: Filter {#IFNAME} matches @IFNAME BLACKLIST cannot be evaluated despite the fact that
EXPRESSION TYPE of 'Result is False' was used.

There are two problems I see here

  • Filter for empty(undefined) value cannot be evaluated despite its type of 'Result is False'
  • There is no discovery error (red cross with the comment) which could dramatically assist in debugging such issue. Error or warning stating that not all oids stated in discovery key can be found on the the host could help dramatically

    I want you to consider two things here:

1) Make discovery filters more soft.
So in case of 'Result is FALSE' type of expression undefinied can pass as OK. Please consider this just because that template can possibly be applied to broad range of devices where OIDs availability may vary.
2) And/OR
Please also make a warning appear in INFO column of discovery page of the host that would assist in debugging problems that might rise during such discovery

Thank you!

P.S. here are some console output tests for the device that doesn't have ifXtable

administrator@zabbix:~$ snmpwalk -c virton -v 1 10.40.0.30 .1.3.6.1.2.1.31.1.1.1
administrator@zabbix:~$

same with debug on:

administrator@zabbix:~$ snmpwalk -c virton -v 1 10.40.0.30 .1.3.6.1.2.1.31.1.1.1 -d
 
Sending 44 bytes to UDP: [10.40.0.30]:161->[0.0.0.0]
0000: 30 2A 02 01  00 04 06 76  69 72 74 6F  6E A1 1D 02    0*.....virton...
0016: 04 24 58 66  7F 02 01 00  02 01 00 30  0F 30 0D 06    .$Xf.......0.0..
0032: 09 2B 06 01  02 01 1F 01  01 01 05 00                 .+..........
 
 
Received 50 bytes from UDP: [10.40.0.30]:161->[0.0.0.0]
0000: 30 30 02 01  00 04 06 76  69 72 74 6F  6E A2 23 02    00.....virton.#.
0016: 04 24 58 66  7F 02 01 00  02 01 00 30  15 30 13 06    .$Xf.......0.0..
0032: 0D 2B 06 01  04 01 CE 12  01 01 01 01  01 00 42 02    .+............B.
0048: 73 54                                                 sT
 
 
Sending 44 bytes to UDP: [10.40.0.30]:161->[0.0.0.0]
0000: 30 2A 02 01  00 04 06 76  69 72 74 6F  6E A0 1D 02    0*.....virton...
0016: 04 24 58 66  80 02 01 00  02 01 00 30  0F 30 0D 06    .$Xf.......0.0..
0032: 09 2B 06 01  02 01 1F 01  01 01 05 00                 .+..........
 
 
Received 44 bytes from UDP: [10.40.0.30]:161->[0.0.0.0]
0000: 30 2A 02 01  00 04 06 76  69 72 74 6F  6E A2 1D 02    0*.....virton...
0016: 04 24 58 66  80 02 01 02  02 01 01 30  0F 30 0D 06    .$Xf.......0.0..
0032: 09 2B 06 01  02 01 1F 01  01 01 05 00                 .+..........

However, it's all fine you poll IF-MIB counters:

administrator@zabbix:~$ snmpwalk -c virton -v 1 10.40.0.30 IF-MIB::ifDescr
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: eth1
IF-MIB::ifDescr.4 = STRING: wifi0
IF-MIB::ifDescr.5 = STRING: ath0
IF-MIB::ifDescr.6 = STRING: eth0.40
IF-MIB::ifDescr.7 = STRING: ath0.40
IF-MIB::ifDescr.8 = STRING: br0
IF-MIB::ifDescr.9 = STRING: br1


 Comments   
Comment by Andrey Melnikov [ 2017 May 30 ]

Create second template for this crap hardware. Or upgrade firmware on your Ubiquiti device.

Comment by Rostislav Palivoda (Inactive) [ 2017 Jun 14 ]

Closing. Reopen if still actual.

Comment by Vitaly Zhuravlev [ 2017 Jun 22 ]

Again, just experienced this on trunk with SNMP discovery of device that doesn't have IF-MIB::ifXTable on board.

vso is it possible to reproduce by sending json please ? It would really help.

Comment by Vitaly Zhuravlev [ 2017 Jun 23 ]

vso, here you go:
discovery key:

discovery[{#SNMPVALUE},ifOperStatus,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFNAME},1.3.6.1.2.1.31.1.1.1.1,{#IFDESCR},.1.3.6.1.2.1.2.2.1.2,{#IFTYPE},.1.3.6.1.2.1.2.2.1.3]

{"data":[{"{#SNMPINDEX}":"1","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"2","{#IFDESCR}":"Vlan-interface1","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"9","{#SNMPVALUE}":"1","{#IFADMINSTATUS}":"1","{#IFDESCR}":"Vlan-interface9","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49152","{#SNMPVALUE}":"1","{#IFADMINSTATUS}":"1","{#IFDESCR}":"AUX0","{#IFTYPE}":"23"},{"{#SNMPINDEX}":"49153","{#SNMPVALUE}":"1","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/1 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49154","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/2 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49155","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/3 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49156","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/4 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49157","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/5 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49158","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/6 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49159","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/7 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49160","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/8 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49161","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/9 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49162","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/10 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49163","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/11 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49164","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/12 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49165","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/13 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49166","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/14 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49167","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/15 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49168","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/16 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49169","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/17 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49170","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/18 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49171","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/19 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49172","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/20 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49173","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/21 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49174","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/22 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49175","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/23 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49176","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/24 : copper","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49177","{#SNMPVALUE}":"1","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/25 : fiber","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49178","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/26 : fiber","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49179","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/27 : fiber","{#IFTYPE}":"6"},{"{#SNMPINDEX}":"49180","{#SNMPVALUE}":"2","{#IFADMINSTATUS}":"1","{#IFDESCR}":"gigabitEthernet 1/0/28 : fiber","{#IFTYPE}":"6"}]}

and filter:

So,

{#IFNAME}

and

{#IFALIAS}

are just not in JSON at all.

Comment by Vladislavs Sokurenko [ 2017 Jun 23 ]

1) Make discovery filters more soft.
So in case of 'Result is FALSE' type of expression undefinied can pass as OK. Please consider this just because that template can possibly be applied to broad range of devices where OIDs availability may vary.

Do you think that there could be situations when you would not wan't missing value to be considered the same as empty value ? So you would not want it to be discovered ?

Does not make sense to threat missing tag as empty value since it is uknown and we cannot apply filter to it, and cannot determine if it match.

So it's expected behavior.

Is workaround possible using or filter to filter out those that are missing tag ?

Comment by Vitaly Zhuravlev [ 2017 Jun 23 ]

Main problem is that LLD not returning MACROSES i'm expecting absolutely silently. It's incredible hard to debug why my LLD returns nothing. No warnings, not even a log line.
So, go fo the second part:

2) And/OR
Please also make a warning appear in INFO column of discovery page of the host. That would assist in debugging problems that might rise during such discovery

Comment by Viktors Tjarve [ 2017 Jul 20 ]

To me this issue looks more like a new functionality request (ZBXNEXT) and less like a bug because everything is working as expected. So if this is a new development it should be decided how the end result should look exactly. Two main areas for improvement should be considered. First would be checking OIDs to be discovered by the discovery rule. Second - checking of the discovery rule filter. Eventually most likely only one (if any) direction will be selected for development.

We must make clear:
What exactly do we want to indicate?

  • For discovery OIDs:
    • discovery OID exists on a device, value is received but not used anywhere
    • macro in discovery does no exist on a device
  • For filter:
    • the value for used macro does not exist
    • the combination of macros used in the filter does not exist and all results will be filtered out

Where we want to see the information?

  • log file
  • indication in INFO column in frontend with comment
  • performing validation before allowing to create discovery rule
  • add "Test" button for filter to get result immediately with the current filter setup applied
Comment by Vitaly Zhuravlev [ 2017 Jul 21 ]

Already discussed this with sasha

What exactly do we want to indicate?

  • We need to indicate that one of the oids user requested is not available on the device. (macro in discovery does no exist on a device)
    Where we want to see the information?
  • indication in INFO column in frontend with comment
Comment by Viktors Tjarve [ 2017 Oct 17 ]

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

Comment by Andris Zeila [ 2017 Oct 17 ]

Successfully testted, please review minor fixes in r73577.

viktors.tjarve Looks good. CLOSED

Comment by Viktors Tjarve [ 2017 Oct 18 ]

Released in:

  • 3.0.13rc1 r73610, r73611
  • 3.2.10rc1 r73612
  • 3.4.4rc1 r73613
  • 4.0.0alpha1 r73614
Generated at Wed Jul 16 11:19:39 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.