From: Buchan M. <bg...@st...> - 2008-04-22 08:16:25
|
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 <ch...@su...> 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 > > hob...@hs... |