Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-07-13T18:35:36Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/237ISC DHCP per class lease limit2023-07-13T18:35:36ZFrancis DupontISC DHCP per class lease limitQuote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficul...Quote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficult for a
new client in a class to get an address. Once a class with such a
limit has reached its limit, the only way a new client in that class
can get a lease is for an existing client to relinquish its lease,
either by letting it expire, or by sending a DHCPRELEASE packet.
Classes with lease limits are specified as follows:
class "limited-1" {
lease limit 4;
}
This will produce a class in which a maximum of four members may hold a
lease at one time.
>>>
Often associated with cloned classes. Requested by a customer but a priori not easy to implement.
Note that in Kea lease assignment is done before calling setReservedClientClasses.
Support tickets: [support#18293](https://support.isc.org/Ticket/Display.html?id=18293), [support#17523](https://support.isc.org/Ticket/Display.html?id=17523), [support#19968](https://support.isc.org/Ticket/Display.html?id=19968)
Being implemented in Kea.ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/kea/-/issues/581ISC DHCP "decline"2019-04-18T15:36:10ZFrancis DupontISC DHCP "decline"According to ISC DHCP dhcpd config doc:
```
The declines keyword
allow declines;
deny declines;
ignore declines;
The DHCPDECLINE message is used by DHCP clients to indicate that the lease the se...According to ISC DHCP dhcpd config doc:
```
The declines keyword
allow declines;
deny declines;
ignore declines;
The DHCPDECLINE message is used by DHCP clients to indicate that the lease the server has
offered is not valid. When the server receives a DHCPDECLINE for a particular address, it
normally abandons that address, assuming that some unauthorized system is using it. Unfor-
tunately, a malicious or buggy client can, using DHCPDECLINE messages, completely exhaust
the DHCP server's allocation pool. The server will eventually reclaim these leases, but not
while the client is running through the pool. This may cause serious thrashing in the DNS,
and it will also cause the DHCP server to forget old DHCP client address allocations.
The declines flag tells the DHCP server whether or not to honor DHCPDECLINE messages. If it
is set to deny or ignore in a particular scope, the DHCP server will not respond to DHCPDE-
CLINE messages.
The declines flag is only supported by DHCPv4 servers. Given the large IPv6 address space
and the internal limits imposed by the server's address generation mechanism we don't think
it is necessary for DHCPv6 servers at this time.
Currently, abandoned IPv6 addresses are reclaimed in one of two ways:
a) Client renews a specific address:
If a client using a given DUID submits a DHCP REQUEST containing
the last address abandoned by that DUID, the address will be
reassigned to that client.
b) Upon the second restart following an address abandonment. When
an address is abandoned it is both recorded as such in the lease
file and retained as abandoned in server memory until the server
is restarted. Upon restart, the server will process the lease file
and all addresses whose last known state is abandoned will be
retained as such in memory but not rewritten to the lease file.
This means that a subsequent restart of the server will not see the
abandoned addresses in the lease file and therefore have no record
of them as abandoned in memory and as such perceive them as free
for assignment.
The total number addresses in a pool, available for a given DUID value, is internally lim-
ited by the server's address generation mechanism. If through mistaken configuration, mul-
tiple clients are using the same DUID they will competing for the same addresses causing the
server to reach this internal limit rather quickly. The internal limit isolates this type
of activity such that address range is not exhausted for other DUID values. The appearance
of the following error log, can be an indication of this condition:
"Best match for DUID <XX> is an abandoned address, This may be a
result of multiple clients attempting to use this DUID"
where <XX> is an actual DUID value depicted as colon separated
string of bytes in hexadecimal values.
```ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/kea/-/issues/2582ISC DHCP sub classes2022-10-18T12:11:49ZFrancis DupontISC DHCP sub classesISC DHCP support sub classes:
```
In addition to classes, it is possible to declare subclasses. A subclass
is a class with the same name as a regular class, but with a specific
submatch expression which is hashed fo...ISC DHCP support sub classes:
```
In addition to classes, it is possible to declare subclasses. A subclass
is a class with the same name as a regular class, but with a specific
submatch expression which is hashed for quick matching. This is
essentially a speed hack - the main difference between five classes with
match expressions and one class with five subclasses is that it will be
quicker to find the subclasses. Subclasses work as follows:
class "allocation-class-1" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
class "allocation-class-2" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
allow members of "allocation-class-1";
range 10.0.0.11 10.0.0.50;
}
pool {
allow members of "allocation-class-2";
range 10.0.0.51 10.0.0.100;
}
}
The data following the class name in the subclass declaration is a
constant value to use in matching the match expression for the class.
When class matching is done, the server will evaluate the match
expression and then look the result up in the hash table. If it finds a
match, the client is considered a member of both the class and the
subclass.
Subclasses can be declared with or without scope. In the above example,
the sole purpose of the subclass is to allow some clients access to one
address pool, while other clients are given access to the other pool, so
these subclasses are declared without scopes. If part of the purpose of
the subclass were to define different parameter values for some clients,
you might want to declare some subclasses with scopes.
In the above example, if you had a single client that needed some
configuration parameters, while most didn't, you might write the
following subclass declaration for that client:
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
option root-path "samsara:/var/diskless/alphapc";
filename "/tftpboot/netbsd.alphapc-diskless";
}
In this example, we've used subclassing as a way to control address
allocation on a per-client basis. However, it's also possible to use
subclassing in ways that are not specific to clients - for example, to
use the value of the vendor-class-identifier option to determine what
values to send in the vendor-encapsulated-options option. An example of
this is shown under the VENDOR ENCAPSULATED OPTIONS head in the
dhcp-options(5) manual page.
```
Sub-classes are essentially an improvement in both the evaluation process (match expression is evaluated once and its value is compared with a hash table) and configuration (less things to repeat and exposed relationship). The same idea can be used in Kea: currently Keama just recombines match expression and value in regular classes, losing the fact the parent depends on a matching sub class...ISC DHCP Migration