Browse Source

[3575] Description of v4 conflict resolution updated.

Tomek Mrugalski 10 years ago
parent
commit
a4a158f98f
1 changed files with 25 additions and 2 deletions
  1. 25 2
      doc/guide/dhcp4-srv.xml

+ 25 - 2
doc/guide/dhcp4-srv.xml

@@ -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