[Devmon] [hobbit] Devmon device support, Cross post between lists

Tue Apr 22 21:10:39 CEST 2008

On Tue, Apr 22, 2008 at 1:09 AM, Buchan Milne <bgmilne at staff.telkomsa.net>
wrote:

> On Friday 18 April 2008 17:47:21 Robert Holden wrote:
> > I have noticed quite a bit of (unnecessary) redundancy when it comes to
> the
> > cisco templates.
>
> Why do you think it is specific to cisco templates? E.g., the if_load
> template
> works just as well with any device that supports the RFC-standard IFMIB
> (e.g.
> the linux-openwrt template has the if_load test taken almost directly from
> a
> cisco device). The only differences are really how devices are named, and
> thus maybe default device patterns that should be ignored.
>

Most of the equipment we are monitoring is cisco , as hobbit is used to
monitor all our servers.  As a result, I do not have enough experience with
SNMP as it relates to servers to answer your question.  As for RFC-standard
IFMIB, you are right, all cisco devices should follow these standards, but
these relate to Interfaces on the devices.  But having a static oid for all
interfaces will not always work:

-------------------------------------------------------------------------------------------------------
ifSpeed [ifBps] (1.3.6.1.2.1.2.2.1.5) vs ifHighSpeed (
1.3.6.1.2.1.31.1.1.1.15)

   The range of ifSpeed is limited to
   reporting a maximum speed of (2**31)-1 bits/second, or approximately
   2.2Gbs.  SONET defines an OC-48 interface, which is defined at
   operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
   Thus, ifSpeed is insufficient for the future, and this memo defines
   an additional object: ifHighSpeed.

   The ifHighSpeed object reports the speed of the interface in
   1,000,000 (1 million) bits/second units.  Thus, the true speed of the
   interface will be the value reported by this object, plus or minus
   500,000 bits/second.   [RFC 2233
<http://www1.tools.ietf.org/html/rfc2233>, 3.1.7]

-------------------------------------------------------------------------------------------------------
ifInOctets (.1.3.6.1.2.1.2.2.1.10) vs ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6)
ifOutOctets (1.3.6.1.2.1.2.2.1.16) vs ifHCOutOctets (1.3.6.1.2.1.31.1.1.1.10
)

   As the speed of network media increase, the minimum time in which
   a 32 bit counter will wrap decreases.  For example, a 10Mbs stream
   of back-to-back, full-size packets causes ifInOctets to wrap in
   just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7
   minutes, and at 1Gbs, the minimum is 34 seconds.  Requiring that
   interfaces be polled frequently enough not to miss a counter wrap
   is increasingly problematic.   [RFC 2233
<http://www1.tools.ietf.org/html/rfc2233>, 3.1.6]

As devmon polls data every 5 minutes, it probably should use the HC versions
of counters when needed (Gb+ speeds).  Is there a transform for performing
an IF statement/substitution?

Example: IF the ifSpeed > 20Mb, use ifHCInOctets instead of ifInOctets.

   For interfaces that operate at 20,000,000 (20 million) bits per
   second or less, 32-bit byte and packet counters MUST be used.  For
   interfaces that operate faster than 20,000,000 bits/second, and
   slower than 650,000,000 bits/second, 32-bit packet counters MUST
   be used and 64-bit octet counters MUST be used.  For interfaces
   that operate at 650,000,000 bits/second or faster, 64-bit packet
   counters AND 64-bit octet counters MUST be used. [RFC 2233
<http://www1.tools.ietf.org/html/rfc2233>, 3.1.6]

Some tests, such as serial, fans & power have some differences from device
to device.  At times an OID is not available (power/fans), other times, the
information is only available under a different OID (serial).  So this
creates some difference between templates (hence cisco-common vs
cisco-switch in my previous email).

> > I have been able to reduce nearly all the cisco devices
> > down to two templates:  cisco-switch and cisco-common
> > I still have a few minor issues to deal with, but should have something
> to
> > post to the group in about a weeks time.  The biggest of these issues is
> > finding something in the specs "model" that is common to the
> cisco-switch
> > (2811, 4003, 5500, & 6506), that is not found in all the other devices.
> > Simularily, I would like to find something in the specs "model" that is
> > common to all other cisco devices (cisco-common).
> >
> > note: Many switches are still able to use cisco-common (2900, 3500,
> 3550,
> > etc), so I probably have to come up with a better name for cisco-switch.
>
> Well, the issue is that you shouldn't really distinguish features on a
> device
> based on the hardware model in the first place.
>
> If we stick to the Cisco topic, is a 6500 a switch? Is a 7600 a router?
> What
> if I put a better supervisor in the 6500 ? If I put a CSM blade into a
> 6500,
> or into a 7600, is one a load balancer and the other not?
>
> Moving on, if I run a RADIUS server (which supports the RADIUS MIB) on a
> HP
> ProLiant, is a Dell PowerEdge *not* a RADIUS server?
>
> So, yes, I think we need a new approach to:
> 1)Which tests are done on a specific device
> 2)Which tests are done by default on a device of a specific kind of
> hardware
>

What about IOS vs CATOS, or differences between versions of IOS?  I have yet
to come up with a better way to do this, but I thinking it will be along the
lines of:
   1. SNMP Get manufacturer
   2. SNMP Get hardware model
   3. SNMP Get OS & OS Version
   4. SNMP Get Software & Version ??
   5. Run appropriate tests

Unfortunately, this can mess up the nice & clean layout to the templates
that devmon has now.

> > I will see what I can find on your subinterfaces issue.
>
> IMHO, if the device lies over SNMP, you should report it to the vendor,
> rather
> than workaround the problem in an SNMP manager.
>
> > I am also working on an idea (change to devmon) to allow for "default"
> > templates depending on vendor.
>
> I would prefer that you discuss any design issues on the development list
> ...
>

I just signed up for the devmon-devel list.
   https://lists.sourceforge.net/lists/listinfo/devmon-devel
I will post my ideas for changes & templates to that list.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20080422/f07a61eb/attachment.html>