[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-users
Subject:    Re: DHCP Failover DDNS leases file issue or bug?
From:       "Colin Simpson" <Colin.Simpson () iongeo ! com>
Date:       2011-02-14 18:38:46
Message-ID: 1297708726.25220.23.camel () cowie ! iouk ! ioroot ! tld
[Download RAW message or body]

That explains it.

It's a shame, it makes DHCP in fail over just a bit less transparent in
operation. 

Thanks for the reply

Colin

On Mon, 2011-02-14 at 16:59 +0000, David Hankins wrote:
> On Mon, Feb 14, 2011 at 4:55 AM, Colin Simpson
> <Colin.Simpson@iongeo.com> wrote:
> I have been playing with using failover DHCP. We also use
> dynamic DNS
> updating. I'm using RHEL 6 with dhcp-4.1.1-12.P1.el6 which I'd
> guess is
> just 4.1.1
> 
> The scenario I have been testing is Primary server down and
> secondary
> up.
> 
> What will now happen to DNS when the lease expires?
> 
> Does the Secondary handle this and remove this entry from DNS
> properly?
> 
> 
> Yes.  The primary will move the lease to expired.  When the secondary
> acknowledges this change, it will tear down the dns names on its end.
> 
> And what if the secondary is now goes down, we'll presumably
> just end up
> with lots of stale DNS entries that won't get removed ever? Or
> will they
> remove when/if the secondary comes back and sees it has DNS
> entries it
> needs to now expire (or isn't it that clever).
> 
> 
> If the secondary goes down, then the lease cannot expire unless the
> primary server is moved to partner-down.
> 
> 
> Probably, because the secondary is down, the primary will nail up its
> own DDNS state for the same client.
> 
> 
> Is this a bug? Shouldn't it send all the fields across when
> they resync?
> 
> 
> A missing feature.  'Binding scopes' are not synced across the
> failover channel.  The failover protocol channel actually doesn't
> (closely) resemble dhcpd's lease structure, so you can't look at it
> like a 1:1 mapping.
> 
> 
> It looks like the leases file does get updated on both for dns
> items if
> both are up when a renew comes from the client. Strange.
> 
> 
> More likely that is a rebind, and both servers are answering in that
> case.
> 
> 
> Any thoughts?
> 
> 
> The failover protocol as specified (draft-ietf-dhc-failover-12 (or
> 13?)) has the primary doing all ddns teardown work (because the
> primary initiates all expirations except a secondary in
> partner-down).  This is inefficient, which is one small problem, but
> mainly it doesn't work well unless you support the
> specification-defined failover ddns options to transfer state, or as I
> said find a way to sync binding scopes ("set var = value;") across the
> channel.
> 
> 
> I sat down to try and provide binding scope transfers in the last few
> iterations of work before 4.2, and unfortunately it was sufficiently
> complicated (not impossible) that it didn't make it.
> 
> 
> -- 
> David W. Hankins
> SRE
> Google, Inc.
> plain text document attachment (ATT3821267.txt)
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

This email and any files transmitted with it are confidential and are intended solely \
for the use of the individual or entity to whom they are addressed.  If you are not \
the original recipient or the person responsible for delivering the email to the \
intended recipient, be advised that you have received this email in error, and that \
any use, dissemination, forwarding, printing, or copying of this email is strictly \
prohibited. If you received this email in error, please immediately notify the sender \
and delete the original.


_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


[prev in list] [next in list] [prev in thread] [next in thread]