Newbie OID issue

ad7742 · Post by **ad7742** » Tue Nov 29, 2005 2:36 pm

(Please excuse any odd terminology that I use - I am not overly familiar with the SNMP / cacti lingo)

I have been attempting to index the MIB of Allot Communications' NetEnforcer traffic shaping device. They implement the standard interface MIB, and performing an SNMP walk against the interface index returns the following:

IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3

All fine.

Also, if I do an SNMP walk against the BytesIn, I get the following:

IF-MIB::ifInOctets.1 = Counter32: 2946132927
IF-MIB::ifInOctets.2 = Counter32: 1584211163
IF-MIB::ifInOctets.3 = Counter32: 3163560039

Again, fine. These interfaces are being graphed using the standard interface graph template and all is working well.

However, within the device one can define a set of "Pipes" which monitor traffic flowing between IP addresses. For the sake of this post, they have much the same features of an interface (e.g. BytesIn, BytesOut).

When I do an SNMP walk against the Pipes index, I get the following:

SNMPv2-SMI::enterprises.2603.1.2.1.1.1.1.1.0 = INTEGER: 1
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.1.2.0 = INTEGER: 2
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.1.3.0 = INTEGER: 3
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.1.4.0 = INTEGER: 4
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.1.5.0 = INTEGER: 5

As you can see, the OIDs have an extra ".0" appended to the end of them (when compared with the output from walking the Interfaces index). Therefore, I need to run a regexp against the results to get a useable index:

OID/REGEXP:.*\.([0-9]*)\.0$

This works fine.

However, here (finally) is the problem. When I run an SNMP walk against the BytesIn OID, I get the following:

SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.1.0 = Counter64: 970788937
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.2.0 = Counter64: 1960039165
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.3.0 = Counter64: 76166508372
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.4.0 = Counter64: 1425653257
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.5.0 = Counter64: 5704847

Cacti does not seem to think that I'm getting any valid data back, presumably because for each Pipe it is trying to get data back from

.2603.1.2.1.1.1.4.1

instead of

.2603.1.2.1.1.1.4.1.0

Would that make sense? If so, how could I make sure Cacti reads the data correctly.

If it helps at all, turning on verbose logging shows the following output:

11/19/2005 12:30:04 PM - CMDPHP: Poller[0] Host[7] DS[909] WARNING: Result from SNMP not valid. Partial Result:
11/19/2005 12:30:04 PM - CMDPHP: Poller[0] Host[7] DS[909] SNMP: v1: myhost.mydomain.com, dsname: traffic_in, oid: .1.3.6.1.4.1.2603.1.2.1.1.1.4.3, output: U

Where does it get that uppercase U from?

Thank you in advance for any assistance you can provide.

Post by **gandalf** » Fri Dec 09, 2005 3:21 pm

You are using snmp v1 but your examples show 64 bit counters . These are only supported for snmp v2c. So please change your device config in cacti to snmp v2 (this imples v2c).
Reinhard

ad7742 · Post by **ad7742** » Mon Feb 06, 2006 9:08 am

Reinhard

Thanks very much for your reply. Due to email issues, I did not realise anyone had got back to me on this.

I have changed the SNMP version being used and now I get back a more useful error mssage:

"No Such Instance currently exists at this OID"

This allows me to show that the ".0" at the end of the OID is unfortunately required - by running the snmpget command as follows:

# snmpget -v 2c -c COMMUNITYSTRING HOSTNAME .1.3.6.1.4.1.2603.1.2.1.1.1.9.2
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.9.2 = No Such Instance currently exists at this OID

# snmpget -v 2c -c COMMUNITYSTRING HOSTNAME .1.3.6.1.4.1.2603.1.2.1.1.1.9.2.0
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.9.2.0 = Counter64: 10087

Any ideas on how I could get round this? Thanks again for your help on this.

Post by **gandalf** » Mon Feb 06, 2006 3:05 pm

Is this a SNMP table? Then please have a look at the last walkthrough of my signature. Perhaps this may help
Reinhard

randomt · Post by **randomt** » Tue May 09, 2006 8:24 pm

Was there a resolution to this in the walkthrough that is no longer present? I didnt catch anything that would explain how one goes about getting cacti to query something like: oid.INDEX.1.1 for the output values, or perhaps it has been a long day and I am blind?

Post by **gandalf** » Wed May 10, 2006 11:32 am

ad7742 wrote:OID/REGEXP:.*\.([0-9]*)\.0$

This works fine.

However, here (finally) is the problem. When I run an SNMP walk against the BytesIn OID, I get the following:

SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.1.0 = Counter64: 970788937
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.2.0 = Counter64: 1960039165
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.3.0 = Counter64: 76166508372
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.4.0 = Counter64: 1425653257
SNMPv2-SMI::enterprises.2603.1.2.1.1.1.4.5.0 = Counter64: 5704847

Cacti does not seem to think that I'm getting any valid data back, presumably because for each Pipe it is trying to get data back from

.2603.1.2.1.1.1.4.1

instead of

.2603.1.2.1.1.1.4.1.0

I suppose you're close. Please post the result of a Verbose Query of that Associated Data Query.
Reinhard

Post by **gandalf** » Wed May 10, 2006 11:34 am

randomt wrote:Was there a resolution to this in the walkthrough that is no longer present? I didnt catch anything that would explain how one goes about getting cacti to query something like: oid.INDEX.1.1 for the output values, or perhaps it has been a long day and I am blind?

My walkthrough is still present. But you're correct, two dimensional indices are not dealt with. For this, you've to use the OID/REGEXP stuff like that found above. But this is a bit tricky, but doable. Please post your XML and the output of the corresponding snmpwalk to help you
Reinhard

randomt · Post by **randomt** » Wed May 10, 2006 12:10 pm

Here is the result from an snmpwwalk on this OID table.. the only information I am interested in falls under 1.3.6.1.4.1.3052.5.1.1.1.1.6.INDEX.1.1

(this is the omnitronix SL81 temperature oid table)

Code: Select all

snmpwalk -c ***** -v 1 x.x.x.x 1.3.6.1.4.1.3052.5.1.1.1.1.6                       
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.1.1 = INTEGER: 22
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.1 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.2 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.3 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.4 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.5 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.6 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.7 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.1.2.8 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.1.1 = INTEGER: 26
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.1 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.2 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.3 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.4 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.5 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.6 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.7 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.2.2.8 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.1.1 = INTEGER: 28
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.1 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.2 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.3 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.4 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.5 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.6 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.7 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.3.2.8 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.1.1 = INTEGER: 34
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.1 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.2 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.3 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.4 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.5 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.6 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.7 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.4.2.8 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.1.1 = INTEGER: 21
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.1 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.2 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.3 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.4 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.5 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.6 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.7 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.5.2.8 = INTEGER: 0
SNMPv2-SMI::enterprises.3052.5.1.1.1.1.6.200.1.1 = INTEGER: 30

I tried doing this:

Code: Select all

      <ifTemp>
         <name>Temperature</name>
         <method>walk</method>
         <source>value</source>
         <direction>output</direction>        <oid>OID/REGEXP:\.1\.3\.6\.1\.4\.1\.3052\.5\.1\.1\.1\.1\.6\.*\.1\.1$</oid>
      </ifTemp>

I gather that regex is not correct, but it was worth a shot..

Thanks

Post by **gandalf** » Wed May 10, 2006 3:29 pm

Try

Code: Select all

      <ifTemp>
         <name>Temperature</name>
         <method>walk</method>
         <source>value</source>
         <direction>output</direction>        <oid>OID/REGEXP:.*(\d*\.1\.1)$</oid>
      </ifTemp>

And post the result of the Verbose Query
Reinhard

randomt · Post by **randomt** » Wed May 10, 2006 3:58 pm

This is the result of this xml file in verbose mode:

Code: Select all

<query>
   <name>Get SNMP Probe Interfaces</name>
   <description>Queries the omnitronix for a list of monitorable temperature probes</description>
   <oid_index>.1.3.6.1.4.1.3052.5.2.1.2.1.1</oid_index>
   <oid_num_indexes>.1.3.6.1.4.1.3052.5.2.1.1</oid_num_indexes>
   <index_order>ifIndex:omniTemp</index_order>  
   <index_order_type>numeric</index_order_type>
   <index_title_format>|chosen_order_field|</index_title_format>
   <fields>
      <ifIndex>
         <name>Index</name>
         <method>walk</method>
         <source>value</source>
         <direction>input</direction>
         <oid>.1.3.6.1.4.1.3052.5.2.1.2.1.1</oid>
      </ifIndex>
      <omniTemp>
         <name>Temperature</name>
         <method>walk</method>
         <source>value</source>
         <direction>output</direction>
         <oid>OID/REGEXP:.*(\d*\.1\.1)$</oid> 
      </omniTemp>
   </fields>
</query>

Code: Select all

+ Running data query [13].
+ Found type = '3' [snmp query].
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ XML file parsed ok.
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.4.1.3052.5.2.1.2.1.1'
+ Located input field 'ifIndex' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.4.1.3052.5.2.1.2.1.1'
+ Found item [ifIndex='1'] index: 1 [from value]
+ Found item [ifIndex='2'] index: 2 [from value]
+ Found item [ifIndex='3'] index: 3 [from value]
+ Found item [ifIndex='4'] index: 4 [from value]
+ Found item [ifIndex='5'] index: 5 [from value]
+ Found item [ifIndex='200'] index: 200 [from value]
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'
+ Found data query XML file at '/srv/www-data/cacti/resource/snmp_queries/SL81.dataquery.xml'

randomt · Post by **randomt** » Wed May 10, 2006 4:31 pm

Not sure if this is significant, but I have another field

Code: Select all

      <omniName>
         <name>Name</name>
         <method>walk</method>
         <source>value</source>
         <direction>input</direction>
         <oid>OID/REGEXP:.*(\d*\.1\.1)$</oid>                                                                    
      </omniName>

gives:

Code: Select all

+ Located input field 'omniName' [walk]
+ Executing SNMP walk for data @ 'OID/REGEXP:.*(\d*\.1\.1)$'
+ Found item [omniName='SNMP-Link SL81 1.09 STDB'] index: 0 [from value]
+ Found item [omniName='OID: .1.3.6.1.4.1.3052.5.3.2'] index: 0 [from value]
+ Found item [omniName='554184400'] index: 0 [from value]
+ Found item [omniName=''] index: 0 [from value]
+ Found item [omniName=''] index: 0 [from value]
+ Found item [omniName=''] index: 0 [from value]
+ Found item [omniName='72'] index: 0 [from value]

which is the same result I get if i put <oid></oid> (empty field) - which is the same result i got reguardless of what regex i have tried up to date - possibly the <oid></oid> field doesnt accept a regex at all?

Post by **gandalf** » Thu May 11, 2006 1:20 pm

Oops, I made a mistake, sorry.
<oid_index_parse>OID/REGEXP: ...</oid_index_parse> must be added for the XML header, not for the field(s). See http://www.cacti.net/downloads/docs/htm ... y_xml.html for complete syntax. And please see http://forums.cacti.net/viewtopic.php?t=13089 (found it after some searches) where this type of problem was already discussed. You'll find a working example within
Reinhard

randomt · Post by **randomt** » Thu May 11, 2006 1:27 pm

Ah yes I have read those, but they don't address this particular situation..

The oid indexes are fine, its the actual output field that has an extra set of oid layers after the index.. Eventually I got tired of trying to trick cacti into accepting this, and instead just made a quick script that queries via snmp through perl and just appends the .1.1 to the output oid (after the index is appended first)

Once i have it all working nicely i'll likely post the templates for these omnitronix devices, likely others that use them for temperature monitoring would appreciate it :>

Post by **gandalf** » Thu May 11, 2006 2:05 pm

randomt wrote:The oid indexes are fine, its the actual output field that has an extra set of oid layers after the index.. Eventually I got tired of trying to trick cacti into accepting this, and instead just made a quick script that queries via snmp through perl and just appends the .1.1 to the output oid (after the index is appended first)

Sorry, didn't realize this. Hope you'll get it!
Reinhard

randomt · Post by **randomt** » Thu May 11, 2006 5:27 pm

Unfortunately I now have the same problem http://forums.cacti.net/viewtopic.php?t=13183 seemed to have, where everything is working as expected... except that the rdd creation never happens (so the graph generation chokes due to a file not found on the .rra).. i'll keep digging in the forums to see if someone else found a resolution to this time of thing. (no the debug log doesnt show anything particularely useful.. the only time my device shows up is for the one .rra hat i manually generated by copying the command shown from the debug mode of data-sources (although this graph doesnt seem to receive any information)

Oh if only there was a simple snmp mechanism to append something to the end of the oid after the script appends an index heh.. anyway i'll keep at it before starting to post screens and scripts and whatnot.. i am stubborn.

Cacti

Newbie OID issue

Newbie OID issue

Re: Newbie OID issue

Who is online