mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-09-01 14:35:29 +00:00
[#2719] Addressed minor review comments
This commit is contained in:
@@ -4495,14 +4495,14 @@ By default, kea-dhcp4 does not allocate or store a lease when offering an addres
|
|||||||
to a client in response to a DHCPDISCOVER. In general, kea-dhcp4, can fulfill client
|
to a client in response to a DHCPDISCOVER. In general, kea-dhcp4, can fulfill client
|
||||||
demands faster by deferring lease allocation and storage until it receives DHCPREQUESTs
|
demands faster by deferring lease allocation and storage until it receives DHCPREQUESTs
|
||||||
for them. Release 2.3.6 added a new parameter to kea-dhcp4, ``offer-lifetime``, which
|
for them. Release 2.3.6 added a new parameter to kea-dhcp4, ``offer-lifetime``, which
|
||||||
(when not zero) instructs the server to allocate and persist a lease when generating an
|
(when not zero) instructs the server to allocate and persist a lease when generating a
|
||||||
DHCPOFFER and:
|
DHCPOFFER and:
|
||||||
|
|
||||||
- The persisted lease's lifetime is equal to ``offer-lifetime`` (in seconds).
|
- The persisted lease's lifetime is equal to ``offer-lifetime`` (in seconds).
|
||||||
|
|
||||||
- The lifetime sent to the client in the DHCPOFFER via option 51 will still be based
|
- The lifetime sent to the client in the DHCPOFFER via option 51 will still be based
|
||||||
on ``valid-lifetime``. This avoids issues with clients that may reject offers lifetimes they
|
on ``valid-lifetime``. This avoids issues with clients that may reject offers whose
|
||||||
perceive as too short.
|
lifetimes they perceive as too short.
|
||||||
|
|
||||||
- DDNS updates are not performed. As with the default behavior, that occurs on DHCPREQUEST.
|
- DDNS updates are not performed. As with the default behavior, that occurs on DHCPREQUEST.
|
||||||
|
|
||||||
@@ -4517,7 +4517,7 @@ DHCPOFFER and:
|
|||||||
|
|
||||||
- In sites running multiple instances of kea-dhcp4 against a single, shared lease store, races
|
- In sites running multiple instances of kea-dhcp4 against a single, shared lease store, races
|
||||||
for given address values are lost during DHCPDISCOVER processing rather than during DHCPREQUEST
|
for given address values are lost during DHCPDISCOVER processing rather than during DHCPREQUEST
|
||||||
processing. Servers that lose the race for the address will simply not respond the client
|
processing. Servers that lose the race for the address will simply not respond to the client
|
||||||
rather than NAK them. The client in turn will simply retry DHCPDISCOVER. This should reduce
|
rather than NAK them. The client in turn will simply retry DHCPDISCOVER. This should reduce
|
||||||
the amount of traffic such conflicts incur.
|
the amount of traffic such conflicts incur.
|
||||||
|
|
||||||
|
@@ -1534,7 +1534,6 @@ public:
|
|||||||
/// If the client query is a BOOTP query or something other than
|
/// If the client query is a BOOTP query or something other than
|
||||||
/// DHCPDISCOVER, return 0.
|
/// DHCPDISCOVER, return 0.
|
||||||
///
|
///
|
||||||
/// @todo Classes not supported yet.
|
|
||||||
/// Otherwise, the value will be selected from the first
|
/// Otherwise, the value will be selected from the first
|
||||||
/// class matched to the query which defines it or from the subnet
|
/// class matched to the query which defines it or from the subnet
|
||||||
/// if none do. Classes are searched in the order they are assigned
|
/// if none do. Classes are searched in the order they are assigned
|
||||||
|
Reference in New Issue
Block a user