MIB Protocol Statistics (RFC1213) [v2.1 - 2009-05-10]
Moderators: Developers, Moderators
-
- Posts: 5
- Joined: Mon Sep 07, 2009 2:40 pm
- Location: San Francisco
OID Index for Fedora release 8?
Guys:
This data query looks great, and it would be extremely useful for some things I am working on. I am having difficulty getting it to work for monitoring a Fedora release 8 system, though.
Some additional information:
- I am running Cacti 0.8.7b. I dropped the version number in the template to be able to import it. I know this is a nono, but I can't upgrade the cacti version right now.
- I am already monitoring other services via the SNMP system. Specifically, I am using the interface.xml script to monitor the ethernet traffic.
- I am using Net-SNMP 5.4.
I suspect that the OID index is incorrect. When I pull the data associated with the default OID index (.1.3.6.1.2.1.7.2), I get:
UDP-MIB::udpNoPorts.0 = Counter32: 14
Or the number of UDP packets that arrived with no port.
The data query does execute in Cacti, but it returns only 1 SNMP data point, which is the UDP data, I suspect.
Any pointers here?
Thanks!
This data query looks great, and it would be extremely useful for some things I am working on. I am having difficulty getting it to work for monitoring a Fedora release 8 system, though.
Some additional information:
- I am running Cacti 0.8.7b. I dropped the version number in the template to be able to import it. I know this is a nono, but I can't upgrade the cacti version right now.
- I am already monitoring other services via the SNMP system. Specifically, I am using the interface.xml script to monitor the ethernet traffic.
- I am using Net-SNMP 5.4.
I suspect that the OID index is incorrect. When I pull the data associated with the default OID index (.1.3.6.1.2.1.7.2), I get:
UDP-MIB::udpNoPorts.0 = Counter32: 14
Or the number of UDP packets that arrived with no port.
The data query does execute in Cacti, but it returns only 1 SNMP data point, which is the UDP data, I suspect.
Any pointers here?
Thanks!
The index IS correct, as I'm merely using it to create a 'fake index' for Cacti. Just pealing off the last OID of ".0" with the REGEX. Only problem which you could possibly have with that, is if your OS does not respond to .1.3.6.1.2.1.7.2.
As for your lack of data... you are not getting any graphs, they're blank, errors in the cacti.log, other?
Able to snmpwalk .1.3.6.1.2.1.4.3, .1.3.6.1.2.1.6.10, .1.3.6.1.2.1.11.1, and .1.3.6.1.2.1.5.1 and data is returned?
As for your lack of data... you are not getting any graphs, they're blank, errors in the cacti.log, other?
Able to snmpwalk .1.3.6.1.2.1.4.3, .1.3.6.1.2.1.6.10, .1.3.6.1.2.1.11.1, and .1.3.6.1.2.1.5.1 and data is returned?
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
-
- Posts: 5
- Joined: Mon Sep 07, 2009 2:40 pm
- Location: San Francisco
The OS does respond to .1.3.6.1.2.1.7.2: UDP-MIB::udpNoPorts.0 = Counter32: 14. This is a Fedora core 8 based distribution running Net SNMP 5.4BSOD2600 wrote:The index IS correct, as I'm merely using it to create a 'fake index' for Cacti. Just pealing off the last OID of ".0" with the REGEX. Only problem which you could possibly have with that, is if your OS does not respond to .1.3.6.1.2.1.7.2.
As for your lack of data... you are not getting any graphs, they're blank, errors in the cacti.log, other?
Able to snmpwalk .1.3.6.1.2.1.4.3, .1.3.6.1.2.1.6.10, .1.3.6.1.2.1.11.1, and .1.3.6.1.2.1.5.1 and data is returned?
Also, I can snmpwalk all four of those OIDs and I get data returned.
When I run the query in the UI, I get:
Code: Select all
+ Running data query [13].
+ Found type = '3' [snmp query].
+ Found data query XML file at '/usr/share/cacti/resource/snmp_queries/RFC1213.xml'
+ XML file parsed ok.
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.2.1.7.2'
+ Inserting index data [value='0']
+ Found data query XML file at '/usr/share/cacti/resource/snmp_queries/RFC1213.xml'
+ Found data query XML file at '/usr/share/cacti/resource/snmp_queries/RFC1213.xml'
+ Found data query XML file at '/usr/share/cacti/resource/snmp_queries/RFC1213.xml'
The graphs generated from this data are blank.
Any recommendations on where to look next?
That is correct. It found/created the fake index.Adam O'Donnell wrote:When I run the query in the UI, I get:
You went to the 'Create graphs for this device' screen to create the graphs, right?Adam O'Donnell wrote:The graphs generated from this data are blank.
Change the cacti logging level to medium (or higher). Look what data is returned for the various protocol stats queries against that device.
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
-
- Posts: 5
- Joined: Mon Sep 07, 2009 2:40 pm
- Location: San Francisco
It does look like the SNMP query is firing correctly:BSOD2600 wrote:That is correct. It found/created the fake index.Adam O'Donnell wrote:When I run the query in the UI, I get:
You went to the 'Create graphs for this device' screen to create the graphs, right?Adam O'Donnell wrote:The graphs generated from this data are blank.
Change the cacti logging level to medium (or higher). Look what data is returned for the various protocol stats queries against that device.
Code: Select all
09/11/2009 12:15:03 AM - CMDPHP: Poller[0] Host[3] DS[74] SNMP: v2: IPADDR1, dsname: udpInErrors, oid: .1.3.6.1.2.1.7.3.0, output: 29330
09/11/2009 12:15:03 AM - CMDPHP: Poller[0] Host[3] DS[74] SNMP: v2: IPADDR2, dsname: udpNoPorts, oid: .1.3.6.1.2.1.7.2.0, output: 10
09/11/2009 12:15:03 AM - CMDPHP: Poller[0] Host[4] DS[76] SNMP: v2: IPADDR2, dsname: udpInErrors, oid: .1.3.6.1.2.1.7.3.0, output: 29727
It wouldn't hurt, since you apparently don't have any data stored.Adam O'Donnell wrote:The graphs are still blank, though. Should I delete the graphs or the data source and start over?
Please post a graph debug output of one of the graphs. Also, with the cacti logging level set to debug, trace what happens to the data from Host[3] DS[74]. We're looking for the rrdtool update command... manually running the update command that cacti used, does it work?
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
-
- Posts: 5
- Joined: Mon Sep 07, 2009 2:40 pm
- Location: San Francisco
Graph creation looks fine:BSOD2600 wrote:It wouldn't hurt, since you apparently don't have any data stored.Adam O'Donnell wrote:The graphs are still blank, though. Should I delete the graphs or the data source and start over?
Please post a graph debug output of one of the graphs. Also, with the cacti logging level set to debug, trace what happens to the data from Host[3] DS[74]. We're looking for the rrdtool update command... manually running the update command that cacti used, does it work?
Code: Select all
RRDTool Command:
/usr/bin/rrdtool graph - \
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title="Server0 - UDP Protocol Statistics" \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--alt-autoscale \
--vertical-label="per 5 minutes" \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/usr/share/cacti/rra/server0_udpnoports_77.rrd":udpInErrors:AVERAGE \
DEF:b="/usr/share/cacti/rra/server0_udpnoports_77.rrd":udpInErrors:MAX \
DEF:c="/usr/share/cacti/rra/server0_udpnoports_77.rrd":udpNoPorts:AVERAGE \
DEF:d="/usr/share/cacti/rra/server0_udpnoports_77.rrd":udpNoPorts:MAX \
CDEF:cdefa=a,300,* \
CDEF:cdefd=b,300,* \
CDEF:cdefe=c,300,* \
CDEF:cdefh=d,300,* \
AREA:cdefa#FF5700FF:"udpInErrors" \
GPRINT:cdefa:LAST:"Current\:%8.2lf %s" \
GPRINT:cdefa:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:cdefd:MAX:"Maximum\:%8.2lf %s\n" \
AREA:cdefe#C4FD3DFF:"udpNoPorts":STACK \
GPRINT:cdefe:LAST:" Current\:%8.2lf %s" \
GPRINT:cdefe:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:cdefh:MAX:"Maximum\:%8.2lf %s\n"
RRDTool Says:
OK
Code: Select all
<!-- 2009-09-11 01:50:00 EDT / 1252648200 --> <row><v> 0.0000000000e+00 </v><v> 0.0000000000e+00 </v></row>
-
- Posts: 5
- Joined: Mon Sep 07, 2009 2:40 pm
- Location: San Francisco
Issues with RFC1213 stats tools in ubuntu 8.04 with SNMP v2
Hi folks: Warning Cacti "rookie" here...
I have cacti 0.8.7e on ubuntu 8.04LTS running successfully in my installation, generating queries and graphs such as CPU & memory, & generic interface traffic stats. I know that snmp queries are reliable as when I go to the devices page for a particular device, and do a verbose query, I get "reliable" data. An example, the generic CPU query...
I wish to enable the RFC 1213 statistics tools. I have installed the tools from the installation package and confirmed that they are in place with what I believe are correct permissions: (correctly "owned" by the cacti user for the machine that is serving as cacti server)
I also imported the data query template cacti_data_query_rfc1213_statistics.xml as per instructions.
Problem is that when the RFC1213 query is added to a particular device, cacti reports "success" in adding the query, but reports 0 items and 0 rows. When I run the verbose query the response is as follows
Following some of the other posts in this thread, I ssh to the local machine and do some snmpwalk attempts (making sure to use snmp v2 as that is the configuration for the snmpd on the machines I am querying)
if i query in the 'public' side:
If I "go up" a couple of levels in the mib, success. (note: this is trimmed for privacy, and to save space... )
I would appreciate recommendations for where to look from here to understand why the stats with this RFC1213 are not successfully visible.
I'm guessing there is something wrong in the snmpd.conf, but the snmpd.conf "looks" pretty generic.
Note: in an earlier post BSOD suggested some other 'walks'
Running those reports errors, which very much makes me think its an snmpd.conf issue...
Thank you for any suggestions.
I have cacti 0.8.7e on ubuntu 8.04LTS running successfully in my installation, generating queries and graphs such as CPU & memory, & generic interface traffic stats. I know that snmp queries are reliable as when I go to the devices page for a particular device, and do a verbose query, I get "reliable" data. An example, the generic CPU query...
Code: Select all
+ Running data query [9].
+ Found type = '6 '[script query].
+ Found data query XML file at '/usr/share/cacti/site/resource/script_server/host_cpu.xml'
+ XML file parsed ok.
+ Executing script for list of indexes '/usr/bin/php -q /usr/share/cacti/site/scripts/ss_host_cpu.php 192.168.125.10 5 2:161:500:1:10:private:::MD5::DES: index'
+ Executing script query '/usr/bin/php -q /usr/share/cacti/site/scripts/ss_host_cpu.php 192.168.125.10 5 2:161:500:1:10:private:::MD5::DES: query index'
+ Found item [hrProcessorFrwID='0'] index: 0
+ Found item [hrProcessorFrwID='1'] index: 1
+ Found item [hrProcessorFrwID='2'] index: 2
+ Found item [hrProcessorFrwID='3'] index: 3
+ Found item [hrProcessorFrwID='4'] index: 4
+ Found item [hrProcessorFrwID='5'] index: 5
+ Found item [hrProcessorFrwID='6'] index: 6
+ Found item [hrProcessorFrwID='7'] index: 7
+ Found data query XML file at '/usr/share/cacti/site/resource/script_server/host_cpu.xml'
+ Found data query XML file at '/usr/share/cacti/site/resource/script_server/host_cpu.xml'
+ Found data query XML file at '/usr/share/cacti/site/resource/script_server/host_cpu.xml'
+ Found data query XML file at '/usr/share/cacti/site/resource/script_server/host_cpu.xml'
I wish to enable the RFC 1213 statistics tools. I have installed the tools from the installation package and confirmed that they are in place with what I believe are correct permissions: (correctly "owned" by the cacti user for the machine that is serving as cacti server)
I also imported the data query template cacti_data_query_rfc1213_statistics.xml as per instructions.
Problem is that when the RFC1213 query is added to a particular device, cacti reports "success" in adding the query, but reports 0 items and 0 rows. When I run the verbose query the response is as follows
Code: Select all
+ Running data query [10].
+ Found type = '3' [snmp query].
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/RFC1213.xml'
+ XML file parsed ok.
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.2.1.7.2'
+ No SNMP data returned
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/RFC1213.xml'
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/RFC1213.xml'
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/RFC1213.xml'
Code: Select all
snmpwalk -v 2c localhost -c private .1.3.6.1.2.1.7.2.0
UDP-MIB::udpNoPorts.0 = No Such Object available on this agent at this OID
Code: Select all
snmpwalk -v 2c localhost -c public .1.3.6.1.2.1.7.2.0
UDP-MIB::udpNoPorts.0 = No more variables left in this MIB View (It is past the end of the MIB tree)
Code: Select all
snmpwalk -v 2c localhost -c private .1.3.6.1.2.1
SNMPv2-MIB::sysDescr.0 = STRING: Linux banana 2.6.24-24-generic #1 SMP Fri Sep 18 16:16:18 UTC 2009 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (14708) 0:02:27.08
SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)
................deleted..............
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (0) 0:00:00.00
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: eth2
IF-MIB::ifDescr.4 = STRING: eth1
IF-MIB::ifType.1 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.4 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifMtu.1 = INTEGER: 16436
IF-MIB::ifMtu.2 = INTEGER: 9000
IF-MIB::ifMtu.3 = INTEGER: 1500
IF-MIB::ifMtu.4 = INTEGER: 1500
IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 10000000
IF-MIB::ifSpeed.3 = Gauge32: 10000000
IF-MIB::ifSpeed.4 = Gauge32: 10000000
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.2 = STRING: 0:21:91:21:1a:a6
IF-MIB::ifPhysAddress.3 = STRING: 0:23:ae:76:f0:a5
IF-MIB::ifPhysAddress.4 = STRING: 0:21:91:19:7b:4b
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
IF-MIB::ifAdminStatus.4 = INTEGER: up(1)
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: up(1)
IF-MIB::ifOperStatus.4 = INTEGER: up(1)
IF-MIB::ifLastChange.1 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.2 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.3 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.4 = Timeticks: (0) 0:00:00.00
IF-MIB::ifInOctets.1 = Counter32: 325103853
IF-MIB::ifInOctets.2 = Counter32: 1318443194
IF-MIB::ifInOctets.3 = Counter32: 306457298
IF-MIB::ifInOctets.4 = Counter32: 7104497
IF-MIB::ifInUcastPkts.1 = Counter32: 181598
IF-MIB::ifInUcastPkts.2 = Counter32: 4376547
IF-MIB::ifInUcastPkts.3 = Counter32: 399624
IF-MIB::ifInUcastPkts.4 = Counter32: 36696
IF-MIB::ifInNUcastPkts.1 = Counter32: 0
IF-MIB::ifInNUcastPkts.2 = Counter32: 30
IF-MIB::ifInNUcastPkts.3 = Counter32: 0
IF-MIB::ifInNUcastPkts.4 = Counter32: 0
IF-MIB::ifInDiscards.1 = Counter32: 0
IF-MIB::ifInDiscards.2 = Counter32: 0
IF-MIB::ifInDiscards.3 = Counter32: 0
IF-MIB::ifInDiscards.4 = Counter32: 0
IF-MIB::ifInErrors.1 = Counter32: 0
IF-MIB::ifInErrors.2 = Counter32: 0
IF-MIB::ifInErrors.3 = Counter32: 0
IF-MIB::ifInErrors.4 = Counter32: 0
IF-MIB::ifInUnknownProtos.1 = Counter32: 0
IF-MIB::ifInUnknownProtos.2 = Counter32: 0
IF-MIB::ifInUnknownProtos.3 = Counter32: 0
IF-MIB::ifInUnknownProtos.4 = Counter32: 0
IF-MIB::ifOutOctets.1 = Counter32: 325103853
IF-MIB::ifOutOctets.2 = Counter32: 75815
IF-MIB::ifOutOctets.3 = Counter32: 247600356
IF-MIB::ifOutOctets.4 = Counter32: 7499218
IF-MIB::ifOutUcastPkts.1 = Counter32: 181598
IF-MIB::ifOutUcastPkts.2 = Counter32: 1174
IF-MIB::ifOutUcastPkts.3 = Counter32: 351565
IF-MIB::ifOutUcastPkts.4 = Counter32: 33825
IF-MIB::ifOutNUcastPkts.1 = Counter32: 0
IF-MIB::ifOutNUcastPkts.2 = Counter32: 0
IF-MIB::ifOutNUcastPkts.3 = Counter32: 0
IF-MIB::ifOutNUcastPkts.4 = Counter32: 0
IF-MIB::ifOutDiscards.1 = Counter32: 0
IF-MIB::ifOutDiscards.2 = Counter32: 0
IF-MIB::ifOutDiscards.3 = Counter32: 0
IF-MIB::ifOutDiscards.4 = Counter32: 0
IF-MIB::ifOutErrors.1 = Counter32: 0
IF-MIB::ifOutErrors.2 = Counter32: 0
IF-MIB::ifOutErrors.3 = Counter32: 0
IF-MIB::ifOutErrors.4 = Counter32: 0
IF-MIB::ifOutQLen.1 = Gauge32: 0
IF-MIB::ifOutQLen.2 = Gauge32: 0
IF-MIB::ifOutQLen.3 = Gauge32: 0
IF-MIB::ifOutQLen.4 = Gauge32: 0
.........deleted.............
I would appreciate recommendations for where to look from here to understand why the stats with this RFC1213 are not successfully visible.
I'm guessing there is something wrong in the snmpd.conf, but the snmpd.conf "looks" pretty generic.
Note: in an earlier post BSOD suggested some other 'walks'
Running those reports errors, which very much makes me think its an snmpd.conf issue...
Code: Select all
snmpwalk -v 2c localhost -c private .1.3.6.1.2.1.4.3
IP-MIB::ipInReceives = No Such Object available on this agent at this OID
snmpwalk -v 2c localhost -c private .1.3.6.1.2.1.6.10
TCP-MIB::tcpInSegs = No Such Object available on this agent at this OID
snmpwalk -v 2c localhost -c private .1.3.6.1.2.1.11.1
SNMPv2-MIB::snmpInPkts = No Such Object available on this agent at this OID
snmpwalk -v 2c localhost -c private .1.3.6.1.2.1.5.1
IP-MIB::icmpInMsgs = No Such Object available on this agent at this OID
Looks like you've narrowed down the issue pretty well. Unfortunately, I'm not a linux person and have no idea why those MIB files aren't loaded for your snmp agent.
Probably would receive more help if you reposted this issue/question in the linux forum... just let them know the IP-MIB, TCP-MIB, SNMPv2-MIB (basically those OIDs you last tried to snmpwalk) are not working, yet other snmp queries are just fine on that server.
Probably would receive more help if you reposted this issue/question in the linux forum... just let them know the IP-MIB, TCP-MIB, SNMPv2-MIB (basically those OIDs you last tried to snmpwalk) are not working, yet other snmp queries are just fine on that server.
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
Partially solved.
the problem was with the snmpd.conf blocking the data being presented out of the RFC1213 mib.
"for now" I've opened up the snmpd.conf with fewer restrictions while I figure out how to get the data that I want "released" while maintaining the privacy of the SNMP that we need. When I get that sorted, I will put in a follow up post.
"for now" I've opened up the snmpd.conf with fewer restrictions while I figure out how to get the data that I want "released" while maintaining the privacy of the SNMP that we need. When I get that sorted, I will put in a follow up post.
- RaduAlexandru
- Posts: 43
- Joined: Mon Mar 28, 2005 5:06 pm
- Location: Bucharest, Romania
- Contact:
Yes
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
- RaduAlexandru
- Posts: 43
- Joined: Mon Mar 28, 2005 5:06 pm
- Location: Bucharest, Romania
- Contact:
-
- Posts: 2
- Joined: Wed Nov 11, 2009 7:33 pm
MIB Protocol Statistics (RFC1213)
As a cacti newbie, I have a question about Data Queries. I imported the RFC1213 template successfully. The cacti log show that the snmp query is returning a U for the OID. When I manually snmpget the OID I get no reply, which explains the "U". I can snmpwalk the tree on the host in question, so no snmp problems here. How is the OID that I see in the logs determined? I don't believe it is in the XML file. Is a snmpwalk performed at template import time that stores the OID into the DB? It looks like the wrong OID is being used.Any suggestions?
Who is online
Users browsing this forum: No registered users and 2 guests