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

[#1428] Addressed review comments

Browse Source
This commit is contained in:
Marcin Siodelski
2020-10-12 18:20:58 +02:00
parent 5a1a92f97b
commit caac37eaba
2 changed files with 26 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
doc/sphinx/arm/dhcp4-srv.rst
View File

@@ -4747,41 +4747,41 @@ library returns an error in response to the ``reservation-add`` command
when it detects that the reservation exists in the database for the IP when it detects that the reservation exists in the database for the IP
address for which the new reservation is being added. address for which the new reservation is being added.
In some deployments a single host can select one of the several network In some deployments a single host can select one of several network
interfaces to communicate with the DHCP server and the server must assign interfaces to communicate with the DHCP server and the server must assign
the same IP address to the host regardless of the interface used. Since the same IP address to the host regardless of the interface used. Since
each interface is assigned a different MAC address, it implies that each interface is assigned a different MAC address, it implies that
several host reservations must be created to associate all of the MAC several host reservations must be created to associate all of the MAC
addresses present on this host with the IP addresses. Using different addresses present on this host with the IP addresses. Using different
IP addresses for each interface is impractical and is considered a waste IP addresses for each interface is impractical and is considered a waste
of the IPv4 address space, especially that the host typically uses only one of the IPv4 address space, especially since the host typically uses only one
interface for the communication with the server, hence only one IP address interface for communication with the server, hence only one IP address
is in use. is in use.
This causes a need for creating multiple host reservations for a single This causes a need for creating multiple host reservations for a single
IP address within a subnet and it is supported since Kea 1.9.1 release IP address within a subnet and it is supported beginning with Kea 1.9.1
as optional mode of operation enabled with the ``ip-reservations-unique`` release as optional mode of operation enabled with the
global parameter. ``ip-reservations-unique`` global parameter.
The ``ip-reservations-unique`` is a boolean parameter, which defaults to The ``ip-reservations-unique`` is a boolean parameter, which defaults to
``true``, in which case it is not allowed to specify multiple reservations ``true``, which forbids the specification of more than one reservation
for the same IP address in a given subnet. Setting this parameter to for the same IP address within a given subnet. Setting this parameter to
``false`` allows for creating such reservations both in the Kea configuration ``false`` allows for creating such reservations both in the Kea configuration
file and in the host database backends via ``host-cmds`` hooks library. file and in the host database backends via ``host-cmds`` hooks library.
This setting is currently supported by the most popular host database This setting is currently supported by the most popular host database
backends, i.e. MySQL and PostgreSQL. It is not supported for Cassandra, backends, i.e. MySQL and PostgreSQL. It is not supported for Cassandra,
Host Cache (see :ref:`hooks-host-cache`) and Radius backend Host Cache (see :ref:`hooks-host-cache`) or Radius backend
(see :ref:`hooks-radius`). An attempt to set ``ip-reservations-unique`` (see :ref:`hooks-radius`). An attempt to set ``ip-reservations-unique``
to ``false`` when any of these three backends is in use yields a to ``false`` when any of these three backends is in use yields a
configuration error. configuration error.
.. note:: .. note::
When ``ip-reservations-unique`` is set to ``true`` the server ensures When ``ip-reservations-unique`` is set to ``true`` (the default value)
that IP reservations are unique for a subnet within a single host backend the server ensures that IP reservations are unique for a subnet within
and/or Kea configuration file. It does not guarantee that the reservations a single host backend and/or Kea configuration file. It does not
are unique across multiple backends. guarantee that the reservations are unique across multiple backends.
The following is the example configuration with two reservations for The following is the example configuration with two reservations for
@@ -4813,7 +4813,7 @@ It is possible to control the ``ip-reservations-unique`` via the
the currently used backends (backends do not support the new setting), the currently used backends (backends do not support the new setting),
the new setting is ignored and the warning log message is output. the new setting is ignored and the warning log message is output.
The backends continue to use the default setting, i.e. expecting that The backends continue to use the default setting, i.e. expecting that
IP reservations are unique within each subnet. In order to allow for IP reservations are unique within each subnet. In order to allow
creating non unique IP reservations the administrator must remove creating non unique IP reservations the administrator must remove
the backends which lack support for it from the configuration file. the backends which lack support for it from the configuration file.
@@ -4823,7 +4823,7 @@ the default mode in which this is no longer allowed. The administrators
must make sure that at most one reservation for the given IP address must make sure that at most one reservation for the given IP address
exists within a subnet prior to switching back to the default mode. exists within a subnet prior to switching back to the default mode.
If such duplicates are left in the configuration file, the server If such duplicates are left in the configuration file, the server
reports a configuration error. Leaving such reservations in the host will report a configuration error. Leaving such reservations in the host
databases does not cause configuration errors but may lead to lease databases does not cause configuration errors but may lead to lease
allocation errors during the server operation when it unexpectedly allocation errors during the server operation when it unexpectedly
finds multiple reservations for the same IP address. finds multiple reservations for the same IP address.

22
doc/sphinx/arm/dhcp6-srv.rst
View File

@@ -4144,30 +4144,30 @@ the same lease within a subnet in the Kea configuration file. The
in the database for the lease for which the new reservation is being added. in the database for the lease for which the new reservation is being added.
Similar to DHCPv4 (see :ref:`multiple-reservations-same-ip4`), the DHCPv6 Similar to DHCPv4 (see :ref:`multiple-reservations-same-ip4`), the DHCPv6
server can also be configured to allow for creating multiple reservations server can also be configured to allow creating multiple reservations
for the same IPv6 address and/or delegated prefix in a given subnet. This for the same IPv6 address and/or delegated prefix in a given subnet. This
is supported since Kea 1.9.1 release as optional mode of operation enabled is supported beginning with Kea 1.9.1 release as optional mode of operation
with the ``ip-reservations-unique`` global parameter. enabled with the ``ip-reservations-unique`` global parameter.
The ``ip-reservations-unique`` is a boolean parameter, which defaults to The ``ip-reservations-unique`` is a boolean parameter, which defaults to
``true``, in which case it is not allowed to specify multiple reservations ``true``, which forbids the specification of more than one reservation
for the same lease in a given subnet. Setting this parameter to ``false`` for the same lease in a given subnet. Setting this parameter to ``false``
allows for creating such reservations both in the Kea configuration allows for creating such reservations both in the Kea configuration
file and in the host database backends via ``host-cmds`` hooks library. file and in the host database backends via ``host-cmds`` hooks library.
This setting is currently supported by the most popular host database This setting is currently supported by the most popular host database
backends, i.e. MySQL and PostgreSQL. It is not supported for Cassandra, backends, i.e. MySQL and PostgreSQL. It is not supported for Cassandra,
Host Cache (see :ref:`hooks-host-cache`) and Radius backend Host Cache (see :ref:`hooks-host-cache`) or Radius backend
(see :ref:`hooks-radius`). An attempt to set ``ip-reservations-unique`` (see :ref:`hooks-radius`). An attempt to set ``ip-reservations-unique``
to ``false`` when any of these three backends is in use yields a to ``false`` when any of these three backends is in use yields a
configuration error. configuration error.
.. note:: .. note::
When ``ip-reservations-unique`` is set to ``true`` the server ensures When ``ip-reservations-unique`` is set to ``true`` (the default value)
that IP reservations are unique for a subnet within a single host backend the server ensures that IP reservations are unique for a subnet within
and/or Kea configuration file. It does not guarantee that the reservations a single host backend and/or Kea configuration file. It does not guarantee
are unique across multiple backends. that the reservations are unique across multiple backends.
The following is the example configuration with two reservations for The following is the example configuration with two reservations for
@@ -4199,7 +4199,7 @@ It is possible to control the ``ip-reservations-unique`` via the
the currently used backends (backends do not support the new setting), the currently used backends (backends do not support the new setting),
the new setting is ignored and the warning log message is output. the new setting is ignored and the warning log message is output.
The backends continue to use the default setting, i.e. expecting that The backends continue to use the default setting, i.e. expecting that
IP reservations are unique within each subnet. In order to allow for IP reservations are unique within each subnet. In order to allow
creating non unique IP reservations the administrator must remove creating non unique IP reservations the administrator must remove
the backends which lack support for it from the configuration file. the backends which lack support for it from the configuration file.
@@ -4209,7 +4209,7 @@ decided to return to the default mode in which this is no longer allowed.
The administrators must make sure that at most one reservation for The administrators must make sure that at most one reservation for
the given IP address or delegated prefix exists within a subnet prior the given IP address or delegated prefix exists within a subnet prior
to switching back to the default mode. If such duplicates are left in to switching back to the default mode. If such duplicates are left in
the configuration file, the server reports a configuration error. the configuration file, the server will report a configuration error.
Leaving such reservations in the host databases does not cause Leaving such reservations in the host databases does not cause
configuration errors but may lead to lease allocation errors during configuration errors but may lead to lease allocation errors during
the server operation when it unexpectedly finds multiple reservations the server operation when it unexpectedly finds multiple reservations