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:
- SNMP Get manufacturer
- SNMP Get hardware model
- SNMP Get OS & OS Version
- SNMP Get Software & Version ??
- 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