DHCP Failover DDNS leases file issue or bug?

[Colin Simpson]

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 at 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 at 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.