Creation of duplicate leases in failover mode
Patrick Schoo
Patrick.Schoo at nl.compuware.com
Tue Mar 14 11:33:39 UTC 2006
Hi,
Version: DHCP 3.0.4b3
I have noticed duplicate leases are introduced in the leases database when
failover is used. The following scenario shows how this happens.
- A lease with a uid and a hardware ethernet entry is in the backup state.
- A client with this uid does a DHCPDISCOVER and requests the IP address which
also matches the leases database.
- The primary server finds the lease in the database but can not give it to
the client (not mine to allocate). It will send a new lease to the client in
the DHCPOFFER phase.
- The secondary server also finds the lease, but this server is able to hand
it to the client.
Depending on the address the client chooses the following happens:
Client chooses the IP address from the primary
The client now has an address which is different from the requested address.
Actually there is no good reason for this because the requested address was
available. The leases database contains two entries with identical uids, one
lease in the active state and one lease in the backup state.
Client chooses the IP address from the secondary
The client acquires the address it requested. This seems to happen with DHCP
clients which are more persistent in reclaiming their IP address. The first
DHCPDISCOVER is ignored by the secondary (load balance to peer). But the
second DHCPDISCOVER is granted. However, the leases database on the primary
has a new entry marked as free, but with the uid and hardware address of the
client. It seems this new entry is not synched with the secondary, because
the same lease has a different uid and hardware address and none of the time
fields (tstp, tsfp, atsfp and cltt) are updated.
Possible fix:
When a DHCPDISCOVER is done and the uid or hardware ethernet is found in the
leases file and the leases is in backup state =>
The primary should just hand out the lease it has found, or should load
balance to the secondary. This behaviour could be based on the value of the
split variable.
Other effects:
The leases database gradually gets polluted with duplicate entries. Clients
that do not specify an IP address during the DISCOVER phase can get a
different IP addresses after each reboot. For DHCP 3.0.4b2 I have created a
patch to get rid of duplicate leases. The patch did not make it in b3,
perhaps because it uses the dissociate_lease call. This routine is still
available in the b3 code, but there are no references to it. The routine did
clear the uid and the hardware address from the leases file, but it did not
synchronise these changes to the secondary.
Best regards,
Patrick Schoo.
More information about the dhcp-users
mailing list