On Tue, Apr 22, 2008 at 1:09 AM, Buchan Milne <user-9b139aff4dec@xymon.invalid>
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.
I will post my ideas for changes & templates to that list.
Robert