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
