9. When the incoming packet belongs to the special class, `DROP`, it is
dropped and an informational message is logged with the packet
information. Since Kea version 1.9.8 it is allowed to make DROP
- class dependent of KNOWN/UNKNOWN classes.
+ class dependent on KNOWN/UNKNOWN classes.
10. If needed, addresses and prefixes from pools are assigned, possibly
based on the class information when some pools are reserved for
relay from which to extract the information, with a value of 0
indicating the relay closest to the DHCPv6 server. Negative values
allow specifying relays counted from the DHCPv6 client, -1 indicating
- the relay closest to the client. In general, negative "nest" level is
+ the relay closest to the client. In general, a negative "nest" level is
the same as the number of relays + "nest" level. If the requested
encapsulation doesn't exist, an empty string "" is returned. This
expression is allowed in DHCPv6 only.
- packet-queue-statistics: average queue size for last 10, 100 and 1000
packets. Statistics using an approach similar to the Unix ``top`` command.
The averaged queue size for the last 10 packets can be considered an
- instantaneous value, while average for the last 1000 packets shows
- longer term trend.
+ instantaneous value, while the average for the last 1000 packets shows
+ a longer term trend.
The ``high-availability`` information is returned only when the command is
sent to the DHCP servers being in the HA setup. This parameter is
}
-Note that only one of name or code is required; there is no need to
+Note that either name or code is required; there is no need to
specify both. Space has a default value of "dhcp4", so this can be skipped
as well if a regular (not encapsulated) DHCPv4 option is defined.
Finally, csv-format defaults to true, so it too can be skipped, unless
By default, Kea aims to follow the RFC documents to promote better standards
compliance. However, there are buggy implementations out there that cannot be
easily fixed or upgraded. Therefore Kea provides an easy to use compatibility
-mode for broken or non-compliant clients. In that purpose, flags have to be
+mode for broken or non-compliant clients. For that purpose, flags have to be
enabled in order to enable uncommon practices:
.. code-block:: json
Similar to DHCPv4 (see :ref:`multiple-reservations-same-ip4`), the DHCPv6
server can also be configured to allow creating multiple reservations
for the same IPv6 address and/or delegated prefix in a given subnet. This
-is supported beginning with Kea 1.9.1 release as optional mode of operation
+is supported beginning with Kea release 1.9.1 as an optional mode of operation
enabled with the ``ip-reservations-unique`` global parameter.
The ``ip-reservations-unique`` is a boolean parameter, which defaults to
the shared network. Internally, the server selects one of the subnets
belonging to a shared network and tries to allocate a lease from this
subnet. If the server is unable to allocate a lease from the selected
-subnet (e.g., due to pools exhaustion), it will use another subnet from
+subnet (e.g., due to pool exhaustion), it will use another subnet from
the same shared network and will try to allocate a lease from this subnet,
etc. Therefore, the server will typically allocate all leases
available in a given subnet before it starts allocating leases from
We view this largely as a site configuration issue. A shared-network
generally means the same physical link, so services configured by options
from subnet A should be as easily reachable from subnet B and vice versa.
- There are number of ways to avoid this situation:
+ There are a number of ways to avoid this situation:
- Use the same values for options and parameters for subnets within the shared-network.
- Use subnet selectors or client class guards that ensure that for a single client's query, the same subnet will be used for all IA options in that query.
It will list available parameters.
Hammer is able to set up various operating systems running either in LXC
-or in VirtualBox. To list of supported systems, use the
+or in VirtualBox. For a list of supported systems, use the
``supported-systems`` command:
.. code-block:: console
the selected shared network, use the `remote-network[46]-get` command.
The example response above contains three shared networks. One of the
-shared networks is associated will all servers, so it is included in
+shared networks is associated with all servers, so it is included in
the list of shared networks to be used by "server1" and "server2".
The remaining two shared networks are returned because one of them
is associated with the "server1" and another one is associated with
option may be present for a subnet belonging to the shared network.
Such an option instance is not affected by this command as this
command merely deletes the shared network level option. In order to
-delete subnet level option the `remote-option[46]-subnet-del`
+delete a subnet level option the `remote-option[46]-subnet-del`
command must be used instead.
The following command attempts to delete an option having the
is the same as in the Kea configuration file (see :ref:`dhcp4-std-options`
and :ref:`dhcp6-std-options`). The option information is carried in the
`options` list. Another list, `shared-networks`, contains a map with the
-name of the shared network for which the option is to be set. If such option
+name of the shared network for which the option is to be set. If such an option
already exists for the shared network, it is replaced with the new instance.
::
prefix delegation pool prefix and length identifying the pool. If the
option is not explicitly specified for this pool, no option is deleted.
In particular, the given option may exist for a subnet containing
-the specified pool. Such option instance is not affected by this
+the specified pool. Such an option instance is not affected by this
command as this command merely deletes a prefix delegation pool level
-option. In order to delete subnet level option the
+option. In order to delete a subnet level option the
`remote-option6-subnet-del` command must be used instead.
::
is the same as in the Kea configuration file (see :ref:`dhcp4-std-options`
and :ref:`dhcp6-std-options`). The option information is carried in the
`options` list. Another list, `pools`, contains a map with the IP address
-range or prefix identifying the pool. If such option already exists for the
-pool, it is replaced with the new instance.
+range or prefix identifying the pool. If such an option already exists for
+the pool, it is replaced with the new instance.
For example:
in the Kea configuration file (see :ref:`dhcp4-std-options`
and :ref:`dhcp6-std-options`). The option information is carried in the
`options` list. Another list, `subnets`, contains a map with the identifier of
-the subnet for which the option is to be set. If such option already exists
+the subnet for which the option is to be set. If such an option already exists
for the subnet, it is replaced with the new instance.
::
to each other, but also to the backup servers. As of Kea 1.7.8 the active
servers no longer expect the acknowledgments from the backup servers
before responding to the DHCP clients, therefore the overhead of sending
-the lease updates to the backup servers is minimized comparing to the
+the lease updates to the backup servers is minimized compared to the
earlier Kea versions.
The last supported configuration, passive-backup, has been introduced
-in Kea 1.7.8 release. In this configuration there is only one active
+in Kea release 1.7.8. In this configuration there is only one active
server and typically one or more backup servers. A passive-backup
configuration with no backup servers is also accepted but it is no
different than running a single server with no HA function at all.
allocated leases. The major advantage of the passive-backup mode is that
it provides some redundancy of the lease information but with better
performance of the primary server responding to the DHCP queries. Since
-Kea 1.7.8 release, the primary server does not have to wait for the
+Kea release 1.7.8, the primary server does not have to wait for the
acknowledgments to the lease updates from the backup servers before it
sends a response to the DHCP client. This reduces the response time
comparing to the load-balancing and hot-standby cases in which the
default, the primary server does not wait for the acknowledgments from
the backup servers and responds to the DHCP query right after sending
the lease updates to all backup servers. If any of the lease updates
- fails, a backup server misses such lease update but the DHCP client
+ fail, a backup server misses the lease update but the DHCP client
is still provisioned. This default configuration can be changed by
setting the ``wait-backup-ack`` configuration parameter to ``true``,
in which case the primary server always waits for the acknowledgements
A server will only use the pool fragments owned by the partner when
the partner is not running. See the notes in the
:ref:`ha-supported-configurations` highlighting differences between
- the ``load-balancing`` and ``hot-standby`` modes. The semantics of the pools
+ the ``load-balancing`` and ``hot-standby`` modes. The semantics of the pool
partitioning is explained further in this section.
The :ref:`ha-load-balancing-advanced-config` provides advanced pools
partitioning examples.
- ``delayed-updates-limit`` - specifies a maximum number of lease
updates which can be queued while the server is in the
``communication-recovery`` state. This parameter was introduced in
- Kea 1.9.4 release. The special value of 0 configures the server to
+ Kea release 1.9.4. The special value of 0 configures the server to
never transition to the ``communication-recovery`` state and the
server behaves as in earlier Kea versions. The default value of this
parameter is 100.
If a server in the ``communication-recovery`` state re-establishes
communication with its partner, it will try to send the partner all
of the outstanding lease updates the server has queued. This is done
-synchronously and may take considerable amount of time before the server
+synchronously and may take a considerable amount of time before the server
transitions to the ``load-balancing`` state and resumes normal operation.
The maximum number of lease updates which can be queued in the
``communication-recovery`` state is controlled by the ``delayed-updates-limit``.
that is its role.
Finally, because there is always one server responding to DHCP queries,
-there is only one scope - ``HA_server1`` - in use within pools
+there is only one scope - ``HA_server1`` - in use within pool
definitions. In fact, the ``client-class`` parameter could be removed
from this configuration without harm, because there can be no conflicts
in lease allocations by different servers as they do not allocate leases
in the terminated state. Also, an error will be returned if the maintenance
request was already sent to the other server.
-Upon receiving the ``ha-maintenance-start`` command, the server1 will
-send the ``ha-maintenance-notify`` command to the server2 to put this
-server in the ``in-maintenance`` state. If the server2 confirms, the server1
+Upon receiving the ``ha-maintenance-start`` command, server1 will
+send the ``ha-maintenance-notify`` command to server2 to put this
+server in the ``in-maintenance`` state. If server2 confirms, server1
will transition to the ``partner-in-maintenance`` state. This is similar
to the ``partner-down`` state, except that in the ``partner-in-maintenance``
-state the server1 continues to send lease updates to the server2 until
-the administrator shuts down the server2. The server1 now responds to all
+state server1 continues to send lease updates to server2 until
+the administrator shuts down server2. Server1 now responds to all
DHCP queries.
-The administrator may safely shut down the server2 being in the
+The administrator may safely shut down server2 it being in the
``in-maintenance`` state and perform necessary maintenance actions. When
-the server2 is offline, the server1 will encounter communication issues
+server2 is offline, server1 will encounter communication issues
with the partner and will immediately transition to the ``partner-down``
state in which it will continue to respond to all DHCP queries but will
-no longer send lease updates to the server2. Starting the server2 after
+no longer send lease updates to server2. Starting server2 after
the maintenance will trigger normal state negotiation, lease database
synchronization and, ultimately, a transition to the load-balancing or
-hot-standby state. The maintenance can now be performed for the server1.
+hot-standby state. The maintenance can now be performed on server1.
It should be initiated by sending the ``ha-maintenance-start`` to the
server2.
to manually set the HA scopes that are being served.
Note that the backup server can sometimes be used to handle DHCP traffic
-if both active servers are down. The backup server does not perform
+if both active servers are down. The backup server does not perform the
failover function automatically; thus, in order to use the backup server
to respond to DHCP queries, the server administrator must enable this
function manually.
by transitioning it to the waiting state. A partner in the
``communication-recovery`` state may send this command to cause the server
to synchronize its lease database. The database synchronization is required
-when the partner failed to send all lease database updates after
+when the partner has failed to send all lease database updates after
re-establishing connection after a temporary connection failure. It is also
required when the ``delayed-updates-limit`` is exceeded when the server is
in the ``communication-recovery`` state.
- ``state`` - specify the state of added lease, can be 0 for ``default``,
1 for ``declined`` and 2 for ``expired-reclaimed`` state. Any other
- value will cause error. Note that using 1 for a "IA_PD" lease type is
+ value will cause an error. Note that using 1 for a "IA_PD" lease type is
illegal and will be rejected.
- ``user-context`` - specifies the user context to be associated with
}
}
-If any of the leases is malformed, no leases changes are applied
+If any of the leases are malformed, no lease changes are applied
to the lease database. If the leases are well-formed but there is a
failure to apply any of the lease changes to the database, the command
continues to be processed for other leases. All the leases for which
The option to which an action applies may be specified by either its
numeric code or its name.. At least the code or the name must be
specified. The option space is the DHCPv4 or DHCPv6 spaces depending
-of the server where the hook library is loaded. Other spaces as vendor
+on the server where the hook library is loaded. Other spaces as vendor
spaces could be supported in a further version.
The library is available since Kea 1.7.1 and can be loaded in a
For global reservations, use a value of zero (0). For reservations
scoped to a specific subnet, use that subnet's ID.
-At the opposite when the subnet id is not specified in the command
+On the other hand when the subnet id is not specified in the command
parameters it is added to each host in responses. If the subnet id
has the unused special value this means the host entry belongs only
to the other IP version (i.e. IPv6 in DHCPv4 server or IPv4 in DHCPv6
# It is replaced by the "reservations-global"
# "reservations-in-subnet" and "reservations-out-of-pool"
# parameters.
- # Specify if server should lookup global reservations.
+ # Specify if the server should lookup global reservations.
"reservations-global": false,
- # Specify if server should lookup in-subnet reservations.
+ # Specify if the server should lookup in-subnet reservations.
"reservations-in-subnet": true,
- # Specify if server can assume that all reserved addresses
+ # Specify if the server can assume that all reserved addresses
# are out-of-pool.
"reservations-out-of-pool": false,
"subnet4": [
As such, it is recommended to use ``systemctl`` commands if they are available. Native
Kea packages do not provide keactrl and instead ``systemctl`` service definitions are
provided instead. Consult documentation of your system for details. Briefly, here
-are example commands to checks status, start, stop and restart various Kea daemons:
+are example commands to check status, start, stop and restart various Kea daemons:
.. code-block:: console
(messages are logged to syslog using a specified name). Any other value is
interpreted as a filename to which messages should be written.
-The flush (true of false) Option
+The flush (true or false) Option
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Flush buffers after each log message. Doing this will reduce performance
being configured.
- the ``key-file`` string parameter specifies the private key of the
- end-entity certificate of Kea instance being configured.
+ end-entity certificate of the Kea instance being configured.
The file must not be encrypted and it is highly recommended to
restrict its access.
packets per seconds, CPU usage, memory utilization and others).
- Kea uses CI (Continuous Integration). This means that the great majority of tests (all unit and system
tests, and in some cases also performance tests) are run for every commit. Many lighter tests are
- ran on branches, before the code is even accepted.
+ run on branches, before the code is even accepted.
- Negative testing. Many unit and system tests check for negative scenarios, such as incomplete,
broken, truncated packets, API commands, configuration files, incorrect sequences (such as sending
packets in invalid order) and more.
--------------------------------------------
The ``statistic-sample-age-set-all`` command sets time based limits
-for collecting samples for all statistics. It takes single-integer parameter
+for collecting samples for all statistics. It takes a single-integer parameter
called ``duration``, which specifies the time limit for statistic
in seconds. An example command may look like this:
Since Kea 1.6, by default, each statistic holds 20 data points. Setting such
a limit prevents unlimited memory growth.
-There are two ways to define the limts: time based (e.g. keep samples from
+There are two ways to define the limits: time based (e.g. keep samples from
the last 5 minutes) and size based. It's possible to change the size based
limit by using one of two commands: ``statistic-sample-count-set``,
to set size limit for single statistic and ``statistic-sample-count-set-all``
for setting size based limits for all statistics. To set time based
-limit for single statistic use ``statistic-sample-age-set``, and
+limits for single statistic use ``statistic-sample-age-set``, and
``statistic-sample-age-set-all`` to set time based limits for all statistics.
For a given statistic only one type of limit can be active. It means that storage
is limited only by time based limit or size based, never by both of them.
projects / thirdparty / kea.git / commitdiff
