Hi Isaac,

The part that is missing is Required Classification
(https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#required-classification).
Mark the classes "only-if-required" and then use the
"require-client-classes" list in the shared-network(s), subnet(s) or
pool(s) to prompt evaluation of class membership.  This will also
prevent the clients from being members of the classes if not in a
desired shared-network / subnet / pool

On Mon, Dec 9, 2024 at 11:19 AM Isaac Brummel <ibrum...@xes-inc.com> wrote:
>
> Hi Darren,
>
> Thanks for the information. The option class-tagging looks like a great 
> feature, unfortunately I need to use the stable release for now. I'm trying 
> to recreate what you explained in your first paragraph and I'm having trouble 
> finding a way to make it work. I have generic client classes setup for legacy 
> and efi:
>
> "client-classes": [
>     {
>         "name": "ipxe_legacy",
>         "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'",
>         "boot-file-name": "youshallnotpass"
>     },
>     {
>         "name": "ipxe_efi",
>         "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00007'",
>         "boot-file-name": "youshallnotpass"
>     },
> ],
>
>
> Then I'm using the flex option hook to dynamically set the boot-file-name 
> option. This is the part where I'm struggling. I want to restrict this to a 
> specific subnet so I created a custom option but I later realized this hook 
> only works for the query packet and not the outgoing packet.
>
> {
>     "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_flex_option.so",
>     "parameters": {
>         "options": [
>             {
>                 "name": "boot-file-name",
>                 "add": "ifelse((option[244].text == '1') and 
> (member('ipxe_legacy')),'ipxe/netboot.xyz.kpxe','')"
>             },
>             {
>                 "name": "boot-file-name",
>                 "add": "ifelse((option[244].text == '1') and 
> (member('ipxe_efi')),'ipxe/netboot.xyz.efi','')"
>             }
>         ]
>     }
> }
>
>
> Subnet:
>
> "subnet4": [
>     {
>         "id": 1,
>         "subnet": "10.10.10.0/24",
>         "calculate-tee-times": true,
>         "valid-lifetime": 60,
>         "ddns-qualifying-suffix": "kea-dev.com",
>         "option-data": [
>             {
>                 "name": "subnet-id",
>                 "code": 244,
>                 "data": "1",
>                 "always-send": true
>             }
>         ],
>     }
> ]
>
>
> Do you have any ideas to be able to dynamically set the boot-file-name to a 
> different value per-subnet?
>
> Thanks,
> Isaac
> ________________________________
> From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Darren Ankney 
> <darren.ank...@gmail.com>
> Sent: Thursday, December 5, 2024 2:35 PM
> To: Kea user's list <kea-users@lists.isc.org>
> Subject: [External] - Re: [Kea-users] Client Class for a Specific Subnet
>
> Hi Isaac,
>
> Your choices are limited at the moment.  You can use the flex option
> hook to replace option content based on class membership as described
> in the hook documentation:
> https://kea.readthedocs.io/en/kea-2.6.1/arm/hooks.html#libdhcp-flex-option-so-flexible-option-actions-for-option-value-settings
> There is also this KB article that shows this in action:
> https://kb.isc.org/docs/redefining-standard-options though the subject
> of the article is actually about sending different content in an
> option than it is supposed to carry.
>
> In this case, you could set the "else" portion of your ISC DHCP
> configuration as an option in the corresponding subnet in the Kea
> configuration.  Make the client a member of the class as you've shown.
> Then use the flex option hook to replace the option content if the
> client is a member of "ipxe_legacy_netbootxyz".
>
> In the development version 2.7.4, there is the new method called
> "Option Class-Tagging":
> https://kea.readthedocs.io/en/kea-2.7.4/arm/classify.html#option-class-tagging
> that will allow you to tag any option to be sent based on class
> membership.  This is an effective replacement for the "if"
> functionality in ISC DHCP.  This will first appear in a stable version
> in 3.0.0.
>
> Thank you,
> Darren Ankney
>
> On Wed, Dec 4, 2024 at 3:48 PM Isaac Brummel <ibrum...@xes-inc.com> wrote:
> >
> > Hello,
> > I'm in the process of migrating an ISC DHCP server to Kea. I'm trying to 
> > re-create a feature that we use in the ISC DHCP config to set a boot file 
> > name if a specific vendor-class-identifier is met. The ISC DHCP 
> > share-network looks like:
> >
> > shared-network FOOBAR {
> >     allow bootp;
> >
> >     subnet 10.10.10.0 netmask 255.255.255.0 {
> >
> >         # default PXE boot
> >         if substring(option vendor-class-identifier, 0, 20) = 
> > "PXEClient:Arch:00000" {
> >             filename "ipxe/netboot.xyz.kpxe";
> >         } else {
> >             filename "ipxe/netboot.xyz.efi";
> >         }
> >
> >
> > For Kea I can create the client class just fine, but how can I restrict 
> > these client classes to apply only to this subnet? I have other subnets 
> > that use a different boot file name. It doesn't seem like using 
> > "client-class" in the "subnet4" config would work as that would require a 
> > client to meet the classification, when that's not necessary.
> >
> > "client-classes": [
> >     {
> >         "name": "ipxe_legacy_netbootxyz",
> >         "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'",
> >         "next-server": "10.10.10.5",
> >         "boot-file-name": "ipxe/netboot.xyz.kpxe"
> >     },
> >     {
> >         "name": "ipxe_efi_netbootxyz",
> >         "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00007'",
> >         "next-server": "10.10.10.5",
> >         "boot-file-name": "ipxe/netboot.xyz.efi"
> >     }
> > ],
> >
> >
> > 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

Reply via email to