nv-l
[Top] [All Lists]

FW: Antw: Re: NetView Discovery and ARP

To: nv-l@lists.tivoli.com
Subject: FW: Antw: Re: NetView Discovery and ARP
From: mailshield <mailshield@burlington.com>
Date: Thu, 15 Mar 2001 11:30:01 -0500

-----Original Message-----
From: Michael Seibold [mailto:Michael.Seibold@gek.de]
Sent: Thursday, March 15, 2001 3:09 AM
To: nv-l@tkg.com
Subject: Antw: Re: [NV-L] NetView Discovery and ARP


Hi Les, hi Paul,

I don't think there is so much mysterie about discovery. Maybe I'm wrong but
here is the way I think it works with most tools (without seed-File, that is
tool-specific):

o   read the arp-cache of your local machine your software is running on
     In most cases you now you have at least the IP-address of the
default-gateway discovered. If your Network is not switched you'll have more
adresses.

Loop for each new IP-address

    o    try to read the interface-table with snmp from this IP-address
          If you have snmp-access this will give you a list of connected
IP-networks you now can draw on your map

    o    try to read the ARP-table from this IP-address
          this will give you more new IP-addresses to work on

    o    try to read the routing-tables from this IP-address
          this might give you even more addresses to work on

end loop


The seedfile can help to
- set up addresses that have to be checked to speed up discovery
- prevent other addresses from beeing checked
- ... (see manual)


It is easy to see why discovery sometime fails:
- you have no snmp-access to a gateway due to incorrect communities
- you have no snmp-access to a gateway due to access-lists or firewalls
- you have devices without snmp (are there still some out there?)
- some ip-addresses are very silent and are no longer in an arp-table
  (some tools try to avoid this doing a ping to all possible IP-addresses, 
   but just think of a Class A - network...)
- routing problems: you discover IP-addresses in some arp-tables but 
  you are unable to reach them
- one of the most common problems is that you use name resolution 
  and this may take very long if 
  the addresses can't be resolved. I observed a case where the second 
  or third nameserver in hierarchy didn't answer and there seemd to be a 
  timeout-problem which caused netmon to wait forever,
  so there were no more status changes on the map 
  (wasn't too bad, erverything stayed green forever ;-)).


Well, I hope I am not too wrong with this and didn't forget too much, but
from this model I could solve or at least find all problems regarding
discovery so far (well, there is this problem with firewalls discussed
lately...).


Happy discovering

Michael Seibold
Gmünder Ersatzkasse GEK




>>> lesdickert@hotmail.com 15.03.2001  04.22 Uhr >>>
I think you're going to find that, like
all other products that do network
discovery, NetView's discovery process
is a trade secret.  Translation:  even
the developers don't understand it.

I think you can bet ARP is involved though.

Les Dickert
Verisign Consulting


>From: "Paul Maine Jr." <paulm@msicc.com>
>Reply-To: IBM NetView Discussion <nv-l@tkg.com>
>To: "Netview List (E-mail)" <nv-l@tkg.com>
>Subject: [NV-L] NetView Discovery and ARP
>Date: Wed, 14 Mar 2001 14:33:40 -0600
>
>Does NetView use ARP as part of the automated discovery process? If so, how
>does it use ARP? I have read conflicting statements in the Tivoli
>documentation.
>
>Thank You
>Paul
>_________________________________________________________________________
>NV-L List information and Archives: http://www.tkg.com/nv-l 

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com 

_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l


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

Archive operated by Skills 1st Ltd

See also: The NetView Web