Ouch. My advice is to try a posting to the list before using a sledge
hammer to solve your problems. That's the only way we can truly help.
That said, do you have a seed file? If not, build one which contains the
IP addresses or hostnames of your backbone devices, and possibly one
important device in each network that you wish to monitor. You can build
one from serversetup under the discovery options for the network monitor
daemon. Once you have one you can edit it with the java editor of with
notepad. You should never attempt to clear the databases without having a
good seed file handy to speed re-discover y.
It's also good to keep in mind how automated discovery works. netmon will
read the ARP cache of already-discovered devices using SNMP, looking for
hints as to what else might be out there. He then has to be able to ping
them to put them in the database, and query them with SNMP in order to
determine just what kind of a device they are. So your devices must be
talking to one another, else you will have to use the ping spray option to
get things rolling. And you should have the correct community names in
communitynames.conf. Even better would be to have them in the database
maintained by snmpconf.exe already.
If this advice doesn't help, then perhaps you should contact Support. If
you have a list of nodes to discover, and netmon is set to discover all
networks, then they should be discovered, and only a netmon trace will tell
you why not.
Your second issue has nothing to do with clearing trapd.log, though that
might help you understand what is happening. I think that it too is a
matter for Support. What's happening is that some daemon or process which
has registered with trapd to receive traps is too busy processing what it
already has to keep up with what is being added to it's internal queue (a
socket connection). When the queue reaches the predetermined maximum size,
trapd disconnects the application rather than let its own internal storage
be depleted with events destined for this unresponsive application. The
question is first, what application is it, and second, why is it falling
behind? Most of the well-known NetView daemons (snmpcollect, netmon, etc)
will have their name show up in that message. "netmon-related application"
is the default and could be anyone, including Switch Analyzer. One cause
of this could be a trap storm, which is where trapd.log might be of some
help in determining that. Another could be a problem with that other
process, so the trick is to determine whom it is. That's more difficult to
determine, and you'll probably need a trapd.trace at the time that it
occurs as well as a process list.
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
Sent by: <email@example.com>
[nv-l] discovery not happening
Please respond to
I am running netview 7.1.4 on windows with fix pack 3,
In my netview it discovered almost all networks, recently a new router
was added to the remote location ,I was trying every thing possible to get
it on the map I even tried the loadhosts command it did not work ,then I
tried the ovtopofix command,it give me a bizaree error message ,yesterday I
cleared the database a put a rediscovery now it is unable to get half the
nodes on map even the links are missing
Could any one help me out,
Second concern is not all events are coming to tec ?
In tec always an error message I get is----( netmon-related Application
reached maximum number of outstanding events, disconnecting from trap)
So what I do is clear the trapd log ??
Thanks in advance
(Embedded image moved to file:| |
pic27363.jpg)USTechnology | |
firstname.lastname@example.org Technopark, Trivandrum
Tel: ++91-471-2335777 extn 8652
Description: JPEG image