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

[#2073] Text edits (interim save through line 4582)

Browse Source
This commit is contained in:
Suzanne Goldlust
2021-09-21 18:16:42 +00:00
committed by Thomas Markwalder
parent fd69a001ba
commit dc4da8e8ed
1 changed files with 15 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -4361,13 +4361,13 @@ Reserving a Hostname
--------------------
When the reservation for a client includes the ``hostname``, the server
will return this hostname to the client in the Client FQDN or Hostname
returns this hostname to the client in the Client FQDN or Hostname
option. The server responds with the Client FQDN option only if the
client has included the Client FQDN option in its message to the server. The
server will respond with the Hostname option if the client included
server responds with the Hostname option if the client included
the Hostname option in its message to the server, or if the client
requested the Hostname option using the Parameter Request List option.
The server will return the Hostname option even if it is not configured
The server returns the Hostname option even if it is not configured
to perform DNS updates. The reserved hostname always takes precedence
over the hostname supplied by the client or the autogenerated (from the
IPv4 address) hostname.
@@ -4395,7 +4395,7 @@ configuration:
}
}
will result in assigning the "alice-laptop.example.isc.org." hostname to
will result in assigning the `"alice-laptop.example.isc.org."` hostname to
the client using the MAC address "aa:bb:cc:dd:ee:ff". If the
``ddns-qualifying-suffix`` is not specified, the default (empty) value will
be used, and in this case the value specified as a ``hostname`` will be
@@ -4436,7 +4436,7 @@ options follow the same rules as any other options. These can be
standard options (see :ref:`dhcp4-std-options`),
custom options (see :ref:`dhcp4-custom-options`),
or vendor-specific options (see :ref:`dhcp4-vendor-opts`). The following
example demonstrates how standard options can be defined.
example demonstrates how standard options can be defined:
::
@@ -4483,19 +4483,19 @@ Vendor-specific options can be reserved in a similar manner:
} ]
}
Options defined at host level have the highest priority. In other words,
if there are options defined with the same type on global, subnet,
class, and host levels, the host-specific values will be used.
Options defined at the host level have the highest priority. In other words,
if there are options defined with the same type on the global, subnet,
class, and host levels, the host-specific values are used.
.. _reservation4-message-fields:
Reserving Next Server, Server Hostname, and Boot File Name
----------------------------------------------------------
BOOTP/DHCPv4 messages include "siaddr", "sname", and "file" fields. Even
BOOTP/DHCPv4 messages include `"siaddr"`, `"sname"`, and `"file"` fields. Even
though DHCPv4 includes corresponding options, such as option 66 and
option 67, some clients may not support these options. For this reason,
server administrators often use the "siaddr", "sname", and "file" fields
server administrators often use the `"siaddr"`, `"sname"`, and `"file"` fields
instead.
With Kea, it is possible to make static reservations for these DHCPv4
@@ -4527,11 +4527,11 @@ Reserving Client Classes in DHCPv4
:ref:`classification-using-expressions` explains how to configure
the server to assign classes to a client, based on the content of the
options that this client sends to the server. Host reservations
options that this client sends to the server. Host reservation
mechanisms also allow for the static assignment of classes to clients.
The definitions of these classes are placed in the Kea configuration or
a database. The following configuration snippet shows how to specify that
a client belongs to classes ``reserved-class1`` and ``reserved-class2``. Those
a client belongs to the classes ``reserved-class1`` and ``reserved-class2``. Those
classes are associated with specific options sent to the clients which belong
to them.
@@ -4574,11 +4574,11 @@ to them.
In some cases the host reservations can be used in conjunction with client
classes specified within the Kea configuration. In particular, when a
host reservation exists for a client within a given subnet, the "KNOWN"
host reservation exists for a client within a given subnet, the `"KNOWN"`
built-in class is assigned to the client. Conversely, when there is no
static assignment for the client, the "UNKNOWN" class is assigned to the
static assignment for the client, the `"UNKNOWN"` class is assigned to the
client. Class expressions within the Kea configuration file can
refer to "KNOWN" or "UNKNOWN" classes using the "member" operator.
refer to `"KNOWN"` or `"UNKNOWN"` classes using the `"member"` operator.
For example:
::