Re: [Kea-users] Missing features from dhcp-eval
Hi Vladimir, You are correct, I believe. Kea flex-option hook cannot overwrite siaddr (next-server) since it isn't a DHCP option. Do you need next-server for other clients? You can set it to an empty string like so: "next-server": "", at the global or subnet level. See here for further information: https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#next-server-siaddr Thank you, Darren Ankney On Sun, Oct 15, 2023 at 4:41 PM Vladimir Nikolic wrote: > > Thanks Darren. > > I'm trying to set up custom next-server and boot-file-name by setting up > options 66 in 67 through the flex option hook, everything based on > relaying router ip. > I can see that KEA server sends both these options properly. > But PXE (VMware) client properly picks the filename (option 67) but > wrongly picks the SIADDR ip instead of TFTP server name (option 66). > I presume flex option hook can't rewrite the next-server (SIADDR) value? > > Regards, > Vladimir > > On 2023-10-15 21:35, Darren Ankney wrote: > > Hi Vladimir, > > > > You should be able to do something like this with the flex option > > hook: > > https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#libdhcp-flex-option-so-flexible-option-actions-for-option-value-settings > > > > Just need to find out what can be tested for. Is the traffic relayed? > > Will there be a specific giaddr for the client in the subnet that you > > want to set the custom options? You can test for a specific relay > > agent IP (giaddr) with pkt4.giaddr == 192.0.2.1, for example. You can > > test if a client is a member of the PXEClients class with > > member('PXEClients'). > > > > Hope this helps! > > > > Thank you, > > > > Darren Ankney > > > > On Sun, Oct 15, 2023 at 11:40 AM Vladimir Nikolic > > wrote: > >> > >> Let's say I want to send custom next-server and filename to PXE > >> clients, > >> depending on subnet in which they are located. > >> > >> In dhcpd, I define a new option, e.g.: > >> option something-new code 250 = string; > >> > >> Then I set its value in some of the subnets: > >> subnet xyz { > >> option something-new "my-value"; > >> ... > >> > >> And within a class definition, I can set up options (e.g. next-server > >> and filename) based on the value of something-new option (defined > >> within > >> subnets): > >> class "PXEClients" { > >> match if substring(option vendor-class-identifier, 0, 9) = > >> "PXEClient"; > >> if config-option something-new = "my-value" > >> next-server my-new-server; > >> filename "my-new-filename"; > >> } else { > >> next-server my-old-server; > >> filename "my-old-filename"; > >> } > >> ... > >> > >> So it's one class with different next-server/filename options, based > >> on > >> the subnet in which clients live. > >> > >> From what I've seen so far, you can't do something similar in KEA. > >> You have to define next-server and filename in every of those subnets, > >> and that will apply to all the clients in that subnet (not just to > >> those > >> belonging to PXEClients class). > >> > >> Thanks > >> > >> > >> On 2023-10-15 17:18, Darren Ankney wrote: > >> > Hi, > >> > > >> > I'm not entirely sure what you are asking here. Do you mean that you > >> > need to add a client to a class based on what subnet was selected? > >> > > >> > Thank you, > >> > > >> > Darren Ankney > >> > > >> > On Fri, Oct 13, 2023 at 12:36 PM Vladimir Nikolic via Kea-users > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> We are struggling with the migration from DHCPD to KEA. > >> >> Is there any easy alternative to this dhcp-eval feature: > >> >> > >> >> config-option option-name > >> >> The config-option operator returns the value for the specified > >> >> option that the DHCP client or server has been configured to send. > >> >> > >> >> In DHCPD, we define an option, and then set it up on particular > >> >> subnets. > >> >> It can then be used during class evaluation, by config-option feature. > >> >> In that way, different classes (with e.g. different next-server and/or > >> >> filename defined) can be assigned to similar clients, just based on > >> >> the > >> >> option value set in a subnet definition. > >> >> > >> >> From what we've seen so far, something like that is not possible with > >> >> KEA. > >> >> Looks like we'll have to find an alternative solution. > >> >> > >> >> Thanks > >> >> -- > >> >> 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
Re: [Kea-users] Missing features from dhcp-eval
Thanks Darren. I'm trying to set up custom next-server and boot-file-name by setting up options 66 in 67 through the flex option hook, everything based on relaying router ip. I can see that KEA server sends both these options properly. But PXE (VMware) client properly picks the filename (option 67) but wrongly picks the SIADDR ip instead of TFTP server name (option 66). I presume flex option hook can't rewrite the next-server (SIADDR) value? Regards, Vladimir On 2023-10-15 21:35, Darren Ankney wrote: Hi Vladimir, You should be able to do something like this with the flex option hook: https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#libdhcp-flex-option-so-flexible-option-actions-for-option-value-settings Just need to find out what can be tested for. Is the traffic relayed? Will there be a specific giaddr for the client in the subnet that you want to set the custom options? You can test for a specific relay agent IP (giaddr) with pkt4.giaddr == 192.0.2.1, for example. You can test if a client is a member of the PXEClients class with member('PXEClients'). Hope this helps! Thank you, Darren Ankney On Sun, Oct 15, 2023 at 11:40 AM Vladimir Nikolic wrote: Let's say I want to send custom next-server and filename to PXE clients, depending on subnet in which they are located. In dhcpd, I define a new option, e.g.: option something-new code 250 = string; Then I set its value in some of the subnets: subnet xyz { option something-new "my-value"; ... And within a class definition, I can set up options (e.g. next-server and filename) based on the value of something-new option (defined within subnets): class "PXEClients" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; if config-option something-new = "my-value" next-server my-new-server; filename "my-new-filename"; } else { next-server my-old-server; filename "my-old-filename"; } ... So it's one class with different next-server/filename options, based on the subnet in which clients live. From what I've seen so far, you can't do something similar in KEA. You have to define next-server and filename in every of those subnets, and that will apply to all the clients in that subnet (not just to those belonging to PXEClients class). Thanks On 2023-10-15 17:18, Darren Ankney wrote: > Hi, > > I'm not entirely sure what you are asking here. Do you mean that you > need to add a client to a class based on what subnet was selected? > > Thank you, > > Darren Ankney > > On Fri, Oct 13, 2023 at 12:36 PM Vladimir Nikolic via Kea-users > wrote: >> >> Hi, >> >> We are struggling with the migration from DHCPD to KEA. >> Is there any easy alternative to this dhcp-eval feature: >> >> config-option option-name >> The config-option operator returns the value for the specified >> option that the DHCP client or server has been configured to send. >> >> In DHCPD, we define an option, and then set it up on particular >> subnets. >> It can then be used during class evaluation, by config-option feature. >> In that way, different classes (with e.g. different next-server and/or >> filename defined) can be assigned to similar clients, just based on >> the >> option value set in a subnet definition. >> >> From what we've seen so far, something like that is not possible with >> KEA. >> Looks like we'll have to find an alternative solution. >> >> Thanks >> -- >> 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
Re: [Kea-users] Missing features from dhcp-eval
Hi Vladimir, You should be able to do something like this with the flex option hook: https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#libdhcp-flex-option-so-flexible-option-actions-for-option-value-settings Just need to find out what can be tested for. Is the traffic relayed? Will there be a specific giaddr for the client in the subnet that you want to set the custom options? You can test for a specific relay agent IP (giaddr) with pkt4.giaddr == 192.0.2.1, for example. You can test if a client is a member of the PXEClients class with member('PXEClients'). Hope this helps! Thank you, Darren Ankney On Sun, Oct 15, 2023 at 11:40 AM Vladimir Nikolic wrote: > > Let's say I want to send custom next-server and filename to PXE clients, > depending on subnet in which they are located. > > In dhcpd, I define a new option, e.g.: > option something-new code 250 = string; > > Then I set its value in some of the subnets: > subnet xyz { > option something-new "my-value"; > ... > > And within a class definition, I can set up options (e.g. next-server > and filename) based on the value of something-new option (defined within > subnets): > class "PXEClients" { > match if substring(option vendor-class-identifier, 0, 9) = > "PXEClient"; > if config-option something-new = "my-value" > next-server my-new-server; > filename "my-new-filename"; > } else { > next-server my-old-server; > filename "my-old-filename"; > } > ... > > So it's one class with different next-server/filename options, based on > the subnet in which clients live. > > From what I've seen so far, you can't do something similar in KEA. > You have to define next-server and filename in every of those subnets, > and that will apply to all the clients in that subnet (not just to those > belonging to PXEClients class). > > Thanks > > > On 2023-10-15 17:18, Darren Ankney wrote: > > Hi, > > > > I'm not entirely sure what you are asking here. Do you mean that you > > need to add a client to a class based on what subnet was selected? > > > > Thank you, > > > > Darren Ankney > > > > On Fri, Oct 13, 2023 at 12:36 PM Vladimir Nikolic via Kea-users > > wrote: > >> > >> Hi, > >> > >> We are struggling with the migration from DHCPD to KEA. > >> Is there any easy alternative to this dhcp-eval feature: > >> > >> config-option option-name > >> The config-option operator returns the value for the specified > >> option that the DHCP client or server has been configured to send. > >> > >> In DHCPD, we define an option, and then set it up on particular > >> subnets. > >> It can then be used during class evaluation, by config-option feature. > >> In that way, different classes (with e.g. different next-server and/or > >> filename defined) can be assigned to similar clients, just based on > >> the > >> option value set in a subnet definition. > >> > >> From what we've seen so far, something like that is not possible with > >> KEA. > >> Looks like we'll have to find an alternative solution. > >> > >> Thanks > >> -- > >> 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
Re: [Kea-users] Missing features from dhcp-eval
Let's say I want to send custom next-server and filename to PXE clients, depending on subnet in which they are located. In dhcpd, I define a new option, e.g.: option something-new code 250 = string; Then I set its value in some of the subnets: subnet xyz { option something-new "my-value"; ... And within a class definition, I can set up options (e.g. next-server and filename) based on the value of something-new option (defined within subnets): class "PXEClients" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; if config-option something-new = "my-value" next-server my-new-server; filename "my-new-filename"; } else { next-server my-old-server; filename "my-old-filename"; } ... So it's one class with different next-server/filename options, based on the subnet in which clients live. From what I've seen so far, you can't do something similar in KEA. You have to define next-server and filename in every of those subnets, and that will apply to all the clients in that subnet (not just to those belonging to PXEClients class). Thanks On 2023-10-15 17:18, Darren Ankney wrote: Hi, I'm not entirely sure what you are asking here. Do you mean that you need to add a client to a class based on what subnet was selected? Thank you, Darren Ankney On Fri, Oct 13, 2023 at 12:36 PM Vladimir Nikolic via Kea-users wrote: Hi, We are struggling with the migration from DHCPD to KEA. Is there any easy alternative to this dhcp-eval feature: config-option option-name The config-option operator returns the value for the specified option that the DHCP client or server has been configured to send. In DHCPD, we define an option, and then set it up on particular subnets. It can then be used during class evaluation, by config-option feature. In that way, different classes (with e.g. different next-server and/or filename defined) can be assigned to similar clients, just based on the option value set in a subnet definition. From what we've seen so far, something like that is not possible with KEA. Looks like we'll have to find an alternative solution. Thanks -- 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
Re: [Kea-users] Missing features from dhcp-eval
Hi, I'm not entirely sure what you are asking here. Do you mean that you need to add a client to a class based on what subnet was selected? Thank you, Darren Ankney On Fri, Oct 13, 2023 at 12:36 PM Vladimir Nikolic via Kea-users wrote: > > Hi, > > We are struggling with the migration from DHCPD to KEA. > Is there any easy alternative to this dhcp-eval feature: > > config-option option-name > The config-option operator returns the value for the specified > option that the DHCP client or server has been configured to send. > > In DHCPD, we define an option, and then set it up on particular subnets. > It can then be used during class evaluation, by config-option feature. > In that way, different classes (with e.g. different next-server and/or > filename defined) can be assigned to similar clients, just based on the > option value set in a subnet definition. > > From what we've seen so far, something like that is not possible with > KEA. > Looks like we'll have to find an alternative solution. > > Thanks > -- > 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