Thanks for the info on how to set up AIX to look in the host file prior
to looking into at the DNS. I have wanted to figure out how to do this,
so I could set up each router with a better name assoicated with it
other than the interface name. Each interface on a router in our
network has a different name. However each interface name is unique
within the network. There is no association in DNS names on one router
that would be associated with the another router.
What is strange is when I look at some routers they will have 10
interface icons, but the router really has 15 interfaces. All 15
interfaces are up and when you do an nmdemandpoll they all show as being
up. The other 5 interfaces will be in another separate router object.
It is like Netview thinks I have 2 routers instead of 1.
The problem with routers and switches showing up in the wrong subnets,
seems to be associated with the HSRP that I am using on the Cisco
equipment. Netview seems to detect the HSRP on the Cisco 7513 and 7206
devices fine. But it doesn't seem to recognize it correctly on a Cisco
2524 running IOS 11.2(16). On a Cisco 2524 object, the interface
address will show up as an interface and the HSRP address will show up
as an interface. It is the HSRP address that seems to be connecting the
router to the incorrect subnet. I think with the HSRP address it
doesn't associate it with a subnet so it does the best it can to put it
into some subnet. I have worked around the problem by "Adding Object"
for the proper subnet. After I create the subnet object I can usually
delete the router object and rediscover it. When I rediscover it; it
connects it to the correct subnet.
I assume when you said I should put on the 5.1.2 patch, that will bring
my release of Netview up to level 5.1.2? Tivoli Professional Services
installed the 5.1.1 service. They said that there were problems with
release 5.1.2 and that we should hold off on this.
Again, thanks for the info on netsvc.conf.
Raymond
===================================================================
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
|