nv-l

MidLevel Manager's snmptrap app.

1999-04-05 12:37:19
Subject: MidLevel Manager's snmptrap app.
From: James Shanks <James_Shanks AT TIVOLI DOT COM>
To: nv-l AT lists.tivoli DOT com
Date: Mon, 5 Apr 1999 12:37:19 -0400
You are correct that there is a problem with snmptrap -t and traps sent via
tcp in NetView V5.1 and 5.1.1.
The trapd daemon was deleting everything in an application's queue when it
disconnected.  This should not affect applications like MLM which connect
and stay connected.  But others, like snmptrap -t, will have there traps
deleted before they can be processed.  APAR IX87601 has been taken for
this.  If you need an efix now, please contact Support.


James Shanks
Tivoli (NetView for UNIX) L3 Support


Date:    Fri, 26 Mar 1999 14:51:36 -0700
From:    Bob Engley <bob.engley AT UALBERTA DOT CA>
Subject: MidLevel Manager's snmptrap app.
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii



Folks,
  I have been using NetView's midlevel manager to forward local
traps to NetView using default port 162 , but using TCP instead
of UDP. (Yes, we have a firewall!) This all works fine.
  However (There always seems to be a glitch), when testing the
link I sometimes would like to use snmptrap (the standalone)
application that comes with MidLevel Manager, and to make things
simple - NOT go through the midLevel manager, but send the trap
directly to our NetView machine.  The fact that "snmptrap -t ..."
doesn't reach Netview, but that "snmptrap ..." through the mlm
does work suggests that the snmptrap application doesn't work
correctly with tcp (the -t parameter)
 Has anyone had any success using snmptrap and tcp?


--
/in haste
/Bob

<Prev in Thread] Current Thread [Next in Thread>
  • MidLevel Manager's snmptrap app., James Shanks <=