David -
I don't even pretend to be a DNS expert,because I have no practical
experience, only classroom.
But I can tell you this, for any interface for which you have a hostname,
you must get the exact same response to
nslookup <short_hostname>
nslookup <fully_qualified_hostname>
nslookup <IP_Address>
every time you do it.
James Shanks
Tivoli (NetView for UNIX) L3 Support
"David T. Smith" <dsmith@TUCKERNET.COM> on 08/25/98 05:33:45 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView et alia <NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks)
Subject: Re: NetView-T/EC-DNS Implementation Problem... HELP!
At 04:33 PM 8/25/98 -0400, James_Shanks@TIVOLI.COM wrote:
>David -
>
>You are absolutely correct that NetView expects your hostname to resolve
to
>one and only one IP address and your IP address to resolve to one and the
>same hostname. NetView does not do his own name resolution. He relies on
>the operating system to give the same answer to gethostbyname as
>gethostbyaddress, which are the only two calls he makes. If you
>deliberately set up DNS to violate this convention, then you can expect
>problems with NetView, such as those Julio reports.
However, NetView can get confused here. In our environment, we had systems
with multiple IP interfaces (not performing routing) and different DNS
names for each interface. In that case there were symbols for these
systems in each of the IP Network maps corresponding to the network number.
However, while the symbols (mostly) appeared to connect to the same
object, the symbol name showing up on the map was randomly selected from
the names available to that object. For example, a single node configured
as follows:
host1-a A 192.168.1.1
host1-b A 192.168.2.1
host1-c A 192.168.3.1
would show up on the map sometimes as hots1-a, sometimes as host1-b and
sometimes as host1-c (and the names were not related to the network
displaying the symbol. When I named the host as follows:
host1 A 192.168.1.1
A 192.168.2.1
A 192.168.3.1
1.1.168.192.in-addr.arpa PTR host1.network
1.2.168.192.in-addr.arpa PTR host1.network
1.3.168.192.in-addr.arpa PTR host1.network
the resolution on the NetView side seemed to be correct. However, I
haven't followed up on propagation of Tivoli errors as we are only
propagating Node UP and Node Down errors at this time and not for the nodes
I made this change on.
Which would you consider an incorrect DNS configuration?
>
>I am not an expert on HSRP but I did not think it required any DNS changes
>or multiple resolution. I thought that was the whole point of it, that
the
>name and IP address stayed paired but that the location of the interface
>changed from router to router, as if you had unplugged the box in one
>location and moved it to another. ....
That is correct as far as I know. However, HSRP addresses do not show up in
the Interfaces table (they are accessible elsewhere), and this causes
problems in consolidating all of a router's interfaces under the same
object. I expect this is what Version 5.[01] will handle (we are expecting
to deploy it in the near future).
Thanks,
DTS
--
//==========================================================\\
||David T. Smith | Specialists in ||
||Tucker Network Technologies | Network Computing ||
||50 Washington St., PO 429 | -------------------- ||
||South Norwalk, CT 06856 | dsmith@tuckernet.com ||
\\=========================================================//
|