Ad Widget

Collapse

SNMP Discovery Rule seems to Skip First Entry in Index

Collapse
This topic has been answered.
X
X
 
  • Time
  • Show
Clear All
new posts
  • jonzey
    Junior Member
    • Jun 2024
    • 5

    #1

    SNMP Discovery Rule seems to Skip First Entry in Index

    Hi all,

    Bit of a weird one that I've been trying to wrap my head around. Currently running some traffic through an SNMP managed Power Controller and trying to build some discovery rules for a number of the outputs.

    An example of one of these parent trees, returning the Index Details are below.

    Code:
    snmpwalk -v 2c -c public 192.168.100.10 .1.3.6.1.4.1.39145.10.9.1.1
    iso.3.6.1.4.1.39145.10.9.1.1.0 = INTEGER: 0
    iso.3.6.1.4.1.39145.10.9.1.1.1 = INTEGER: 1
    iso.3.6.1.4.1.39145.10.9.1.1.2 = INTEGER: 2
    iso.3.6.1.4.1.39145.10.9.1.1.3 = INTEGER: 3
    iso.3.6.1.4.1.39145.10.9.1.1.4 = INTEGER: 4
    The MIB details are essentially
    • .1.3.6.1.4.1.39145.10.9.1.1 - Parent Tree
    • .1.3.6.1.4.1.39145.10.9.1.1.{$ALARM_INDEX} - Alarm Index
    • .1.3.6.1.4.1.39145.10.9.1.2.{$ALARM_NAME} - Alarm Name
    • .1.3.6.1.4.1.39145.10.9.1.3.{$ALARM_STATUS} - Alarm State
    What I'm finding is inconsistent behavior between testing the discovery rule and actually applying it to the same host. The discovery rule I'm using is the below in order to get the Index number and Name, as all I'm interested in is the status (marrying the Index details to the name)

    Discovery Rule:
    Code:
    discovery[{#ALARM_INDEX},1.3.6.1.4.1.39145.10.9.1.1,{#ALARM_ NAME},.1.3.6.1.4.1.39145.10.9.1.2]

    In the Template Editor, whenever I manually enter the details into the test box (IP, Port, Community etc) it returns the Index as expected.

    Result when Testing in the Template Editor:
    Code:
    [{"{#SNMPINDEX}":"0","{#ALARM_INDEX}":"0","{#ALARM_NAME}":"Alarm #1"},{"{#SNMPINDEX}":"1","{#ALARM_INDEX}":"1","{ #ALARM_NAME}":"Alarm #2"},{"{#SNMPINDEX}":"2","{#ALARM_INDEX}":"2","{ #ALARM_NAME}":"Alarm #3"},{"{#SNMPINDEX}":"3","{#ALARM_INDEX}":"3","{ #ALARM_NAME}":"Alarm #4"},{"{#SNMPINDEX}":"4","{#ALARM_INDEX}":"4","{ #ALARM_NAME}":"Alarm #5"}]
    Click image for larger version

Name:	Testing_via_Template_Editor.png
Views:	267
Size:	130.0 KB
ID:	486222


    However after I apply the template to the host (the exact same host) it seems to skip the first OID for the index (the .0 item). Even using the test function (which is identical in look and feel to the template editor, but just from the host window).

    Result after applying to the Host:
    Code:
    [{"{#SNMPINDEX}":"1","{#ALARM_INDEX}":"1","{#ALARM_NAME}":"Alarm #2"},{"{#SNMPINDEX}":"2","{#ALARM_INDEX}":"2","{ #ALARM_NAME}":"Alarm #3"},{"{#SNMPINDEX}":"3","{#ALARM_INDEX}":"3","{ #ALARM_NAME}":"Alarm #4"},{"{#SNMPINDEX}":"4","{#ALARM_INDEX}":"4","{ #ALARM_NAME}":"Alarm #5"}]
    Click image for larger version

Name:	Template_Applied_to_Host.png
Views:	272
Size:	132.6 KB
ID:	486223

    I can't seem to see any filters or anything else which would be triggering this behavior, as I'm basically testing the template, then applying it to the exact same host and getting different results.

    I'm seeing this exact same behavior with a few OIDs, and it's always skipping the .0 index value which is the first entry for all these OIDs. So I'm suspecting that's the why but I'm not sure how to correct this. I'm running this on the 7.0 LTS Container Appliance version (our dev instance).

    Any ideas?
    Attached Files
  • Answer selected by jonzey at 31-07-2024, 02:30.
    jonzey
    Junior Member
    • Jun 2024
    • 5

    So I found out what the issue was. Essentially this MIB is a VERY old one, that hasn't been updated in a very long time.

    I was originally using SNMP v3, then tried v2c. Turns out if I change the integration to Zabbix to use SNMPv1 it works. Funny eh? Anyway now it's all working at expected. I'm guessing because it's using such an old SNMP standard, Zabbix only recognises it when you use the old v1 version of SNMP.

    Eventually I'll probably look at whether there's a way I can script it, so that I can use SNMPv3, but it works for now.

    Here's the template, for the very specific use case where this board is used. (ICT200DB-12IRC Remotely Switched PDP). This same template may be viable for other boards, but I haven't tried it. Anyway, have at it!
    Attached Files

    Comment

    • jonzey
      Junior Member
      • Jun 2024
      • 5

      #2
      So I found out what the issue was. Essentially this MIB is a VERY old one, that hasn't been updated in a very long time.

      I was originally using SNMP v3, then tried v2c. Turns out if I change the integration to Zabbix to use SNMPv1 it works. Funny eh? Anyway now it's all working at expected. I'm guessing because it's using such an old SNMP standard, Zabbix only recognises it when you use the old v1 version of SNMP.

      Eventually I'll probably look at whether there's a way I can script it, so that I can use SNMPv3, but it works for now.

      Here's the template, for the very specific use case where this board is used. (ICT200DB-12IRC Remotely Switched PDP). This same template may be viable for other boards, but I haven't tried it. Anyway, have at it!
      Attached Files

      Comment

      Working...