Date: Mon, 7 Aug 1995 17:27:27 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: gibbs@freefall.cdrom.com (Justin T. Gibbs) Cc: jkh@time.cdrom.com, freebsd-current@freebsd.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: workaround for talk's address problem Message-ID: <199508080027.RAA01875@gndrsh.aac.dev.com> In-Reply-To: <199508071440.HAA05932@freefall.cdrom.com> from "Justin T. Gibbs" at Aug 7, 95 07:40:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >NFS does not have such a problem, or at least I have never seen it, and > >I have _lots_ of networks, all but 1 serving NFS: > > > >gndrsh# nslookup gndrsh.aac.dev.com > >Server: gndrsh.aac.dev.com > >Address: 0.0.0.0 > > > >Name: gndrsh.aac.dev.com > >Addresses: 198.145.92.49, 198.145.92.241, 198.145.92.17, 198.145.92.33 > > > > > >mountd gets confused if you add an interface and don't restart it, but > >other than that and routing path problems it works just fine. It does > >not have the problem that was described about talk, NFS handles this > >stuff just fine! > > Is gndrsh the only multi-homed machine you have? Since gndrsh is also > the nameserver you are resolving from, you will not see the problem with > NFS so long as any client is on a net local to gndrsh. Bind is smart > enough to order its results to any client on a local net since it can > easily determine which is "closest" to the client. Humm.. I'll have to go play with that idea and point my nfs clients at some far away secondary name server :-). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508080027.RAA01875>