Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-22T13:17:40Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3266status-get command must return an HA relationship identifier2024-03-22T13:17:40ZMarcin Siodelskistatus-get command must return an HA relationship identifierWe now support the hub-and-spoke setup with multiple relationships in one server. The HA state can be retrieved using the `status-get` command. The problem is, though, that the `status-get` result lacks an association between returned lo...We now support the hub-and-spoke setup with multiple relationships in one server. The HA state can be retrieved using the `status-get` command. The problem is, though, that the `status-get` result lacks an association between returned local/remote entries and the configured relationships. It makes it nearly impossible to match the returned statuses with the relationships we maintain in the Stork database. The status-get response must return identifiers of the HA relationships to enable this matching.kea2.5.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3250Unattended terminated state and a reboot2024-03-27T21:53:51ZMarcin SiodelskiUnattended terminated state and a rebootConsider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP cl...Consider the following case. The clocks on two HA-enabled servers diverge and the clock skew eventually exceeds 60 seconds. As a result, both servers transition to the terminated state. In this state, the servers continue serving DHCP clients but do not exchange the lease updates nor heartbeats. An administrator neglects to correct the clocks and one of the servers reboots. The server enters the `waiting` state and remains in this state hoping that the other server is restarted so they can continue the lease database synchronization and start normal operation. However, the server is unaware that its reboot was not triggered in the course of fixing the clocks, so it will wait for the partner endlessly (or until the administrator comes to work in the morning). The waiting server is not responding to the DHCP traffic until then.
This situation should not occur in a setup where NTP has been enabled. It also should not occur if there is a proper monitoring to detect that the clocks diverge early enough. However, there are chances this situation may happen when all of this is neglected.
The proposed solution is to apply a timeout (could even be several to 10 minutes long) for a server in the waiting state. If the transition of its partner does not occur until this timeout elapses, the server in the waiting state transitions back to the terminated state and continues serving the clients. The waiting server MUST NOT transition to the waiting state immediately after it detects that its partner is in the terminated state to allow enough time to the administrator to reboot the server sequentially after correcting the clocks.
[SF1598](https://isc.lightning.force.com/lightning/r/Case/500S6000003jBs3IAE/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3206subnet-get commands should fetch leases for selected subnets with pagination2024-03-22T13:15:53ZMarcin Siodelskisubnet-get commands should fetch leases for selected subnets with paginationIn HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships...In HA, we use lease commands to synchronize the database. The lease commands fetch all leases with pagination. However, in the hub-and-spoke model it would be useful to fetch the leases only for selected subnets because the relationships are partitioned by subnet. Today, all leases have to be fetched by each relationship and those that do not belong to the relationship are discarded. This is inefficient. One thing to consider is that subnet identifiers are listed explicitly in the commands.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3178Run multiple HA relationships in hub-and-spoke configuration2024-01-26T14:35:10ZMarcin SiodelskiRun multiple HA relationships in hub-and-spoke configurationThis is the actual implementation of the hub-and-spoke model described in the design ticket: https://gitlab.isc.org/isc-projects/kea/-/issues/1149
It should add the logic to run multiple `HAService` instances concurrently. The major iss...This is the actual implementation of the hub-and-spoke model described in the design ticket: https://gitlab.isc.org/isc-projects/kea/-/issues/1149
It should add the logic to run multiple `HAService` instances concurrently. The major issue is to implement the callouts for the `subnet4_select` and `subnet6_select` hook points that would be used in the hub-and-spoke configuration to select the relationship based on the selected subnet. We should also test that the `HAService` instances do not stomp on each other, that are thread safe etc. After this ticket, the hub-and-spoke configuration should be usable, at least in a basic form.
[support#22017](https://support.isc.org/Ticket/Display.html?id=22017).kea2.5.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2918ISC DHCP log emulation2023-10-06T17:12:30ZPeter DaviesISC DHCP log emulation---
name: ISC DHCP log emulation
about: Kea to generate logging similar ISC DCHP.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Kea's forensic logging hooks library ...---
name: ISC DHCP log emulation
about: Kea to generate logging similar ISC DCHP.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
Kea's forensic logging hooks library can be configured generate messages that look
like ISC DHCP logging but DHCPDISCOVER/DHCPOFFER and SOLICIT/ADVERTISE
packets are not logged.
**Is your feature request related to a problem? Please describe.**
As a help to folks who are planning to migrate from ISC DCHP to Kea it may be helpful if
Kea could be induced to produce logging that approximate those generated by ISC DCHP.
**Describe the solution you'd like**
There appear to be two ways forward:
1) Enhance Kea's forensic logging hooks library.
2) Generate new logging messages at severity INFO
**Additional context**
See [RT #22155](https://support.isc.org/Ticket/Display.html?id=22155)kea2.5.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2875perfdhcp enhancements: do not allow -6 -J usage without -A2023-06-15T16:13:14ZPiotrek Zadrogaperfdhcp enhancements: do not allow -6 -J usage without -AWhile working on #2834 it occurred to me that using `perfdhcp -6 -J` without `-A1` makes no sense.
It could be considered as an exception and some nice hint could be returned to the user.While working on #2834 it occurred to me that using `perfdhcp -6 -J` without `-A1` makes no sense.
It could be considered as an exception and some nice hint could be returned to the user.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2824Optimizations in the allocator selection: copy the existing state2023-04-13T13:49:14ZMarcin SiodelskiOptimizations in the allocator selection: copy the existing stateThe random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and ...The random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and the subnet pools, we could perhaps avoid re-building the allocator state but keeping the existing state aside, and then copying the pointer to the allocation state to the new subnet instance. In that case we'd only have the overhead during the startup, renumbering and an allocator change. In all other cases, the reconfiguration would be smooth.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2780Free lease queue allocator2023-07-17T13:58:22ZMarcin SiodelskiFree lease queue allocatorThe Free lease queue allocator populates leases at the startup or reconfiguration in the server's memory. It installs callbacks in LeaseMgr using #2764. When a DHCP request comes in, it picks the next free lease for a subnet and offers i...The Free lease queue allocator populates leases at the startup or reconfiguration in the server's memory. It installs callbacks in LeaseMgr using #2764. When a DHCP request comes in, it picks the next free lease for a subnet and offers it to the client. When the client requests the lease and the lease is allocated, the callbacks are invoked causing the lease removal from the populated list. Similarly, when the lease is deleted or reclaimed, the lease is put back into the queue.
This ticket doesn't necessarily contain optimizations to inherit populated leases across reconfigurations. It means that the leases will be populated every time, the server is reconfigured. But, that's fine for the first step. We will address it in another ticket.
Also see: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/free-lease-queues-designkea2.3.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2771Optionally fuse sent vendor options2023-03-16T14:32:36ZFrancis DupontOptionally fuse sent vendor optionsCurrently with multiple vendors one vendor option is sent for each vendor: this is RFC compliant but can disturb clients: the idea is to create new builtin client classes which fuse vendor options when set (and when sizes permit).
(this...Currently with multiple vendors one vendor option is sent for each vendor: this is RFC compliant but can disturb clients: the idea is to create new builtin client classes which fuse vendor options when set (and when sizes permit).
(this ticket is mostly to save the idea i.e. not to be addressed before a problem is reported)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2763Lease start time of state2023-04-28T07:24:29ZFrancis DupontLease start time of stateBoth v4 Bulk Leasequery (BLQ) and RADIUS accounting have use of keeping the start time of state for assigned leases i.e. the date of the transistion to the default (0) state. This ticket proposes to keep it in the user context, the RADIU...Both v4 Bulk Leasequery (BLQ) and RADIUS accounting have use of keeping the start time of state for assigned leases i.e. the date of the transistion to the default (0) state. This ticket proposes to keep it in the user context, the RADIUS table keeping it can be reused for the design.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2592partner-down state transition when max-unacked-clients reached2022-11-24T14:45:22ZMarcin Siodelskipartner-down state transition when max-unacked-clients reachedSuppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients ...Suppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients should retry getting the lease with the increased value of the `secs` field before the server considers partner dead. One would expect the server to make `partner-down` transition as soon as the number of unacked clients reaches the configured number. In fact, the state transitions are generally performed when the server completes a heartbeat or a lease update. It is possible that under heavy traffic there will be much larger number of unacked clients and the server still sits in the normal state (e.g. hot-standby), waiting for the heartbeat trigger. Assuming the heartbeat interval is reasonable, it should probably be fine. However, we may consider starting the transition as soon as the number of unacked clients reaches the configured maximum.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2543Add feature to ignore RAI Link Selection suboption for subnet selection2023-07-17T13:58:24ZDan TheisenAdd feature to ignore RAI Link Selection suboption for subnet selectionIt seems that some vendors may not allow granular control of the option 82 suboptions which are sent. We should add a configuration parameter that allows clients to choose whether or not the RAI Link Selection suboption (option 82.5) is ...It seems that some vendors may not allow granular control of the option 82 suboptions which are sent. We should add a configuration parameter that allows clients to choose whether or not the RAI Link Selection suboption (option 82.5) is used as the primary source of truth for which subnet to use. Clients need to be able to choose the subnet selection logic that Kea regardless of which vendors they use for routing equipment. The specific client in question is attempting to use option 82.1 to classify packets into specific client classes, and use client classification to determine the subnet which a client has an address assigned from. The subnet specified by the routers in the Link Selection subnet is not necessarily the subnet which the client should use. The client uses Juniper routers as DHCP relays, and Juniper's docs do not shed light on how to specifically disable the Link Selection suboption: https://stage.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-sessions/topics/topic-map/dhcp-option-82-using.html#id-using-dhcp-relay-agent-option-82-information
Users should be able to ignore the Link Selection suboption as a primary source of truth for subnet selection, and instead fall back to the normal subnet selection process that is used when the Link Selection suboption is not present. In this case, the routers still include a giaddr (relay address) in the bootp header that can be used for shared network selection.
(Another proposed solution was flex-option for queries)
[RT#20921](https://support.isc.org/Ticket/Display.html?id=20921)kea2.3.2Dan TheisenDan Theisenhttps://gitlab.isc.org/isc-projects/kea/-/issues/2434Include interface statuses in the status-get response2022-07-22T11:50:32ZSlawek FigielInclude interface statuses in the status-get responseI have a slight problem with Kea DHCP daemons during writing system tests for Stork. I run the Kea in the Docker container, and next, I use the perfdhcp to generate traffic. The Kea daemon starts very quickly after the container runs, an...I have a slight problem with Kea DHCP daemons during writing system tests for Stork. I run the Kea in the Docker container, and next, I use the perfdhcp to generate traffic. The Kea daemon starts very quickly after the container runs, and not all interfaces are available yet. I used the retry socket binding solution developed in #1716, which works as expected. But there is no possibility of checking if the binding passed successfully. It means I don't know when I can safely call the perfdhcp.
It will be convenient to include the interface listening statuses in the `status-get` command response.
It ~isn't~ is a blocker for me. ~I'm writing the shell script that checks the interface status using Linux net-tools.~ I tried to write the shell script that checks if the binding is available, but I failed,kea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2256Prepare subnet selection speedup: patrica trees2023-06-19T12:08:06ZFrancis DupontPrepare subnet selection speedup: patrica treesPatricia trees are the optimal general data structure for IP prefix lookup: the number of comparisons is bounded by the number of bits so 32 or 128 for IP, the real number depends on the number of nodes where children differs and in the ...Patricia trees are the optimal general data structure for IP prefix lookup: the number of comparisons is bounded by the number of bits so 32 or 128 for IP, the real number depends on the number of nodes where children differs and in the real world is far lower.
BTW the current code just iterates on all subnetworks so is linear in the number of subnets (average case N/2, N for the worst case which includes the not found case). The patricia tree gives also overlaps (equality or inclusion).backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2255Prepare subnet selection speedup: auxiliary tables2023-07-31T13:32:51ZFrancis DupontPrepare subnet selection speedup: auxiliary tablesThere are at least two cases where an index can or should not be used/added to a multi index:
- when the corresponding data structure is not supported, e.g. patricia tree for IP prefixes
- when the default is very common: the multi ind...There are at least two cases where an index can or should not be used/added to a multi index:
- when the corresponding data structure is not supported, e.g. patricia tree for IP prefixes
- when the default is very common: the multi index works but gives a lot of values for this default value so it doubles the insert/delete operation time
- when a direct index value change is convenient: this breaks the multi index so must not be done (instead the multi index must be updated which is a complex (to code) and slow (to execute) operation)
The solution is to add in parallel of a multi index soem auxiliary tables which provide a specific lookup. The auxiliary table is a base type with add, delete and change (which is in general delete followed by add).backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2254Prepare subnet selection speedup: simplified collections2022-01-18T16:35:34ZFrancis DupontPrepare subnet selection speedup: simplified collectionsThe global collection is the only case where all indexes of SubnetXCollection are useful. In other cases, for instance members of a shared network, it is enough to have the by-id and by-prefix indexes.
The code comes from #554The global collection is the only case where all indexes of SubnetXCollection are useful. In other cases, for instance members of a shared network, it is enough to have the by-id and by-prefix indexes.
The code comes from #554kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2235Protect hook DSOs to be loaded by the wrong server2023-07-17T13:58:25ZFrancis DupontProtect hook DSOs to be loaded by the wrong serverOr just apply #50 solution to all hooks.Or just apply #50 solution to all hooks.kea2.3.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2208Make forensic log timestamp configurable2022-01-21T16:55:00ZPeter DaviesMake forensic log timestamp configurableThis is a tracking ticket to ensure we don't forget merge requests originating from the 19485-kea-premium tracking branch.
[RT 19485](https://support.isc.org/Ticket/Display.html?id=19485)This is a tracking ticket to ensure we don't forget merge requests originating from the 19485-kea-premium tracking branch.
[RT 19485](https://support.isc.org/Ticket/Display.html?id=19485)kea2.1.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1989Issues with qualifying suffix when clients use a combination of Hostname and ...2024-03-27T12:50:32ZMarcin SiodelskiIssues with qualifying suffix when clients use a combination of Hostname and Client FQDN optionA client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of these options, not both. If the Client FQDN is present in the client's message,...A client sends option 12 (Hostname) or option 81 (Client FQDN) to communicate the desired name to the server. The server assumes that the client sends one of these options, not both. If the Client FQDN is present in the client's message, it processes this option and ignores the Hostname option.
The server may append a qualifying suffix to the received name or replace the name entirely. The qualified name is terminated with a dot in Client FQDN and is never terminated with a dot in the Hostname option.
We deliberately made a change in the processing of the Hostname option several years ago when it turned out that some DHCP clients have issues with consuming the dot terminated hostname. It appears that it has implications for some clients.
We received a report about a client who uses a combination of option 12 and option 81 in the 4-way exchange. The client sends a partial name in option 12. The server qualifies the name with the suffix and sends option 12 back. The client uses the qualified name (without a dot) and sends it in the Client FQDN option as a partial name. The server qualifies the received name again on the grounds that it is a partial name. Even though the client shouldn't use a combination of these options, we could probably prevent qualifying the name twice by checking if the received name already has a suffix equal to the configured one.
One solution that comes to mind is to always append the dot to the hostnames returned in option 12. However, as mentioned before, we deliberately removed the dots because some clients did not accept them.
We can also consider whether it should be possible to explicitly include a dot via host reservations. If a host reservation has a dot for the hostname, the server would always include a dot. Thus, it would be possible to make exceptions for selected clients.
[RT #18375](https://support.isc.org/Ticket/Display.html?id=18735)
UPDATE: The original problem has been addressed in #1529. However, there's a request [see below](https://gitlab.isc.org/isc-projects/kea/-/issues/1989#note_227456) to add two parameters:
- [ ] allow the administrator to configure which field (option 12 or option 81) to prefer if both exist (RFC violation, that you can actually do now with DDNS tuning hook).
- [ ] including a trailing dot or not could be a configurable feature (or it could be left to the administrator if they include a trailing dot on the qualifying suffix itself.)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1972DHCP servers should fetch client classes from the config backend2021-07-26T16:54:51ZMarcin SiodelskiDHCP servers should fetch client classes from the config backendFollowing the work done in #1928, we need to extend the DHCPv4 and DHCPv6 servers to use client classes from the MySQL database. They should periodically fetch the classes whenever any of the classes have been added or modified.Following the work done in #1928, we need to extend the DHCPv4 and DHCPv6 servers to use client classes from the MySQL database. They should periodically fetch the classes whenever any of the classes have been added or modified.kea1.9.10Marcin SiodelskiMarcin Siodelski