Based on my observations of netmon's behavior, it appears to me
that this often happens when it discovers non-snmp things. For this
reason it is a bad idea to put non-snmp things in the seedfile. Find the
routers and hubs first, so the networks get drawn correctly, and then
the questionable things, or things we can only get the mask for via
icmp, will join their friends rather than vice-versa. The first guy on it
is usually the culprit. I know it gets the mask via snmp if it can, and
if not, apparently there is some way to get it from the ping that I don't
The key is the sequence of events. So an initial seedfile that excludes
non-snmp ([email protected] 0) and includes the routers ordered from near to far
will get you off to a good start. Then open it up for broader discovery.
Deleting and rediscovering networks that were found too soon also
takes care of it.
Sometimes even after you get it all right, there are a couple of odd,
disconnected networks with nothing on them that keep coming back.
Those I hide, and explain away as 'junk from somebody's arp cache'
and don't worry about them. Yes, that is a made-up explanation.
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
I seem to get this all the time....
I'll be setting up a netview map and Netview picks up a network such
as 10.0.0.0 ie a "class A" network. I check the topodump and there
are no devices referencing a network with that netmask, but it
picks it up nonetheless. If I delete it, it comes back sooner or later.
All I can do is hide it.
Sometimes this causes netview to connect devices incorrectly and only
after I do an ovtopofix -r of the clashing network, can I get things
to draw correctly.
Today I had a case which was a fairly normal class C network (255.255.255.0)
but netview decided that network was 255.255.255.192 and drew it as two
networks. Again no devices referenced this network with incorrect netmasks.
Does anyone know how Netview decides what networks it is going to use?
To me it would appear to involve the dark side of the force.