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.
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. Perhaps someone else with more
understanding of this protocol can explain it. In any case, depending on
your version of NetView, there are other ways to handle HSRP. It is better
supported in V5.0 and of course 5.1
Tivoli (NetView for UNIX) L3 Support
"David T. Smith" <dsmith AT TUCKERNET DOT COM> on 08/25/98 09:14:21 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView et alia <NV-L AT UCSBVM.UCSB DOT EDU>
To: NV-L AT UCSBVM.UCSB DOT EDU
cc: (bcc: James Shanks)
Subject: Re: NetView-T/EC-DNS Implementation Problem... HELP!
At 4:50 PM -0400 8/24/98, Julio W. Troya wrote:
>We are currently in the process of implementing DNS for our
>NetView environment and have found a problem which we
[...system specifics deleted...]
>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"
>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
>hence T/EC thinks it is a different device:
> RG100BRA 10.22.0.2 Node up
I am also concerned about this issue. The installation I am working on has
not yet fully enabled DNS so many of the reports are passed by IP address
and thus we do not yet have this problem, but I can see a contradiction
between NetView's use of DNS and T/EC's as shown by Julio's problem:
NetView seems to want the inverse addresses to point to a single
name for the node (we have had difficulties where DNS names based on
individual addresses have caused multiple icons to be created--also partly
due to HSRP issues).
T/EC (and TME) want a single address/name matchup so that forward
resolution of a name returns the same address every time.
However, I believe that Cisco Routers can be configured to use a single IP
address for all SNMP traps so that might help on part of Julio's problem.
This address (which could be on a loopback interface), might help although,
since status polls are done through ICMP, it may not.
||David T. Smith | Specialists in ||
||Tucker Network Technologies | Network Computing ||
||50 Washington St., PO 429 | -------------------- ||
||South Norwalk, CT 06856 | dsmith AT tuckernet DOT com ||