Hey all! I know this isn’t an icinga problem per se, but I’m hoping someone might have had this problem, and figured out a workaround. When I poll our router for OID 126.96.36.199.188.8.131.52.184.108.40.206.1.35 with snmpwalk, I get a response with the expected values, but when I use check_snmp, I get the error mentioned in the title. What do? Should I just build an snmpwalk template and use that instead of check_snmp?
.0 at the end of the OID.
Not sure if the snmpwalk has the
.0 added as well
Instances of managed objects are identified by appending an
instance-identifier to the object’s object identifier. Scalar
objects and columnar objects use different ways to construct the
Scalar objects have exactly one object instance. It is identified by
appending a single `0’ sub-identifier to the object identifier of the
Within tables, different instances of the same columnar object are
identified by appending a sequence of one or more sub-identifiers to
the object identifier of the columnar object which consists of the
values of object instances that unambiguously distinguish a table
row. These indexing objects can be columnar objects of the same
and/or another table, but MUST NOT be scalar objects. Multiple
applications of the same object in a single table indexing
specification are strongly discouraged.
No dice, unfortunately
user@la-hq-inframon01:/home/infraadmin# snmpwalk -v 3 -c <community> -a sha -A <auth> -x aes -X <pass> -u <user> -l authpriv <ip> 220.127.116.11.18.104.22.168.22.214.171.124.1.35
SNMPv2-SMI::enterprises.126.96.36.199.188.8.131.52.2106351616 = INTEGER: 1
SNMPv2-SMI::enterprises.184.108.40.206.220.127.116.11.2106380288 = INTEGER: 1
SNMPv2-SMI::enterprises.18.104.22.168.22.214.171.124.2106544128 = INTEGER: 1
SNMPv2-SMI::enterprises.126.96.36.199.188.8.131.52.2113761280 = INTEGER: 1
SNMPv2-SMI::enterprises.184.108.40.206.220.127.116.11.2125221888 = INTEGER: 1
SNMPv2-SMI::enterprises.18.104.22.168.22.214.171.124.2172710912 = INTEGER: 1
user@la-hq-inframon01:/home/infraadmin# snmpwalk -v 3 -c <community> -a sha -A <auth> -x aes -X <pass> -u <user> -l authpriv <ip> 126.96.36.199.188.8.131.52.184.108.40.206.1.35.0
SNMPv2-SMI::enterprises.220.127.116.11.18.104.22.168.0 = No Such Object available on this agent at this OID
Well, as you can see the OID ends not at
.35 but has another identifier following. You need to chose which one you want to query. I guess the numbers following are not random but represent something.
If you have the MIB file of that system you could download it and put it under
/usr/share/snmp/mibs (path might differ depending on your distribution). That should show you the string representation of the OID. Or you simply look into the MIB file with a text editor.
So, each of those identifiers is a reference for the active tunnels, and I was hoping to get all of the tunnel statuses from a single check_snmp command, but i guess it’ll take a little more doing.
instead of snmpwalk, there’s snmpget but you might want to investigate snmptable so it associates “related” OIDS to each other - OIDs may be itemized e.g. ending with .1.index could be “name”, .2.index could be a value so to get all index with their associated oids/values the snmptable would show them like
index name state
1 nameA 1
2 nameB 1
tricky part is getting the name of the table - for interfaces it’s ifTable as an example (IF-MIB)