Bruce,
I've had the same problem in the past on w2k netview & had to change
netview platforms.
In my situation the routers being monitored were quite busy. If the
device is busy and you send an snmp query to it, then it can simply
ignore your query since it has higher priority work to complete
(routing!). Also, if you send a query for a large number of objects
then this can cause the query to be ignored too. The combination of a
busy router and large (no metric for how large is large I'm afraid) snmp
query increases the chance of the query being ignored. The result is
the deferred collection.
You can reduce the snmpCollect deferred timeout value which is 1hr by
default. This won't mean the deferrals will stop, just that snmpCollect
will try that query again in a shorter timeframe. When I did this I
still ended up with large numbers of consecutive deferrals which created
large holes in my data.
I was pointed at the maxpuds value which is available on Unix/Linux
netview versions (not available on windows) - have a search on the
archive for that for more info. As a test I tried putting a Solaris
Netview in place, set the maxpdus to 40 and it all worked fine. I've
tried w2k netview polling ~600 interfaces on two large but quiet routers
& it never completed a query - swapping to AIX/netview & maxpuds=50 &
all was ok.
hth
K
------------------------------------------------------------------------
---
Karl Prinelle
Elyzium Ltd
Office: +44 (0)1753 515000
Mobile: +44 (0)7813 189198
E-mail: karl.prinelle AT elyzium.co DOT uk
Website:www.elyzium.co.uk
------------------------------------------------------------------------
---
Elyzium Disclaimer:
This email transmission is confidential and intended solely for the
person
or organisation to whom it is addressed. If you are not the intended
recipient, you must not copy, distribute or disseminate the information,
or
take any action in reliance of it. Any views expressed in this message
are
those of the individual sender, except where the sender specifically
states
them to be the views of any organisation or employer.
If you have received this message in error, do not open any attachment
but please notify the sender (above) deleting this message from your
system.
Please rely on your own virus check no responsibility is taken by the
sender for any damage arising out of any bug or virus infection.
------------------------------------------------------------------------
---
-----Original Message-----
From: Haibo Yang [mailto:hbyang AT sysway DOT com]
Sent: 30 August 2003 10:20
To: nv-l AT lists.tivoli DOT com
Subject: [nv-l] MIB Bata Collector Problem and Very big snmpcol.trace
Hello List:
Netview 7.1.3+Win2000 Server +MS SQL Server2000+ Popular Patches.
There are currently more than 50 routers in my customers enviroment and
I have set the Mib datacolletor to collect data for all the CisocDevices
for avgBusy5, BandwitdthUtilHdx, ifInErrors, ifOutErrors, BitsIn,
BitsOut etc. which are all standard mib-2 OID or default Cisco OID or
MIB Expression provided by Netview. When I use sql to query the
collected data in sql2000, I find that for a Cisco 7507, there are more
than 300 entries for avgBusy5, but for some other cisco 3664, 3662 there
are much less entries and even there is none!!!
And for only less than one week, the snmpcol.trace has grown into a
monitor with the size up to 400Mb. I can not open it with a notebook!
But I am quite sure what are recorded in the snmpcol.conf. it must be
something like this "Thur. Aug 14 15:29:39 : Deferring SNMP collection
of avgBusy5.0 on
10.10.30.200 60 minutes (1.00 hours). Consecutive deferral #1.
"
How to make snmpcollect get data succefully every time it collects
configured OID values? If it can not do it successfully all the time, in
the following .conf, how to make the Deferal interval shorter to 5
minture?
Collecting data correctly is very important in this scenario!
The following is a sample snmpcol.conf
############## beginning ########################
MIB .1.3.6.1.2.1.2.2.1.11 .* ifInUcastPkts pkts/sec COUNTER S hbyang
W 10.10.10.* 0xffffffff 3600 > 10000.000000 <= 50.000000 % s 58720263
MIB .1.3.6.1.2.1.2.2.1.17 .* ifOutUcastPkt units/sec COUNTER S hbyang
W 10.10.10.* 0xffffffff 3600 > 10000.000000 <= 50.000000 % s 58720263
MIB .1.3.6.1.2.1.2.2.1.14 .* ifInErrors errors/sec COUNTER R hbyang
C smartset:Routers 0xffffffff 1800 > 10.000000 <= 90.000000 % s 58720263
MIB .1.3.6.1.2.1.2.2.1.20 .* ifOutErrors errors/sec COUNTER S hbyang
W 10.10.10.* 0xffffffff 3600 > 10.000000 <= 90.000000 % s 58720263
MIB .1.3.6.1.2.1.11.1 0 snmpInPkts units/sec COUNTER S hbyang
W 10.10.10.* 0xffffffff 3600 > 10.000000 <= 70.000000 % s 58720263
MIB BandwidthUtilHdx .* BandwidthUtilHdx units EXPRESSION R hbyang
C smartset:Routers 0xffffffff 1800 > 20.000000 <= 75.000000 % s 58720263
MIB .1.3.6.1.4.1.9.2.1.58 0 avgBusy5 units INTEGER R hbyang
C smartset:CiscoDevices 0xffffffff 1800 > 90.000000 <= 75.000000 % s
58720263
MIB .1.3.6.1.4.1.9.2.1.46 0 bufferFail units INTEGER R hbyang
C smartset:CiscoDevices 0xffffffff 1800 > 0.000000 <= 0.000000 x% s
58720263
MIB .1.3.6.1.2.1.6.9 0 tcpCurrEstab units GAUGE R hbyang
C smartset:WebServers 0xffffffff 1800 > 0.000000 <= 0.000000 xA s
58720263
#################### End ##############################################
Thank you all!
Cordially
Bruce Yang
0086-755-26743243
hbyang AT sysway DOT com
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group help
line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|
