DHCP Failover questions

David W. Hankins dhankins at isc.org
Fri Nov 13 23:17:48 UTC 2009

On Fri, Nov 13, 2009 at 11:27:48AM -0500, Jason Frisvold wrote:
> 	What bothers us is that both servers are responding to the DHCPDISCOVER
> packets coming in.  Why are the servers not honoring the split?  Are we
> doing something wrong here?


1) The lease has to be covered by a failover peer relationship.  This
   means it's a dynamic lease, in a pool, with a peer declared.  For
   example a host record with a fixed-address statement won't be
   covered (but these are stateless anyway so there is no harm in

2) The failover relationship in question must be in the "cooperating"
   service state.  This indicates the remote peer is ready to answer.
   So, check your failover state, if it's 'normal' then this probably
   isn't it, if it isn't normal then that's something to look at.

3) 'load_balance_max_secs >= ntohs(secs)' - LBA is disabled if the
   client is sending a 'secs' field that is greater than the
   configured limit.  Note that some clients always send zero, and
   some clients are confused about the integer byte order of the
   16-bit field (and so, for '1' second they send '256').

4) HBA hashes to the local server.

If all four conditions are fulfilled, then the DHCPDISCOVER is
ignored; 'load balance to peer' is logged.

Note that some DHCPREQUESTs are not load balanced even though it
is expected the peer server may be able to answer.  This is a
limitation brought on by deeper problems; the DHCP software has
trouble differentiating between packets intended for it, and its
peer, because of the way it keeps track of IP addresses assigned
to interfaces (and so whether or not a server-identifier is local
or remote).  When a lease is free or backup this is used to decide.
The trouble comes with 'active' leases.

There is usually no harm from this of course, but we did make changes
in later maintenance to resolve problems that arise from inconsistent
updates between the servers (both try to update the lease to each
other) and some race conditions that arise ("dueling updates").

David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20091113/73b91bf0/attachment.bin>

More information about the dhcp-users mailing list