It might be an idea to see if you can prohibit the other class in each subnet.
Specifically if you can prohibit "RPD" in the subnet where only "RPD_new" should be. This may not work if the device fits both classes, I have never tested this - just an idea. Thanks Sten > On 17 Jul 2024, at 17.25, Xiao, Yu (CCI-Atlanta) via Kea-users > <[email protected]> wrote: > > Hi Bob, > > Yes, I have tested and indeed it is as you suspected. Seems this client-class > configuration has no control over the subnet configuration even it’s there. > > But I think it is a good idea if we can add these restrictions between the > client class and the subnet. Let me check if there’s an existing feature on > this. > > > > Best Regards, > Yu > > > From: Bob Harold <[email protected] <mailto:[email protected]>> > Date: Wednesday, July 17, 2024 at 11:11 AM > To: Kea user's list <[email protected] <mailto:[email protected]>> > Cc: Xiao, Yu (CCI-Atlanta) <[email protected] <mailto:[email protected]>> > Subject: [EXTERNAL] Re: [Kea-users] One question on the subnet configuration > > > On Tue, Jul 16, 2024 at 5:11 PM Xiao, Yu (CCI-Atlanta) via Kea-users > <[email protected] <mailto:[email protected]>> wrote: > Hi experts, > > I configured two client classes for my test RPDs. And I also configured three > subnets for three different RPDs. I found that even in the subnet > configuration, I have correlated the client-class “RPD_new” for that subnet 3 > to use. But in reality, kea just ignored this configuration, and use the > client class “RPD” for all 3 subnets. And because my test RPDs satisfied both > “RPD” and “RPD_new” client classes, and my test RPD used the configurations > in “RPD” instead of “RPD_new”. > > My guess is that the order matters, and it takes the first match. > Your first class matches any client class where the first three characters > are "RPD", so it matches both "RPD" and "RPD_new". > You might try putting the RPD_new class first, so it has a chance of matching > a client before the RDP class matches. > > -- > Bob Harold > > > Why the configuration “client-class” under “subnet6” won’t take effective as > I thought? > > "client-classes": [ > { > "name": "RPD", > "test": "substring(option[17].option[2].hex,0,3) == 'RPD'", > "option-data": [ > { > "space": "vendor-4491", > "name": "syslog-servers", > "code": 34, > "data": "2000:109:20:3100:10:0:252:23", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "time-servers", > "code": 37, > "data": "2000:109:20:3100::37", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "time-offset", > "code": 38, > "data": "0", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "ccap-cores", > "code": 61, > "data": "2000:109:20:3100:10:0:254:34", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "vendor-opts", > "code": 17, > "always-send": true > } > ] > }, > { > "name": "RPD_new", > "test": "substring(option[1].hex,0,9) == 0x000400001010D22BC9", > "option-data": [ > { > "space": "vendor-4491", > "name": "syslog-servers", > "code": 34, > "data": "2000:109:20:3100:10:0:252:1", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "time-servers", > "code": 37, > "data": "2000:109:20:3100::9", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "time-offset", > "code": 38, > "data": "0", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "ccap-cores", > "code": 61, > "data": "2000:109:20:3100:0:0:0:4", > "always-send": true > }, > { > "space": "vendor-4491", > "name": "vendor-opts", > "code": 17, > "always-send": true > } > ] > } > ], > # Finally, we list the subnets from which we will be leasing addresses. > "subnet6": [ > { > "id": 1, > "subnet": "2000:109:20:3110::1/64", > "pools": [ > { > "pool": "2000:109:20:3110::1-2000:109:20:3110::10" > } > ], > "relay": { > "ip-addresses": [ "2000:109:20:3110::1" ] > }, > "interface": "ens18", > "client-class": "RPD", > "allocator": "iterative" > }, > { > "id": 2, > "subnet": "2000:109:20:5320::1/64", > "pools": [ > { > "pool": "2000:109:20: 5320::1-2000:109:20: 5320::10" > } > ], > "relay": { > "ip-addresses": [ "2000:109:20: 5320::1" ] > }, > "interface": "ens18", > "client-class": "RPD", > "allocator": "iterative" > }, > { > "id": 3, > "subnet": "2000:109:20:2110::1/64", > "pools": [ > { > "pool": "2000:109:20: 2110::1-2000:109:20: 2110::9" > } > ], > "relay": { > "ip-addresses": [ "2000:109:20: 2110::1" ] > }, > "interface": "ens18", > "client-class": "RPD_new", > "allocator": "iterative" > } > ], > > > > Best Regards, > Yu > > -- > 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] <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > https://lists.isc.org/mailman/listinfo/kea-users
signature.asc
Description: Message signed with OpenPGP
-- 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
