On Thu, Aug 28, 2008 at 03:24:58PM +0200, Morten Brekkevold wrote:
On Tue, 19 Aug 2008 17:35:44 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
Error and the lines leading up to it: [14-Aug-2008 14:40:01 ] Some data is missing for b1-l1-cat1 (). [14-Aug-2008 14:40:01*] Received SNMP response with error code noSuchName. OID: 1.3.6.1.4.1.9.9.13.1.3.1.3.1
And yet if I look at the SNMP OID support listed for the device as reported by NAV I see:
b1-l1-cat1 tempInlet 1.3.6.1.4.1.9.9.13.1.3.1.3.1 CISCO-ENVMON-MIB ciscoEnvMonTemperatureStatusValue 21600
which implies the OID is supported, and is the device inlet temperature.
Is there some additional IOS config required to make this particular data available to Cricket? Being new to OIDs, I'm confused as to why it seems to be available according to NAV, yet Cricket's getting an error.
I'm sorry to say that NAV's support for monitoring temperatures on Cisco devices is hopelessly broken.
The abovementioned OID refers to the temperature value of a temperature sensor indexed as 1 in the proprietary CISCO-ENVMON-MIB. NAV assumes this is the inlet temperature sensor. However, the MIB definition states that the sensor indices are arbitrarily chosen by the device, and have no intrinsic meaning. The name of each sensor must be read from a different column of the temperature table.
The equipment base this was written for (several years ago) may very well have had their inlet sensors indexed as 1 in the temperature table, but recent IOS versions seem to have changed things.
b1-l1-cat1 may have indexed one of its temperature sensors as 1 during the initial import into NAV, and then changed its mind at a later time. That would account for the problem you're having.
Thanks for the explanation. What then is the recommended way to suppress errors related to this OID? NAV kindly generates email alerts for errors when querying devices, we just have a few too many related to this OID :)
Is there a recommended way to configure NAV to not poll our 3750 stacks for temp data? I see there are config files under Cricket for generic routers and switches with this OID, i.e.:
/etc/nav/cricket-config/routers/Defaults /etc/nav/cricket-config/switches/Defaults
And also some reference in
/etc/nav/cricketoids.txt /etc/nav/cricket-config/config.db
It looks like Cricket generates the Defaults file and the config.db each night, while cricketoids.txt is static, but it's not clear to us where those nightly builds are driven from (i.e. where we could remove/suppress the temp entry).
It sounds like even using snmpwalk to grab the current indexed value wouldn't help as it is liable to change.
The temperature queries work just fine for our Cisco 6509, so ideally we wouldn't want to generically remove temp readings for everything.
A week ago I knew far less about OIDs and I think I was better for it :)
Thanks, Tim
On Thu, 28 Aug 2008 15:18:12 +0100 Tim Chown tjc@ecs.soton.ac.uk wrote:
b1-l1-cat1 may have indexed one of its temperature sensors as 1 during the initial import into NAV, and then changed its mind at a later time. That would account for the problem you're having.
Thanks for the explanation. What then is the recommended way to suppress errors related to this OID? NAV kindly generates email alerts for errors when querying devices, we just have a few too many related to this OID :)
There is no recommended way, really. Cricket is a noisy fellow, complaining about every little thing that annoys it, and since it normally runs every five minutes, it annoys the heck out of many a sysadmin during the course of a day.
Most installations I've run into either direct cron-mail from Cricket into /dev/null, or put it into a mailbox they check less often than their inbox. It's output is not all terribly useful.
Is there a recommended way to configure NAV to not poll our 3750 stacks for temp data?
You could re-profile them and see whether NAV notices that they don't support that OID anymore.
As each SNMP-enabled device is entered into NAV, getDeviceData will make a profile of which OIDs it responds to. This profile is available in the report system: Find a device in the "All IP Devices" report, click on the number in the SNMP column (if the column is empty, it means that no OIDs exist in the profile, or the device has not yet been profiled). If NAV thinks the device responds to the offending temperature OID, it will be listed there.
A device will normally only be re-profiled if its software version changes, or NAV detects it has been replaced (i.e. serial number has changed). You can manually trigger a re-profiling of a device:
First go to Edit Database, edit the device and click the Update-button without making any actual changes. This step invalidates the OID profile.
Then look up the device in IP Device Center and click the "Refresh" link to trigger getDeviceData to start polling the device immediately. gDD will see the OID profile has been invalidated and will start re-profiling (this part of gDD is called the OID tester, or OID_TEST in the logs).
If you wish to re-profile a batch of devices, you have to tinker with a little SQL.
I see there are config files under Cricket for generic routers and switches with this OID, i.e.:
/etc/nav/cricket-config/routers/Defaults /etc/nav/cricket-config/switches/Defaults
And also some reference in
/etc/nav/cricketoids.txt /etc/nav/cricket-config/config.db
It looks like Cricket generates the Defaults file and the config.db each night, while cricketoids.txt is static, but it's not clear to us where those nightly builds are driven from (i.e. where we could remove/suppress the temp entry).
What happens is this: NAV runs a nightly job (makecricketconfig.pl) which will generate/update the Cricket configuration files from scratch, based on the contents of the NAV database. The device OID profiles are what mainly defines which OIDs are configured to be collected by Cricket. The Defaults files you refer to are the config files updated by NAV.
Cricket compiles all the textual config information from the directory tree below /etc/nav/cricket-config/ into a more efficient binary format and stores this in /etc/nav/cricket-config/config.db . The compilation process happens automatically each time a config file is changed manually or by NAV.
The file /etc/nav/cricketoids.txt, OTOH, was obsoleted several years ago, it serves no function. But thanks to you pointing out it still exist, we've removed it from the next release.
A week ago I knew far less about OIDs and I think I was better for it :)
Welcome to the wonderful world of SNMP ;)
-
Morten Brekkevold -
Tim Chown