Add configurable max repetitions for SNMP bulk walks

[c-kr]

I monitor remote hosts over high-latency VPN connections. Regular live checks are unsuitable in this environment because they frequently time out, so I use the offline bulk-walk cache mode instead.

Currently, snmpbulkwalk uses its default max-repetitions value of 10. This requires significantly more round trips than a value of 100.

For example:

Default (max-repetitions = 10)

$ time /usr/lib/monitoring-plugins/check_nwc_health \
    --hostname <host> \
    --community <community> \
    --mode bulkwalk \
    --offline \
    --timeout 900

OK - all requested oids are in /tmp/snmpwalk_check_nwc_health_<host>

real    2m11.662s
user    0m0.223s
sys     0m0.052s

Configured with max-repetitions = 100

$ time /usr/lib/monitoring-plugins/check_nwc_health \
    --hostname <host> \
    --community <community> \
    --mode bulkwalk \
    --offline \
    --timeout 900 \
    --max-repetitions 100

OK - all requested oids are in /tmp/snmpwalk_check_nwc_health_<host>

real    0m33.970s
user    0m0.226s
sys     0m0.057s

This reduces the runtime from about 132 seconds to 34 seconds for this connection.

Proposed change

Add a --max-repetitions option that passes the configured value to snmpbulkwalk through -Cr.

The default remains conservatively set to 10, matching the Net-SNMP default and preserving existing behavior. Users monitoring devices over high-latency connections can increase the value when appropriate.

Values smaller than 1 are rejected during argument validation.

[lausser]

install net-snmp-perl and run the plugin with an environment SNMP_XS_ENABLE=1
Add -vvvvvvvvvvvvvvvvvv to see if it is using the right libraries. (some time in the future, i will deprecate the pure-Perl Net::SNMP and replace it by the standard net-snmp. Then the snmp stack is the same as for snmpget/snmpwalk)

[c-kr]

Im not sure if I understood you correct. Did you want me to test the vpn performance problem with the XS Backend or was it meant to test my PR against it?

Anyway, I did both and can confirm that:

• Both backends work with the PR and that the new backend was loaded successfully:

SNMP module available, attempting XS backend session
Using SNMP module (XS) backend - modern ciphers available

• The performance problem is unchanged when switching backends (without changing the max repetitions)

IMO this PR should not be influenced by the backend as the only thing it changes is to add the -Cr argument to the external snmpbulkwalk binary run.

[c-kr]

Ah, I think now I got it.

The XS Backend already uses dynamic max-repititions based on query size, so I should not need to use the cache file at all. I'll try it, thanks.