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

[#3590] Finished required precedence update

Browse Source
This commit is contained in:
Francis Dupont
2024-10-02 15:15:15 +02:00
parent 3b0d99dc87
commit bb78477129
5 changed files with 111 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
doc/sphinx/arm/classify.rst
View File

@@ -138,8 +138,8 @@ The classification process is conducted in several steps:
callouts are called here.
12. Classes marked as "required" are evaluated in the order in which
they are listed: first the shared network, then the subnet, and
finally the pools that assigned resources belong to.
they are listed: first pools, then the subnet, and finally
the shared network that assigned resources belong to.
13. Options are assigned, again possibly based on the class information
in the order that classes were associated with the incoming packet.
@@ -910,15 +910,16 @@ subnet, shared network, or pools are known but output-option processing has not
yet been done. For this purpose, the ``only-if-required`` flag, which is
``false`` by default, allows the evaluation of the ``test`` expression or the
``template-test`` expression only when it is required, i.e. in a
``require-client-classes`` list of the selected subnet, shared network, or pool.
``require-client-classes`` list of the selected pool, subnet, or shared network.
The ``require-client-classes`` list, which is valid for shared-network, subnet,
and pool scope, specifies the classes which are evaluated in the second pass
before output-option processing. The list is built in reverse-precedence
order of the option data, i.e. an option data item in a subnet takes precedence over
one in a shared network, but a required class in a subnet is added after one in a
shared network. The mechanism is related to the ``only-if-required`` flag but it
is not mandatory that the flag be set to ``true``.
The ``require-client-classes`` list, which is valid for pool, subnet,
and shared-network scope, specifies the classes which are evaluated in
the second pass before output-option processing. The list is built in
same precedence order of the option data, i.e. an option data item in
a subnet takes precedence over one in a shared network, and also a
required class in a subnet is added before one in a shared
network. The mechanism is related to the ``only-if-required`` flag but
it is not mandatory that the flag be set to ``true``.
.. note ::

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

@@ -3322,8 +3322,8 @@ DNS servers set to 192.0.2.1 and 192.0.2.2.
Required Classification
~~~~~~~~~~~~~~~~~~~~~~~
In some cases it is useful to limit the scope of a class to a
shared network, subnet, or pool. There are two parameters which are used
In some cases it is useful to limit the scope of a class to a pool,
subnet, or shared network. There are two parameters which are used
to limit the scope of the class by instructing the server to evaluate test
expressions when required.
@@ -3333,9 +3333,9 @@ is not evaluated at the reception of the incoming packet but later, and
only if the class evaluation is required.
The second is ``require-client-classes``, which takes a list of class
names and is valid in shared-network, subnet, and pool scope. Classes in
names and is valid in pool, subnet, and shared network scope. Classes in
these lists are marked as required and evaluated after selection of this
specific shared network/subnet/pool and before output-option processing.
specific pool/subnet/shared network and before output-option processing.
In this example, a class is assigned to the incoming packet when the
specified subnet is used:
@@ -3370,9 +3370,9 @@ over ``option-data`` in a class. If ``option-data`` is moved to a
required class and required in the subnet, a class evaluated earlier
may take precedence.
Required evaluation is also available at the shared-network and pool levels.
The order in which required classes are considered is: shared-network,
subnet, and pool, i.e. in the reverse order from the way in which
Required evaluation is also available at the shared network and pool levels.
The order in which required classes are considered is: pool, subnet,
and shared network, i.e. in the same order from the way in which
``option-data`` is processed.
.. note::

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

@@ -3096,8 +3096,8 @@ eRouter1.0 client class are allowed to use that pool.
Required Classification
~~~~~~~~~~~~~~~~~~~~~~~
In some cases it is useful to limit the scope of a class to a
shared network, subnet, or pool. There are two parameters which are used
In some cases it is useful to limit the scope of a class to a pool,
subnet, or shared network. There are two parameters which are used
to limit the scope of the class by instructing the server to evaluate test
expressions when required.
@@ -3107,9 +3107,9 @@ is not evaluated at the reception of the incoming packet but later, and
only if the class evaluation is required.
The second is ``require-client-classes``, which takes a list of class
names and is valid in shared-network, subnet, and pool scope. Classes in
names and is valid in pool, subnet, and shared network scope. Classes in
these lists are marked as required and evaluated after selection of this
specific shared network/subnet/pool and before output-option processing.
specific pool/subnet/shared network and before output-option processing.
In this example, a class is assigned to the incoming packet when the
specified subnet is used:
@@ -3148,9 +3148,9 @@ over ``option-data`` in a class. If ``option-data`` is moved to a
required class and required in the subnet, a class evaluated earlier
may take precedence.
Required evaluation is also available at shared-network and pool/pd-pool
Required evaluation is also available at shared network and pool/pd-pool
levels. The order in which required classes are considered is:
shared-network, subnet, and (pd-)pool, i.e. in the reverse order from the
(pd-)pool, subnet, and shared network, i.e. in the same order from the
way in which ``option-data`` is processed.
.. _dhcp6-ddns-config: