RE: [nv-l] Seedfile entries not being discovered

Well, if you are game about it, then you could do what the Level 2 Support guy would have you do as a first-level look. Remove the netmon trace file. Move those addresses to the top of your seed file. Then turn on the full netmon trace (netmon -M 31 from the command line ) and then have it re-read the seed file (netmon -y from the command line). After a few minutes, grep the netmon trace file for those addresses. When you find them, turn off the netmon trace (netmon -M 0) and browse the file for where those addresses occur. You should be able to see what happens when netmon tries to find them. Sometimes the error messages are clear, sometimes not.

If you can't figure it out, call Support. NetView Level 2 has people who read those traces all the time. Helping solve discovery problems is part of their every-day job. And when they can't, that's how APARs get written to fix a discovery problem.

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

"Christopher J Petrina" <cjp8 AT meadwestvaco DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com

03/02/2004 02:12 PM

Please respond to
nv-l

To	nv-l AT lists.us.ibm DOT com
cc
Subject	RE: [nv-l] Seedfile entries not being discovered

To my knowledge there is no NAT'ing that should be causing any issues. The few sites we have that are being NAT'd I have made special considerations for. I have labeled those so I know how to deal with them. The only thing I know that is quarky about the network, is that the WAN is ATM/Frame other then that I cannot think of anything else that owuld cause the troubles. Nothing in OSPF I can think of would prevent the devices from being discovered

Thanks
Chris Petrina

"Barr, Scott" <Scott_Barr AT csgsystems DOT com>
Sent by: owner-nv-l AT lists.us.ibm DOT com

03/02/2004 01:57 PM
Please respond to nv-l

To: <nv-l AT lists.us.ibm DOT com>
cc:
Subject: RE: [nv-l] Seedfile entries not being discovered

I ran across this recently. It was due to NAT. I had a stub object in the database. What was happening is I had a valid path to the box and could snmpwalk the device. But when NetView attempted to add it to discovery, it was unable to because the interface table did not contain the address that I traversed to get to the box with SNMP.

Is NAT involved in any of these objects?
-----Original Message-----
From: owner-nv-l AT lists.us.ibm DOT com [mailto:owner-nv-l AT lists.us.ibm DOT com]On Behalf Of Christopher J Petrina
Sent: Tuesday, March 02, 2004 12:08 PM
To: nv-l AT lists.us.ibm DOT com
Subject: [nv-l] Seedfile entries not being discovered

I have seen this now for awhile. I have ip addresses in the seed file that are not being discovered. Theya re valid and pingable IP addresses. I reviewed the netmon.trace log and it shows both a sending and a receiving of a ping from 10.213.1.6 but nothing else. When I do an ovtopodump | grep 10.213.1.6 returns no value either. I ahve seen this in many of the IP addresses. All of which have basically the same entries in netmon.trace they are sent a ping they return the answer and then nothing more comes of these devices. These are by the way L3 switches/Router ip addresses. I never thought anything of it since finding devices via a seedfile is a very core level of Netview and never have I heard of Netview not finding a device in the seedfile when it was alive. So Ithought it could be the way in whcih I was discovering them. But this just does not seem to make sense to me. Any h! elp? it is a fairly big se! edfile as we are not doing auto discovery. We only want to discover what is in the seedfile.

Chris Petrina

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service._______________________________________________________________