HW/SW/FW versions flipping back and forth on devices

[Morten Brekkevold]

Several NAV users report that they receive numerous
alerts about devices' hardware versions changing back
and forth again. The volume of these alerts is so
huge that many opt to filter them from their alert
profiles.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1550393&group_id=107608&atid=648170]

[Morten Brekkevold (mbrekkevold)]

An investigation of NTNU's installation reveals that mostly
HP devices are affected by this issue, but also a few Cisco
devices.

Furthermore, it appears that the HP and CiscoModule plugins
are both launched for many HP devices, and they each set the
hardware version of the device, but to different values.
This is what causes the value to flip back and forth.

The HP module reads the hardware version from a HP
proprietary OID, which is undocumented. NAV's assumption
that this OID (1.3.6.1.4.1.11.2.14.11.5.1.1.4.0) contains
the hardware version probably stems from an old session of
reverse engineering/snmpwalking HP devices.

Many HP devices support the ENTITY-MIB, which provides
values for hardware, firmware and software revisions. The
HP devices tested report 0 as their hardware version in this
MIB, whereas the hardware version returned by the
aforementioned proprietary OID are reported as _firmware_
versions in the ENTITY-MIB.

The CiscoModule plugin retrieves hardware versions from the
ENTITY-MIB, which means that a typical HP device will have
its hardware version value changed continually between its
firmware version number and the number 0.

The most probable solution is to instead interpret the above
mentioned proprietary OID as a firmware version, rather than
a hardware version (trusting the ENTITY-MIB, which is
standard and well documented (RFC 2737)). The number seems
to coincide with the ROM/BIOS version numbers of the HP devices.

[Morten Brekkevold (mbrekkevold)]

A partial fix was committed in r3616.

It now works for HP, but some Cisco devices seem to have
internal conflicts about which hardware revision is correct.

[Morten Brekkevold (mbrekkevold)]

Originator: YES

Further tests for Cisco devices reveals the following:

Cisco devices that aren't chassis based will have a module entry that
corresponds to the same device as its netbox entry. The problem seems to
be that the CiscoModule plugin retrieves serial numbers for the chassis
(netbox) from a different OID than it does for modules.

Many of these Cisco devices report mismatching hardware revisions strings
in the CISCO-STACK-MIB and in ENTITY-MIB. The plugin will use one for the
module's HwVer, and the other for the chassis' HwVer, but since both are
the same device, the device has its HwVer set twice in a collection run.

Normally, this shouldn't be a problem, but a design problem in
getDeviceData (inheritance vs. composition in the data containers) makes it
possible to have two in-memory instances that both represent the same
device, and this is why two deviceHwVerChanged alerts are dispatched in a
row.

[Morten Brekkevold (mbrekkevold)]

Originator: YES

The Cisco part of the issue has been fixed in r3937.

[Morten Brekkevold (mbrekkevold)]

Originator: YES

I'm reopening this bug due to reports from the University of Oslo that
they still are receiving alerts about flipping version numbers on Cisco
devices. Apparently there are more inconsistencies in the MIBs provided by
these devices, the three conflicting mibs appear to be
OLD-CISCO-CHASSIS-MIB, CISCO-STACK-MIB and ENTITY-MIB.

[Morten Brekkevold (mbrekkevold)]

Originator: YES

Fixed in r4260, and hopefully it will stick this time (confirmed by UiO,
at least). Should be scheduled for NAV 3.3.1.