Creation of duplicate leases in failover mode

[Patrick Schoo]

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.