mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-31 05:55:28 +00:00
Code Issues Releases Wiki Activity

[3575] Description of v4 conflict resolution updated.

Browse Source
This commit is contained in:
Tomek Mrugalski
2015-02-10 19:57:10 +01:00
parent 59ac2f9dff
commit a4a158f98f
1 changed files with 25 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
doc/guide/dhcp4-srv.xml
View File

@@ -1821,7 +1821,7 @@ temporarily override a list of interface names and listen on all interfaces.
<section it="reservation4-conflict">
<title>Conflicts in DHCPv4 reservations</title>
<para>As reservations and lease information are kept in different places,
<para>As reservations and lease information are kept separately,
conflict may arrise. Consider the following series of events. The server
has configured 192.0.2.10 to 192.0.2.20 dynamic pool range. Host A
requests an address and gets 19.0.2.10. Now the system administrator
@@ -1840,6 +1840,7 @@ temporarily override a list of interface names and listen on all interfaces.
the server has to temporarily assign a different address (not matching
what has been reserved) to host B.</para>
<!-- let's keep this text around. It describes how that is working in v6
<para>When the host A renews its address, the server will discover that
the address being renewed is now reserved for someone else (host
B). Therefore the server will remove the lease and will inform the host A
@@ -1852,7 +1853,29 @@ temporarily override a list of interface names and listen on all interfaces.
server will also remove its temporary lease. It will revert to the server
discovery phase and will eventually send a REQUEST message. This time the
server will find out that there is a reservation for that host and the
reserved address 192.0.2.10 is not used, so it will be granted.</para>
reserved address 192.0.2.10 is not used, so it will be granted.</para> -->
<para>When the host A renews its address, the server will discover that
the address being renewed is now reserved for someone else (host
B). Therefore the server will inform the host A that it is no longer
allowed to use it by sending NAK message. The server will remove the
lease, though, as there's small chance that the NAK may be lost if the
network is lossy. If that happens, the client will not receive any
responses, so it will retransmit its Request packet. Once the NAK is
received by the host A, it will then revert to the server discovery and
will eventually get a different address. Besides allocating a new lease,
the server will also remove the old one. As a result the address
192.0.2.10 will be no longer used. When host B tries to renew its
temporary address, the server will detect that it has a valid lease, but
there is a reservation for a different address. The server will send NAK
to inform host B that its address is no longer usable, but will keep its
least (again, the NAK may be lost, so the server will keep it, until the
client gets back for a new address). The host B will revert to the server
discovery phase and will eventually send a REQUEST message. This time the
server will find out that there is a reservation for that host and the
reserved address 192.0.2.10 is not used, so it will be granted. It will
also remove the lease for the temporary address that the host B previously
had.</para>
<para>This recovery will succeed, even if other hosts will attempt to get
the reserved address. Had the host C requested address 192.0.2.10 after