Hi Darren,
Thanks for the response,
"client-class": [
"allow-one",
"HA_dhcp1"
]
--> I tried this but it gives me a syntax error
Syntax check failed with: kea-dhcp4.conf:90.29: syntax error, unexpected [,
expecting constant string
so in my case where subnets have multiple client class combinations, then I
need to create multiple client class definitions. I have only 5 class
definitions overall when I use ISC DHCP now it may go more than 10+, It is
making bit complex when compared to the ISC-DHCP flow
Kraishak
On Fri, May 5, 2023 at 8:38 PM Darren Ankney <darren.ank...@gmail.com>
wrote:
> Hello Kraishak,
>
> I don't think you can have multiple client classes specified at the
> pool level. If you could, it would be done something like this:
>
> "client-class": [
> "allow-one",
> "HA_dhcp1"
> ]
>
> You will probably need to create a class for each that contains the
> members you want in that pool as you show in the second example. Its
> made easier by the "member" and "not member" syntax.
>
> Thank you,
>
> Darren Ankney
>
> On Fri, May 5, 2023 at 9:25 AM Kraishak Mahtha <kraishak....@gmail.com>
> wrote:
> >
> > Hi all,
> >
> > I have a use case where one of the client class definitions should be
> applied for all subnets and my configuration has also been in the HA, so
> basically I need to assign two classes or sometimes I need to add more
> class statements to a subnet.
> > So I tried configuring it like this and it didn't give me any syntax
> error
> > Code snippet 1:
> > ===============
> > "subnet4": [{
> > "subnet": "4.0.0.0/24",
> > "valid-lifetime": 86400,
> > "option-data": [
> > {
> > "data": "test.com",
> > "name": "domain-name"
> > },
> > {
> > "data": "255.255.255.0",
> > "name": "subnet-mask"
> > },
> > {
> > "data": "4.0.0.1",
> > "name": "routers"
> > }
> > ],
> > "pools": [{
> > "client-class": "allow-one,HA_dhcp1",
> > "pool": "4.0.0.2-4.0.0.6"
> > }],
> > "id": 1
> > }],
> > "client-classes": [
> > {"name": "deny-one"},
> > {
> > "test": "(not(member('deny-one')))",
> > "name": "allow-one"
> > }
> > ]
> >
> > Basically, in the deny class statement, I will be adding my
> black-listing clients. I am able to start the kea-dhcp service with the
> above config file and the service is up and running but logically it seems
> to be wrong and I am facing issues while the lease flow,
> > Later when I searched more for multiple class statements then I found
> like
> > Code snippet 2:
> > ===============
> > "Dhcp4": {
> > "client-classes": [{
> > "name": "phones",
> > "test": "substring(option[60].hex,0,6) == 'Aastra'",
> > }, {
> > "name": "laptops",
> > "test": "not member('phones')"
> > }, {
> > "name": "phones_server1",
> > "test": "member('phones') and member('HA_server1')"
> > }, {
> > "name": "phones_server2",
> > "test": "member('phones') and member('HA_server2')"
> > }, {
> > "name": "laptops_server1",
> > "test": "member('laptops') and member('HA_server1')"
> > }, {
> > "name": "laptops_server2",
> > "test": "member('laptops') and member('HA_server2')"
> > }],
> > Where we need to create one more class definition combined with the
> existing class,
> >
> > I want to know if code snippet 2 is the only way of dealing with the
> multiple client classes, I think code snippet 1 is also another way of
> dealing with the client classes because it is not giving any syntax error
> when I start kea-dhcp(Or I could be wrong to...)
> >
> > The problem is I have a use case where I have 5-6 client classes for
> some subnets and among these I will be using 2,3,4 for one subnet and 1,4,5
> for another subnet likewise If I follow the second way of dealing with the
> multiple client classes the configuration would be much complex.
> > In ISC-DHCP we just need one statement for the client class like
> > allow members of client1;
> > deny member of client2;
> > ....some thing like this
> >
> > If anyone has familiarity with these concepts, much appreciate for your
> guidance or suggestion
> >
> > Thanks in advance
> > Kraishak
> >
> >
> >
> >
> > --
> > 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
