[collectd] I don't know the ASN type #130

[Mark]

Hi List,
I know this question has been asked before, and I'm also pretty sure it
hasn't been answered before, which is why I'm asking again. I'm attempting
to use SNMP to graph Citrix Netscaler metrics. I'm calling using this Data
block:

   <Data "ns_vservers">
       Type "ns_vserver"
       Table true
       Instance "SNMPv2-SMI::enterprises.5951.4.1.3.1.1.1"
       Values "SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43"
   </Data>

I get the warning (which frankly, should be an error) in messages saying:

snmp plugin: I don't know the ASN type #130 (OID:
"SNMPv2-SMI::enterprises.5951.4.1.3.10.1.1", data block "ns_vservers", host
block ...

After several tcpdumps, I figured out what's happening. Using
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.1 as the base, the plugin iterates
through all of the values in SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43.
When it gets to the end of the tree, it makes its final GetNextRequest:

09:45:18.054252 IP collectd_server.35222 > netscaler.snmp  C= ...
GetNextRequest(132)
E:5951.4.1.3.1.1.43.18.83.78.86.45.67.74.45.67.74.88.45.72.84.84.80.45.86.83
E:5951.4.1.3.10.1.2.31.73.78.105.122.115.106.115.120.99.101.110.104.100.100.48.98.105.99.53.109.114.102.100.112.106.122.98.118.102.97.83.28.84.76.83.49.45.68.72.69.45.82.83.65.45.65.69.83.45.50.53.54.45.67.66.67.45.83.72.65
09:45:18.054560 IP netscaler.snmp > collectd_server.35222:  C= ...
GetResponse(72)
E:5951.4.1.3.1.1.43.18.83.78.86.45.86.67.77.45.65.100.109.105.110.45.72.84.84.80="0"
E:5951.4.1.3.10.1.1=[endOfMibView]

As you can see, the Netscaler returns a #130 meaning end-of-the-line for
this MIB. The SNMP plugin should take this as a hint to go to the next
value in the "Values" list, or stop. It doesn't. Because it doesn't
understand it, it thinks the returned GetNextRequest response
(E:5951.4.1.3.10.1.1) is a valid MIB and continues querying, thinking it's
in the same tree. It's not.

09:45:18.054699 IP collectd_server.35222 > netscaler.snmp:  C= ...
GetNextRequest(71)
E:5951.4.1.3.1.1.43.18.83.78.86.45.67.74.45.67.74.88.45.72.84.84.80.45.86.83
E:5951.4.1.3.10.1.1
09:45:18.055299 IP netscaler.snmp > collectd_server.35222:  C=
...GetResponse(117)
E:5951.4.1.3.1.1.43.18.83.78.86.45.86.67.77.45.65.100.109.105.110.45.72.84.84.80="0"
E:5951.4.1.3.10.1.1.19.83.78.86.45.67.74.45.67.74.88.45.72.84.84.80.83.45.86.83.12.83.83.76.51.45.82.67.52.45.77.68.53="SSL3-RC4-MD5"

It now continues to SNMP GetNext down this rabbit hole until it receives
the next endOfMibView which resets the search to E:5951.4.1.3.10.1.1 and
starts all over again.

Looking through the code (5.1.0), I can't quite make out what the plugin is
expecting for the end of mib. According to net-snmp, the plugin should be
responsible for recognizing this tag:

Why do I sometimes get "End of MIB" when walking a tree, and sometimes not?
--------------------------------------------------------------------------

  This depends on which MIB modules are supported by the agent you are
  querying and exactly what you're asking for.

  Note that a tree is walked by repeatedly asking for "the next entry" until
  all the values under that tree have been retrieved.  However, the agent has
  no idea that this is what's happening - all it sees is a request for "the
  next entry after X".

  If the object X happens to be the last entry in a sub-tree, the agent will
  provide the next object supported (as requested) even though this will be
  in a different subtree.  It's up to the querying tool to recognise that
  this last result lies outside the area of interest, and simply discard it.

  If the object X happens to be the last entry supported by the agent, it
  doesn't have another object to provide, so returns an "end of MIB"
  indication.  The Net-SNMP tools report this with the message above.

  But in either case, the actual information provided will be the same.



So it appears that the SNMP plugin does not recognize that the "last result
lies outside the area of interest" and when the agent tells it explicitly,
it has no idea what to do with that information. What is the best way to
work around this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20120906/ecf859ba/attachment.html>