DHCP Failover and duplicate responses

David W. Hankins David_Hankins at isc.org
Fri Sep 7 18:56:13 UTC 2007


On Fri, Sep 07, 2007 at 12:03:33PM -0600, Jesse Norell wrote:
>   Anyways, I've setup a dhcp failover pair and I find that with both
> running, normal lease renewals work fine, but an explicit release/renew
> assignes a different ip address every time.  It's actually the secondary
> server that does that (the primary server will try to assign the same ip
> address, the secondary tries to change it, and it always ends up
> changed).  Is there a way (configuration) to have the same ip address
> always assigned?

When a lease is released, it enters the 'free' state.  The secondary
can not allocate 'free' leases.  It can only allocate 'backup' leases.

The lease *may* move to backup state if the pool is rebalanced.  But
that is not very likely since the server will elect to move the oldest
leases (with the most historical expiration) first to backup state.  I
don't think there was a motivation for this, I think it's just a
result of how the leases are sorted in memory.


In 3.1.0, we added a failover feature called 'mac address affinity'
which immediately queues a free->backup state change if the released
or expired lease "would have" been load balanced to the secondary,
and reinforces that desire in pool rebalance events.

This doesn't guarantee that the secondary will be around to offer and
then allocate this lease to this client, or even that it will choose
to do so when the time comes, so it is not a guarantee that the lease
will always be granted.  But it should lower the frequency of the
behaviour you're describing, and cause less 'pool churn'.

It has another useful property, which is that if the leases are
load balanced between primary and secondary to start with, then
expirations and releases will more or less return leases to
the free and backup states in something resembling balance.  This
means 3.1.0's scheduled pool rebalance events may not need to fire
as frequently as they might need to otherwise.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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


More information about the dhcp-users mailing list