Re: Netview and its handling of traps

2000-06-15 11:15:00
Subject: Re: Netview and its handling of traps
From: Ray Schafer <schafer AT tkg DOT com>
To: nv-l AT lists.tivoli DOT com
Date: Thu, 15 Jun 2000 15:15:00 +0000

Unless your machine is real slow,  16 traps per second is nothing compared to
what NetView can sustain.  I have personally seen it handle 100 traps per
second for several minutes at a time, and we saw no problems.    Of course, we
had set the application queue size of trapd to 30,000 (If I recall - Daxesh are
you listening?)  but that was to prevent applications getting disconnected from

Maybe your machine is running an old version of trapd (about 2 years ago trapd
was improved to be able to handle a lot more traps), or maybe you are low on
RAM, or your CPU is slow.  Make sure if you do a comparison with HP, you do
apples to apples.  Try to match the RAM, CPU power (as best you can - they are
different architectures), etc.

"Tremblay, David A." wrote:

> To the group:
> I am under the impression that the maximum number of traps that NetView can
> handle per second is 16.  Is this number sound correct?
> I know that we have run tests here at John Hancock where we have forced 20
> SNMP traps per second to be generated, performed a snmpwalk of a known
> discovered device and watched it hang until we stopped forwarding the traps.
> At that time netview played catch up with those traps, snmpwalk was
> performed successfully and NetView returned to normal.
> I just want to confirm this with the group, Netview DOES NOT have ANY
> mechanism to filter out the number of traps coming in from a particular
> configured device during a trap storm?    We recently experienced a trap
> storm recently in which 3 monitored devices went down and we received over
> 60 traps generated per second from 3 identical devices (digital recorders).
> During this trap storm, NetView came to a grinding halt because it was
> overwhelmed by the number of traps trying to be processed.   We managed to
> get around this by switching from our Production NetView server to our
> Development NetView server since it wasn't configured to receive traps from
> those particular devices.
> When I talked with support and was told the only way to fix the problem was
> to go to the device and turn off the traps or configure the number of traps
> forwarded to be a lesser amount than current configured.  I also went down
> the path of talking about the ESE.automation file and using rulesets but
> that will not effected anything expect for filtering what is displayed to
> the event viewer or filtering forwarded events to TEC.
> I know I can remedy this problem outside of NetView by using a product such
> as Veritas Nerve Center to pre-filter traps/alarms and forward them to trapd
> after the fact.  But I was looking for ANY other solution native to NetView
> in dealing with this problem.  Are MLM's a way to remedy this situation?
> Lastly, I have been told that HP Openview can handle a much higher number of
> traps and has filtering built into the product.   I am still gathering
> information to see if these claims are true and will post what I find when
> the information has been confirmed.
> Any responses will be both welcomed and appreciated,
> Dave
> David A. Tremblay                                             John Hancock
> Financial Services
> Lead Systems Analyst                                      Information
> Technology Services
> Enterprise Management Tools                       Technology Shared Services
> E-Mail: dtremblay AT jhancock DOT com
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l

Ray Schafer                   | schafer AT tkg DOT com
The Kernel Group              | Distributed Systems Management

<Prev in Thread] Current Thread [Next in Thread>