ISC Dhcp Failover behavior for INIT-REBOOT scenario
ravi kumar
ravikumar.lrk at gmail.com
Thu May 20 15:09:59 UTC 2010
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/20100520/b9a1202b/attachment.html>
More information about the dhcp-users
mailing list