Mike -

Well, you can get some temporary relief by adjusting the "connected applications
queue size" on trapd to a number much higher than his default size of 2000.  Try
20,000, assuming that you have enough memory and paging space on the box for
something like this.

What happens is that when the UDP socket fills up, trapd queues traps until the
socket is empty and then passes all the queued events to waiting applications.
If the applications cannot keep up, they are forced off, so by raising the queue
limit you can prevent that.

But you cannot prevent other problems by doing this.  The NetView daemons still
have to process all those traps, and by having so many from other sources, you
delay NetView's own processing, even slowing down the map updates and so on.

And you will not get any sympathy from me by saying:

I know that traps should be stopped at the source, but I don't own all the
network equipements, and I have to live with them coming...

NetView does not need these traps from other sources and they do not come in by
accident.  Someone had to configure that router to change its trap destination
to the NetView box.  And that same person had to be told to do that because the
router will not configure itself nor will it tell you what the address of the
NetView box is.    So whoever was told to configure that router that way  could
be just as well told to re-configure it to stop sending any traps to NetView or
else to use a configuration file that is more reasonable and does not send so
many.


James Shanks
Tivoli (NetView for UNIX) L3 Support



Mike Raad <mike.raad AT FR.IBM DOT COM> on 11/04/99 03:47:56 AM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
      <NV-L AT UCSBVM.UCSB DOT EDU>

To:   NV-L AT UCSBVM.UCSB DOT EDU
cc:    (bcc: James Shanks/Tivoli Systems)
Subject:  NetView stops after trap arrival




Hello,
I have a problem with NetView V5.1.1 and Optivity 8.1.1 on AIX 4.2.1 - all
patches are installed and server works fine, but often we see a great number of
traps arrving to NetView,  they are all the same, then NetView daemons stop one
after the other because they can't bufferize anymore and NetView GUI stops, and
NetView is in bad state.
I know that traps should be stopped at the source, but I don't own all the
network equipements, and I have to live with them coming...

Can anyone tell me if he had this problem with Netview ? where should I start
looking ? what can I do to protect NetView from going down ?

Cordialement - Best Regards
Mike Raad
Tel : +33 (0) 2 40 41 44 64 , GSM 0685035546
Systems & Network Management Specialist - TIVOLI
IBM France   (e-mail address : mike.raad AT fr.ibm DOT com)