Re: [TCLUG:5871] resolving multihomed ips

[Clay Fandre <cfandre@minn.net>]

OK. I figured it out. For some reason (RH default?) in my
/etc/nsswitch.conf file, the order of the hosts entry was:
NIS DNS FILES
which resulted in lookups to use NIS before DNS. That caused nslookup to
work (since it always uses DNS) but other services used NIS to resolve
hostnames, resulting in the wrong IP. After I switched the order to
FILES DNS NIS
everything seems to be working correctly.

Mark,
It also works with the default glibc that comes with RH (both 5.2 and
6.0), and I didn't have to use the sortlist option in my resolv.conf.

I'm not really sure what the sortlist does. It seems to me it would
break what I am trying to accomplish. I want my services to use the
first IP returned by DNS, and doesn't sortlist order that list???

Clay Fandre

"Mark A. Bentley" wrote:
> 
> On Fri, 7 May 1999, Clay Fandre wrote:
> > /etc/hosts is empty except for the localhost, kramer, and DNS server. So
> > it is resolving the name with the DNS server, but it is using the last
> > IP it gets, instead of the first. Anyone have a multihomed server with
> > this working? Both Slowaris and HS-UX works fine.
> >
> > Clay
> >
> 
> Yes, I did get it working.  It seems odd that you'd always be getting the
> same undesired IP from the list of addresses though.  Without sortlist
> functionality you'd normally resolve IPs in a round-robin fashion.  For
> example, using ping, which is linked against the libc6 that comes with
> RedHat 5.2, ping caesar.cs.umn.edu and you'll see that the IP resolved
> rotates:
> 
>    PING caesar.cs.umn.edu (160.94.239.160): 56 data bytes
>    64 bytes from 160.94.239.160: icmp_seq=0 ttl=254 time=1.4 ms
> 
>    PING caesar.cs.umn.edu (128.101.224.60): 56 data bytes
>    64 bytes from 128.101.224.60: icmp_seq=0 ttl=254 time=1.4 ms
> 
>    PING caesar.cs.umn.edu (128.101.228.60): 56 data bytes
>    64 bytes from 128.101.228.60: icmp_seq=0 ttl=254 time=1.3 ms
> 
>    PING caesar.cs.umn.edu (128.101.248.6): 56 data bytes
>    64 bytes from 128.101.248.6: icmp_seq=0 ttl=254 time=1.8 ms
> 
>    PING caesar.cs.umn.edu (128.101.230.60): 56 data bytes
>    64 bytes from 128.101.230.60: icmp_seq=0 ttl=254 time=14.8 ms
> 
>    PING caesar.cs.umn.edu (160.94.239.160): 56 data bytes
>    64 bytes from 160.94.239.160: icmp_seq=0 ttl=254 time=3.3 ms
> 
> If I ping a multi-homed host which has an interface on the same subnet I'm
> on, we get:  (this is doing "ping mail.cs" from feyd.cs)
> 
>    PING mail.cs.umn.edu (128.101.229.42): 56 data bytes
>    64 bytes from 128.101.229.42: icmp_seq=0 ttl=255 time=2.7 ms
> 
>    PING mail.cs.umn.edu (128.101.229.42): 56 data bytes
>    64 bytes from 128.101.229.42: icmp_seq=0 ttl=255 time=4.6 ms
> 
>    PING mail.cs.umn.edu (128.101.229.42): 56 data bytes
>    64 bytes from 128.101.229.42: icmp_seq=0 ttl=255 time=12.2 ms
> 
> For this to work, you need to put a line in your /etc/resolv.conf like
> this:
> 
>    sortlist 128.101.229.0/255.255.255.0
> 
> ...that's network/netmask.  The problem is RedHat didn't compile in
> sortlist support when they built glibc. To fix the problem, I just added a
> -DRESOLVSORT in the resolv/Makefile, rebuilt the RPMs and installed them
> again (need to use --force.)
> 
> If you don't feel like rebuilding the RPMs, you can grab the ones I built
> from:
> 
>    ftp://ftp.cs.umn.edu/users/bentlema/RedHat/5.2
> 
> See Bugzilla bug #1467:
> 
>   http://developer.redhat.com/bugzilla/show_bug.cgi?id=1467&BUGLIST=1467
> 
> RedHat claims that the sortlist code hasn't been tested, and they don't
> intend to fix this bug.
> 
> --Mark
> 
> ==========================================================================
> Mark A Bentley                  Email:  bentlema@cs.umn.edu
> Systems Staff, CSci Dept
> University of Minnesota         URL:    http://www.cs.umn.edu/~bentlema/