[Kea-users] How to use ifelse in the client-class definition

[perl-list]

Perhaps you could set the desired options within the class instead of in the subnet specification?  You could have a class for PXEClient and a class for everyone else?   I'm not sure the below is correct but maybe on the right track?

"Dhcp4": {
    "client-classes": [
        {
            "name": "PXEClient",
            "test": "option[60].hex == 'PXEClient'",
            "option-data": [
                {
                     ...
                }
            ]
        },
        {
            "name": "notPXEClient",
            "test": "not(option[60].hex == 'PXEClient')",
            "option-data": [
                {
                     ...
                }
            ]
        }
    ],
    ...
}

----- Original Message -----
> From: "Veronique Lefebure" <veronique.lefebure at cern.ch>
> To: "kea-users" <Kea-users at lists.isc.org>
> Sent: Wednesday, July 21, 2021 4:11:20 AM
> Subject: [Kea-users] How to use ifelse in the client-class definition

> Hi,

> Now that I got the confirmation that we cannot use ifelse in the host
> reservation, let me give more details about what we are looking for at the
> level of the client-class definition.

> (this refers to [
> https://lists.isc.org/mailman/htdig/kea-users/2021-July/003149.html |
> [Kea-users]
>         Example for ifelse in host reservation or class (isc.org) ] )

> We have clients of 2 types: type1 and type2.

> Both types need to get, from the DHCP server, a different IP for "next-server"
> and for "Option 54": IP1 for type1, IP2 for type2.

> But those options ("next-server" and "Option 54") should be sent to the clients
> ONLY when the clients send "PXEClient" in Vendor-Class Option 60 of their
> DHCPDISCOVER or DHCPREQUEST messages.

> How can we reach that, without having to make a test, in the class definition,
> on the mac address of the clients ?

> Implementing such a test on the mac addresses allows to reach the desired
> behaviour, but then we have several 100000 mac addresses to list in the test.
> This makes the configuration file 1) huge 2) unreadable 3) unacceptably slow to
> be validated, especially for ipv6.

> Also we cannot set the client-class in the host reservation because, in that
> case, the test is not evaluated (this is what we have observed), and
> consequently the options "next-server" and "option 54" are provided to the
> client *even* when DHCPDISCOVER or DHCPREQUEST messages do NOT contain the
> "PXEClient" string in Vendor-Class Option 60.

> Thanks for your help.

> Veronique

> _______________________________________________
> 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 mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users