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 [Kea-users] Example for ifelse in host reservation or
class (isc.org)
<https://lists.isc.org/mailman/htdig/kea-users/2021-July/003149.html> )
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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
