Hi Bill,
have you tried to ovstop netmon / ovstart netmon? Very often this helps.
If this won't help, stop/restart netview: ovstop nvsecd, wait and check that
all daemons stopped (ps -ef | fgrep -i ov). Then restart netview with
/etc/netnmrc and wait until all daemons have done their job (you may watch the
event window to see what's going on). In more than 90% of the cases those red
Icons will disappear now.
I have written a script to do the ovstop/ovstart netmon every night, initiated
by a crontab entry. Togther with some fixes in the databases (ovtopofix and
ovmapcount with various parameters, see man pages) this may help you out of
many problems like this. Unfortunally I am not allowed to give away the script.
Michael Seibold
>>> Bill Painter <william.t.painter@LMCO.COM> 18.02.2000 00.24 Uhr >>>
-----Original Message-----
From: Leslie Clark <lclark@US.IBM.COM>
To: NV-L@UCSBVM.UCSB.EDU <NV-L@UCSBVM.UCSB.EDU>
Date: Wednesday, September 22, 1999 8:20 PM
Subject: Re: Ping list not getting pinged?
This thread seems to have two subjects going on, an of course I have
opinions on both of them.
The netmon option (undocumented) that controls how many outstanding
ping requests you can have is -q. It is 16 by default in V5, and may be set
as high as 32. You can tell what it is set to by the number of entries at
the
top of the output (in netmon.trace) of netmon -a 3. Note that the increase
does NOT seem to apply to the number of outstanding snmp requests
(wouldn't THAT be nice!) Just add -q 32 to the netmon.lrf file and process
it
manually (ovdelobj, ovaddobj, stop/start netmon).
Usually the red things you are talking about are considered false alarms,
and are due to having too short a timeout or retry setting. However there
was recently a lengthy discussion on this forum about network
characteristics
that lead to lost pings that tuning timeouts won't help. A bunch of clues
but
nothing conclusive, I think. You might want to search the archives for the
last
15-30 days, unless it clears up with the tuning of the timeouts.
I've got one customer where this is a continuous problem. I went so far as
to set up a rule to ping the interface when there is an interface down
event,
and found that the script would have to actually sleep about 30 seconds
before pinging, for the ping to get through. I have no idea. I'm a software
person. But Netview is doing its job in reporting that there is SOME kind
of problem.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
We are experiencing a problem where a node will appear to go down, and it
will
stay red. If I go in and manually ping the node then Netview will send a
node
up message and the node will go green again. Can anyone suggest some
diagnostics?
Thanks
Bill Painter
william.t.painter@lmco.com
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
|