While testing some SNMP OIDs from a Check Point firewall, I noticed an unexpected behavior with the Zabbix SNMP Walk functionality. Specifically, it truncates values with discontiguous OID indexes.

🛑 The issue:

When discovering VPNs from a Check Point firewall, Zabbix does not detect them all. Some VPNs are simply missing from the SNMP walk master item.

The standard Check Point OOTB template checks the VPN MIB table with OID 1.3.6.1.4.1.2620.500.9002.1.2 (tunnelPeerObjName) to discover the VPN names.

Check Point's firewall uses the peer IP address as the table index.
SNMP (bulk)walk assumes lexicographically increasing OIDs.

Since Check Point's OID indexes (IP addresses) are not naturally sorted in SNMP lexicographic order, the device sometimes returns indexes such as ...200.1.2.3.0 before ...187.1.2.3.0.

When the agent returns an OID that is less than or equal to a previously returned OID, Net-SNMP prints: Error: OID not increasing

📝 Steps to reproduce:

This issue can be reproduced by simply testing the MIB objects (tunnelPeerObjName) from a VPN-enabled Check Point firewall. Alternatively, it can be tested outside of Zabbix by simply running an "snmp(bulk)walk" command in the Server or Proxy terminal.

Using only Zabbix SNMP parameters, the result is truncated.

# snmpbulkwalk -v 2c -c [community] 172.17.0.89 -Oe -Ot -On 1.3.6.1.4.1.2620.500.9002.1.2
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN1"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN2"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN3"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN4"
.1.3.6.1.4.1.2620.500.9002.1.2.186.1.2.3.0 = STRING: "VPN5"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN6"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN7"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN8"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN9"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN10"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN11"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN12"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN13"
Error: OID not increasing: .1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0
 >= .1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN14"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN15"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN16"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN17"
Error: OID not increasing: .1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0
 >= .1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN18"
Error: OID not increasing: .1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0
 >= .1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN19"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN20"
Error: OID not increasing: .1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0
 >= .1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0

Note the "OID not increasing" error. This indicates that the device is using the peer IP address as the table index, which is not sorted in SNMP lexicographic order.

This causes Zabbix to truncate the results of the "Walk" master items.

The above picture displays a Zabbix test with only 12 VPN names when 80 should have been captured.

✅ Expected:

A correct SNMP (bulk)walk for this MIB table should use the "-Cc" parameter because it "does not check if returned OIDs are increasing".

The correct output is shown below using Zabbix parameters plus the "-Cc" parameter.

# snmpbulkwalk -v 2c -c [community] 172.17.0.89 -Oe -Ot -On -Cc 1.3.6.1.4.1.2620.500.9002.1.2
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN01"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN02"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN03"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN04"
.1.3.6.1.4.1.2620.500.9002.1.2.186.1.2.3.0 = STRING: "VPN05"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN06"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN07"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN08"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN09"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN10"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN11"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN12"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN13"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN14"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN15"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN16"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN17"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN18"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN19"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN20"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN21"
.1.3.6.1.4.1.2620.500.9002.1.2.18.1.2.3.0 = STRING: "VPN22"
.1.3.6.1.4.1.2620.500.9002.1.2.179.1.2.3.0 = STRING: "VPN23"
.1.3.6.1.4.1.2620.500.9002.1.2.179.1.2.3.0 = STRING: "VPN24"
.1.3.6.1.4.1.2620.500.9002.1.2.52.1.2.3.0 = STRING: "VPN25"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN26"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN27"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN28"
.1.3.6.1.4.1.2620.500.9002.1.2.138.1.2.3.0 = STRING: "VPN29"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN30"
.1.3.6.1.4.1.2620.500.9002.1.2.155.1.2.3.0 = STRING: "VPN31"
.1.3.6.1.4.1.2620.500.9002.1.2.186.1.2.3.0 = STRING: "VPN32"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN33"
.1.3.6.1.4.1.2620.500.9002.1.2.186.1.2.3.0 = STRING: "VPN34"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN35"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN36"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN37"
.1.3.6.1.4.1.2620.500.9002.1.2.138.1.2.3.0 = STRING: "VPN38"
.1.3.6.1.4.1.2620.500.9002.1.2.98.1.2.3.0 = STRING: "VPN39"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN40"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN41"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN42"
.1.3.6.1.4.1.2620.500.9002.1.2.52.1.2.3.0 = STRING: "VPN43"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN44"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN45"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN46"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN47"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN48"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN49"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN50"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN51"
.1.3.6.1.4.1.2620.500.9002.1.2.45.1.2.3.0 = STRING: "VPN52"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN53"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN54"
.1.3.6.1.4.1.2620.500.9002.1.2.159.1.2.3.0 = STRING: "VPN55"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN56"
.1.3.6.1.4.1.2620.500.9002.1.2.54.1.2.3.0 = STRING: "VPN57"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN58"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN59"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN60"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN61"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN62"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN63"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN64"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN65"
.1.3.6.1.4.1.2620.500.9002.1.2.189.1.2.3.0 = STRING: "VPN66"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN67"
.1.3.6.1.4.1.2620.500.9002.1.2.131.1.2.3.0 = STRING: "VPN68"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN69"
.1.3.6.1.4.1.2620.500.9002.1.2.198.1.2.3.0 = STRING: "VPN70"
.1.3.6.1.4.1.2620.500.9002.1.2.187.1.2.3.0 = STRING: "VPN71"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN72"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN73"
.1.3.6.1.4.1.2620.500.9002.1.2.200.1.2.3.0 = STRING: "VPN74"
.1.3.6.1.4.1.2620.500.9002.1.2.18.1.2.3.0 = STRING: "VPN75"
.1.3.6.1.4.1.2620.500.9002.1.2.34.1.2.3.0 = STRING: "VPN76"
.1.3.6.1.4.1.2620.500.9002.1.2.206.1.2.3.0 = STRING: "VPN77"
.1.3.6.1.4.1.2620.500.9002.1.2.177.1.2.3.0 = STRING: "VPN78"
.1.3.6.1.4.1.2620.500.9002.1.2.201.1.2.3.0 = STRING: "VPN79"

Nothing is actually broken on the SNMP agent side.
The host SNMP agent is answering correctly; however, it violates the assumptions of a strict SNMP walk.

This is mostly a design behavior of the Zabbix "Walk" item, which only uses the "-Oe -Ot -On" options and requires an increasing index.

This probably affects all major versions of Zabbix with the "Walk" item implementation (6.4+ if I'm not mistaken).

A safe fix seems to be adding the "-Cc*" parameter to Zabbix "Walk" implementation, so that it can actually tell the SNMP manager to accept non-increasing OIDs.*

I consider this an important fix for Zabbix's SNMP "Walk" implementation because truncated values hinder Zabbix monitoring reliability.