Re: trapd behind???

[James Shanks <James_Shanks@TIVOLI.COM>]

There is nothing you can configure in trapd to speed things up.

 You can issue "  trapd -T " from the command line and that will toggle the
trapd trace, and the /usr/OV/log/trapd.trace file will show what trapd is
doing - queuing or processing traps.  The trace has been improved in 5.1.1
so that it also shows the queue size as each trap is queued or dequeued.

I'm not sure whether the trace will be helpful you in determining where the
problem lies if you did not see it before. Are you certain that the rate of
trap arrival has not changed?   Last time I worked on a problem like this,
someone had reconfigured a router (actually several) to send in some new
traps and they were flooding trapd.

James Shanks
Tivoli (NetView for UNIX) L3 Support



Sean Davidson <sean.davidson@MAIL.PUBLIX.COM> on 04/19/99 12:33:43 PM

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: trapd behind???





Here's what I've got in /etc/services for snmp trap port:

snmp-trap       162/tcp                         # snmp monitor trap port
snmp-trap       162/udp                         # snmp monitor trap port

Looks like Netview is getting the traps first and Optivity is not involved.

Are there any queue sizes or anything else that needs to be checked? I've
not had this problem before.
Normally, there is a negligible amount of time between when trapd gets the
trap and it appears in the events appl.

________________________________________
Thanks,
Sean Davidson

Sean Davidson - Sr. Network Systems Engineer
Publix Super Markets, Inc.
P.O. Box 32015
Lakeland, Fl. 33802-2015
Email - sean.davidson@publix.com
Voice - (941) 686-8754 x6889
Fax - (941)616-5659


-----Original Message-----
From: James Shanks [mailto:James_Shanks@TIVOLI.COM]
Sent: Monday, April 19, 1999 11:45 AM
To: NV-L@UCSBVM.ucsb.edu
Subject: Re: trapd behind???


But who gets the traps first, Optivity or trapd?  /etc/services should tell
you whether NetView is listening on 162/udp or not.  If he is, then he gets
them first; If not, then he doesn't get them unless or until Optivity sends
them to him.

But in NetView 5.1, even if Optivity is not involved, NetView will queue
traps, rather than process them, as long as there is something to read on
his sockets.  This guarantees that traps are not lost, no matter what rate
they are sent.  Indeed it was tested and found that traps are not lost even
at a 100/sec.  But that does not mean that they are processed that fast.
The rate has to fall so that processing can occur.  If trap traffic is
bursty as it usually is, then there will be time for processing, but if the
rate is high,  then trapd will be "behind" in the sense that he will still
be processing old stuff for awhile.  That's the way it works.

The real trick in all this is to decide what traps agents should send and
to send only those.  Some customers have found that most agent traps are
ignored anyway, and that by turning off those they don't use, they can
reduce cpu on the NetView box and recover valuable network bandwidth they
were wasting sending traps nobody looked at.


James Shanks
Tivoli (NetView for UNIX) L3 Support



Sean Davidson <sean.davidson@MAIL.PUBLIX.COM> on 04/19/99 11:27:08 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:  trapd behind???





I'm getting Agent traps streaming steadily into my trapd.log file. The
particular device is a Cisco router, I can do debug snmp packet and see
that
there are no traps being sent. I also ran iptrace on the AIX box and see no
traps coming in from this device, yet tail -f /usr/OV/log/trapd.log shows
the events coming in from this device at appx two events per second. The
only thing I can figure is that trapd is behind. Any pointers on what to
look for?

I am also running Optivity/LAN on this same box (v8.1), so I know he could
be part of the problem.

I'm running NetView6000 v5.1 on AIX 4.2.1 and Tivoli v3.6

________________________________________
Thanks,
Sean Davidson

Sr. Network Systems Engineer
Publix Super Markets, Inc.
P.O. Box 32015
Lakeland, Fl. 33802-2015
Email - sean.davidson@publix.com
Voice - (941) 686-8754 x6889
Fax - (941)616-5659

Here's what I've got in /etc/services for snmp trap port:

snmp-trap       162/tcp                         # snmp monitor trap port
snmp-trap       162/udp                         # snmp monitor trap port

Looks like Netview is getting the traps first and Optivity is not involved.

Are there any queue sizes or anything else that needs to be checked? I've not had this problem before.
Normally, there is a negligible amount of time between when trapd gets the trap and it appears in the events appl.

________________________________________
Thanks,
Sean Davidson

Sean Davidson - Sr. Network Systems Engineer
Publix Super Markets, Inc.
P.O. Box 32015
Lakeland, Fl. 33802-2015
Email - sean.davidson@publix.com
Voice - (941) 686-8754 x6889
Fax - (941)616-5659

-----Original Message-----
From: James Shanks [mailto:James_Shanks@TIVOLI.COM]
Sent: Monday, April 19, 1999 11:45 AM
To: NV-L@UCSBVM.ucsb.edu
Subject: Re: trapd behind???

But who gets the traps first, Optivity or trapd?  /etc/services should tell
you whether NetView is listening on 162/udp or not.  If he is, then he gets
them first; If not, then he doesn't get them unless or until Optivity sends
them to him.

But in NetView 5.1, even if Optivity is not involved, NetView will queue
traps, rather than process them, as long as there is something to read on
his sockets.  This guarantees that traps are not lost, no matter what rate
they are sent.  Indeed it was tested and found that traps are not lost even
at a 100/sec.  But that does not mean that they are processed that fast.
The rate has to fall so that processing can occur.  If trap traffic is
bursty as it usually is, then there will be time for processing, but if the
rate is high,  then trapd will be "behind" in the sense that he will still
be processing old stuff for awhile.  That's the way it works.

The real trick in all this is to decide what traps agents should send and
to send only those.  Some customers have found that most agent traps are
ignored anyway, and that by turning off those they don't use, they can
reduce cpu on the NetView box and recover valuable network bandwidth they
were wasting sending traps nobody looked at.

James Shanks
Tivoli (NetView for UNIX) L3 Support

Sean Davidson <sean.davidson@MAIL.PUBLIX.COM> on 04/19/99 11:27:08 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:  trapd behind???

I'm getting Agent traps streaming steadily into my trapd.log file. The
particular device is a Cisco router, I can do debug snmp packet and see
that
there are no traps being sent. I also ran iptrace on the AIX box and see no
traps coming in from this device, yet tail -f /usr/OV/log/trapd.log shows
the events coming in from this device at appx two events per second. The
only thing I can figure is that trapd is behind. Any pointers on what to
look for?

I am also running Optivity/LAN on this same box (v8.1), so I know he could
be part of the problem.

I'm running NetView6000 v5.1 on AIX 4.2.1 and Tivoli v3.6

________________________________________
Thanks,
Sean Davidson

Sr. Network Systems Engineer
Publix Super Markets, Inc.
P.O. Box 32015
Lakeland, Fl. 33802-2015
Email - sean.davidson@publix.com
Voice - (941) 686-8754 x6889
Fax - (941)616-5659