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

[James Shanks <jshanks@us.ibm.com>]

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@meadwestvaco.com>
Sent by: owner-nv-l@lists.us.ibm.com

03/02/2004 02:12 PM

Please respond to
nv-l

To	nv-l@lists.us.ibm.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@csgsystems.com> Sent by: owner-nv-l@lists.us.ibm.com 03/02/2004 01:57 PM Please respond to nv-l

To:        <nv-l@lists.us.ibm.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@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Christopher J Petrina
Sent: Tuesday, March 02, 2004 12:08 PM
To: nv-l@lists.us.ibm.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._______________________________________________________________