Joel,
Thanks for the advice. I'm having better luck now. I've got some other
discovery issues now to work through. However, the routers that netmon has
found that have the DNS entries as the loopback address are being discovered
the way I would like for them to be discovered.
FYI for the Tivoli guys, the "discover loopback interfaces" was not
documented in the 5.1 installation guide where I thought it should've been.
That is, in the "Changing Daemon Defaults" section for netmon, page 8-6.
It's documented in the man pages. Unfortunately, I did not look there in
the beginning.
Mark S. Lucas
Employers Reinsurance Corp.
Networking Systems Specialist
(913) 676-5718 (direct)
(913) 676-5108 (fax)
Mark.Lucas@ercgroup.com
> "Opinions expressed in this message are my own and do not represent
> the opinions
> or policies of ERC or any of its employees, directors,
> officers, shareholders or affiliates."
>
-----Original Message-----
From: Joel A. Gerber [mailto:joel.gerber@USAA.COM]
Sent: Wednesday, November 11, 1998 12:40 PM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Re: How to get NV5.1 to recognize loopback addresses in routers
Here are two things you should look into:
1) you are right that NetView uses the first interface that it discovers for
a router for the label, selection name, etc. Since you set up loopback
interfaces on the routers, and the IP addresses of those interfaces are
defined in your DNS, make sure that your netmon seedfile also has those
names (or associated IP addresses) listed. Even with the seedfile
configured this way, there can still be problems. If there are other
entries in your seedfile (like an IP address range) that will allow netmon
to discover the routers, then you may still get the same results. Where
this has occurred in our network, I have just deleted the router object from
the map(s), and then rediscovered it by pinging it by name. Netmon should
discover it correctly in that case.
2) It also sounds like netmon is not discovering the loopback interfaces at
all. Make sure that the "discover loopback interfaces" option is turned on
in the netmon daemon configuration. Check if the netmon daemon is running
with the "-L" flag. This option allow netmon to discover loopback
interfaces that have an IP address other than 127.0.0.1.
-----Original Message-----
From: Mark Lucas [SMTP:Mark.Lucas@ERCGROUP.COM]
Sent: Tuesday, November 10, 1998 10:14
To: NV-L@UCSBVM.UCSB.EDU
Subject: How to get NV5.1 to recognize loopback addresses in
routers
Joel,
I filed your below response away knowing at sometime I'd refer back
to it.
I'm in the process of building a NV5.1 system and there are several
Cisco
routers in our network that have multiple paths to them. I was
looking for
a way to associate one host name/IP address with a router such that
via DNS
we'd always be able to telnet/ping/traceroute to that node and not
have to
worry about a particular interface being down on a router.
Assigning a
loopback address to the router seems to be the way to go to achieve
that
capability.
I pre-configured DNS as you recommended below. That is, I assigned
loopback
addresses to all routers and only put those names in DNS. However,
as
Netview is discovering my network, it's mechanism is using the IP
address of
the first interface it encounters for a particular router as it's
label,
selection name, and IP hostname, etc. Furthermore, an "ovobjprint
-s ..."
of that router doesn't even acknowledge the presence of the loopback
interface, as it's "TopM Interface Count" is 3 (two serial plus 1
token-ring).
So, my question to anybody out there is is there anyway that I can
have
Netview recognize these loopback addresses? And, furthermore, would
there
be a way of telling or fooling the discovery mechanism into picking
the
loopback interface as it's main object in the database? Thanks for
any
suggestions.
Mark S. Lucas
Employers Reinsurance Corp.
Networking Systems Specialist
(913) 676-5718 (direct)
(913) 676-5108 (fax)
Mark.Lucas@ercgroup.com
-----Original Message-----
From: Joel A. Gerber [mailto:joel.gerber@USAA.COM]
Sent: Tuesday, August 25, 1998 7:53 AM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Re: NetView-T/EC-DNS Implementation Problem... HELP!
If your routers support it, I would recommend configuring a virtual
loopback
interface with an IP address, and then define that IP address in
your DNS.
Make sure that it is the only IP address defined in your DNS to
avoid the
problem with round-robin. If there are multiple paths in your
network, you
will also get the added benefit of better connectivity to your
routers. For
example, if you have multiple IP addresses defined in DNS, and one
of them
is not accessible because the interface is down, (or the path to
that
interface is "broken"), then NetView will fail trying to access that
router.
The round-robin support in DNS will help a little, because it will
return
the next IP address the next time NetView queries that router.
However, you
will still have failures. Loopback interfaces solve this problem
because
the routers will automatically update their routing tables to
provide a path
to the loopback interface when an interface is down (assuming there
IS
another network path).
-----Original Message-----
From: Julio W. Troya [SMTP:julio_troya@HOTMAIL.COM]
Sent: Monday, August 24, 1998 15:50
To: NV-L@UCSBVM.UCSB.EDU
Subject: NetView-T/EC-DNS Implementation Problem...
HELP!
We are currently in the process of implementing DNS for our
NetView environment and have found a problem which we
cannot solve.
Our environment consists of a NetView (5.0) server which
feeds
multiple interface-router events to T/EC (3.1), and here's
where the
problem manifests itself. Both servers are running with AIX
4.2.
Our NetView server is also configured as a secondary DNS
server, and
whenever NetView resolves the host name to an IP address, it
will
always return with a different primary IP address for the
router.
It seems that it is selecting the next IP address in an
"round-robin"
fashion.
Because we get a different IP address for each event, T/EC
is unable
to
correlate clearing events with old down events. For
example, T/EC
will receive a node down event:
RG100BRA 10.0.7.131 Node down
when the clearing event arrives, the interface address will
be
different, and
hence T/EC thinks it is a different device:
RG100BRA 10.22.0.2 Node up
I have included the response to two nslookup commands, the
second
executed immediately after the first. As you can see, for
each
command, we get a different IP address as the first
interface in the
router.
> nslookup RG100BRA
Server: localhost.bns
Address: 127.0.0.1
Name: RG100BRA.corp.bns
Addresses: 10.0.7.131, 10.22.0.2, 10.22.0.6,
10.170.0.1
10.171.0.1, 10.0.12.3, 10.0.4.189
> nslookup RG100BRA
Server: localhost.bns
Address: 127.0.0.1
Name: RG100BRA.corp.bns
Addresses: 10.22.0.2, 10.22.0.6, 10.170.0.1,
10.171.0.1
10.0.12.3, 10.0.4.189, 10.0.7.131
1. We would like to know if there is a way to 'force'
NetView to use
a specific IP address as the primary IP address for the
router,
without having to use the /etc/hosts file?
2. Has anyone implemented DNS, NetView and T/EC
successfully?
3. Is there a Redbook which describes this type of
implementation?
Any help will be greatly appreciated.
Julio W. Troya
Associate Technical Specialist
Enterprise Systems Management
Bank of Nova Scotia
Scarborough, Ontario, Canada
Tel: 416-701-7144
Fax: 416-288-4400
E-mail: julio_troya@hotmail.com
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
|