Don't do the only name parameter. But I find it good practice to always classify clients in some meaningful way, client classes provide this.
On Mon, May 6, 2024 at 2:12 PM David Farje <davidabelfa...@gmail.com> wrote: > You can use client classes. You can create a client class with only the > "name" parameter and associate the subnet with the client class. That way > the subnet object has a descriptive string you can use to reference. See > the following > > > https://kea.readthedocs.io/en/kea-2.2.0/arm/classify.html#configuring-subnets-with-class-information > > Best Regards, > David > > On Mon, May 6, 2024 at 12:47 PM Xiao, Yu (CCI-Atlanta) via Kea-users < > kea-users@lists.isc.org> wrote: > >> I agree, So if we have string name for those subnets, we can use our >> tools to manipulate those information much easier and people who use them >> will understand easier. It’s better we have another non-key ID as Marek >> suggested. >> >> >> >> >> >> >> >> Best Regards, >> >> Yu >> >> >> >> >> >> *From: *Kea-users <kea-users-boun...@lists.isc.org> on behalf of Marek >> Hajduczenia <mxhajducze...@gmail.com> >> *Date: *Monday, May 6, 2024 at 12:31 PM >> *To: *'Kea user's list' <kea-users@lists.isc.org> >> *Subject: *[EXTERNAL] Re: [Kea-users] Two questions regarding to kea >> subnet configuration >> >> I understand the scaling factor and just throwing it out there – it would >> help to have perhaps non-key ID to search for, say “name” or something in >> the line of, making it a more unique value to search for. >> >> >> >> *From:* Kea-users <kea-users-boun...@lists.isc.org> * On Behalf Of *David >> Farje >> *Sent:* Monday, May 6, 2024 10:13 AM >> *To:* Kea user's list <kea-users@lists.isc.org> >> *Subject:* Re: [Kea-users] Two questions regarding to kea subnet >> configuration >> >> >> >> Definitely string ID is nicer to manage. The thing is, Kea seems to be >> designed to support a large number of subnets and DB backend. In this case >> it is better to use an integer because I don't think you want a string >> based primary key on a DB table with millions of entries. >> >> >> >> Regarding your second question I believe you may find some answers here: >> >> >> https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#address-allocation-strategies-in-dhcpv4 >> <https://urldefense.com/v3/__https:/kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html*address-allocation-strategies-in-dhcpv4__;Iw!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuIsTwbvG$> >> >> >> >> Regards, >> >> David >> >> >> >> >> >> On Mon, May 6, 2024 at 9:21 AM <mxhajducze...@gmail.com> wrote: >> >> I can confirm – the lack of support for string ID is pretty annoying >> right now, and forces me to create ranges for specific applications, which >> will not scale well in production. >> >> >> >> On the second one, I observed that it goes numerically from the bottom of >> the pool range up, so ::2, ::3, etc. In ISC, it seems to have been random >> selection from the pool, with attempt made to populate all stanzas. Kea >> seems to prefer numerically incrementing assignment, which is pretty bad >> for security purposes (if a user knows it, they can pretty much guess >> previous assignments). I preferred personally the old ISC way of doing >> things. >> >> >> >> Marek >> >> >> >> *From:* Kea-users <kea-users-boun...@lists.isc.org> *On Behalf Of *Xiao, >> Yu (CCI-Atlanta) via Kea-users >> *Sent:* Monday, May 6, 2024 6:10 AM >> *To:* Kea user's list <kea-users@lists.isc.org> >> *Cc:* Xiao, Yu (CCI-Atlanta) <yu.x...@cox.com> >> *Subject:* [Kea-users] Two questions regarding to kea subnet >> configuration >> >> >> >> Greetings, >> >> >> >> I have two questions related to the kea design. First, seems currently we >> can only assign numeric IDs to subnets, but for subnet management, it’s >> more convenient to use a string, is it possible to add this feature? >> Second, how kea design to distribute the ip addresses inside of the subnet >> esp ipv6 subnet? Is it totally random? Thank you. >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> Yu >> >> >> >> -- >> ISC funds the development of this software with paid support >> subscriptions. Contact us at https://www.isc.org/contact/ >> <https://urldefense.com/v3/__https:/www.isc.org/contact/__;!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuGFCeiXp$> >> for more information. >> >> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users >> <https://urldefense.com/v3/__https:/lists.isc.org/mailman/listinfo/kea-users__;!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuIWs4xfY$> >> . >> >> Kea-users mailing list >> Kea-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/kea-users >> <https://urldefense.com/v3/__https:/lists.isc.org/mailman/listinfo/kea-users__;!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuIWs4xfY$> >> >> -- >> 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
