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

[#2103] Additional text edits through line 5878

Browse Source
This commit is contained in:
Suzanne Goldlust
2021-10-12 21:20:23 +00:00
committed by Andrei Pavel
parent dfe741e77e
commit a1e83273b8
1 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -5356,16 +5356,16 @@ DHCP servers use subnet information in two ways. It is used to
both determine the point of attachment, i.e. where the client is
connected to the network, and to
group information pertaining to a specific location in the network.
However, it is sometimes useful to have more than one
Sometimes it is useful to have more than one
logical IP subnet deployed on the same physical link.
Understanding that two or more subnets are used on the same link requires
additional logic in the DHCP server. This capability is called "shared
networks" in Kea, and sometimes also
"shared subnets"; in Microsoft's nomenclature it is called "multinet."
There are many use cases where the feature is useful; here we
There are many cases where the shared networks feature is useful; here we
explain just a handful of the most common ones. The first and by far
most common use case is an existing network that has grown and is
most common use case is an existing IPv4 network that has grown and is
running out of available address space. Rather than migrating all
devices to a new, larger subnet, it is easier to simply configure
additional subnets on top of the existing one. Sometimes, due to address
@@ -5402,7 +5402,7 @@ default.
all the addresses from the first subnet in a shared network before
allocating addresses from other subnets.
In order to define a shared network an additional configuration scope is
To define a shared network, an additional configuration scope is
introduced:
::
@@ -5461,12 +5461,12 @@ of two or more subnets. However, for testing purposes, an empty subnet
or a network with just a single subnet is allowed. This is not a
recommended practice in production networks, as the shared network logic
requires additional processing and thus lowers the server's performance.
To avoid unnecessary performance degradation, the shared subnets should
To avoid unnecessary performance degradation, shared subnets should
only be defined when required by the deployment.
Shared networks provide the ability to specify many parameters in the
shared network scope that apply to all subnets within it. If
necessary, it is possible to specify a parameter in the shared network scope and
necessary, it is possible to specify a parameter in the shared-network scope and
then override its value in the subnet scope. For example:
::
@@ -5541,7 +5541,7 @@ subnets in a shared network are expected to be used on the same physical
link, it is a configuration error to attempt to define a shared network
using subnets that are reachable over different interfaces. In other
words, all subnets within the shared network must have the same value
of the ``interface`` parameter. The following configuration is an
for the ``interface`` parameter. The following configuration is an
example of what **NOT** to do:
::
@@ -5568,7 +5568,7 @@ example of what **NOT** to do:
} ]
To minimize the chance of configuration errors, it is often more convenient
to simply specify the interface name once, at the shared network level, as
to simply specify the interface name once, at the shared-network level, as
shown in the example below.
::
@@ -5632,7 +5632,7 @@ of what **NOT** to do:
}
]
Again, it is better to specify the relay address at the shared network
Again, it is better to specify the relay address at the shared-network
level; this value will be inherited by all subnets belonging to the
shared network.
@@ -5669,7 +5669,7 @@ host reservation in this subnet, or simply if the initially selected subnet has
more addresses available. Therefore, it is strongly recommended to always
specify subnet selectors (interface or relay address) at the shared-network
level if the subnets belong to a shared network, as it is rarely useful to
specify them at the subnet level and it may lead to the configuration errors
specify them at the subnet level and may lead to the configuration errors
described above.
Client Classification in Shared Networks
@@ -5687,7 +5687,7 @@ appropriate subnet is selected for a given client type.
If a subnet is associated with a class, only the clients belonging to
this class can use this subnet. If there are no classes specified for a
subnet, any client connected to a given shared network can use this
subnet. A common mistake is to assume that a subnet including a client
subnet. A common mistake is to assume that a subnet that includes a client
class is preferred over subnets without client classes. Consider the
following example:
@@ -5725,7 +5725,7 @@ subnet 10.0.0.0/24 will be used (or preferred) for this client. The
server can use either of the two subnets, because the subnet 192.0.2.0/26
is also allowed for this client. The client classification used in this
case should be perceived as a way to restrict access to certain subnets,
rather than a way to express subnet preference. For example, if the
rather than as a way to express subnet preference. For example, if the
client does not belong to the "b-devices" class, it may only use the
subnet 192.0.2.0/26 and will never use the subnet 10.0.0.0/24.
@@ -5779,7 +5779,7 @@ be refused service. However, this may be a desired outcome if one wishes
to provide service only to clients with known properties (e.g. only VoIP
phones allowed on a given link).
Note that it is possible to achieve an effect similar to the one
It is possible to achieve an effect similar to the one
presented in this section without the use of shared networks. If the
subnets are placed in the global subnets scope, rather than in the
shared network, the server will still use classification rules to pick