Network delay kills zone transfers?
Christopher Earley
cearley at peri.com
Thu Jun 24 21:48:46 UTC 1999
Folks,
Just wondering if anyone answered Matt Larson's question
from May 28th (and my news server failed to suck it in)?
I've got the same exact problem with a secondary server
in Singapore (xfer from a primary in New York). Truss of relevant
procs shows numerous EAGAIN errors. At first I suspected memory &
swap problems, but a memory and swap boost hasn't helped, and the
Stevens books mention that EAGAIN is sometimes synonomous with the
EWOULDBLOCK error for network reads, so lost/slow packets might be
the issue.
I've got named 4.9.3-P1 on Solaris 2.5.1 for the failing
secondary. An answer to Matt's question would be a great help.
Thanks,
Christopher Earley
Periphonics Corporation
cearley at peri.com
Matt Larson wrote:
>
> Hi, folks.
>
> I've got a customer with a slave about 600ms away from its master
> server. The slave is unable to perform zone transfers: they start and run
> for a few minutes, only to die with this familiar error on the slave:
>
> zoneref: Masters for secondary zone "x.y.z.IN-ADDR.ARPA" unreachable
>
> (I'm sorry to be flaky and blank out the zone name, but this is one of
> those "I could tell you but then I'd have to kill you" organizations.)
>
> Only this one topologically distant name server has this problem; the other
> slaves are fine. This remote name server is a slave for several zones from
> the same master and all fail similarly. This remote slave can ping the
> master just fine, albeit with the 600ms delay. Both servers run a recent
> version of AIX (not sure which version) running the BIND name server
> shipped by IBM, which is 4.9.something.
>
> Is named-xfer not able to cope with this much latency? Or could that be a
> red herring?
>
> I'd be grateful for any ideas.
>
> Thanks,
>
> Matt
>
> --
> Matt Larson <matt at acmebw.com>
> Acme Byte & Wire / http://www.acmebw.com
More information about the bind-users
mailing list