Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-10-23T14:58:37Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2796"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign le...2023-10-23T14:58:37Zuedvt359"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign lease to reserved host)When resolving conflicts between active leases and host reservations, Kea relies on the client with the active lease to cooperate. When lease times are long, and the client with the active lease goes offline, the host with the reservatio...When resolving conflicts between active leases and host reservations, Kea relies on the client with the active lease to cooperate. When lease times are long, and the client with the active lease goes offline, the host with the reservation must wait for the lease to expire fully before it will be assigned to it.
This is a feature request for what the documentation calls the "naive approach" of just re-assigning IPs, at least for out-of-pool reservations.
I posted this to the Kea-Users mailing list in January, and got a bunch of replies, indicating that this feature would be appreciated by other users, too: https://lists.isc.org/pipermail/kea-users/2023-January/003847.html
Picture the following situation:
Initially:
- Leases are valid for a long time (11 days, per customer requirement)
- There is a host reservation for \<mac1\> and \<ip1\>
- The device with \<mac1\> got a lease for \<ip1\>
Now, the hardware is replaced and the reservation is updated, so the new device gets the same IP:
- remove reservation for \<mac1\> and \<ip1\>
- add reservation for \<mac2\> and \<ip1\>
- the old device is unplugged, and therefore cannot release its lease
- the new device is plugged in and requests a lease
Now, Kea looks for the host reservation for \<mac2\> and notices that
\<ip1\> is still leased to \<mac1\>, so it refuses to reassign this IP.
I read through section 8.3.2 of the documentation, and the conflict
resolution protocol used seems to not handle our case here (where the
old device doesn't release its lease). It expects the old device with
\<mac1\> to renew its lease, before responding with DHCPNAK and
reallocating \<ip1\> to \<mac2\>.
The documentation describes that "A naive approach would to be
immediately remove the existing lease for Host A and create a new one
for Host B" -- this would be exactly what we want, and what our
previous setup did.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/856Enable dynamic prefix support2024-02-07T22:34:55ZTiago GasparEnable dynamic prefix support---
name: Enable dynamic prefix support
about: Allow dynamic prefixes in a interface
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
From all I've searched all over the ...---
name: Enable dynamic prefix support
about: Allow dynamic prefixes in a interface
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
From all I've searched all over the internet this is not a standard kea nor ISC-DHCP option
- Are you sure what you would like to do is not possible using some other mechanisms?
I can't see any other way to do this without a wacky faulty scipt
- Have you discussed your idea on kea-users or kea-dev mailing lists?
No, I'm new to this of contributing and have no idea on how to do that
**Is your feature request related to a problem? Please describe.**
So I have a Linux system, in this case OpenWRT as the main router in my home, and I receive a IPv6 prefix from my ISP of size /56 and OpenWRT receives it and assigns it to each interface with the size I describe, but as the prefix is dynamic I can't configure the prefix in kea's config files because it is constantly changing.
**Describe the solution you'd like**
My suggestion is that kea could allow us to set a interface to listen on (as it does) and in the `"subnet":` option it could allow us to set a network like ::/60 (witch is the address for unspecified network)
**Describe alternatives you've considered**
I've considered setting only the listening interface and no subnet option but theãt wouldn't work as Kea also works as a stateless DHCPv6 server, so this is the best way I can think that the server can work as stateless and stateful DHCPv6 with or without a dynamic prefix
**Additional context**
I have a OpenWRT in my house and my ISP gives me a IPv6 Dynamic prefix, although OpenWRT natively handles IPv6 very well with Odhcpd, it doesn't offer many options to give out to clients besides the required ones like DNS and Gateway so I decided to dich odhcpd and I thought of dhcpd but I saw that Kea was a new, better DHCP meant to replace dhcpd at some point so as I'm all for the new and better I installed Kea and got this problem.
**Funding its development**
I'm curently studying so I don't have the money to fund it, but I work in networking every day so I can help you develop this feature asn needed and as I can
**Participating in development**
Yes absolutely! I'm here as needed Just ask, sometimes I can take a bit because of school but I will answer
**Contacting you**
I'd rather you contact me trough github or through here, I will enable e-mail notifications and if you really need to talk I'll privately send my phone numberoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/46Please add circuit-ID to result of get lease-42022-11-02T15:08:42ZGhost UserPlease add circuit-ID to result of get lease-4We want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode SætreWe want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode Sætrebackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2984Add support for Delegated-IPv6-Prefix to RADIUS hook2024-03-27T12:55:24ZDarren AnkneyAdd support for Delegated-IPv6-Prefix to RADIUS hookCurrently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to cr...Currently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to create a reservation for a prefix based on the content of delegated-ipv6-prefix (https://www.rfc-editor.org/rfc/rfc4818) in the access-accept response.
[RT22056](https://support.isc.org/Ticket/Display.html?id=22056)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2714RFE: HA plugin ability to detect partner inabilty to receive client requests ...2023-07-31T14:12:57ZKevin FlemingRFE: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'---
name: Feature request
about: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'
---
**Some initial questions**
- Are you sure your feature is not already implemented in the l...---
name: Feature request
about: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on kea-users or kea-dev mailing lists? Yes
**Is your feature request related to a problem? Please describe.**
(This issue was created as a result of an extensive thread on kea-users)
When the HA plugin is being used in either hot-standby or load-balancing mode, Kea peers are able to notice some forms of communications failures and force the other peers to the 'partner-down' state in order to provide service to clients supported by the other peer.
However, in a situation where client requests are not being delivered to a peer, but it is otherwise fully operational including the peer-to-peer communications link, clients supported by that peer will not be serviced, but the other peer(s) care unable to notice the issue and take action to correct it. This situation could arise when the Kea peers are using separate network links for client traffic and HA traffic, or when the Kea peers are receiving client traffic via a DHCP relay and the relay configuration is incorrect.
**Describe the solution you'd like**
One (or more) opt-in mechanisms that the Kea admin can choose to enhance the ability to detect peer failures to service clients, even when the peer's Kea daemon is otherwise fully operational.
**Describe alternatives you've considered**
Some discussions about external monitoring solutions have occurred, and that is certainly an option which some admins could choose.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? Yes
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? Yesnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2169ddns-rev-domainname2022-11-02T15:10:41ZPeter Daviesddns-rev-domainnameThe ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0....The ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0.168.192.in-addr.arpa. CNAME 20.0-64.0.168.192.in-addr.arpa.
20.0-64.0.168.192.in-addr.arpa. PTR mypc.example.com.
From a question raised on Kea-users@lists.isc.org mailing list.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2090Support for supersede together with dhcp-server-identifier2023-03-08T19:10:29ZVeroniqueSupport for supersede together with dhcp-server-identifierWe need to configure *dhcp-server-identifier* using the supersede hook but the server does not send an ACK. Instead it dropped the DHCP request complaining that "it contains a foreign server identifier".
Here is our configuration:
``` ...We need to configure *dhcp-server-identifier* using the supersede hook but the server does not send an ACK. Instead it dropped the DHCP request complaining that "it contains a foreign server identifier".
Here is our configuration:
```
[...]
"client-classes": [
{
"name": "Windows",
"user-context": {},
},
{
"name": "Desktop",
"user-context": {},
},
[...]
"reservations": [
{
"hw-address": "aa:aa:aa:aa:aa:01",
"ip-address": "111.111.111.111",
"hostname": "client1",
"client-classes": [
"Desktop"
]
},
{
"hw-address": "aa:aa:aa:aa:aa:02",
"ip-address": "111.111.111.222",
"hostname": "client2",
"client-classes": [
"Windows"
]
},
[...]
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_bootp.so",
"parameters": {}
},
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/local/lib/kea/hooks/libdhcp_flex_option.so",
"parameters": {
"options": [
{
"code": 54,
"supersede": "ifelse(substring(option[vendor-class-identifier].text, 0, 9) == 'PXEClient' and member('Desktop'), 'xx.xx.xx.xx', ifelse(substring(option[vendor-class-identifier].text, 0, 9) == 'PXEClient' and member('Windows'), 'yy.yy.yy.yy', 'zz.zz.zz.zz'))"
}
]
}
}
],
```
Could this be supported in a coming release ?
Knowing that we have 100's of 1000's of clients in each class, we cannot test on their mac address in the class definition because it would generate a HUGE configuration file containing HUGE test expressions, so big that the validation takes hours to complete.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1688Auto-detect congestion (busy state thresholds)2022-11-02T15:10:18ZVicky Riskvicky@isc.orgAuto-detect congestion (busy state thresholds)This is a general requirement to adapt to improve performance under unusual load. The feature will require some further design thought.
**Congestion Handling**
Being able to handle peak loads is an important feature for service provider...This is a general requirement to adapt to improve performance under unusual load. The feature will require some further design thought.
**Congestion Handling**
Being able to handle peak loads is an important feature for service providers. Congestion handling features attempts to improve the DHCP performance when the service becomes busy and is not able to fulfill all incoming requests. In cable operators the following scenarios are usual:
- Massive firmware updates- causing cable modems to restart
- Power outages- affecting cable modems in a region or fiber node.
- A fiber node might serve up to ~2,000 subscribers
- CMTS reboots- due to scheduled maintenance or outages
- RF plant rearrangements- where fiber nodes are combined or splitted causing cable modems within the node to re register
- DDI infrastructure maintenance or outages.
- Business requirements- such as massive actions to customers, i.e. disabling customers with unpaid bills.
Suggestion
**Busy state threshold**
Defines a mechanism to allow Kea to evaluate whether it is operating in a normal or busy state. Kea could use the value of the “packet-queue-size” parameter in the multi-threaded configuration section to evaluate if the system should enter a busy state, for example when the queue capacity is 75% full the system transitions to a busy state and may take actions to improve DHCP performance, such as enabling one or more congestion handling features on the fly, like reducing logging, packet prioritization, and/or batch insertion. When the queue capacity is 25% full or less, the system should return from busy to normal state.
It is likely that customers would want to be able to adjust these high and low watermarks.
It should be possible to explicitly enable/disable this feature.
The various actions that Kea will take to handle the congestion should be determined based on some analysis of what will have the most impact in maintaining normal responsiveness to clients under peak loads.
```
# example suggested configuration section
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 4,
"packet-queue-size": 16
"busy-state-pct" : 75,
"normal-state-pct" : 25
}
```
The “capacity” value in the “dhcp-queue-control” configuration section might also be used to evaluate busy state.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1281Explore methods of enhancing lease synchronization2024-01-09T21:14:42ZPeter DaviesExplore methods of enhancing lease synchronization**Explore methods of enhancing lease synchronization**
To minimise the time taken to synchronize lease data when a primary Kea server comes online after an outage. Thereby minimise the time in which dhcp traffic is not processed.
Is it...**Explore methods of enhancing lease synchronization**
To minimise the time taken to synchronize lease data when a primary Kea server comes online after an outage. Thereby minimise the time in which dhcp traffic is not processed.
Is it possible to speed up the convergence of lease data on a HA pair by giving a server knowledge of what leases its partner has?
Or a mechanism where Kea server could request only lease updates that were made while it was off line. Based either on time or maybe some serial nr? The case where one Kea server can be standby for more than one primary could make this difficult to implement.
Or some out-of-bounds method of copying the lease file contents?
RT [#16560](https://support.isc.org/Ticket/Display.html?id=16560)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/586disable dhcpdecline via configuration option2019-04-25T16:01:56ZGhost Userdisable dhcpdecline via configuration optionI disabled the DHCPDECLINE feature in the KEA source.
In our FTTH access network IP conflict never ever can happen, because of the dhcp snooping
based IP- and ARP anti spoofing, so processing the DHCPDECLINE messages from the clients is ...I disabled the DHCPDECLINE feature in the KEA source.
In our FTTH access network IP conflict never ever can happen, because of the dhcp snooping
based IP- and ARP anti spoofing, so processing the DHCPDECLINE messages from the clients is just a vulnerability.
I suggest the DHCPDECLINE feature should be disable via configuration option, global or/and subnet level.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/226ISC DHCP server config option adaptive-lease-time-threshold2022-11-02T15:08:42ZFrancis DupontISC DHCP server config option adaptive-lease-time-threshold>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease len...>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease length for new clients within this pool to min-lease-time sec-
onds. Clients renewing an already valid (long) leases get at least
the remaining time from the current lease. Since the leases expire
faster, the server may either recover more quickly or avoid pool
exhaustion entirely. Once the number of allocated leases drop below
the threshold, the server reverts back to normal lease times. Valid
percentages are between 1 and 99.
>>>
A good idea for a lease allocation hook library.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-27T20:44:57ZPeter DaviesCableLabs option (RFC3495): Inconsistent "option_def" usage in client class definitionsInconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"opt...Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
```
However, if this "option-def" is defined within a client class as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
The following message is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
```
If the "Option_122" "option-def" is changed to private option "224" as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
Then the following error is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
```
[SF00001775](https://isc.lightning.force.com/lightning/r/Case/500S6000006TLtj/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3219Implement RFC9527: Homenet DHCPv6 options2024-01-25T14:54:51ZTomek MrugalskiImplement RFC9527: Homenet DHCPv6 optionsA new set of three DHCPv6 options are being published in [RFC9527](https://www.rfc-editor.org/authors/rfc9527.html). If this link no longer works, it means the RFC is published.
The options' formats are reasonably simple (a 16-bits long...A new set of three DHCPv6 options are being published in [RFC9527](https://www.rfc-editor.org/authors/rfc9527.html). If this link no longer works, it means the RFC is published.
The options' formats are reasonably simple (a 16-bits long bit field + fqdn) and are DHCPv6 only. There's no special processing - normal ORO stuff, although the server will likely keep some values user specific (so will be used mainly as host reservation options).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3217Neighbor discovery for dhcpv62024-02-19T21:40:42ZVaclav MichalekNeighbor discovery for dhcpv6This is a request to implement IPv6 neighbor discovery mechanism (rfc4861) in DHCPv6 server to obtain MAC hardware addresses.
The method is also suggested in [related issue](https://gitlab.isc.org/isc-projects/kea/-/issues/1729 "Feature...This is a request to implement IPv6 neighbor discovery mechanism (rfc4861) in DHCPv6 server to obtain MAC hardware addresses.
The method is also suggested in [related issue](https://gitlab.isc.org/isc-projects/kea/-/issues/1729 "Feature request: DHCPv6 - use real MAC address from dhcp6 request (mac-sources=raw)").
**Is your feature request related to a problem? Please describe.**
The feature is needed for reliable host-based reservations and identification of DHCPv6 clients.
**Describe the solution you'd like**
Two new mac-source methods (query OS neighbor cache, neighbor discovery) are to be implemented.
```plaintext
"mac-sources": [ "neigh-cache", "neigh-discovery" ]
```
**Describe alternatives you've considered** At this time, there is no practical alternative.
**Funding its development** No funding.
**Participating in development** I am planning to write the code (though with no experience with Kea developement).
**Contacting you** ... E-mail in my profile.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3201Allow static leases by hostname like in the old ISC dhcpd2024-01-18T14:52:27ZLuigi BaldoniAllow static leases by hostname like in the old ISC dhcpd---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hard...---
name: Allow reservations by hostname
about: Allow creating reservations by hostname like in the old ISC dhcp server
---
**Describe the solution you'd like**
In the old ISC dhcpd one could add entries like:
```
host myhost {
hardware ethernet 08:00:aa:bb:cc:dd;
fixed-address myhost;
}
```
Kea allows this:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"ip-address": "192.0.2.10"
}
]
```
Would it be possible to implement this feature in Kea so to have something like:
```
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"hostname-address": "myhost"
}
]
```
?
**Describe alternatives you've considered**
I am aware of the possibility of using ddns and RFC2136 to supply data to a domain name server.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3192Allow `perfdhcp` to behave like an endpoint client2024-01-11T14:52:45ZChrisPortmanAllow `perfdhcp` to behave like an endpoint client---
name: perfdhcp DHCPv4 not as a relay
about: Support for perfdchp DHCPv4 Operation as a normal client (not relay)
---
**Is your feature request related to a problem? Please describe.**
I would like to be able to use perfdhcp to test...---
name: perfdhcp DHCPv4 not as a relay
about: Support for perfdchp DHCPv4 Operation as a normal client (not relay)
---
**Is your feature request related to a problem? Please describe.**
I would like to be able to use perfdhcp to test a dhcp implementation including the ability to process DORA over broadcast.
**Describe the solution you'd like**
An option that enabled perfdhcp to act as an end client as opposed to a relay, which means using broadcast traffic, not setting
giaddr and binding to port 68 and not 67.
**Additional context**
I'm specifically trying to tests a DHCP application on the same host. This means that the dhcp process binds on 67 and the current behaviour of perfdhcp is to also bind on 67 which fails. If perfdhcp can function as a normal client, it can use 68.
**Funding its development**
Unfortunately no, but see next section
**Participating in development**
I have a patch ready to submit via a MR once I can get permission to fork.
**Contacting you**
Please reach out via github. I can provide email via a direct message if required.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3188Support hot plugging network interfaces2024-02-01T10:52:48ZJakub OkońskiSupport hot plugging network interfaces---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` i...---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` is not present when Kea starts.
I want to be able to declare subnets & definitions for a USB adapter that I sometimes hotplug to the gateway. Without support from Kea, I'd need to keep two different configs and reload Kea at appropriate times. I assume it's also going to fail when a network interface it's listening on disappears.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3170Feature request: Add regex classification expression2023-11-30T14:29:47ZottoreiFeature request: Add regex classification expressionIt would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.It would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3144redetect-interfaces command2024-02-08T14:35:31ZTomek Mrugalskiredetect-interfaces commandThe idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is tha...The idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is that Kea could be told that some new interfaces appeared or disappeared (VLAN, PPP, some other tunnel etc.) and Kea should redetect them. For an added bonus, there should be a way to tell Kea to open sockets on those new interfaces. This can be done either by telling Kea to open the on any newly detected interfaces or perhaps return a list of interfaces and have a dedicated call `open-socket` or something similar? Anyway, this would be useful to have a mini-design for.
This problem is not new and there are many requests in this problem space:
- A [nicely described use case in #3040](https://gitlab.isc.org/isc-projects/kea/-/issues/3040#note_414899)
- #1084
- #3062
- possibly couple morenext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3140Feature request: Add Statistics Counters for dropped packets (for various dif...2024-03-27T12:51:09ZCathy AlmondFeature request: Add Statistics Counters for dropped packets (for various different reasons)---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
...---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
This is loosely related to issue #3125 for counting some dropped packets due to HA (#3125 is more about not logging them unnecessarily though, or being able to disable the per-event logging).
This is a request to add a specific packet counts for both HA and for other dropped packets such as ones dropped due to kea being disabled.
Customer requesting this feature currently has an issue where they can't tell if an operator has misconfigured their network such that Kea wasn't receiving any traffic or if it was in a disabled state due to Kea HA sync.
Version 2.2
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0