nv-l
[Top] [All Lists]

Re: Netview/Optivity and DNS-BIND-Bug AIX 4.3.2

To: nv-l@lists.tivoli.com
Subject: Re: Netview/Optivity and DNS-BIND-Bug AIX 4.3.2
From: "Waddle, Duane" <DWaddle@COMDATA.COM>
Date: Wed, 13 Oct 1999 11:57:50 -0500
Junk BIND 4.9.3 and go for one in the release 8 track, like 8.2.1 or 8.1.2

My $.02
--D

> -----Original Message-----
> From: Winfried Gehrig [SMTP:Winfried.Gehrig@SKF.COM]
> Sent: Wednesday, October 13, 1999 6:07 AM
> To:   NV-L@UCSBVM.UCSB.EDU
> Subject:      Netview/Optivity and DNS-BIND-Bug AIX 4.3.2
>
> Hello Netview/Optivity-folks around the world,
>
> I would like to add the following DNS-Bug-Info on AIX4.3.2 to Your
> discussion
> around Netview and Optivity.
>
> We have found out, that the DNS-Bind-Version 4.9.3-implementation on AIX
> 4.3.2
> is not
> working correctly when You want to use the "DNS-address-sorting-feature"
> on LANs
> where we use historically several IP-subnets per
> physical-router-interface.
> We use the Netview/Optivity-NMS also as Primary-DNS with several
> IP-addresses on
> the LAN-interfaces to a Token-Ring- and Ethernet-Network.
> The DNS is not able to sort out the nearest IP-address of multihomed
> machines
> like servers and routers.
>
> The effect is that applications like Netview/Optivity are sending  Pings
> not to
> the nearest
> available interface of multihomed-machines like servers and routers.
>
> Our AIX-DNS-machine is configured with the following IP-addresses:
>
> tr0: flags=e0a0043<UP,BROADCAST,RUNNING,ALLCAST,MULTICAST,GROUPRT,64BIT>
>
>         inet 163.158.61.160 netmask 0xfffffe00 broadcast 163.158.61.255
>
>         inet 163.158.56.160 netmask 0xfffffe00 broadcast 163.158.57.255
>
>         inet 163.158.58.160 netmask 0xfffffe00 broadcast 163.158.59.255
>
>         inet 163.158.68.160 netmask 0xfffffe00 broadcast 163.158.69.255
>
>         inet 163.158.70.160 netmask 0xfffffe00 broadcast 163.158.71.255
>
> en0:
> flags=e080863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64
> BIT>
>
>         inet 163.158.62.160 netmask 0xfffffe00 broadcast 163.158.63.255
>
>
> The mistake can be seen by starting named with debug-level 5:
>
> Debug turned ON, Level 5
> Version = named 4.9.3 Tue Sep 30 09:51:20 CDT 1997:/
>      build@jto.austin.ibm.com:
> considering [163.158.61.160]
> dqp->dq_addr 163.158.61.160 d_dfd 7
> listening [163.158.61.160]
> considering [163.158.61.160]
> dup interface address 163.158.61.160 on tr0
> considering [163.158.61.160]
> One line with dup for every IP-address is appearing here.
>
> Network and sort list contains only first IP-adress of each
> network-adapter
>
> addr xa39d3c00 mask xfffffe00 my_addr xa39d3da0 163.158.61.160
> addr xa39d3e00 mask xfffffe00 my_addr xa39d3ea0 163.158.62.160
>
>
> We have tested this also on a SUN which is used as BACKUP-DNS and can say
> that
> address-sorting is
> working correctly. Starting named with same Debug-level on SUN shows up
> with all
>  IP-addresses of the
> SUN in the DEBUG-Output.
>
> Does anybody of You know of a PTF for this mistake ?
> We have already informed IBM in Germany but nothing has happened since
> several
> weeks
>
> Any tip or hint is welcome
>
>                       ```
>                      (o o)
> ------------------oOO-(_)-OOo------------------
> Winfried Gehrig         mailto:Winfried.Gehrig@skf.com
> SKF GmbH                FON  ++49(0)9721 56 3077
> Schweinfurt     Virtual FAX  ++49(0)9721 5663266
> (Germany)
> Our bearings turn the planet
> http://www.skf.com
> -----------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web