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

[Buchan Milne <bgmilne (at) staff.telkomsa.net>]

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.

> 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

> 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 ...

>
> Robert Holden
>
> On Fri, Apr 18, 2008 at 7:17 AM, Chris Wopat <chrisw (at) supranet.net> wrote:
> > Hello,
> >
> > Chiming in on some info on Devmon. While primarily targeted to the Devmon
> > list, it may be useful to hobbit/devmon users who don't subscribe to that
> > list.
> >
> > The cisco-7206 template works perfectly fine on a Cisco 7500. I'm sure it
> > works on a 7200 as well. I also have an old 7000 here, but I don't want
> > to boot it up to test. Anyway, it may be in the best interest to rename
> > 7206 to 7200, and just copy its templates to a 7500 folder, or genericly
> > rename the whole thing cisco-7000.
> >
> > Also, there is a typo in the USING doc:
> >
> >
> > http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/docs/USING?revision
> >=3&view=markup
> >
> > This line is listed:
> >        DEVMON:tests(cpu),thresh(cpu;CPUTotal5Min;y=50;r=90)
> >
> > But it should be:
> >        DEVMON:tests(cpu),thresh(cpu;CPUTotal5Min;y:50;r:90)
> >
> > It's correct in the details furter down the page, but the equal symbols
> > should be colons near the top when it first mentions thresh().
> >
> > Lastly, and this is very minor, Devmon doesn't properly detect
> > administratively down interfaces in all cases. On one router, I am using
> > subinterfaces as follows:
> >
> > GigabitEthernet0/2
> > GigabitEthernet0/2.1
> > GigabitEthernet0/2.2
> > GigabitEthernet0/2.3
> > ..etc..
> >
> > If I shut down Gi0/2, 'sh ip int br' shows its subinterfaces
> > administratively down, but devmon doesn't detect that- one has to go into
> > each subinterface and shut them down as well. It does appear that the OID
> > that checks admin status (.1.3.6.1.2.1.2.2.1.7) does indeed say up, which
> > is why it's showing red:
> >
> > ifAdminStatus.89 = INTEGER: up(1)
> >
> > I couldnt find any alternate OID to report ifAdminStatus, so short of
> > putting in code to check parent interface status, it probably couldn't be
> > considered a bug, but I thought I'd mention it.
> >
> > --Chris
> >
> > To unsubscribe from the hobbit list, send an e-mail to
> > hobbit-unsubscribe (at) hswn.dk