Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-07-17T13:58:24Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/248ISC DHCP spawning classes2023-07-17T13:58:24ZFrancis DupontISC DHCP spawning classesISC DHCP has spawning classes:
>>>
Many cable modem head-end systems can be configured to add a Relay
Agent Information option to DHCP packets when relaying them to the DHCP
server. These systems typically ad...ISC DHCP has spawning classes:
>>>
Many cable modem head-end systems can be configured to add a Relay
Agent Information option to DHCP packets when relaying them to the DHCP
server. These systems typically add a circuit ID or remote ID option
that uniquely identifies the customer site. To take advantage of this,
you can write a class declaration as follows:
class "customer" {
spawn with option agent.circuit-id;
lease limit 4;
}
Now whenever a request comes in from a customer site, the circuit ID
option will be checked against the class's hash table. If a subclass
is found that matches the circuit ID, the client will be classified in
that subclass and treated accordingly. If no subclass is found match-
ing the circuit ID, a new one will be created and logged in the
dhcpd.leases file, and the client will be classified in this new class.
Once the client has been classified, it will be treated according to
the rules of the class, including, in this case, being subject to the
per-site limit of four leases.
The use of the subclass spawning mechanism is not restricted to relay
agent options - this particular example is given only because it is a
fairly straightforward one.
>>>
The important statement is the manual is:
>>>
The reason that spawning classes were created was to make it
possible to create lease-limited classes on the fly.
>>>
So they are very bound to the lease limitation feature. As Kea does not support it in fact the whole concept of spawning classes is useless for Kea...ISC DHCP MigrationFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/228ISC DHCP server config option dhcp-cache-threshold2022-05-25T08:37:06ZFrancis DupontISC DHCP server config option dhcp-cache-threshold>>>
The dhcp-cache-threshold statement
**dhcp-cache-threshold** percentage;
The dhcp-cache-threshold statement takes one integer parameter with
allowed values between 0 and 100. The default value is 25 (25% of the
lease time). This par...>>>
The dhcp-cache-threshold statement
**dhcp-cache-threshold** percentage;
The dhcp-cache-threshold statement takes one integer parameter with
allowed values between 0 and 100. The default value is 25 (25% of the
lease time). This parameter expresses the percentage of the total
lease time, measured from the beginning, during which a client's
attempt to renew its lease will result in getting the already
assigned lease, rather than an extended lease.
Clients that attempt renewal frequently can cause the server to
update and write the database frequently resulting in a performance
impact on the server. The dhcp-cache-threshold statement instructs
the DHCP server to avoid updating leases too frequently thus avoiding
this behavior. Instead the server assigns the same lease (i.e.
reuses it) with no modifications except for CLTT (Client Last Trans-
mission Time) which does not require disk operations. This feature
applies to IPv4 only.
When an existing lease is matched to a renewing client, it will be
reused if all of the following conditions are true:
- The dhcp-cache-threshold is larger than zero
- The current lease is active
- The percentage of the lease time that has elapsed is less than dhcp-cache-threshold
- The client information provided in the renewal does not alter any of the following:
- DNS information and DNS updates are enabled
- Billing class to which the lease is associated
- The host declaration associated with the lease
- The client id - this may happen if a client boots without a client id and then starts using one in subsequent requests.
Note that the lease can be reused if the options the client or relay
agent sends are changed. These changes will not be recorded in the
in-memory or on-disk databases until the client renews after the
threshold time is reached.
>>>
The whole idea to cache too frequent requests is a good one even not so simple to implement.
**UPDATE:** Kea now supports cache-threshold since 1.9.4. The Keama should be updated one day.ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/kea/-/issues/216ISC DHCP migration assistant2021-06-18T09:24:14ZFrancis DupontISC DHCP migration assistantIt is the Kea ticket for RT 44949. It replaces Trac 5180.It is the Kea ticket for RT 44949. It replaces Trac 5180.ISC DHCP MigrationFrancis DupontFrancis Dupont