nv-l

Re: MSG: unable to establish connection to netmon daemon

1999-08-09 19:48:47
Subject: Re: MSG: unable to establish connection to netmon daemon
From: Leslie Clark <lclark AT US.IBM DOT COM>
To: nv-l AT lists.tivoli DOT com
Date: Mon, 9 Aug 1999 19:48:47 -0400
I don't think netmon would be kept busy by the incoming traps, but it might be
busy because you just started it. Or it might be behind because the IP interface
on the server is busy with the incoming traps. On Netview for NT I believe there
is a configuration option that controls how long a demandpoll dialog will wait
for netmon to get around to processing it before giving that message and
giving up. In normal circumstance you should find that if you wait a couple of
minutes and try again, the demandpoll will work. Of course, if you have
been fiddling with the polling cycle it might never get unbusy. What have you
set the polling cycle to, and have you done the math to make sure it is
reasonable?
I believe that anything under 5 minutes for the default probably should have a
good
explanation;)


Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking



So you have two questions or  problems.

One is that when netmon is busy you cannot do a demand poll from a NetView
client.  I don't do netmon, so I will leave that alone.  I don't understand the
broken pipe issue, but if you want to pursue it, I suggest you call Support and
get a specialist to work on it with you.

The other question s whether MIBs need to be converted for NT.  The answer is
"no".  A MIB is a MIB is a MIB, and the only thing which distinguishes them is
their SNMP version (currently 1 or 2, though there is a 3 in the works).
Whether you have a MIB loaded should not affect netmon, nor even trapd -- both
should function normally.   If you want to load a MIB you can use the loadmib
(SNMP V1 only) or loadmibv2 (SNMPV1 and V2).  The loadmibv2 function has several
problems in current code with SNMP V2 MIBs,   which are being addressed  by
maintenance in Version 5.1.2, but it often works, depending on what the MIB
says.  There is also a mib2trap function which has several problems in current
code that will be addresses by 5.1.2.  mib2trap is used to generate addtrap
statements from a MIB definition of a trap, so that the traps defined in the MIB
can be automatically added to trapd.conf.  If you don't have a MIB, or mib2trap
isn't working for you, you can also add the trap manually with the Trap Settings
function.


James Shanks
Tivoli (NetView for UNIX) L3 Support



"Chance, Larry" <lchance AT SFBCIC DOT COM> on 08/09/99 09:21:43 AM

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

To:   NV-L AT UCSBVM.UCSB DOT EDU
cc:    (bcc: James Shanks/Tivoli Systems)
Subject:  MSG: unable to establish connection to netmon daemon




[NetView for NT]

I just configured a device on the network to forward traps to NetView.  Boy
did it forward.
It started sending traps every 4 to 5 seconds.  The details showed no
duplicates.  Each trap
was unique.  Is it the vendor's SNMP agent for the device that will have
control of these traps?
I do not have the MIBs for it.  I did see vendor documentation of MIBs for
Unix.  Will I
need to convert Unix MIBs to NT MIBs?  What will I use to make the
conversion?

When I tried to demand poll the device (during the rapid-fire traps) I got
this message:
Unable to establish connection to netmon daemon on server.

The netmon daemon must be running on the server.

Also, check \usr\ov\log\nv.log on server for possible errors.

Local error: Waiting for a process to open the other end of the pipe.



Of course, netmon daemon was running on the server.  It never stopped.  When
I checked nv.log, I had this message:

08/09/99 07:21:47 [nmdemandpoll] Unable to establish connection to netmon
daemon on server. The netmon daemon must be running on the server. Also,
check \usr\ov\log\nv.log on server for possible errors. Local error: Waiting
for a process to open the other end of the pipe.

The log entry was the same as the Demand Poll message.  I changed the device
back to not forwarding traps and reset it.  All is back to normal.

Is this expected of netmon daemon when trapd is overloaded?  Or should I
back off netmon's polling timers?

Thanks,

Larry


<Prev in Thread] Current Thread [Next in Thread>