I have exactly the same situation with the customer I am supporting.
The way I addressed the problem was as follow:
- I specify in the seed file that theses devices are not to be polled with
snmp (to avoid filling the logs with authentication failure) This is not
perfect because on first discovery, the device will still be polled but
once it is discovered there should not be further snmp polling.
- In order to avoid isolated networks for each of the remote sites, I use
loadhosts to create the interfaces of the routers.
The only interface of each router that I know is the LAN interface: I
create it with the correct subnet mask because if I don't, the interface
will be discovered by Netview as in a class A because we use 10.x.x.x
addressing and Netview considers any 10.x.x.x address that it can not get a
mask for as a class A (with mask 255.0.0.0)
In order to avoid the isolated network and to create a "path" between each
site (this is needed for ITSL2), I create a second interface in each of the
routers. This interface is from a subnet that doesn't really exist and I
make sure to unmanage it. This allow Netview to change the icon of the
device to a router and move it in the subnet on the map (so that operators
see it is a connector). Once this is done for each router I get a subnet
where all the routers are connected and this represents the MPLS cloud.
However be aware that RFI will not work correctly as it can not talk snmp
to the routers.
Salutations, / Regards,
Francois Le Hir
Network Projects & Consulting Services
IBM Global Services
Phone: (514) 205 6695
<R.Veenstra@Unive
.nl>
Sent by: To
owner-nv-l@lists. <nv-l@lists.us.ibm.com>
us.ibm.com cc
Subject
03/10/2004 08:07 [nv-l] Network discovery without
AM SNMP access to routers
Please respond to
nv-l
Hi
Our company has a network with some rather odd requirements we have to
adress with Netview.
We have several main offices with both serverfarms and user workstations
(Windows). Additionally we have some 150 remote offices with only client
workstations (windows) and basic authentication/file/print servers. These
are connected over an MPLS WAN by an independent carrier. The WAN routers
are property of this carrier and we are not provided with a community
string to manage them. So effectively we have a CIDR-subnetted network with
over 150 LANs, and are blind with respect to the routers.
Additionaly we need to discover all nodes in all subnets, because we need
the Netview object database as input for several other processes. To
complicate this, the workstations get their IP address by DHCP. But still
we want to discover them, although there is no need to do status
monitoring. We need a complete database of all network-connected nodes with
a basic profile of their capabilities (we check for open ports to detect
Windows OS, Tivoli Endpoint Software, Telnet etc), for which Netview is a
very well-suited tool.
So the issue is: how to build a reliable discovery without access to the
routers? We should not even try to connect to them with SNMP because the
carrier doesn't like us flooding their error logs. Still we want them (as
an IP interface) in our database, because we want to be able to
differentiate between a server that is down and a lost WAN connection.
Can somebody point me in the right direction? This issue goes beyond the
usual network configurations that are covered in the NetView manuals.
Some questions I already have:
- In the seed file one should not add nodes that Netview can't access with
SNMP, so adding the routers isn't a good idea. But how can I make sure they
will be discovered quickly? We want to monitor their status.
- If a node is explicitly excluded from SNMP status polling in the seed
file, will it still be polled for it's configuration with SNMP? If Yes, how
to prevent this?
- We can query the Cisco switches at the remote locations with SNMP. But
since these are ethernet switches that the clients not directly connect to
so I think it's very unlikely one would find more than only a few entries
in their ARP caches. Could this be imploved by something like a periodical
network scan with nmap, using the IP address of the switch as source
address?
With kind regards,
Rick Veenstra
ICT Specialist Midrange
Univé Verzekeringen
Beheer & Exploitatie
team Infrastructuur Ontwikkeling en Beheer
Bezoekadres: Hanzeplein 1, Zwolle - kamer B515
Postadres: Postbus 607, 8000 AP Zwolle
Telefoon: (038) 427 8943
Mailto:r.veenstra@unive.nl
============================================
Toelichting bij dit e-mail bericht:
Dit bericht is slechts bestemd voor de geadresseerde en kan informatie
bevatten die persoonlijk en/of vertrouwelijk is en die niet openbaar mag
worden gemaakt. Indien u niet zelf de geadresseerde bent, wordt u erop
gewezen dat verdere verspreiding, openbaarmaking of vermenigvuldiging van
dit bericht verboden is. Indien u dit bericht per vergissing hebt
ontvangen, verzoek ik u mij zo snel mogelijk op de hoogte te stellen en het
originele bericht en eventuele kopieën ervan, te verwijderen. Dank voor uw
medewerking. Hoe Univé het medium internet beschouwt als informatiedrager
kunt u lezen op deze pagina. Univé kan niet garanderen dat een verzonden
e-mailbericht vrij is van virussen, noch dat e-mailberichten worden
overgebracht zonder inbreuk door of tussenkomst van onbevoegde derden.
============================================
De woorden [deze pagina] in de voorlaatste regel zijn de verwijzing naar de
tekst op de website.
|