Hello Isaac,
Assuming you really need to set these options per subnet, and cannot
relocate them to the global client class, then you might have to
combine this new option with some more traditional trickery. Perhaps
additional-client-class
(https://kea.readthedocs.io/en/kea-2.7.5/arm/dhcp4-srv.html#additional-classification)
might help? Your goal would be to isolate these so that you only set
one per "option-data": { } so they don't overwrite each other. You
can use multiple additional client classes in each subnet to
accomplish this.
Thank you,
Darren Ankney
On Tue, Jan 14, 2025 at 3:47 PM Isaac Brummel <ibrum...@xes-inc.com> wrote:
>
> Hi Darren,
>
> Thanks you for the response. Unfortunately this did not work, still no
> options are sent if both are defined. It also would not scale above two
> entries which is problematic with multiple PXE client versions. What I'm
> trying to replicate is the "if" statements in the now old isc-dhcp server:
>
> if substring(option vendor-class-identifier, 0, 20) =
> "PXEClient:Arch:00006" {
> filename "i386-efi/ipxe.efi";
> }
>
> if substring(option vendor-class-identifier, 0, 20) =
> "PXEClient:Arch:00002" {
> filename "i386-efi/ipxe.efi";
> }
>
> if substring(option vendor-class-identifier, 0, 20) =
> "PXEClient:Arch:00007" {
> filename "ipxe.efi";
> }
>
> Do you know if this is possible with Kea at this moment? Or through a hook?
>
> Thanks,
>
> Isaac
> ________________________________
> From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Darren Ankney
> <darren.ank...@gmail.com>
> Sent: Tuesday, January 14, 2025 2:24 PM
> To: Kea user's list <kea-users@lists.isc.org>
> Subject: [External] - Re: [Kea-users] Option Class-Tagging Configuration
>
> Hi Isaac,
>
> I have not yet experimented with the new "option class-tagging"
> feature, but I can guess that what is happening to you here is that
> the same name in the second option is causing the first option's data
> to be overwritten. Perhaps try using the code for one of them instead
> of the name (not 100% sure that is a valid workaround). The code for
> 'boot-file-name' seems to be 67. So replace "name": "boot-file-name"
> with "code": 67 in one of them perhaps?
>
> Thank you,
> Darren Ankney
>
> On Tue, Jan 14, 2025 at 2:20 PM Isaac Brummel <ibrum...@xes-inc.com> wrote:
> >
> > Hello,
> >
> > I'm trying to use the new "option class-tagging" feature from 2.7.4 to
> > dynamically set boot-file-name to a different value for every subnet. I'm
> > running into an issue where if I have two entries in the "option-data" one
> > for legacy ipxe and one for EFI ipxe none get set, see the below config for
> > an example. If I only set one such as only having the "ipxe_legacy" client
> > class then it correctly sends the boot-file-name. Is there something I'm
> > missing, or a better way to handle this?
> >
> > "client-classes": [
> > {
> > "name": "ipxe_legacy",
> > "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'"
> > },
> > {
> > "name": "ipxe_efi",
> > "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00007'"
> > }
> > ],
> > "subnet4": [
> > {
> > "id": 1,
> > "subnet": "10.10.10.0/24",
> > "calculate-tee-times": true,
> > "valid-lifetime": 60,
> > "ddns-qualifying-suffix": "kea-dev.com",
> > "client-classes": [],
> > "option-data": [],
> > "pools": [
> > {
> > "pool": "10.10.10.100 - 10.10.10.150",
> > "option-data": [
> > {
> > "client-classes": [
> > "ipxe_legacy"
> > ],
> > "name": "boot-file-name",
> > "data": "ipxe/netboot.xyz.kpxe"
> > },
> > {
> > "client-classes": [
> > "ipxe_efi"
> > ],
> > "name": "boot-file-name",
> > "data": "ipxe/netboot.xyz.efi"
> > },
> > {
> > "name": "routers",
> > "data": "10.10.10.1"
> > },
> > {
> > "name": "domain-name-servers",
> > "data": "10.10.10.1, 10.10.10.2"
> > }
> > ]
> > }
> > ]
> > }
> > ]
> >
> > Thanks,
> >
> > Isaac Brummel
> > System Administrator
> > Extreme Engineering Solutions
> > --
> > 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@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-users
> --
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
> --
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
