ISC Dhcp Failover behavior for INIT-REBOOT scenario

[ravi kumar]

<Resending the mail, as there is no response>
Can someone please throw light on ISC's implementation.

regards
Ravi
On Thu, May 20, 2010 at 8:39 PM, ravi kumar <ravikumar.lrk at gmail.com> wrote:

> I would like to know the behavior of Dhcp Failover implementation in
> INIT-REBOOT scenario. Is the following highlighted part taken care of in
> Failover implementation ?
> Also, would like to know if anyone has come across any Client, that behaves
> in below specified manner : Request is sent during INIT-REBOOT, though
> Client doesnot have valid lease.
>
> <Copy-Paste from Dhcp Failover draft [*draft-ietf-dhc-failover-12.txt*<http://tools.ietf.org/html/draft-ietf-dhc-failover-12.txt>
> ]>
>
> One troublesome issue is that of the DHCP client responsibility when
>    sending in DHCPREQUEST/INIT-REBOOT requests.  While the original DHCP
>    RFC was written to require a DHCP client to have time left to run on
>    the lease for an IP address if the client is sending an INIT-REBOOT
>    request, it was sufficiently unclear that some client vendors didn't
>    realize this until recently.  Since the INIT-REBOOT request was sent
>    with the IP address in the dhcp-requested-address option and not in
>    the ciaddr (for perfectly good reasons), the similarity to the RENEW
>    and REBINDING case was lost on many people.
>
>    At present, the failover protocol does not assume that a client send-
>    ing in an INIT-REBOOT request necessarily has a valid lease on the IP
>    address appearing in the dhcp-requested-address option in the INIT-
>    REBOOT request.
>
>    The implications of this are as follows: Assume that there is a DHCP
>    client that gets a lease from one server while that server is unable
>    to communicate with its failover partner.  Then, assume that after
>    that client reboots it is able only to communicate with the other
>    failover server.  If the failover servers have not been able to com-
>    municate with each other during this process, then the DHCP client
>    will get a new IP address instead of being able to continue to use
>    its existing IP address. This will affect no applications on the DHCP
>    client, since it is rebooting.  However, it will use up an additional
>    IP address in this marginal case.
> regards
> Ravi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100524/6846f934/attachment-0001.html>