Where do mcc.py get its data from
NAV 3.10.1 We have several (but not all) routers and switches where cricket try to collect data fram OIDs the devices doesn't know anything about. I fail to find any similarities in type of device or OS-version between the devices. For a switch the offending lines in switches/navTargetTypes looks like this: targetType brusS101-sw.infra.uit.no ds = "c1900Bandwidth, c1900Bandwidth, c1900BandwidthMax, c1900BandwidthMax, mem5minFree, mem5minFree, mem5minUsed, mem5minUsed, sysUpTime, sysUpTime, c2900Bandwidth, c2900Bandwidth, c5000Bandwidth, c5000Bandwidth, c5000BandwidthMax, c5000BandwidthMax, cpu1min, cpu1min, cpu5min, cpu5min, hpcpu, hpcpu, hpmem5minFree, hpmem5minFree, hpmem5minUsed, hpmem5minUsed" view = "bandwidth: c1900Bandwidth c1900BandwidthMax c2900Bandwidth c5000Bandwidth c5000BandwidthMax, cpu: cpu1min cpu5min hpcpu, memory: hpmem5minFree hpmem5minUsed mem5minFree mem5minUsed, sysuptime: sysUpTime" Note that it tries to collect both c1900Bandwidth, c2900Bandwidth and c5000Bandwidth When I check the device via https://nav.example.com/report/netboxsnmpoid?netbox id=## I don't find any OIDs relating to Bandwidth at all. For Cisco routers the offending OID is hpcpu and hpmem*. targetType kulth-gsw.infra.uit.no ds = "c5000Bandwidth, c5000BandwidthMax, cpu1min, cpu5min, hpcpu, hpmem5minFree, hpmem5minUsed, mem5minFree, mem5minUsed, sysUpTime" view = "bandwidth: c5000Bandwidth c5000BandwidthMax, cpu: cpu1min cpu5min hpcpu, memory: hpmem5minFree hpmem5minUsed mem5minFree mem5minUsed, sysuptime: sysUpTime" Any ideas why mcc.py puts them in? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo@uit.no Dep. of Information Technology --- Univ. of Tromsø
Den 05.01.2012 12:42, skrev Ingeborg Hellemo:
NAV 3.10.1
We have several (but not all) routers and switches where cricket try to collect data fram OIDs the devices doesn't know anything about. I fail to find any similarities in type of device or OS-version between the devices.
Any ideas why mcc.py puts them in?
You are most probably experiencing the same bug as was reported on several toolboxes. The rrd-database has somehow, sometime been populated with all possible datasources for each rrd-file. A bug/inconsistency prevents mcc from cleaning this mess. So what should you do? Hopefully cleaning the rrd-database will help you. Try to delete all records regarding routers and switches (not interfaces) in rrd_file. -- John-Magne Bredal IT-Avdelingen Norges teknisk-naturvitenskaplige universitet (NTNU) Mob: 91 89 73 66
I have just installed NAV 3.10.3 and configured the new /sensors-subtree i cricket. That didn't work very well. For several switches I get [01-Mar-2012 13:21:16*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1 This OID is not listed as supported when I check the "Report > IP Device SNMP OID support" for the boxes. A second bug is an ups which is missing read only community. Still a /sensors-subtree is created with the line snmp-community = This makes cricket-compile to report an error: [01-Mar-2012 13:13:58*] Missing equals sign at (or before) /usr/local/cricket/cricket-config/sensors/mv110-c107-ups.infra.uit.no/navTarget s line 6. --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo@uit.no Dep. of Information Technology --- Univ. of Tromsø
On Thu, 01 Mar 2012 13:36:54 +0100 Ingeborg Hellemo <ingeborg.hellemo@uit.no> wrote:
For several switches I get
[01-Mar-2012 13:21:16*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1
This OID is not listed as supported when I check the "Report > IP Device SNMP OID support" for the boxes.
And it wouldn't be; this OID is CISCO-ENVMON-MIB::ciscoEnvMonTemperatureStatusValue.1 - NAV claims to have found a temperature sensor in CISCO-ENVMON-MIB with the particular snmp id of 1. This sensor should be listed in the sensor database table for this netbox. Can you confirm this?
A second bug is an ups which is missing read only community. Still a /sensors-subtree is created with the line snmp-community =
This makes cricket-compile to report an error: [01-Mar-2012 13:13:58*] Missing equals sign at (or before) /usr/local/cricket/cricket-config/sensors/mv110-c107-ups.infra.uit.no/navTarget s line 6.
Well, that is certainly stupid. The sensors configuration plugin doesn't verify that the community is set (it probably should), but then it only picks netboxes in which NAV has found environment sensors. Did the UPS at one point have an SNMP community set in NAV? -- Morten Brekkevold UNINETT
On Thu, 01 Mar 2012 13:36:54 +0100 Ingeborg Hellemo <ingeborg.hellemo@uit.no> wrote:
For several switches I get
[01-Mar-2012 13:21:16*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1
This OID is not listed as supported when I check the "Report > IP Device SNMP OID support" for the boxes.
And it wouldn't be; this OID is CISCO-ENVMON-MIB::ciscoEnvMonTemperatureStatusValue.1 - NAV claims to have found a temperature sensor in CISCO-ENVMON-MIB with the particular snmp id of 1.
This sensor should be listed in the sensor database table for this netbox. Can you confirm this?
After upgrading to 3.11.0 this has magically corrected itself, but for one box. In 'sensor' I find two rows with oid=.1.3.6.1.4.1.9.9.13.1.5.1.3.[12]. So I guess if I just remove these everything will be OK?
A second bug is an ups which is missing read only community. Still a /sensors-subtree is created with the line snmp-community =
This makes cricket-compile to report an error: [01-Mar-2012 13:13:58*] Missing equals sign at (or before) /usr/local/cricket/cricket-config/sensors/mv110-c107-ups.infra.uit.no/navTarget s line 6.
Well, that is certainly stupid. The sensors configuration plugin doesn't verify that the community is set (it probably should), but then it only picks netboxes in which NAV has found environment sensors. Did the UPS at one point have an SNMP community set in NAV?
I guess the SNMP community has once been set. And I would like to set it again, but when I edit the device I get TypeMismatchError at /seeddb/netbox/edit/1853/ Octet-stream parse error at Pdus Request Method: POST Request URL: https://nav.uit.no/seeddb/netbox/edit/1853/ Django Version: 1.3.1 Exception Type: TypeMismatchError Exception Value: Octet-stream parse error at Pdus Exception Location: /usr/local/lib/python2.7/site-packages/pysnmp/asn1/encodin g/ber/base.py in berDecode, line 370 Python Executable: /usr/local/bin/python Python Version: 2.7.2 If I use a wrong community I get this error after "Continue" on the first page of /seeddb/netbox/edit/1853/. If I use the correct community I do not get the error until I press "Save" on the second page. As a fix for now I will set the community directly into the database. --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo@uit.no Dep. of Information Technology --- Univ. of Tromsø
On Fri, 16 Mar 2012 09:33:58 +0100 Ingeborg Hellemo <ingeborg.hellemo@uit.no> wrote:
After upgrading to 3.11.0 this has magically corrected itself, but for one box.
In 'sensor' I find two rows with oid=.1.3.6.1.4.1.9.9.13.1.5.1.3.[12]. So I guess if I just remove these everything will be OK?
Ok, that was strange. Since you don't have an SNMP community set for the UPS, its pre-existing list of sensors should never be edited by NAV (since the SNMP collector doesn't run for that UPS any more). But yes, deleting the sensor entries related to the UPS' netboxid should do the trick. I'll whip up a patch to _not_ generate cricket-config for sensors for devices without a community.
I guess the SNMP community has once been set. And I would like to set it again, but when I edit the device I get
TypeMismatchError at /seeddb/netbox/edit/1853/
Octet-stream parse error at Pdus
Request Method: POST Request URL: https://nav.uit.no/seeddb/netbox/edit/1853/ Django Version: 1.3.1 Exception Type: TypeMismatchError Exception Value:
Octet-stream parse error at Pdus
Exception Location: /usr/local/lib/python2.7/site-packages/pysnmp/asn1/encodin g/ber/base.py in berDecode, line 370 Python Executable: /usr/local/bin/python Python Version: 2.7.2
If I use a wrong community I get this error after "Continue" on the first page of /seeddb/netbox/edit/1853/. If I use the correct community I do not get the error until I press "Save" on the second page.
Another device with a wonky SNMP implementation? Do you have a full traceback from the error? If so, please file a bug report: https://bugs.launchpad.net/nav/+filebug
As a fix for now I will set the community directly into the database.
Ok. No problems with the device in ipdevpoll.log then? -- Morten Brekkevold UNINETT
On Fri, 16 Mar 2012 09:33:58 +0100 Ingeborg Hellemo <ingeborg.hellemo@uit.no> wrote:
After upgrading to 3.11.0 this has magically corrected itself, but for one box.
In 'sensor' I find two rows with oid=.1.3.6.1.4.1.9.9.13.1.5.1.3.[12]. So I guess if I just remove these everything will be OK?
Ok, that was strange. Since you don't have an SNMP community set for the UPS, its pre-existing list of sensors should never be edited by NAV (since the SNMP collector doesn't run for that UPS any more).
No, these two issues were unrelated. The device with the unknown OID was a switch with correct community-settings. Over the weekend the troublesome OID has removed itself from the 'sensor'-table and the cricket-config is correct. Go figure.
But yes, deleting the sensor entries related to the UPS' netboxid should do the trick. I'll whip up a patch to _not_ generate cricket-config for sensors for devices without a community.
That would be sensible.
I guess the SNMP community has once been set. And I would like to set it again, but when I edit the device I get
TypeMismatchError at /seeddb/netbox/edit/1853/
Octet-stream parse error at Pdus
Another device with a wonky SNMP implementation? Do you have a full traceback from the error? If so, please file a bug report: https://bugs.launchpad.net/nav/+filebug
Will do.
As a fix for now I will set the community directly into the database.
Ok. No problems with the device in ipdevpoll.log then?
Well, we get a lot of [WARNING twsnmp.protocol] Bad response from ('129.242.35.52', 161): '0&\x02\x01\x01\x04\x06<SNMPCOMMUNITY>\xa2\x1e\x02\x03#S\xb1\x02\x01\x05\x02\x0 1\x000\x0c0\n\x06\x06+\x06\x01\x02\x01\x01\x05\x00' but we also get these from other devices which do not crash the webinterface. --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo@uit.no Dep. of Information Technology --- Univ. of Tromsø
On Mon, 19 Mar 2012 11:01:28 +0100 Ingeborg Hellemo <ingeborg.hellemo@uit.no> wrote:
But yes, deleting the sensor entries related to the UPS' netboxid should do the trick. I'll whip up a patch to _not_ generate cricket-config for sensors for devices without a community. That would be sensible.
The patch will be in 3.11.1.
Another device with a wonky SNMP implementation? Do you have a full traceback from the error? If so, please file a bug report: https://bugs.launchpad.net/nav/+filebug
Will do.
Thanks!
As a fix for now I will set the community directly into the database.
Ok. No problems with the device in ipdevpoll.log then?
Well, we get a lot of [WARNING twsnmp.protocol] Bad response from ('129.242.35.52', 161): '0&\x02\x01\x01\x04\x06<SNMPCOMMUNITY>\xa2\x1e\x02\x03#S\xb1\x02\x01\x05\x02\x0 1\x000\x0c0\n\x06\x06+\x06\x01\x02\x01\x01\x05\x00' but we also get these from other devices which do not crash the webinterface.
For this error I would prescribe: Try to get rid of twistedsnmp and use pynetsnmp instead, if you can. I do trust NetSNMP a whole lot more than twistedsnmp. -- Morten Brekkevold UNINETT
morten.brekkevold@uninett.no said:
For this error I would prescribe: Try to get rid of twistedsnmp and use pynetsnmp instead, if you can.
When you say 'pynetsnmp', is this what you mean? <http://pynetsnmp.sourcearchive.com/> --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo@uit.no Dep. of Information Technology --- Univ. of Tromsø
On Mon, 19 Mar 2012 13:48:50 +0100 Ingeborg Hellemo <ingeborg.hellemo@uit.no> wrote:
morten.brekkevold@uninett.no said:
For this error I would prescribe: Try to get rid of twistedsnmp and use pynetsnmp instead, if you can.
When you say 'pynetsnmp', is this what you mean? <http://pynetsnmp.sourcearchive.com/>
Why, yes I do :) -- Morten Brekkevold UNINETT
participants (3)
-
Ingeborg Hellemo -
John-Magne Bredal -
Morten Brekkevold