Trust you, I do, believe me.
I had forgotten about the 6.0.2 feature of
netmon receiving the link up/down agent traps
and doing an immediate status poll, that's
why I was confused about who was sending
traps to whom. Thanks for clearing it up
for me.
"In James (and Leslie) we trust".
Les Dickert
Verisign Consulting
>From: James_Shanks@tivoli.com
>Reply-To: IBM NetView Discussion <nv-l@tkg.com>
>To: IBM NetView Discussion <nv-l@tkg.com>
>Subject: Re: [NV-L] Maximum number of events?
>Date: Mon, 2 Apr 2001 15:35:01 -0400
>
>
>Trust me, Les. I know what this message means. netmon does not know how
>to stop sending traps. trapd does get raw traps from netmon, and other
>sources, and he forwards some or all of those to other "interested
>parties". ipmap for example gets all netmon traps. And netmon used to get
>(in 5.1) lots of things and just throw them away. Now he gets Link Up and
>Link Down traps from other agents. He uses these to immediately go check
>those nodes so as to respond to changes in your network quicker -- you
>don't have to wait for netmon's polling cycle to come around to those guys
>again. That is a feature of 6.0.2. But netmon cannot process these traps
>while he is initializing. So if you get a whole bunch of them while he is
>still doing his config checks, then they fill up netmon's internal queue in
>trapd and trapd forces him off to protect himself. Which is just as well,
>because netmon will find out about the current state of those interfaces
>during his init routines anyway.
>
>If you like, you can raise the size of netmon's queue (and everybody else's
>too -- it's a global thing) by adjusting the application queue buffer size
>in trapd, but it doesn't pay to make it real big anymore. The default size
>is 2000. You can make it huge, say 20,000 if you like, but that means that
>the first thing netmon will do after he initializes is process all those
>traps. May mean a lot of pointless cycles. But if you think that netmon
>should be just about ready to go when he gets forced off and making the
>buffer bigger, say double or triple, will allow him to stay connected and
>catch up, then give it a shot.
>
>If you want, you can use trapd.trace (just type in "trapd -T" from the
>command line as root to toggle it on and off) to see what other
>applications have connected to trapd. Each time a trap is queued to a
>particular appl, you see a message which says that the queue for that appl
>(identified by an internal number and a PID) is now such and such big.
>Using "ps -ef" you can see what that PID is. It can be enlightening.
>
>
>James Shanks
>Team Leader, Level 3 Support
> Tivoli NetView for UNIX and NT
>
>
>
>"Les Dickert" <lesdickert@hotmail.com>@tkg.com on 04/02/2001 02:20:41 PM
>
>Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
>Sent by: owner-nv-l@tkg.com
>
>
>To: nv-l@tkg.com
>cc:
>Subject: Re: [NV-L] Maximum number of events?
>
>
>
>Huh?
>
>I thought netmon sent traps to trapd, not
>vice versa.
>
>Could the error message mean that trapd is
>not processing the traps from netmon (probably
>due to an external trap storm) and that netmon
>is going to quit sending them for a while?
>
>Les Dickert
>Verisign Consulting
>
>
>
> >From: James_Shanks@tivoli.com
> >Reply-To: IBM NetView Discussion <nv-l@tkg.com>
> >To: IBM NetView Discussion <nv-l@tkg.com>
> >Subject: Re: [NV-L] Maximum number of events?
> >Date: Mon, 2 Apr 2001 10:38:55 -0400
> >
> >
> >That depends on what is going on. The message means that netmon is not
> >processing the traps that trapd is sending to him, probably because he is
> >busy doing something else. When his queue gets full, trapd terminates
>his
> >connection, so that he himself does not wind up in an out-of-memory
> >condition. If you have just restarted netmon then this may be entirely
> >normal, because he has to do all of his initialization and config checks
> >before he can process traps. When he is done with his init stuff, he
>will
> >re-connect to trapd and start paying attention to the incoming trap flow.
> >If you have not just restarted netmon, then you may have a trap storm
> >problem or a netmon hang of some kind to investigate. I would start with
> >the netmon trace and see what netmon is doing in that case, and call
> >Support if you need help.
> >
> >James Shanks
> >Team Leader, Level 3 Support
> > Tivoli NetView for UNIX and NT
> >
> >
> >
> >"Treptow, Craig" <Treptow.Craig@principal.com>@tkg.com on 04/02/2001
> >10:04:51 AM
> >
> >Please respond to IBM NetView Discussion <nv-l@tkg.com>
> >
> >Sent by: owner-nv-l@tkg.com
> >
> >
> >To: "NetView List (E-mail)" <nv-l@tkg.com>
> >cc:
> >Subject: [NV-L] Maximum number of events?
> >
> >
> >
> >
> >
> >Hi. We are running Netview 6.0.2 on AIX 4.3.3. I just saw an event
>scroll
> >by with this message:
> >
> >"netmon reached maximum number of outstanding events, disconnecting from
> >trapd"
> >
> >The processes are still running, and things still appear ok. Should I be
> >concerned?
> >
> >Craig Treptow
> >Principal Financial Group
> >I/S Network Administration
> >(515) 247-6207
> >
> >
> >
> >
> >_________________________________________________________________________
> >NV-L List information and Archives: http://www.tkg.com/nv-l
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>_________________________________________________________________________
>NV-L List information and Archives: http://www.tkg.com/nv-l
>
>
>
>_________________________________________________________________________
>NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________
|