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

[3565] Updated the wording in the kea user guide for reservation-mode param.

Browse Source
This commit is contained in:
Marcin Siodelski
2015-02-16 19:40:43 +01:00
parent 7beb4f3c29
commit a104287eb4
2 changed files with 32 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1891,24 +1891,28 @@ temporarily override a list of interface names and listen on all interfaces.
<title>Fine Tuning IPv4 Host Reservation</title> <title>Fine Tuning IPv4 Host Reservation</title>
<note> <note>
<para><command>reservation-mode</command> in DHCPv6 server in 0.9.1 beta is <para><command>reservation-mode</command> configuration parameter in DHCPv4
accepted, but not used. Full implementation will be available in the upcoming server is accepted, but not used in the Kea 0.9.1 beta. Full implementation
releases.</para> will be available in the upcoming releases.</para>
</note> </note>
<para>Host reservation capability introduces additional restrictions for the <para>Host reservation capability introduces additional restrictions for the
allocation engine during lease selection and renewal. In particular, three allocation engine during lease selection and renewal. In particular, three
major checks are necessary. First, when selecting a new lease, it is not major checks are necessary. First, when selecting a new lease, it is not
sufficient for a candidate lease to be not used by anyone else. It also must sufficient for a candidate lease to be not used by another DHCP client. It
not be reserved for anyone else. Second, when renewing a lease, additional also must not be reserved for another client. Second, when renewing a lease,
check must be performed whether the address being renewed is not reserved additional check must be performed whether the address being renewed is not
for anyone else. Finally, when a host renews an address, the server has to reserved for another client. Finally, when a host renews an address, the server
check whether there's a reservation for this host, so the exisiting (dynamically has to check whether there's a reservation for this host, so the exisiting
allocated) address should be revoked and the reserved one be used instead. (dynamically allocated) address should be revoked and the reserved one be
used instead.
</para> </para>
<para>Some of those checks in certain deployments may be not necessary. Skipping <para>Some of those checks may be unnecessary in certain deployments. Not
them may improve performance. The Kea server allows configuration of the performing them may improve performance. The Kea server provides the
reservation types allowed for each subnet using <command>reservation-mode</command>. <command>reservation-mode</command> configuration parameter to select the
types of reservations allowed for the particular subnet. Each reservation
type has different constraints for the checks to be performed by the
server when allocating or renewing a lease for the client.
Allowed values are: Allowed values are:
<itemizedlist> <itemizedlist>

28
doc/guide/dhcp6-srv.xml
View File

@@ -1898,23 +1898,27 @@ should include options from the isc option space:
<title>Fine Tuning IPv6 Host Reservation</title> <title>Fine Tuning IPv6 Host Reservation</title>
<note> <note>
<para><command>reservation-mode</command> in the DHCPv6 server in 0.9.1 beta is <para><command>reservation-mode</command> in the DHCPv6 server is
implemented, but was not tested and is considered experimental.</para> implemented in Kea 0.9.1 beta, but has not been tested and is
considered experimental.</para>
</note> </note>
<para>Host reservation capability introduces additional restrictions for the <para>Host reservation capability introduces additional restrictions for the
allocation engine during lease selection and renewal. In particular, three allocation engine during lease selection and renewal. In particular, three
major checks are necessary. First, when selecting a new lease, it is not major checks are necessary. First, when selecting a new lease, it is not
sufficient for a candidate lease to be not used by anyone else. It also must sufficient for a candidate lease to be not used by another DHCP client. It
not be reserved for anyone else. Second, when renewing a lease, additional also must not be reserved for another client. Second, when renewing a lease,
check must be performed whether the address being renewed is not reserved additional check must be performed whether the address being renewed is not
for anyone else. Finally, when a host renews an address, the server has to reserved for another client. Finally, when a host renews an address or a
check whether there's a reservation for this host, so the exisiting (dynamically prefix, the server has to check whether there's a reservation for this host,
allocated) address should be revoked and the reserved one be used instead. so the existing (dynamically allocated) address should be revoked and the
</para> reserved one be used instead.</para>
<para>Some of those checks in certain deployments may be not necessary. Skipping <para>Some of those checks may be unnecessary in certain deployments. Not
them may improve performance. The Kea server allows configuration of the performing them may improve performance. The Kea server provides the
reservation types allowed for each subnet using <command>reservation-mode</command>. <command>reservation-mode</command> configuration parameter to select the
types of reservations allowed for the particular subnet. Each reservation
type has different constraints for the checks to be performed by the
server when allocating or renewing a lease for the client.
Allowed values are: Allowed values are:
<itemizedlist> <itemizedlist>