Re: Trapd queue build up

[James_Shanks@tivoli.com]

Reggie -

This is the third time you have posted this note without any modifications.  I
answered you almost two days ago.  Did you not notice my response?  In it I told
you that you should (a) call Support because it is unlikely you can debug this
by yourself and (b) that you will need to turn on the trapd.trace to see what is
going on, and that (c) most likely you are having a periodic trap storm in which
traps arrive at your box at a much higher rate than can be processed by the
applications which have registered with trapd to get traps.  Ultimately you need
to reconfigure the routers or other devices in your network to not send so much
stuff.

I thought I answered all your questions then.  If not, which ones remain?

Are you having a serious problem?  Yes you are and you should look into it.

James Shanks
Team Leader, Level 3 Support
 Tivoli NetView for UNIX and NT



"Rama, R. (Reggie)" <ReggieR@nedcor.co.za> on 07/31/2000 05:29:49 AM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

To:   "'nv-l@tkg.com'" <nv-l@tkg.com>
cc:    (bcc: James Shanks/Tivoli Systems)
Subject:  [NV-L] Trapd queue build up




Hello All Netviewers

We are currently running AIX 4.2.1 and Netview 5.1.2 on a F50 (4CPU & 1GB
RAM) and we are experiencing the following problem.

Over the past few days we have noticed that we receive the following
message
within the trapd.log file "netmon-related Application reached maximum
number
of outstanding events, disconnecting from trapd". The trapd buffer size to
32000 .i.e. trapd -b32000.We are receiving about 4 of these messages per
hour daily now.

When we monitor udp port 162 using the netstat -an command, we find that
the
receive queue builds up to approx 32000 and it sits at this value for a few
minutes and then only does it get cleared and starts it building up again.
I
have looked at all the various Netview configurations and they all seem OK.
I have searched the Netview Archives and could find a suitable reply for
the
questions I have.My questions are :-

 1. Are there application(s) that are not reading the traps from the queue
fast enough that is the cause of the problem.
 2. When we get the above message, does it mean that all the traps that
were
on the queue are discarded (lost).
 3. How does one determine which application(s) are not reading the traps
from the queue and are the cause of the problem.
 4. How does one determine / verify that traps are not being lost .i.e how
does one verify if the data within trapd.log is correct.
 5. Also, we have made no changes to the system at all recently. Are there
any external changes .i.e.many more traps from devices that can cause this
to occurr.

Thanks in advance for the assistance.

Regards
Reggie Rama
ESM - Technology & Operations Division
Nedcor Bank Limited (South Africa)

Tel : +27 - 011 - 8813989
Fax : +27 - 011 -  8814113
e-mail : reggier@nedcor.co.za



Reggie Rama
ESM - Technology & Operations Division
Nedcor Bank Limited (South Africa)

Tel : +27 - 011 - 8813989
Fax : +27 - 011 -  8814113
e-mail : reggier@nedcor.co.za

Hello All Netviewers

We are currently running AIX 4.2.1 and Netview 5.1.2 on a F50 (4CPU & 1GB
RAM) and we are experiencing the following problem.

Over the past few days we have noticed that we receive the following
message
within the trapd.log file "netmon-related Application reached maximum
number
of outstanding events, disconnecting from trapd". The trapd buffer size to
32000 .i.e. trapd -b32000.We are receiving about 4 of these messages per
hour daily now.

When we monitor udp port 162 using the netstat -an command, we find that
the
receive queue builds up to approx 32000 and it sits at this value for a few
minutes and then only does it get cleared and starts it building up again.
I
have looked at all the various Netview configurations and they all seem OK.
I have searched the Netview Archives and could find a suitable reply for
the
questions I have.My questions are :-

 1. Are there application(s) that are not reading the traps from the queue
fast enough that is the cause of the problem.
 2. When we get the above message, does it mean that all the traps that
were
on the queue are discarded (lost).
 3. How does one determine which application(s) are not reading the traps
from the queue and are the cause of the problem.
 4. How does one determine / verify that traps are not being lost .i.e how
does one verify if the data within trapd.log is correct.
 5. Also, we have made no changes to the system at all recently. Are there
any external changes .i.e.many more traps from devices that can cause this
to occurr.

Thanks in advance for the assistance.

Regards
Reggie Rama
ESM - Technology & Operations Division
Nedcor Bank Limited (South Africa)

Tel : +27 - 011 - 8813989
Fax : +27 - 011 -  8814113
e-mail : reggier@nedcor.co.za

Reggie Rama
ESM - Technology & Operations Division
Nedcor Bank Limited (South Africa)

Tel : +27 - 011 - 8813989
Fax : +27 - 011 -  8814113
e-mail : reggier@nedcor.co.za