Hi List,<br>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:<br>
<br>   <Data "ns_vservers"><br>       Type "ns_vserver"<br>       Table true<br>       Instance "SNMPv2-SMI::enterprises.5951.4.1.3.1.1.1"<br>       Values "SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43"<br>
   </Data><br><br>I get the warning (which frankly, should be an error) in messages saying:<br><br>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 ...<br>
<br>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:<br>
<br>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<br>
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]<br><br>
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.<br>
<br>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<br>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"<br>
<br>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.<br><br>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:<br>
<br><pre>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.
</pre><br><br>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?<br>
<br>