nv-l
[Top] [All Lists]

Help with Data Collection

To: nv-l@lists.tivoli.com
Subject: Help with Data Collection
From: Martin Conway <Martin.Conway@BARCLAYS.CO.UK>
Date: Mon, 15 Mar 1999 11:24:00 +0000
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Hi,

I'm trying to track the layer two activity of a group of ethernet
attached NT servers using snmpCollect to single collision frame
counter, output unicast and non-unicast packets and have combined these
values in the following mib expression which should track collisions to
output frames.

.1.3.6.1.2.1.10.7.2.1.4. .1.3.6.1.2.1.2.2.1.17. .1.3.6.1.2.1.2.2.1.18.
+ / 100 *

where :

collision frame counter = .1.3.6.1.2.1.10.7.2.1.4.
output unicast=   .1.3.6.1.2.1.2.2.1.17.
output non-unicast=.1.3.6.1.2.1.2.2.1.18.

This expression forms a single line entry in mibExpr.conf as detailed
below:

Eth_Coll "blah" .1.3.6.1.2.1.10.7.2.1.4. .1.3.6.1.2.1.2.2.1.17.
.1.3.6.1.2.1.2.2.1.18. +  / 100 *

When queried, the agent running on the NT server returns instances of
oid .1.3.6.1.2.1.10.7.2.1.4. as integers rather than the counter values
defined in the relevant RFC. I therefore used mib.coerce to modify the
default returned type as per  the following extract from the file:

# dot3StatsSingleCollisionFrames
.1.3.6.1.2.1.10.7.2.1.4 COUNTER

When I run a data collection against the expression, the values
produced suggest that the oid values for .1.3.6.1.2.1.10.7.2.1.4 are
still being treated as an integer rather than the  rate of change
values which would expected for a counter. As the following extract
from the collected data illustrates:

10s   Mon Mar 15 11:03:14  bts-radb-s01   6417629.53
10s   Mon Mar 15 11:03:24  bts-radb-s01   10077369.61
10s   Mon Mar 15 11:03:34  bts-radb-s01  10326591.06

However, when I collect the single collision frame oid in isolation it
is correctly identified as a counter and I get the following output:

10s  Mon Mar 15 11:09:14 bts-radb-s01  0.00
10s  Mon Mar 15 11:09:24 bts-radb-s01  17.10

Has anyone had experience with this type of behaviour or have I
mis-configured a component of the collection process ?

I can't seem to identify any documentation that specifies the
relationship between mib.coerce and mib expressions, are there any
other references not covered in the dynatext books ?

Thanks in advance

Martin

<Prev in Thread] Current Thread [Next in Thread>
  • Help with Data Collection, Martin Conway <=

Archive operated by Skills 1st Ltd

See also: The NetView Web