Re: [Kea-users] Two questions regarding to kea subnet configuration
It was actually IPv6, so: https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp6-srv.html#allocation-strategies-in-dhcpv6 - On May 6, 2024, at 12:12 PM, David Farje wrote: > 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://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#address-allocation-strategies-in-dhcpv4 > ] > Regards, > David > On Mon, May 6, 2024 at 9:21 AM < [ mailto:mxhajducze...@gmail.com | > 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 < [ mailto:kea-users-boun...@lists.isc.org | >> 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 < [ mailto:kea-users@lists.isc.org | >> kea-users@lists.isc.org >> ] > >> Cc: Xiao, Yu (CCI-Atlanta) < [ mailto:yu.x...@cox.com | 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://www.isc.org/contact/ ] >> for more information. >> To unsubscribe visit [ https://lists.isc.org/mailman/listinfo/kea-users | >> https://lists.isc.org/mailman/listinfo/kea-users ] . >> Kea-users mailing list >> [ mailto:Kea-users@lists.isc.org | Kea-users@lists.isc.org ] >> [ https://lists.isc.org/mailman/listinfo/kea-users | >> 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 -- Dan Geist dan(@)polter.net http://www.polter.net (404)786-6206 -- 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
Re: [Kea-users] Planning some experimentation with HA using ECMP
Brendan, we've nothing special with the use of ECMP as it's just the forwarding decision logic on the spine routers of our datacenter stack. The equal routes are all still inserted there by BGP announcements from the service nodes...I think we have a VERY similar setup. Based on what you need to do to HAVE formal HA mechanisms in place, our thinking is just to avoid it altogether (and let potential conflicts on lease reservations work themselves out with blocking calls to a config database). Hopefully the potential pitfall of having more than one node "bound" to a virtual service IP will be mitigated by nodes not being aware of each others' configurations. We'll keep the list updated with progress. Dan - On Apr 30, 2024, at 9:41 AM, Brendan Kearney wrote: > On 4/30/24 9:18 AM, Dan Geist wrote: >> Thanks Vicky. >> Facebook's dhcplb is an option, but it also solves problems that we don't >> have >> (imbalance of DHCP messaging and need for staged deployments). It also >> requires >> more infra (either physical or virtual) and a slightly greater network >> complexity which differs from what we already support in other services. I'm >> trying to stick with the "just because you have a hammer, you should still >> try >> to use a screwdriver on screws" philosophy :) >> I suppose the WAY in which the traffic is balanced is ultimately a wash, >> though. >> Either way, we'd need Kea instances in a horizontal N-number farm with >> mostly-identical behaviors (regardless of if they listen for the virtual IP >> or >> if it's housed one hop upstream). Ideally, having as little state as possible >> (or as little state that DIFFERS between hosts) is an important aspect. >> Performance tuning, strategy for maintaining the database backend >> (monolithic vs >> multiple replicating instances) and so forth will be important, but is there >> anything inherent about Kea itself that will break this conceptually (unique >> metadata payload in messaging that will break on DHCP refresh to a different >> node or something along those lines)? >> Thanks >> Dan >> - On Apr 30, 2024, at 8:39 AM, Victoria Risk [ mailto:vi...@isc.org | >> ] wrote: >>>> On Apr 29, 2024, at 6:16 PM, Dan Geist [ mailto:d...@polter.net | >>>> ] wrote: >>>> Hi. I have an environment where many of the network services (DNS, NTP, >>>> ToD, >>>> etc.) provide scaling, fault tolerance, and load sharing via ECMP (in >>>> front of >>>> the service) and BGP. Each (of the 2 or more) service node(s) monitors the >>>> status of that service and announces/pulls BGP announcements from the >>>> upstream >>>> router pair. This works really well for protocols with simple >>>> request/response >>>> transactions. >>>> I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, >>>> the >>>> same "virtual service IP" would be configured on each of several Kea nodes >>>> (in >>>> addition to the real link IPs) and they would announce these to the next >>>> hop >>>> (as above). My thinking is that if there is a common configuration and >>>> lease >>>> backend to these multiple nodes, then this can be a way to provide HA >>>> services >>>> (and scaling) to a very large number of devices. My only concern is how the >>>> multi-step transaction will be handled. >>>> Before I spend the time to mock this up, has anyone else tried ECMP load >>>> distribution with DHCP, specifically on Kea, and are there any "gotchas" >>>> to be >>>> aware of? >>> You might want to check out the DHCP Load Balancer from Facebook: [ >>> https://github.com/facebookincubator/dhcplb | >>> https://github.com/facebookincubator/dhcplb ] >>>> Thanks. >>>> Dan >>>> -- >>>> Dan Geist dan(@)polter.net >>>> -- >>>> ISC funds the development of this software with paid support subscriptions. >>>> Contact us at [ https://www.isc.org/contact/ | >>>> https://www.isc.org/contact/ ] >>>> for more information. >>>> To unsubscribe visit [ https://lists.isc.org/mailman/listinfo/kea-users | >>>> https://lists.isc.org/mailman/listinfo/kea-users ] . >>>> Kea-users mailing list >>>> [ mailto:Kea-users@lists.isc.org | Kea-users@lists.isc.org ] >>>> [ https://lists.isc.org/mailman/listinf
Re: [Kea-users] Planning some experimentation with HA using ECMP
Thanks Vicky. Facebook's dhcplb is an option, but it also solves problems that we don't have (imbalance of DHCP messaging and need for staged deployments). It also requires more infra (either physical or virtual) and a slightly greater network complexity which differs from what we already support in other services. I'm trying to stick with the "just because you have a hammer, you should still try to use a screwdriver on screws" philosophy :) I suppose the WAY in which the traffic is balanced is ultimately a wash, though. Either way, we'd need Kea instances in a horizontal N-number farm with mostly-identical behaviors (regardless of if they listen for the virtual IP or if it's housed one hop upstream). Ideally, having as little state as possible (or as little state that DIFFERS between hosts) is an important aspect. Performance tuning, strategy for maintaining the database backend (monolithic vs multiple replicating instances) and so forth will be important, but is there anything inherent about Kea itself that will break this conceptually (unique metadata payload in messaging that will break on DHCP refresh to a different node or something along those lines)? Thanks Dan - On Apr 30, 2024, at 8:39 AM, Victoria Risk wrote: >> On Apr 29, 2024, at 6:16 PM, Dan Geist wrote: >> Hi. I have an environment where many of the network services (DNS, NTP, ToD, >> etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front >> of >> the service) and BGP. Each (of the 2 or more) service node(s) monitors the >> status of that service and announces/pulls BGP announcements from the >> upstream >> router pair. This works really well for protocols with simple >> request/response >> transactions. >> I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the >> same "virtual service IP" would be configured on each of several Kea nodes >> (in >> addition to the real link IPs) and they would announce these to the next hop >> (as above). My thinking is that if there is a common configuration and lease >> backend to these multiple nodes, then this can be a way to provide HA >> services >> (and scaling) to a very large number of devices. My only concern is how the >> multi-step transaction will be handled. >> Before I spend the time to mock this up, has anyone else tried ECMP load >> distribution with DHCP, specifically on Kea, and are there any "gotchas" to >> be >> aware of? > You might want to check out the DHCP Load Balancer from Facebook: [ > https://github.com/facebookincubator/dhcplb | > https://github.com/facebookincubator/dhcplb ] >> Thanks. >> Dan >> -- >> Dan Geist dan(@)polter.net >> -- >> 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 -- Dan Geist dan(@)polter.net -- 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
[Kea-users] Planning some experimentation with HA using ECMP
Hi. I have an environment where many of the network services (DNS, NTP, ToD, etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front of the service) and BGP. Each (of the 2 or more) service node(s) monitors the status of that service and announces/pulls BGP announcements from the upstream router pair. This works really well for protocols with simple request/response transactions. I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the same "virtual service IP" would be configured on each of several Kea nodes (in addition to the real link IPs) and they would announce these to the next hop (as above). My thinking is that if there is a common configuration and lease backend to these multiple nodes, then this can be a way to provide HA services (and scaling) to a very large number of devices. My only concern is how the multi-step transaction will be handled. Before I spend the time to mock this up, has anyone else tried ECMP load distribution with DHCP, specifically on Kea, and are there any "gotchas" to be aware of? Thanks. Dan -- Dan Geist dan(@)polter.net -- 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
Re: [Kea-users] migrating an existing LDAP configuration
The way I read (the admittedly slightly confusing set of pages) is that both MySQL and PostgreSQL are supported as configuration backends in the latest stable open source version, but the hooks to do certain things (like per-host lease reservations, bulk-lease-query and API-based configuration of the DB backend) are only available with the paid support. Anything you want to do with those db backends to replicate/distribute/manage are probably workable, as are 3rd part db HA solutions (there are a few whitepapers out there on people doing KEA with PostGres HA, etc. Obviously, you'll have to implement that part on your own without paid support. The Stork project might give you some extra flexibility but I believe it manages KEA instances natively via API/memfile config and is not compatible with the Db backends. ISC folks, is this accurate? Dan - On Apr 12, 2024, at 8:09 AM, Udo Rader udo.ra...@bestsolution.at wrote: > Hi, > > even after searching the list archives and the docs, I am not really sure what > the migration path for our existing ISC DHCP server could look like. > > Currently we are using ISC DHCP in three different places (data centers). They > all consume their configuration (subnets, static host entries, DHCP options, > ...) from an OpenLDAP server, which is replicated to the different data > centers. > > Every data center has its own base DN in LDAP, eg > > dhcpd.conf in data center1: > [...] > ldap-base-dn "ou=DC1,ou=DHCP,dc=example,dc=com"; > [...] > > dhcpd.conf in data center 2: > [...] > ldap-base-dn "ou=DC2,ou=DHCP,dc=example,dc=com"; > [...] > > dhcpd.conf in data center 3: > [...] > ldap-base-dn "ou=DC3,ou=DHCP,dc=example,dc=com"; > [...] > > Leases are stored locally and they are irrelevant for migration. > > I understand that KEA does not support LDAP as a backend and so I would be > willing to migrate the existing configuration to something else, but even > after > reading the docs, I fail to fully understand what my options are. > > My best guess so far is that I could replace LDAP by either MySQL or Postgres, > configure database replication and have the various local KEA instances > connect > to the replicated local database instances. Is that correct? > > And if so, am I right to assume that for this to work, I need the "Kea > Configuration Backend" (which requires a support subscription)? > > Thanks for any insights. > > Udo > > > Udo Rader, MSc, MBA, Head Unicorn Wrangler > BestSolution.at EDV Systemhaus GmbH > Salurner Straße 15, 6020 Innsbruck, Austria > https://www.BestSolution.at > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > [BestSolution] > -- > 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
[Kea-users] Dhcp6 Prefix Exclude use case question
Greetings, all. I'm exploring using the "prefix exclude" feature to do
something a little different than what it's RFC describes and would like to
know if my scenario would work. In the kea ARM, the example config is as
follows:
"Dhcp6": {
"subnet6": [
{
"subnet": "2001:db8:1::/48",
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64,
"excluded-prefix": "2001:db8:1:8000:cafe:80::",
"excluded-prefix-len": 72
}
]
}
]
}
This allows a device that sends a Prefix Exclude option to be allocated the
indicated /72.
In my environment, we'd like to be able to allocate PDs from a block that is
discrete from the subnet and in which the very first PD is NEVER assigned, ala:
"Dhcp6": {
"subnet6": [
{
"subnet": "2001:db8:1::/48",
"pd-pools": [
{
"prefix": "2001:db8:2::",
"prefix-len": 48,
"delegated-len": 60,
"excluded-prefix": "2001:db8:2::",
"excluded-prefix-len": 60
}
]
}
]
}
Assuming I don't have any dhcpv6 endpoint devices sending the excluded prefix
option, does this accomplish what I'm attempting, which is: never use the first
/60 from the PD /48 prefix?
Thanks
Dan
--
Dan Geist dan(@)polter.net
--
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
