Thank you for reporting this.

What returns the OID which you request by LLD rule? Is that some misconfiguration?

snmpwalk -v2c -c nagios -On .1.3.6.1.4.1.2620.500.9002.1.1

snmpwalk stops after the first two lines of output with the error message:

{{.1.3.6.1.4.1.2620.500.9002.1.2.9.6.19.6.0 = STRING: "peernameX"}}
{{ .1.3.6.1.4.1.2620.500.9002.1.2.21.7.8.6.0 = STRING: "peernameX""}}
Error: OID not increasing: {{.1.3.6.1.4.1.2620.500.9002.1.2.9.6.19.6.0}}
{{ >= .1.3.6.1.4.1.2620.500.9002.1.2.21.7.8.6.}}

The thing is, The IP addresses of this IPsec endpoints are used as part of the OID. Which is ok i guess, but does not work for automated increment which is used to walk down a tree.

snmpbulkwalk seems to work a little different, even though it also has no idea of the IP appearing below .1.3.6.1.4.1.2620.500.9002.1.2. But at least it completes the walk, and prints out all the Peernames (which I wanted to use in my LLD)

Both work with -Cc (man page excerpt: Do not check whether the returned OIDs are increasing.)

I don't know, how you might be able to fix, this, but maybe as a exception handler for this sort of error?

If this kind of error hits, try again without the OID increment check!?

To get a bit more understanding of this OID (i created this Bug report in a hurry...)

Below this OIDs there are IPsec Tunnel related information's, like tunnel stats, endpoint IPs, outgoing,m IPs and so on

More Information can be found here: https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/media-type/html?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=31396

Thank you all in advance

Hello Michael,

This error message might be a little misleading. The actual reason for this, is OID duplicates.

OID .1.3.6.1.4.1.2620.500.9002.1.2.7.40.1.2.0, the one that is throwing out an error, has been mapped before already.

At this point, it cannot be qualified as a Zabbix bug, this is working as expected, since snmpbulkwalk is not supported by Zabbix.

Best Regards,

Renats

Hello Michael,

We have noticed that this issue has not been updated for a long time. May we assume that this case is resolved? If it is not and requires additional work, please comment on the ticket and we will respond accordingly. Alternatively, we're going to change the state of the issue to Resolved in 14 days if we don't hear back from you.

Best Regards,

Renats

@Renats Valiahmetovs

But there are not duplicates there.

unfortunately I cant share the original content as this are public IPs of IPsec endpoints, but you can trust me that there are no duplicates in this table.

Any Idea what I can try to do, to help fix this issue?

For everybody else who stumbles across the same issue. This is my current workaround, for proper discovery:

#!/bin/bash

snmp_community=$2
gw=$1
snmp_oid=$3


if [ -z ${gw} ]; then gw=my.default.hostname; fi
if [ -z ${snmp_community} ]; then snmp_community=my_snmp_community; fi
if [ -z ${snmp_oid} ]; then snmp_oid=".1.3.6.1.4.1.2620.500.9002.1"; fi

#echo debugging information
#echo Using paremters:
#echo Hostname/IP: ${gw}
#echo SNMP community: ${snmp_community}
#echo SNMP OID: ${snmp_oid}

first=1
echo "["
IFS='
' # split on newline
for entrie in $(snmpbulkwalk -v2c -Cc -On -c ${snmp_community} ${gw} ${snmp_oid}.2); do
        if [[ ${first} -eq 0 ]]; then echo -e "\t,\n"; fi
        first=0

        echo "${entrie}" | awk -F= '{gsub('/${snmp_vpn_oid}\.2\./',"",$1); 
        gsub(/\.0 /,"",$1); 
        gsub(/ STRING: /,"",$2); 
        gsub(/"/,"",$2); 
        print "\t{\n\t\t\"{#IP}\":\""$1"\",\n\t\t\"{#NAME}\":\""$2"\"\n\t}\n"}'

done

echo "]"

The basic intention of this check was for the Checkpoint IPsec tunnel discovery, but it can be used for any other SNMP discovery which has the same issues of unordered MIBs returning.

{{To use this script in the zabbix discovery just create a LLD rule with an external check and the following key: snmp_unorderd_mibs_discovery.sh[

,
{$SNMP_COMMUNITY},.1.3.6.1.4.1.2620.500.9002.1]}}

SNMP Information for my Checkpoint SNMP MIBs can be found here:

https://oidref.com/1.3.6.1.4.1.2620.500.9002.1

But still, this would be nice if this would work without my workaround...

 PS.: Now on Github https://github.com/Daywalker01?tab=repositories