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,
> 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