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@jhancock.com
|