Re: trapd problem

MLM will usually send its traps to NetView over tcp, so there should be no
problem there.
But I do not normally work on MLM config so I don't know what your error
messages mean.  I would simply set up the MLM to forward to NetView and it
should do it.  If you have problems with it, I would call Support so the
MLM specialist can assist.

James Shanks
Tivoli (NetView for UNIX) L3 Support



Bob Engley <bob.engley AT UALBERTA DOT CA> on 09/30/98 12:02:33 PM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
      NetView et alia <NV-L AT UCSBVM.UCSB DOT EDU>

To:   NV-L AT UCSBVM.UCSB DOT EDU
cc:    (bcc: James Shanks)
Subject:  Re: trapd problem





On Sep 29,  9:33pm, James_Shanks AT TIVOLI DOT COM wrote:

> Subject: Re: trapd problem
> How about a little more explanation of what you are trying to do here?

OK, you asked for it!
  We have a firewall'ed "secure" subnet which we have to monitor with
NetView.
  The firewall will NOT allow udp through, only tcp.
  We are installing MLM on the secure subnet, and hope to "force"
  tcp traps (even if we have to use "snmptrap -t ...") out to our "main"
  Monitoring station running NetView.
  A simple test using "snmptrap -t ..." from the "MLM" machine 129.128.8.18
  to the NetView machine "condor", with tracing and dump
  on trapd show'ed the following:

Tue Sep 29 16:29:27 1998 Tracing Started
Tue Sep 29 16:29:33 1998 add_connection: [10] connected
30 46 02 01 00 04 06 70 75 62 6c 69 63 a4 39 06     0F.....public.9.
08 2b 06 01 04 01 02 06 0c 40 04 81 80 08 12 02     .+.......@......
01 06 02 01 0f 43 03 1c 75 ca 30 1c 30 1a 06 0b     .....C..u.0.0...
2b 06 01 04 01 02 06 0c 02 01 00 04 0b 74 6f 20     +............to
70 6f 72 74 20 31 36 32 -- -- -- -- -- -- -- --     port 162........
Tue Sep 29 16:29:33 1998 queue_event: queued 72 bytes.

Tue Sep 29 16:29:33 1998 flush_event: flushed 1 events.

Tue Sep 29 16:29:33 1998 del_connection: [10] disconnected
Tue Sep 29 16:30:25 1998 Tracing Stopped


 So are we off base here?
 Why is trapd "flushing"?

>
> When you send a trap to 162/udp it is a one-way operation.  The trap
> receiver just has to listen to the port.  But tcp communication requires
> that the parties involved negotiate a session -- tcp is
connection-oriented
> while udp is conectionless.  So trapd does allow tcp communication --
> netmon sends that way, so does MLM, even another NetView's trapd, but
they
> are designed to do that.
>
> Who is sending the trap to 162/tcp?


--
/in haste
/Bob