DHCP failover - disk full, can not commit to lease file

[Glenn Satchell]

DHCP is not a monitoring system. Why not use your existing, dedicated
monitoring system to detect the failure modes you care about, and get that
to trigger failover. This could be simple - turn off the dhcp service, or
put it in partner-down mode.

There are many possible scenarios where this would be appropriate, but is
this something the dhcp server needs to be able to handle?  Is this the
best use of available dhcp developer time?

regards,
-glenn

On Tue, May 28, 2013 9:27 am, Doug Barton wrote:
> I could make a pretty good argument that "My disk is full and I cannot
> write leases" would be something that should trigger failover.
>
> Doug
>
>
> On 05/27/2013 03:56 PM, Steven Carr wrote:
>> No, your disk is full (and you risk more issues than just DHCP
>> problems), DHCPD needs to be able to write the lease information to
>> disk, without that that it will not function. The DHCP failover
>> protocol does not take into account the resources on the local system
>> when assigning DHCP leases, it assumes your resources are adequate
>> enough for the job.
>>
>>
>>
>> On 27 May 2013 19:53, Louis Lau <Louis_Lau at nechk.nec.com.hk> wrote:
>>> Dear all,
>>>
>>> I have two DHCP servers configured as failover peer and the router
>>> relay the
>>> DHCP/Bootp request to both server. When the system works normaly, a
>>> DHCP
>>> discover from client will be broadcast to both server and the observed
>>> behavour is that both server will offer an DHCP OFFER to the same
>>> client,
>>> The primary DHCP server shall reply an IP-A managed by the Primary, and
>>> the
>>> Secondary shall reply an IP-B that is managed by the secondary. Assume
>>> the
>>> client select IP-A and send an DHCP Request for IP-A to both server.
>>>
>>> However recently, primary server disk is full, and in the log there are
>>> a
>>> lot of
>>>
>>> ommit_leases: unable to commit: No space left on device
>>>
>>> We observed that the DHCP does not failover to the secondary in this
>>> case,
>>> and the primary will still response to DHCPDISCOVER and provide a DHCP
>>> Offer.  And in this case, we observed that most client does not try the
>>> DHCP
>>> offer from secondary but most of them choose the IP assigned from the
>>> Primary DHCP server.
>>>
>>> Is this behaviour normal?
>>>
>>> Are there any configuration that can make the server fail to secondary
>>> DHCP
>>> server for similar case or let the client try the other DHCP OFFER when
>>> the
>>> first DHCP IP does not have a ACK?
>>>
>>> Thanks for your help on this matter.
>>>
>>>
>>> Louis Lau
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>