[Kea-users] Multi-Class Evaluation in Subnets and Pools (ISC to Kea Migration Pattern)

[Darren Ankney]

Hi Kriashak,

I think what you are saying is that the behavior noted here:
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#client-classification-in-shared-networks
where it says:

> If a subnet is associated with one or more classes, only the clients belonging to at least one of these classes may use this subnet.

Is not the way you wished it worked.  You would like Kea to require
membership in ALL of the classes listed in a subnet instead of at
least one.  Other users may disagree with such a radical change.
Perhaps a configuration flag changing the behavior would be a
solution?  In any case, suggest you open an issue here:
https://gitlab.isc.org/isc-projects/kea/-/work_items as that is how
this idea could be brought to the attention of Engineering.

Thank you,
Darren Ankney

On Wed, Aug 26, 2026 at 6:30 AM Kraishak Mahtha <kraishak.edu at gmail.com> wrote:
>
> Hi All,
>
> In the recent Kea 3.0.4 updates, I noticed that the client-classes attribute in the subnet/pool configuration is now defined as an array, which is a good improvement. However, I noticed that we still cannot directly specify multiple client classes as a comma-separated list and have them evaluated as a combination.
>
> For example, in the Kea Reference Guide under 16.12.7 – Load Balancing With Advanced Classification, multiple classes are created to represent combinations such as:
>
> =====Sample config=======
> {
>   "Dhcp4": {
>     "client-classes": [{
>         "name": "phones",
>         "test": "substring(option[60].hex,0,6) == 'Aastra'"
>     }, {
>         "name": "laptops",
>         "test": "not member('phones')"
>     }, {
>         "name": "phones_server1",
>         "test": "member('phones') and member('HA_server1')"
>     }, {
>         "name": "phones_server2",
>         "test": "member('phones') and member('HA_server2')"
>     }, {
>         "name": "laptops_server1",
>         "test": "member('laptops') and member('HA_server1')"
>     }, {
>         "name": "laptops_server2",
>         "test": "member('laptops') and member('HA_server2')"
>     }],
>
>      "subnet4": [{
>         "id": 1,
>         "subnet": "192.0.3.0/24",
>         "pools": [{
>             "pool": "192.0.3.100 - 192.0.3.125",
>             "client-classes": [ "phones_server1" ]
>         }, {
>             "pool": "192.0.3.126 - 192.0.3.150",
>             "client-classes": [ "laptops_server1" ]
>         }],
>
>         "option-data": [{
>             "name": "routers",
>             "data": "192.0.3.1"
>         }],
>     }]
>   }
> }
> =========================================
>
> This approach works, but it can result in a large number of additional client classes when we have multiple base classes and need different combinations for different subnets/pools.
>
> For example, if we have six classes and need:
>
> Subnet 1 → Class 1 + Class 2 + Class 3
>
> Subnet 2 → Class 2 + Class 4 + Class 6
>
> Subnet 3 → Class 1 + Class 5 + Class 6
>
> We would need to create separate combination classes for each required combination. This can make the configuration large and difficult to maintain.
>
> In ISC DHCP, this can be handled more easily using statements such as:
>
> allow members of "class1";
> allow members of "class2";
>
> and additional classes can be added independently as required.
>
> Can anyone please suggest whether there is an existing Kea mechanism or a recommended approach to handle such class combinations without creating a separate class for each combination?
>
> If not, this is a useful enhancement/feature request for Kea, allowing multiple client classes to be associated with a pool and evaluated independently, similar to the allow members of approach in ISC DHCP.
>
> Thanks in Advance
> Kriashak
>
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org