Well, I mean just what I said. Try to follow the flow here.
A trap from a non-NetView agent arrives on port 162. The operating system maps
that port to a socket for trapd to read. As long as there is something to read
on that socket, trapd will read it, and store it in a queue, and re-read the
socket until it is empty. This ensures that no traps are lost due to socket
overflow no matter how fast they come in. When the socket is empty, trapd
begins processing the queued traps, decoding them, logging them, and passing
them on to netmon, ipmap, nvcorrd, and any other process which has registered to
receive traps. These are the "connected applications". They each have a
queue. As trapd processes the trap he puts a copy of it on each application's
queue. They in turn pull them off and process them. If an application's queue
gets full, because it cannot process traps as fast as trapd puts them on the
queue, that application is forced off trapd and his queue emptied. The
application then has to reconnect. Some NetView daemons, like netmon, will
re-connect automatically if they get forced off. Some, like ovtopmd, which
depends on traps from netmon, will just die gracefully and must be re-started.
So if your trap rate is high at times you can prevent this by raising the
application queue limit. The daemons don't die but they still have a lot of
work to do.
Make sense?
Bottom line: Don't send excessive traps to NetView. You are just shooting
yourself in the foot.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Gord Michaels <gord_michaels@HOTMAIL.COM> on 11/04/99 09:31:45 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: NetView stops after trap arrival
James,
What do you mean exactly when you say....
"... trapd queues **traps** until the socket is empty and then passes all
the queued events to waiting applications."
I am confused about the portion in ** **.
Thanks James.
Gord.
>From: James Shanks <James_Shanks@TIVOLI.COM>
>Reply-To: Discussion of IBM NetView and POLYCENTER Manager on NetView
> <NV-L@UCSBVM.ucsb.edu>
>To: NV-L@UCSBVM.ucsb.edu
>Subject: Re: NetView stops after trap arrival
>Date: Thu, 4 Nov 1999 09:12:06 -0500
>
>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@FR.IBM.COM> on 11/04/99 03:47:56 AM
>
>Please respond to Discussion of IBM NetView and POLYCENTER Manager on
>NetView
> <NV-L@UCSBVM.UCSB.EDU>
>
>To: NV-L@UCSBVM.UCSB.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@fr.ibm.com)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
|