Raymond, this sort of thing could be caused by oddities in name resolution.
At each maintenance level of Netview, it has come to rely more and more
on name resolution when drawing the network. Does any interface on either
router have an name (in /etc/hosts or DNS, in either direction) that would
associate it with the other router? It could be that a change was made
after
your 5.0 discovery which Netview would not reflect, but which on
rediscovery
gets drawn differently. Is there anything in /usr/OV/log/netmon.trace about
devices being in the wrong network? Any events about duplicate IP
addresses?
I would make sure that /etc/netsvc.conf says 'hosts=local,bind' (assuming
you
are using a DNS), and that the /etc/hosts file has three entries for each
of the
two routers, with the serial interface first, then the other two. Use the
same name
on each entry for a device (use an alias as well, if you need one, but put
the
common name first).This will override anything that might be in DNS or
WINS.
Use 'rnetstat -I <address>' to make sure you are documenting the actual
configuration of the devices. Then stop netmon, delete the two routers and
all
networks associated with them. Wait for the events to show up saying that
they
were deleted. Use Locate, or 'ovobjprint | grep <address>' to make sure
there
are no duplicate addresses involved. Then 'ovtopofix -a'. Put the two
routers
(by their serial addresses) in the seedfile if you are using one.Then
restart
netmon. If you are not using a seedfile, start pinging those two serial
interfaces
at the commandline to rediscover the routers.
I assume that when you say 'hot standby' you are referring generically to
the BRI
interfaces, and not to Cisco HSRP interfaces.
If they are drawn correctly using this procedure, then you need to do a
close
analysis of your naming procedures for network devices (check forward and
reverse lookup). If they are still not drawn correctly, then you should
call Support,
because I have not seen this problem when naming is done they way Netview
expect it to be done.
Also, you should put on the 5.1.2 patch, although I did not see that
problem at
5.1.1, either, and I have discovered a lot of networks in the past year. I
can say
with confidence that 98% of the time, if Netview draws something goofy,
there is
something goofy in your network. Happy hunting.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
===================================================================
I have been running Netview 5.0 and the discovery worked fine. I just
upgraded to release 5.1.1. I decided to clear the maps and start all
over with discovering the network. I have run into a problem where it
seems Netview doesn't decipher the subnets correctly.
I have 2 routers at 2 different remote offices. Each has an Ethernet
interface, a serial interface and a BRI interface for backup.
Router A has an ip address of 10.192.152.1 and a hot standby address of
10.192.153.1. The subnet mask is 255.255.252.0. With this subnet mask
the network address is 10.192.152.0 and the broadcast address is
10.192.155.255.
Router B has an ip address of 10.192.156.1 and a hot standby address of
10.192.157.1. The subnet mask is 255.255.252.0. With this subnet mask
the network address is 10.192.156.0 and the broadcast address is
10.192.159.255.
What Netview is drawing is 2 router icons representing the 2 router. It
then draws one network icon with an address of 10.192.152.0 and mask of
255.255.252.0. It doesn't draw a network icon with an address of
10.192.156.0 and mask of 255.255.252.0. It then draws connections
between the 2 routers and the 1 network icon (10.192.152.0). When I
"manage" the 10.192.152.0 icon, Netview discovers all the addresses on
the 10.192.152.0 subnet. It doesn't discover any of the address on the
10.192.156.0 subnet. When I double click on the 10.192.152.0 network
icon it shows both routers attached to the same subnet. It also show
the ethernet switches that are at both sites attached to the same
network. But it only shows the workstations at the A location.
Netview has done this same thing at several of the other locations
during the discovery process.
I have verified that each router has the proper subnet masks. What
could be the problem? And, how can I correct this error?
Thanks
|