Re: [Kea-users] Kea-Performance BottleNeck (Need Help)
Hi Muhammad, I assume DHCPv4 from your mention of a /8. That is an extremely large single subnet. It might be a better test to with several smaller subnets unless you have some situation where you will actually serve clients from such a large subnet. If you have not changed the allocator, then it is likely to be slow (especially with a database backend). The default lease allocator is the Iterative Allocator: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#iterative-allocator This could result in many SQL queries while it searches for a free lease to allocate. You may want to investigate the random allocator, which may give better performance https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#random-allocator Also, sometimes the bottleneck is on the test machine itself. With such a large subnet you must be specifying some truly large values for perfdhcp. You might have more luck if you split perfdhcp across several machines with smaller values. A final point would be about your packet-queue and thread-pool settings. See here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#multi-threading-settings-with-different-database-backends where your thread-pool-size might be better if it were at least 12 (probably no more than 16 since you have 16 CPUs).and your packet-queue-size set be 66 * the thread-pool-size So 12 and 792, for example. Hope this helps! Thank you, Darren Ankney On Sat, Jun 1, 2024 at 7:43 AM Muhammad Zain wrote: > > Hi all, > > I am benchmarking a kea-dhcp server (2.4.1) installed on ubuntu. > > Test Setup: > 1. Kea 2.4.1 installed on ubuntu vm 16(vpcu) 8 GB ram. Backend Galera cluster > with haproxy writes on a single master at a time. > 2. /8 subnet. Multithreading enabled packet-queue size 2000 thread-pool-size > 10 > 3. Perf machine is connected via a relay to dhcp. > > Expected Result to achieve 2k-4k leases/seconds > I am getting 600-700 with drop ratio 4 to 5% > > Can you please help me with this?. > Is it possible to configure buffers/ queueing in Kea > > Thank you > Muhammad Zain > -- > 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
Re: [Kea-users] DKIM Violation -Re: DKIM Violation -Re: DKIM Violation -Re: kea-dhcp6-serverid
That is correct.
On Thu, May 30, 2024 at 2:49 PM John Welsh wrote:
>
> I believe that I have, here is a snippet of the config file. Still using the
> ipv4 address for HA url for the ipv6 config...
> Thank you for helping!
>
> John
>
> {
> "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [ {
> "this-server-name": "dhcp1-acccess-ub2204-vm",
> "mode": "load-balancing",
> "send-lease-updates": false,
> "sync-leases": false,
> "heartbeat-delay": 1,
> "max-ack-delay": 5000,
> "max-unacked-clients": 20,
> "peers": [
> {
> "name": "dhcp1-acccess-ub2204-vm",
> "url": "http://10.40.4.54:8000/;,
> "role": "primary",
> "auto-failover": true
> },
> {
> "name": "dhcp2-acccess-ub2204-vm",
> "url": "http://10.40.4.55:8000/;,
> "role": "secondary",
> "auto-failover": true
> }
>]
> } ]
>}
> }
>
> On 5/30/24, 12:34, "Kea-users on behalf of Darren Ankney"
> mailto:kea-users-boun...@lists.isc.org> on
> behalf of darren.ank...@gmail.com <mailto:darren.ank...@gmail.com>> wrote:
>
>
> John,
>
>
> That is correct. If both servers are sharing the same database and
> are both configured for HA, then you may want to look at disabling
> lease synchronization as described here:
> https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#lease-information-sharing
>
> <https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#lease-information-sharing>
>
>
> thank you,
> Darren Ankney
>
>
> On Wed, May 29, 2024 at 11:11 AM John Welsh <mailto:john.we...@goste.net>> wrote:
> >
> > Thanks for the reply and I think I have them working now. I set up a
> > postgresql backend db for the databases and in doing so I am now using the
> > same pools for both servers instead of splitting the pool between them. I
> > did this because each server will register it lease within the database so
> > and each server checks the database to verify that the ip is available
> > before it offers it? At lease that is my understanding.
> >
> > John
> >
> > On 5/28/24, 16:15, "Kea-users on behalf of Darren Ankney"
> > mailto:kea-users-boun...@lists.isc.org>
> > <mailto:kea-users-boun...@lists.isc.org
> > <mailto:kea-users-boun...@lists.isc.org>> on behalf of
> > darren.ank...@gmail.com <mailto:darren.ank...@gmail.com>
> > <mailto:darren.ank...@gmail.com <mailto:darren.ank...@gmail.com>>> wrote:
> >
> >
> > Hi John,
> >
> >
> > This is just a guess, but you may need to review
> > https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration
> >
> > <https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration>
> >
> > <https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration>
> >
> > <https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration;>
> > which shows that you need to use the special client classes of
> > HA_ to manually split the pools in half (there is no
> > auto-split like there was in ISC DHCP). Or simply use hot-standby
> > which requires no special class configuration / pool splitting. If
> > that isn't the problem, then please provide your configuration (with
> > sensitive items redacted) so that the community might better assist
> > you.
> >
> >
> > Thank you,
> > Darren Ankney
> >
> >
> > On Tue, May 28, 2024 at 5:06 PM John Welsh > <mailto:john.we...@goste.net> <mailto:john.we...@goste.net
> > <mailto:john.we...@goste.net>>> wrote:
> > >
> > > Load-Balancing
> > >
> > > On 5/28/24, 15:30, "Kea-users on behalf of
Re: [Kea-users] [EXTERNAL] Kea 2.6.0 is released!
Yu,
I don't think so. I have not actually set this up yet, but it appears
that the subnet relationships are being maintained by the
"ha-server-name" "user-context" parameter in the subnet as shown in
this example from the ARM:
"subnet6": [
{
"id": 2,
"subnet": "2001:db8:2::/64",
"pools": [
{
"pool": "2001:db8:2::/80"
}
],
"interface": "enp0s8",
"user-context": {
"ha-server-name": "server3"
}
}
]
I imagine that you could use the same IP address on the "hub" for all
spoke relationships and simply use a different port for each. I don't
think you need to add multiple IP addresses to the "hub" as implied by
the example configurations under
https://kea.readthedocs.io/en/kea-2.6.0/arm/hooks.html#hub-and-spoke-configuration
One assumes that you would specify relay agent IP addresses or
similar to make the subnet selection happen properly (in the case that
the spoke server is down and the hub server needs to respond to
clients). Again though, I've not tested. But since this is meant to
be used in a context where broadcast networking doesn't make sense,
having to use separate interfaces for each relationship wouldn't make
sense either.
Thank you,
Darren Ankney
On Thu, May 30, 2024 at 1:16 PM Xiao, Yu (CCI-Atlanta) via Kea-users
wrote:
>
> Hi ISC team,
>
>
>
> I read the latest document on Kea 2.6.0 for new Hub and Spoke feature. In the
> beginning, we thought it could provide N+1 backup. But after I read your
> description and configuration example. I feel It’s more like multiple 1+1
> backup, it requires the backup server has a 1-to-1 relationship with all the
> other primary servers. For each 1-to-1 relationship, it requires a different
> interface with both hosts on a different subnet. So if we need to protect N
> servers, we will need N interfaces and two IPs from each of N subnets on this
> central server. Is my understanding correct?
>
>
>
>
>
> +- Central Server --+
>
> | |
>
> +--+ relationship 1 | +--+--+ | relationship 2
> +--+
>
> | Server 1 |===| Server 2 | Server 4 |===|
> Server 3 |
>
> +--+| +--+--+ |
> +--+
>
> | |
>
> +---+
>
>
>
>
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Kea-users on behalf of Suzanne
> Goldlust
> Date: Wednesday, May 29, 2024 at 12:33 PM
> To: kea-users@lists.isc.org
> Subject: [EXTERNAL] [Kea-users] Kea 2.6.0 is released!
>
> ISC is excited to announce the release of Kea 2.6.0, the first version of the
> Kea 2.6 stable branch.
>
> As a reminder: Internet Systems Consortium uses an alternating branch scheme
> for our releases. Branches that have an odd number in the digit after the
> first "." (for example: Kea 2.3, Kea 2.5) are development branches, while
> branches that are even-numbered are intended for stable production use (for
> example: Kea 2.4, Kea 2.6).
>
> With the release of stable branch Kea 2.6, the Kea 2.5 development branch has
> now reached the end of its life and is no longer supported. The new Kea 2.7
> development branch will be released in summer 2024.
>
>
>
> There are now two stable Kea branches: Kea 2.4 (the most recent release is
> Kea 2.4.1, from November 2023), and the new Kea 2.6.0, released today. The
> Kea 2.2 branch has now reached End of Life.
>
> --
>
>
> The 2.6.0 release contains the results of nearly a year's worth of
> development effort, previously previewed in the 2.5 development branch.
>
> Highlights include:
>
> - Hub-and-spoke High Availability
> - New hook libraries
> - Support for more client options
> - Docker images
> - New Cloudsmith packages
>
>
>
> and much more! Please read the full release notes at
> https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.6.0.
>
> Kea 2.6.0 can be downloaded from:
> https://dl.cloudsmith.io/public/isc/kea-2-6/raw/versions/2.6.0/kea-2.6.0.tar.gz.
>
> All current versions, along with the release notes and the Administrator
> Reference Manual (ARM), are also available via the ISC downloads
Re: [Kea-users] Partially failed upgrade from 2.4.1 to 2.6.0: DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/etc/kea/kea-dhcp4.conf': Error initializing h>
Hi Marek, According to your attached keav4 and keav6 files, your HA configuration for both DHCPv4 and DHCPv6 is exactly the same as pertains to "url". Both are trying to listen on http://192.168.150.221:8000/ and http://192.168.150.222:8000/ respectively. You can either use a different port for DHCPv6 or use the IPv6 address. Thank you, Darren Ankney On Wed, May 29, 2024 at 5:35 PM wrote: > > So I ventured to the upgrade from 2.4.1 to 2.6.0 to see if that helps my > integration problems with Stork in any way. Agent and DHCPv6 restarted fine > after reboot. DHCPv4 for some reason is complaining about address being > already in use. The system worked just fine under 2.4.1 without any > complaints about address binding being a problem. > > > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] > DHCPSRV_MEMFILE_BEGIN_EXTRACT_EXTENDED_INFO4 extract extended info with fix > sanity check level > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388 INFO > [kea-dhcp4.dhcpsrv/2755.140174953331136] > DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0 leases, > extended info sanity checks modified 0 / update> > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388 INFO > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_MEMFILE_LFC_SETUP setting up > the Lease File Cleanup interval to 3600 sec > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_REGISTER_TIMER > registering timer: memfile-lfc, using interval: 360 ms > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_START_TIMER > starting timer: memfile-lfc > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_REGISTER_TIMER > registering timer: reclaim-expired-leases, using interval: 1 ms > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_START_TIMER > starting timer: reclaim-expired-leases > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_REGISTER_TIMER > registering timer: flush-reclaimed-leases, using interval: 25000 ms > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_START_TIMER > starting timer: flush-reclaimed-leases > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUTS_BEGIN begin all > callouts for hook dhcp4_srv_configured > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 INFO > [kea-dhcp4.ha-hooks/2755.140174953331136] HA_LOCAL_DHCP_DISABLE local DHCP > service is disabled while the dhcp-kea-node2 is in the WAITING state > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.http/2755.140174953331136] HTTP_CLIENT_MT_STARTED HttpClient has > been started in multi-threaded mode running 4 threads > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 INFO > [kea-dhcp4.ha-hooks/2755.140174953331136] HA_SERVICE_STARTED dhcp-kea-node2: > started high availability service in hot-standby mode as standby server > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUT_CALLED hooks library > with index 3 has called a callout on hook dhcp4_srv_configured that has > address 0x7f7d044> > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 DEBUG > [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUTS_COMPLETE completed > callouts for hook dhcp4_srv_configured (total callouts duration: 0.213 ms) > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404 INFO > [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_CFGMGR_USE_ALLOCATOR using > the iterative allocator for V4 leases in subnet 10.10.1.0/24 > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.405 DEBUG > [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUTS_BEGIN begin all > callouts for hook command_processed > > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.405 DEBUG > [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUT_CALLED hooks library > with index 3 has called a callout on hook co
Re: [Kea-users] DKIM Violation -Re: DKIM Violation -Re: kea-dhcp6-serverid
John, That is correct. If both servers are sharing the same database and are both configured for HA, then you may want to look at disabling lease synchronization as described here: https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#lease-information-sharing thank you, Darren Ankney On Wed, May 29, 2024 at 11:11 AM John Welsh wrote: > > Thanks for the reply and I think I have them working now. I set up a > postgresql backend db for the databases and in doing so I am now using the > same pools for both servers instead of splitting the pool between them. I did > this because each server will register it lease within the database so and > each server checks the database to verify that the ip is available before it > offers it? At lease that is my understanding. > > John > > On 5/28/24, 16:15, "Kea-users on behalf of Darren Ankney" > mailto:kea-users-boun...@lists.isc.org> on > behalf of darren.ank...@gmail.com <mailto:darren.ank...@gmail.com>> wrote: > > > Hi John, > > > This is just a guess, but you may need to review > https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration > > <https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration> > which shows that you need to use the special client classes of > HA_ to manually split the pools in half (there is no > auto-split like there was in ISC DHCP). Or simply use hot-standby > which requires no special class configuration / pool splitting. If > that isn't the problem, then please provide your configuration (with > sensitive items redacted) so that the community might better assist > you. > > > Thank you, > Darren Ankney > > > On Tue, May 28, 2024 at 5:06 PM John Welsh <mailto:john.we...@goste.net>> wrote: > > > > Load-Balancing > > > > On 5/28/24, 15:30, "Kea-users on behalf of Darren Ankney" > > mailto:kea-users-boun...@lists.isc.org> > > <mailto:kea-users-boun...@lists.isc.org > > <mailto:kea-users-boun...@lists.isc.org>> on behalf of > > darren.ank...@gmail.com <mailto:darren.ank...@gmail.com> > > <mailto:darren.ank...@gmail.com <mailto:darren.ank...@gmail.com>>> wrote: > > > > > > Hi John, > > > > > > Are you running HA in "load-balancing" or "hot-standby" mode? > > > > > > Thank you, > > Darren Ankney > > > > > > On Sun, May 26, 2024 at 7:56 PM John Welsh > <mailto:john.we...@goste.net> <mailto:john.we...@goste.net > > <mailto:john.we...@goste.net>>> wrote: > > > > > > I have set up 2 kea dhcp ver 2.4.1 servers and I am seeing some issues > > > with hosts not getting a ipv6 lease. > > > > > > My question is do I need to use the same kea-dhcp6-serverid on both > > > servers if they are running in HA? All hosts will get leases if I disable > > > HA. > > > > > > > > > > > > Thanks! > > > > > > John Welsh > > > > > > -- > > > ISC funds the development of this software with paid support > > > subscriptions. Contact us at https://www.isc.org/contact/ > > > <https://www.isc.org/contact/> <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> > > > <https://lists.isc.org/mailman/listinfo/kea-users> > > > <https://lists.isc.org/mailman/listinfo/kea-users;>. > > > > > > Kea-users mailing list > > > Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org> > > > <mailto:Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org>> > > > https://lists.isc.org/mailman/listinfo/kea-users > > > <https://lists.isc.org/mailman/listinfo/kea-users> > > > <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/ <https://www.isc.org/contact/> > > <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> > > <https://lists.isc.org/mailman/listinfo/kea-user
Re: [Kea-users] DKIM Violation -Re: kea-dhcp6-serverid
Hi John, This is just a guess, but you may need to review https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#load-balancing-configuration which shows that you need to use the special client classes of HA_ to manually split the pools in half (there is no auto-split like there was in ISC DHCP). Or simply use hot-standby which requires no special class configuration / pool splitting. If that isn't the problem, then please provide your configuration (with sensitive items redacted) so that the community might better assist you. Thank you, Darren Ankney On Tue, May 28, 2024 at 5:06 PM John Welsh wrote: > > Load-Balancing > > On 5/28/24, 15:30, "Kea-users on behalf of Darren Ankney" > mailto:kea-users-boun...@lists.isc.org> on > behalf of darren.ank...@gmail.com <mailto:darren.ank...@gmail.com>> wrote: > > > Hi John, > > > Are you running HA in "load-balancing" or "hot-standby" mode? > > > Thank you, > Darren Ankney > > > On Sun, May 26, 2024 at 7:56 PM John Welsh <mailto:john.we...@goste.net>> wrote: > > > > I have set up 2 kea dhcp ver 2.4.1 servers and I am seeing some issues with > > hosts not getting a ipv6 lease. > > > > My question is do I need to use the same kea-dhcp6-serverid on both servers > > if they are running in HA? All hosts will get leases if I disable HA. > > > > > > > > Thanks! > > > > John Welsh > > > > -- > > 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 > > Kea-users@lists.isc.org <mailto: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/ <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 > Kea-users@lists.isc.org <mailto: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 -- 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] Boot-file from HTTP server
Hi Philippe,
what protocol the client uses to obtain the boot file is up to the
client. Perhaps with some specific options specified in a specific way
by the server, but still up to the client (i.e., the manufacturer of
the client will need to give the specifics of how to use http verses
tftp with their particular client which should include details about
what the DHCP server needs to provide).
Thank you,
Darren Ankney
On Mon, May 27, 2024 at 5:25 AM Philippe EA wrote:
>
> Hi All,
>
>
>
> I practically achieved what I want to do with KEA DHCP, the last point is
> using a boot file through HTTP instead of TFTP, I’m unable to run the test at
> the moment so hope you guys can help me while waiting.
>
>
>
> Currently my config for the boot-file is below :
>
>
>
> "reservations": [
>
> {
>
> "hostname": "SCG",
>
> "hw-address": "00:80:d4:0c:30:76",
>
> "next-server": "10.171.20.254",
>
> "boot-file-name": "dhcp-ztp.txt",
>
> "option-data": [
>
> {
>
> "space": "dhcp4",
>
> "name": "tftp-server-name",
>
> "code": 66,
>
> "data": "10.171.20.72"
>
> }
>
> ]
>
> }
>
> ],
>
>
>
> But with this config, the boot file use TFTP protocol.
>
>
>
> I’m thinking of using this config instead :
>
>
>
> "reservations": [
>
> {
>
> "hostname": "SCG",
>
> "hw-address": "00:80:d4:0c:30:76",
>
> "next-server": "10.171.20.254",
>
> "server-hostname": "10.171.20.72",
>
> "boot-file-name": "dhcp-ztp.txt",
>
> }
>
> ],
>
>
>
> With this instead, should I be able to use HTTP protocol ?
>
>
>
> Thanks.
>
>
>
> Regards.
>
>
>
> Philippe EA
>
> --
> 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
Re: [Kea-users] kea-dhcp6-serverid
Hi John, Are you running HA in "load-balancing" or "hot-standby" mode? Thank you, Darren Ankney On Sun, May 26, 2024 at 7:56 PM John Welsh wrote: > > I have set up 2 kea dhcp ver 2.4.1 servers and I am seeing some issues with > hosts not getting a ipv6 lease. > > My question is do I need to use the same kea-dhcp6-serverid on both servers > if they are running in HA? All hosts will get leases if I disable HA. > > > > Thanks! > > John Welsh > > -- > 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
Re: [Kea-users] High memory utilization for Kea server / Stork agent
Hi Marek, It appears that kea-dhcp4. kea-dhcp6, and stork-agent were started multiple times. I do not know how you are starting the daemons but perhaps something changed with the startup process (systemd?) that caused the thing that is starting the daemons to not realize they are running, thusly starting them multiple times? Thank you, Darren Ankney On Mon, May 13, 2024 at 2:16 PM Marek Hajduczenia wrote: > Looking at the historic utilization over the week > > > > > > you can clearly see a rather dramatic increase in memory utilization > starting 5/10, with no specific changes to what the node is doing. > > > > Marek > > > > *From:* Marek Hajduczenia > *Sent:* Monday, May 13, 2024 12:12 PM > *To:* 'Kea user's list' > *Subject:* High memory utilization for Kea server / Stork agent > > > > Dear colleagues, > > > > I have been observing very high memory utilization for Kea VMs. In ~4 > days, the memory utilization has grown from ~2 GB to close to 8GB for no > good reason. > > > > > > > > I seem to be running multiple copies of processes for some reason, with > stork-agent likely being the primary culprit, and Kea DHCP servers being > likely the second culprit. I have the very same situation on both lab > nodes. I have to restart the server / stork agent periodically to eliminate > the memory bloat. > > > > 634 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 7:35.77 > /usr/bin/stork-agent > > 709 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 0:18.34 > /usr/bin/stork-agent > > 710 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 0:34.27 > /usr/bin/stork-agent > > 711 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 0:00.00 > /usr/bin/stork-agent > > 713 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 0:00.01 > /usr/bin/stork-agent > > 727 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 0:00.00 > /usr/bin/stork-agent > > 740 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 1:29.63 > /usr/bin/stork-agent > > 894 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 1:24.96 > /usr/bin/stork-agent > >1921 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 1:29.49 > /usr/bin/stork-agent > > 15986 stork-age 20 0 1866M 26240 15824 S 0.0 0.3 0:53.26 > /usr/bin/stork-agent > >1340 _kea 20 0 507M 23864 16784 S 0.0 0.3 4:54.19 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1341 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:00.00 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1342 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:00.00 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1343 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:00.00 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1344 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:00.00 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1352 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:05.43 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1353 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:05.49 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1354 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:08.22 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > >1355 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:08.25 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > > 20544 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:00.00 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > > 20545 _kea 20 0 507M 23864 16784 S 0.0 0.3 0:00.00 > /usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf > > 679 root 20 0 107M 20736 12596 S 0.0 0.3 0:00.04 > /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown > --wait-for-signal > > 732 root 20 0 107M 20736 12596 S 0.0 0.3 0:00.00 > /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown > --wait-for-signal > >1889 _kea 20 0 507M 19292 14552 S 0.0 0.2 3:05.41 > /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > >1890 _kea 20 0 507M 19292 14552 S 0.0 0.2 0:00.00 > /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > >1891 _kea 20 0 507M 19292 14552 S 0.0 0.2 0:00.00 > /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > >1892 _kea 20 0 507M 19292 14552 S 0.0 0.2 0:00.00 > /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > >1893 _kea 20 0 507M 19292 14552 S 0.0 0.2 0:00.00 > /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > >1897 _kea 20 0 507M 19292 14552 S 0.0 0.2 0:05.47 > /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf > >
Re: [Kea-users] kea-dhcpv6 won't offer adresses to clients
I had trouble processing your text email as well (skipping the tcpdump entirely) but if there is no relay available (local DHCPv6 server), then your laptop should be contacting: [ff02::1:2]%eth1:547 on the server as per RFC 8415. DHCPv6 uses multicast. On Fri, May 10, 2024 at 12:40 PM Django [Bastard Operator from Hell] via Kea-users wrote: > > HI Marek, > > Am 10.05.24 um 14:40 schrieb Marek Hajduczenia: > > > I am sorry, I cannot process this information dump in its current format. > > If you want to send / attach logs and config files via text files + perhaps > > a packet capture on the affected interface, I will be happy to look at it > > O.K. I'll send you a personal email directly to your address in a few > minutes! > > > Best regards > Django > -- > 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
Re: [Kea-users] [EXTERNAL] RE: No DHCP Reply sent out from kea server
Hello all,
You can't redefine already defined options in Kea. So you can't do this:
"option-def": [
{
"space": "dhcp6",
"name": "vendor-opts",
"code": 17,
"type": "empty",
},
]
But you CAN do this:
"option-def": [
{
"space": "vendor-4491",
"name": "vendor-opts",
"code": 17,
"type": "empty",
},
]
because it is not in the "dhcp6" space where option 17 is already defined.
That being said, you don't need to do that. It won't do anything.
What Marek showed is the correct way.
Thank you,
Darren Ankney
On Fri, May 10, 2024 at 9:19 AM wrote:
>
> I will let developers speak to the logic they use to tie it all together
>
>
>
> All I know is that a working configuration for me has a “option-def” section
> (example below)
>
>
>
> ### DOCSIS space for vendor-4491
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "array": true,
>
> "type": "ipv6-address"
>
> },
>
>
>
> followed by “option-data” where previously defined options are filled in with
> value
>
>
>
> {
>
> "space": "vendor-4491",
>
> "name": "tftp-servers",
>
> "code": 32,
>
> "data": "2600:6ce4:0:42::132"
>
> },
>
>
>
> and then finally in subnets / pools I want Option 17 to be sent out, I add to
> “option-data” statement – note that this statement causes Option 17 to be
> filled in with vendor-4491 specific data set
>
>
>
>
> {
>
>
> "space": "dhcp6",
>
>
> "name":
> "vendor-opts",
>
>
> "code": 17,
>
>
> "data": "4491"
>
>
> }
>
>
>
> I do not know, honestly, why you would need the statement you highlighted in
> red below. My config works without it.
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta)
> Sent: Friday, May 10, 2024 7:13 AM
> To: mxhajducze...@gmail.com; 'Kea user's list'
> Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
>
>
> Yes, but it(vendor-opts) is defined under the space vendor-4491 not under the
> space dhcp6, I tried to change the space value to dhcp6 but received error.
>
>
>
> {
>
> "space": "vendor-4491",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "type": "empty",
>
> },
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: mxhajducze...@gmail.com
> Date: Friday, May 10, 2024 at 9:06 AM
> To: Xiao, Yu (CCI-Atlanta) , 'Kea user's list'
>
> Subject: RE: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
>
> I think there is some confusion. If you’re building a new Option in a new
> space, that is different than adding vendor-specific sub-options.
> Vendor-specific option is already pre-defined under dhcp6 space (that is
> option 17), no need to re-define it.
>
>
>
> Marek
>
>
>
> From: Xiao, Yu (CCI-Atlanta
Re: [Kea-users] Over-riding global settings in specific subnets / prefixes
Hi Marek,
I'm still thinking about this one. Out of curiosity, could you try
specifying the option-data inside of the "ecm-vince" client class? I
am curious if that overrides the global option data.
Thank you,
Darren Ankney
On Fri, May 3, 2024 at 4:16 PM wrote:
>
> Good afternoon,
>
>
>
> I observed a rather surprising behavior today in Kea 2.4.1 DHCPv6 server.
>
>
>
> I have a global (shared) custom option value defined as follows. Note the
> config file value
>
>
>
> {
>
> "space": "vendor-4491",
>
> "name": "config-file",
>
> "code": 33,
>
> "data": "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg"
>
> },
>
>
>
> In one of the subnets, I assigned a custom value as follows
>
>
>
> {
>
>"id": 102,
>
>"interface": "enp6s18",
>
>"comment": "CMs connected to Vince's RPDs",
>
>"subnet": "2600:6ce4:0:208::/64",
>
>"relay": {
>
> "ip-addresses": [ "2600:6ce4:0:3e::1" ]
>
>},
>
>"pools": [
>
> {
>
> "pool": "2600:6ce4:0:208::2 -
> 2600:6ce4:0:208::::",
>
> "client-class": "ecm-vince",
>
> "option-data": [
>
> {
>
> "space": "vendor-4491",
>
> "name": "config-file",
>
> "code": 33,
>
> "data":
> "WBDocCfg166_upgrade.cfg"
>
> },
>
> {
>
> "space": "dhcp6",
>
> "name": "dns-servers",
>
> "code": 23,
>
> "data":
> "2600:6ce4:40:12c:8000::3"
>
> }
>
> ]
>
> }
>
>]
>
> },
>
>
>
> hoping that it would override the parameter value assigned globally.
> Unfortunately, the TFTP server logs show that the previous config file value
> is still being served.
>
>
>
> 20:01:57.672602 IP6 2600:6ce4:0:208::24.59455 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:01:59.745978 IP6 2600:6ce4:0:208::27.44638 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:02:00.584499 IP6 2600:6ce4:0:208::39.36093 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:02:00.684559 IP6 2600:6ce4:0:208::2a.57747 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:02:03.390078 IP6 2600:6ce4:0:208::9.35267 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:02:04.210522 IP6 2600:6ce4:0:208::3b.39781 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:02:04.429295 IP6 2600:6ce4:0:208::6.39985 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet
> blksize 1428 tsize 0
>
> 20:02:04.483974 IP6 2600:6ce4:0:208::38.41514 > 2600:6ce4:0:42::132.69: TFTP,
> length 83, RRQ "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg&
Re: [Kea-users] [EXTERNAL] Re: Two questions regarding to kea subnet configuration
Hi Marek, Yes: Services -> Kea Apps -> Click on the Name you are interested in (e.g., kea@127.0.0.1) -> "Raw Configuration" Thank you, Darren Ankney On Tue, May 7, 2024 at 8:00 AM wrote: > Settings are pretty underwhelming so I assume that section would be > somewhere else? > > > > > > -Original Message----- > From: Kea-users On Behalf Of Darren > Ankney > Sent: Tuesday, May 7, 2024 3:55 AM > To: Kea user's list > Subject: Re: [Kea-users] [EXTERNAL] Re: Two questions regarding to kea > subnet configuration > > > > Hi Marek, > > > > > and just wish they were visible in Stork > > > > They sort of are but probably not in the way you are hoping. There is an > area where you can view the raw Kea configuration. They would be shown > there. > > > > Thank you, > > Darren Ankney > > > > On Mon, May 6, 2024 at 10:27 PM Marek Hajduczenia > wrote: > > > > > > I did look at it but it is a highly ineffective way of doing such > > > classification. I do not have much commonality between individual > > > subnets and adding extra complexity of tracking them via client > > > classes is not worth the effort IMHO. I will see what I can do with > > > comments, and just wish they were visible in Stork, via – perhaps, a > > > customizable field. Right now, having several [1] prefixes is hard to > > > track > > > > > > > > > > > > Marek > > > > > > > > > > > > From: David Farje > > > Sent: Monday, May 6, 2024 12:12 PM > > > To: Kea user's list > > > Cc: mxhajducze...@gmail.com; Xiao, Yu (CCI-Atlanta) > > > Subject: Re: [Kea-users] [EXTERNAL] Re: Two questions regarding to kea > > > subnet configuration > > > > > > > > > > > > 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 on behalf of Marek > > > Hajduczenia > > > Date: Monday, May 6, 2024 at 12:31 PM > > > To: 'Kea user's list' > > > 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 On Behalf Of David > > > Farje > > > Sent: Monday, May 6, 2024 10:13 AM > > > To: Kea user's list > > > 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-all > > > ocation-strategies-in-dhcpv4 > > > > > > > > > > > > Regards, > > > > > > David > > > > > > > > > > > > > > > > > > On Mon, May 6, 2024 at 9:21 AM wrote: > >
Re: [Kea-users] [EXTERNAL] Re: Two questions regarding to kea subnet configuration
Hi Marek, > and just wish they were visible in Stork They sort of are but probably not in the way you are hoping. There is an area where you can view the raw Kea configuration. They would be shown there. Thank you, Darren Ankney On Mon, May 6, 2024 at 10:27 PM Marek Hajduczenia wrote: > > I did look at it but it is a highly ineffective way of doing such > classification. I do not have much commonality between individual subnets and > adding extra complexity of tracking them via client classes is not worth the > effort IMHO. I will see what I can do with comments, and just wish they were > visible in Stork, via – perhaps, a customizable field. Right now, having > several [1] prefixes is hard to track > > > > Marek > > > > From: David Farje > Sent: Monday, May 6, 2024 12:12 PM > To: Kea user's list > Cc: mxhajducze...@gmail.com; Xiao, Yu (CCI-Atlanta) > Subject: Re: [Kea-users] [EXTERNAL] Re: Two questions regarding to kea subnet > configuration > > > > 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 > 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 on behalf of Marek > Hajduczenia > Date: Monday, May 6, 2024 at 12:31 PM > To: 'Kea user's list' > 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 On Behalf Of David Farje > Sent: Monday, May 6, 2024 10:13 AM > To: Kea user's list > 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 > > > > Regards, > > David > > > > > > On Mon, May 6, 2024 at 9:21 AM 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 On Behalf Of Xiao, Yu > (CCI-Atlanta) via Kea-users > Sent: Monday, May 6, 2024 6:10 AM > To: Kea user's list > Cc: Xiao, Yu (CCI-Atlanta) > 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/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mai
Re: [Kea-users] Two questions regarding to kea subnet configuration
As far as "naming" subnets, you may want to look at "5.1.2. Comments
and User Context":
https://kea.readthedocs.io/en/kea-2.4.1/arm/config.html#comments-and-user-context.
There is an example there that shows how you might use this mechanism
to identify a subnet:
"Dhcp4": {
"subnet4": [{
"id": 1,
"subnet": "192.0.2.0/24",
"pools": [{ "pool": "192.0.2.10 - 192.0.2.20" }],
"comment": "second floor"
}]
}
Thank you,
Darren Ankney
On Mon, May 6, 2024 at 8:10 AM Xiao, Yu (CCI-Atlanta) via Kea-users
wrote:
>
> 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/ 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
Re: [Kea-users] Combining class definitions with or/and operands
Hi Marek,
The "client-class" is meant to only contain one class and no logical
operands. I am not sure if that configuration should throw an error,
however. There may be other considerations (such as API use to add
classes later) that prevent such checking of the name contained
therein.
Thank you,
Darren Ankney
On Tue, Apr 30, 2024 at 8:45 PM wrote:
>
> Just a foreword, I am experimenting with the class definitions and different
> test structures, since the examples provided in the official documentation
> are very limited. Specifically, I created these match conditions, and they
> seem to work just fine
>
>
>
> "client-classes": [
>
> {
>
> "name": "CTS19-RPDs",
>
>"test": "pkt4.mac == 0x0020a361415b or pkt4.mac == 0x001848fe8f35"
>
> },
>
> {
>
> "name": "CTS17-RPDs",
>
>"test": "(pkt4.mac == 0x0020a3283bfb) or (pkt4.mac ==
> 0x0020a3263a4b) or (pkt4.mac == 0x0020a3263a6b) or (pkt4.mac ==
> 0x0020a35a1b0b)"
>
> },
>
> {
>
> "name": "CTS18-RPDs",
>
>"test": "(pkt4.mac == 0x0020a325c53b) or (pkt4.mac ==
> 0x0018480ae57d) or (pkt4.mac == 0x0020a32b08bb) or (pkt4.mac ==
> 0x0020a328e02b) or (pkt4.mac == 0x0020a357fc6b) or (pkt4.mac ==
> 0x0020a358a5bb) or (pkt4.mac == 0x0020a35eb56b) or (pkt4.mac ==
> 0x0020a35ecadb) or (pkt4.mac == 0x0018480ae35f) or (pkt4.mac ==
> 0x0018480ae903) or (pkt4.mac == 0x0020a35dfb3b) or (pkt4.mac ==
> 0x0020a380378b) or (pkt4.mac == 0x0020a34f93cb)"
>
> }
>
> ],
>
>
>
> As you can see, the test structure seems to not care for brackets () or not,
> and does the matching well even with very long conditions.
>
>
>
> Where the question comes is with the “client-class” statement in individual
> pool / subnet definitions. In the following example, the client class
> statement contains an ‘or’ combination for three different classes defined
> before. It parses fine, but … it does not seem to work. All examples I can
> find show a single entry in the client-class, but I am wondering whether the
> example below is a mistake and the parser should throw an error or not. I do
> know I can create another class that combines three previous classes into
> one, but I find this cleaner to read, where the match in client-class is
> performed on and/or combined structure of different atomic classes.
>
>
>
>{
>
> "id": 1,
>
> "subnet": "172.27.60.16/28",
>
> "relay": {
>
> "ip-addresses": [ "172.27.60.17" ]
>
> },
>
> "pools": [
>
> {
>
>"pool": "172.27.60.18 - 172.27.60.30",
>
>"client-class": "CTS19-RPDs or CTS18-RPDs or
> CTS17-RPDs"
>
> }
>
> ],
>
> "option-data": [
>
> {
>
>"space": "dhcp4",
>
>"name": "subnet-mask",
>
>"code": 1,
>
>"data": "255.255.255.240"
>
> },
>
> {
>
>"space": "dhcp4",
>
>"name": "routers",
>
>"code": 3,
>
>"data": "172.27.60.17"
>
> },
>
> {
>
>"space": "dhcp4",
>
>"name": "vendor-encapsulated-options",
>
>"code": 43,
>
>"csv-format": false,
>
>"data": "3d04ac1b3d04"
>
> }
>
> ]
>
>},
>
>
>
> Is the above shown “client-class” match condition a valid example and should
> it work?
>
>
>
> Regards
>
>
>
> Marek
>
> --
> 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
Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
It looks to me like, in your last screenshot, that option 17 is part
of the solicit message proper rather than the relay portion. It's a
little hard to tell from screenshots.
You can split the classes up for testing (or permanently) so that you
can see exactly what is happening. For example:
{
"name": "ecm-test-1",
"test": "substring(option[17].option[2].hex,0,3) == 'ECM'"
},
{
"name": "md-test-1",
"test": "member('ecm-test-1') and
substring(relay6[2].option[18].hex,0,9) == 'Md1:0/0.0'"
},
This will cause the logs to tell you which classes the client became a
member of so that you can note which part of the test is failing.
I think I've corrected your test strings above to reflect the actual
position in the packet. If you wouldn't mind attaching the actual
packet capture, however, that would make things easier.
Thank you,
Darren Ankney
On Mon, Apr 29, 2024 at 2:19 PM Marek Hajduczenia
wrote:
>
> Thank you, Darren,
>
>
>
> That seems to work as well.
>
>
>
> I did run into another corner case, I think, though. The same table shows
> relay6[nest].option[code].hex as the only available options for classifying
> on options within the Relay6 messages. I assume this applies to option
> 17/18/37, which are part of the relay message and can be accessed at the
> level of Relay6[1] in this example below. However, there are additional
> suboptions within these options, for example, sub-option 14 within option 17,
> so relay6[1].option[17].option[14].hex would be the only way to extract and
> match on this sub-option but this does not seem to be supported today. Is
> there any specific reason as to why?
>
>
>
>
>
> The issue that I am running into is related, i.e., the Solicit message I
> receive traverses two relays as shown below
>
>
>
>
>
> and I want to classify based on option 17, sub-option 2 and also option 18 in
> relay6[1], as shown below
>
>
>
> {
>
> "name": "ecm-1",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'ECM' and
> substring(relay6[1].option[18].hex,0,9) == 'Md1:0/0.0'"
>
> },
>
>
>
> but the valuation logs show the “EVAL_DEBUG_SUB_OPTION_NO_OPTION Requested
> option 17 sub-option 2, but the parent option is not present, pushing result
> 0x” error, which implies option 17, sub-option 2 is requested but not found.
> I suspect it is matching on option 17 in outer relay messages for some reason.
>
>
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUB_OPTION_NO_OPTION
> Requested option 17 sub-option 2, but the parent option is not present,
> pushing result 0x
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '3'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUBSTRING_EMPTY
> Popping length 3, start 0, string 0x pushing result 0x
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string 'ECM'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_EQUAL Popping 0x45434D
> and 0x pushing result 'false'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_OPTION Pushing option
> 18 with value 0x4D64313A302F302E3000A8705DD0DD0D
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '9'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUBSTRING Popping
> length 9, start 0, string 0x4D64313A302F302E3000A8705DD0DD0D pushing result
> 0x4D64313A302F302E30
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
Re: [Kea-users] Reserving address in a pool without client identifier
Hi Adrian,
The best way would be to breakup the pools around any addresses of
this type. You can specify multiple pools as noted here:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#configuration-of-ipv4-address-pools
for example:
{
"subnet": "192.0.4.0/24",
"pools": [
{
"pool": "192.0.4.1 - 192.0.4.14",
"pool": "192.0.4.20 - 192.0.4.254"
}
]
}
Thank you,
Darren Ankney
On Sat, Apr 27, 2024 at 4:52 PM Adrian L Lange wrote:
>
> Hi,
>
> I have a IPv4 pool used for a lot of services, and I usually reserve
> addresses either dynamically or manually.
> However, I now need to make sure an address in this pool won't get allocated
> by accident, and I can't reserve it when it doesn't have a client identifier
> (it's a floating virtual IP). It would be nice if reservations didn't require
> a client identifier or one could be set to "none". As this is not the case,
> and unless I've missed something in the documentation, how can I exclude an
> address from being allocated from a pool?
>
> Regards,
>
> Adrian
> --
> 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
Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek, I recently found out that you can use syntax like: 'vendor[].option[].hex' in class test lines to match instead of 'option[17].option[2].hex' as noted in the table here: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#id3 Though it isn't exalty what you were asking for, perhaps it helps in some way? Thank you, Darren Ankney On Wed, Apr 24, 2024 at 8:51 AM Marek Hajduczenia wrote: > > Thank you, Darren, > > > > If these custom-defined options are outbound only, it would be great if that > was mentioned in the documentation somewhere. In all my reading I did not > find a single reference to that – perhaps I just missed it. I was treating it > as any internally defined variable name, and since it can be used to specify > outbound options, I figured they should also work the same way in ingress > parser. Clearly, a wrong assumption on my part. > > > > Regards > > > > Marek > > > > From: Darren Ankney > Sent: Wednesday, April 24, 2024 3:51 AM > To: mxhajducze...@gmail.com; Kea user's list > Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax > > > > Understood Marek, > > > > > I still dislike the fact that I cannot use option definitions that already > > exist in the very same configuration file. They are there, the parser > > should be able to reference them internally as part of the vendor-specific > > option space. > > > > I understand this statement too. However, I feel it necessary to point out > that those option definitions are so that you can fill option data in the > defined option for outbound packets not so that you can use names to classify > inbound packets. > > > > Thank you, > > Darren Ankney > > > > On Tue, Apr 23, 2024 at 9:50 AM Marek Hajduczenia > wrote: > > Hi Darren, > > > > Thanks for the feedback. > > > > I did run a packet capture from a lab device and it is attached. I hope it > comes through - this is a DHCPv6 traffic from a DOCSIS CM running in IPv6 > mode only, two relay level deep, i.e., inner relay is a vCMTS and outer relay > is the first hop router. I hope clarify some of the questions I have been > asking > > > > Packet 11 is a relayed Solicit with Option 17, containing CableLabs specific > sub-option (4491) and then inside of it, there is sub-option 2 (Device Type), > which is what I need access to classify packets correctly. > > > > > > The very same device, just EROUTER requesting address (packet 21) and again I > will need access to the very same sub-option 2 (Device Type) > > > > > > I will build a configuration pool on a Kea test node next and attempt to use > your syntax suggestion, i.e., "test": > "substring(option[17].option[2].hex,-1,7) == 'EROUTER'" but even if that > works, I still dislike the fact that I cannot use option definitions that > already exist in the very same configuration file. They are there, the parser > should be able to reference them internally as part of the vendor-specific > option space. > > > > I will report back when I am done with a test > > > > Thank you ! > > > > Marek > > > > -Original Message- > From: Kea-users On Behalf Of Darren Ankney > Sent: Tuesday, April 23, 2024 3:32 AM > To: Kea user's list > Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax > > > > Hi Marek, > > > > I failed to notice that this was DHCPv6. I was talking about option > > 125 which is DHCPv4 vendor options. Option 17 is covered in the manual here: > https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcpv6-vendor-specific-options > > I am not clear regarding the presence of option 17 in the inbound packet > (Solicit / request). Is option 17 in the packet? If so, then you may be > able to use a test line like this: > > > > "test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'" > > > > Though again, I've not tested it. But my understanding is that option > > 17 is something the server sets to send back to the client, not the reverse. > So I'm not sure this option will be present in the inbound packets to be > tested. You can easily find out what is there by taking a packet capture, > however. > > > > Thank you, > > Darren Ankney > > > > On Sun, Apr 21, 2024 at 10:00 AM wrote: > > > > > > You did hit the nail on the head, Darren, > > > > > > I have three device "classes" to deal with her: > > > > > > - DOCSIS CM, which will have Option 17 with sub-option
Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit messages
This does not seem to be intended behavior:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#interface-configuration
as this shows the following configurations all as valid:
"interfaces-config": {
"interfaces": [ "*" ]
},
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ]
},
"interfaces-config": {
"interfaces": [ "eth1", "eth3", "*" ]
},
"interfaces-config": {
"interfaces": [ "enp0s2/2001:db8::1234:abcd" ]
},
On Tue, Apr 23, 2024 at 7:04 PM Marek Hajduczenia
wrote:
> I have not been able to find a workaround for this problem on IPv6 side
> for now.
>
>
>
> Marek
>
>
>
> *From:* Kea-users *On Behalf Of *Butler,
> Glenn via Kea-users
> *Sent:* Tuesday, April 23, 2024 3:58 PM
> *To:* Kea user's list
> *Cc:* Butler, Glenn
> *Subject:* Re: [Kea-users] DHCPv6, shared network, and double-relay
> Solicit messages
>
>
>
> I need to figure this out also, as I run Kea in a container that can be
> destroyed and rebuilt anytime. I am thinking I will update the Kea config
> via a shell script run on boot/init.
>
>
>
> Would be nice if there was a "listen on all" option like 0.0.0.0 does for
> IPv4, but all the docs I have read indicate that it only binds to one
> address.
>
>
>
> On Apr 23, 2024 09:26, Marek Hajduczenia wrote:
> --
>
> *WARNING:* *External email. Please verify sender before opening
> attachments or clicking on links.*
> --
>
>
>
> So I think I found the potential solution, though I am not sure I
> understand why this happens. I had to specifically configure the unicast
> IPv6 address in the “interfaces” clause, as follows
>
>
>
> "interfaces-config": {
>
> "interfaces": [
>
> "enp6s18/2600:6ce4:0:42::130"
>
> ]
>
> },
>
>
>
> far from ideal, but it seems to force the association with the unicast
> IPv6 address (marked in yellow highlight below)
>
>
>
> root@server-kea-node1:/etc/kea# ss -tulpn
>
> Netid State Recv-Q Send-Q
> Local Address:PortPeer Address:Port
> Process
>
> udp UNCONN 0 0
> 127.0.0.1:530010.0.0.0:*
> users:(("kea-dhcp-ddns",pid=629,fd=13))
>
> udp UNCONN 0 0
> 127.0.0.53%lo:53 0.0.0.0:*
> users:(("systemd-resolve",pid=610,fd=13))
>
> udp UNCONN 0 0
> 172.17.129.130:67 0.0.0.0:*
> users:(("kea-dhcp4",pid=630,fd=17))
>
> udp UNCONN 0 0
> [2600:6ce4:0:42::130]:547 [::]:*
> users:(("kea-dhcp6",pid=2059,fd=17))
>
> udp UNCONN 0 0
> [fe80::be24:11ff:fea6:ccbe]%enp6s18:547 [::]:*
> users:(("kea-dhcp6",pid=2059,fd=18))
>
> udp UNCONN 0 0
> [ff02::1:2]%enp6s18:547 [::]:*
> users:(("kea-dhcp6",pid=2059,fd=19))
>
> tcp LISTEN 0 4096
> 127.0.0.1:8000 0.0.0.0:*
> users:(("kea-ctrl-agent",pid=628,fd=7))
>
> tcp LISTEN 0
> 128 0.0.0.0:22
> 0.0.0.0:* users:(("sshd",pid=673,fd=3))
>
> tcp LISTEN 0 4096
> 127.0.0.53%lo:53 0.0.0.0:*
> users:(("systemd-resolve",pid=610,fd=14))
>
> tcp LISTEN 0
> 4096
> *:9119 *:*
> users:(("stork-agent",pid=632,fd=8))
>
> tcp LISTEN 0
> 128
> [::]:22 [::]:*
> users:(("sshd",pid=673,fd=4))
>
> tcp LISTEN 0
> 4096
> *:8080 *:*
> users:(("stork-agent",pid=632,fd=9))
>
> tcp LISTEN 0
> 4096
> *:9547 *:* users:(("stork-agent",pid=632,fd=3)
>
>
>
> but this behavior does not seem to be documented anywhere. I did not find
> any indication that for v6 an explicit address allocation is also required,
> otherwise just the link local will be bound. Is this an expected behavior?
>
>
>
> Regards
>
>
>
> Marek
>
>
>
> *From: *mxhajducze...@gmail.com
> *Date: *Tuesday, April 23, 2024 at 9:56 AM
> *To: *'Kea user's list'
> *Subject: *RE: DHCPv6, shared network, and double-relay Solicit messages
>
> I guess netstat is deprecated. “ss” seems to show the binding but … only
> to a link local address for some reason on the v6 side.
>
>
>
> root@server-kea-node1:~# ss -tulpn
>
> Netid State Recv-Q
> Send-Q Local
> Address:Port Peer Address:Port
> Process
>
> udpUNCONN 0
> 0127.0.0.1:53001
> 0.0.0.0:* users:(("kea-dhcp-ddns",pid=629,fd=13))
>
> udpUNCONN 0
> 0
> 127.0.0.53%lo:53 0.0.0.0:*
> users:(("systemd-resolve",pid=610,fd=13))
>
> udpUNCONN 0
> 0 172.17.129.130:67
> 0.0.0.0:* users:(("kea-dhcp4",pid=630,fd=17))
>
> udp
Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
I failed to notice that this was DHCPv6. I was talking about option
125 which is DHCPv4 vendor options. Option 17 is covered in the
manual here:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcpv6-vendor-specific-options
I am not clear regarding the presence of option 17 in the inbound
packet (Solicit / request). Is option 17 in the packet? If so, then
you may be able to use a test line like this:
"test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'"
Though again, I've not tested it. But my understanding is that option
17 is something the server sets to send back to the client, not the
reverse. So I'm not sure this option will be present in the inbound
packets to be tested. You can easily find out what is there by taking
a packet capture, however.
Thank you,
Darren Ankney
On Sun, Apr 21, 2024 at 10:00 AM wrote:
>
> You did hit the nail on the head, Darren,
>
> I have three device "classes" to deal with her:
>
> - DOCSIS CM, which will have Option 17 with sub-option 2 equal to "ECM",
> - DOCSIS embedded router (eROUTER), which will have Option 17 with sub-option
> 2 equal to "EROUTER", and
> - all devices connected to the DOCSIS CM, which will not have Option 17
> (likely) - I do not control these, and these are just a random bag of devices.
>
> My train of through in here is simple: classify incoming DHCP packets
> (Solicits, since I am dealing with IPv6 only for now), and (a) match on ECM
> and give them addresses from a specific target pool, (b) then match on
> EROUTER and give them addresses from a specific target pool, and (c) whatever
> does not match on either condition, get an address from the "client" pool.
>
> In ISC, I was able to do that with "match if" statements, which work fine for
> my purposes. In Kea, I am struggling with logic here, since the parser does
> not seem to support locally defined vendor-specific class space.
>
> I am not sure whether your example below would work for me, since Option 17
> (DHCPv6) will have to have Vendor 4491 (CableLabs) defined wrapper, and only
> then option 2 inside of it. That is what the " match if (option
> docsis.device-type) = > 'EROUTER'" in ISC syntax was achieving as far as I
> know. In Kea, it would be similar to
> "test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'" but parser
> does not like it, obviously. It does seem like it is one of the missing Kea
> features?
>
> Marek
>
> -Original Message-
> From: Darren Ankney
> Sent: Sunday, April 21, 2024 4:39 AM
> To: mxhajducze...@gmail.com; Kea user's list
> Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
>
> Hi Marek,
>
> I don't think you can use vendor option space like that. This MIGHT work:
>
> "test": "substring(option[125].option[2].hex,-1,7) == 'EROUTER'"
>
> But would option 125 exist in the inbound packet? I don't think class
> testing occurs on the outbound packets... It might help to understand what
> you are trying to achieve there as there might be a better way.
>
> Thank you,
> Darren Ankney
>
> On Fri, Apr 19, 2024 at 5:22 PM Marek Hajduczenia
> wrote:
> >
> > Thank you, Darren,
> >
> > That does indeed at least pass the parser stage (actual device testing will
> > have to wait). It is a pity that a regex is not yet available. I saw it was
> > planned for 2.6 release?
> >
> > If I can build on the previous request, this part is more challenging,
> > since it relays on a custom vendor address space, specifically,
> > DOCSIS-specific sub-options in Option 17. Assume I have a
> > "device-type" sub-option defined as follows
> >
> > "option-def": [
> > {
> > "space": "vendor-4491",
> > "name": "device-type",
> > "code": 2,
> > "type": "string"
> > }]
> >
> > and then I would like to classify based on it to translate the ISC
> > compare statement of " match if (option docsis.device-type) =
> > 'EROUTER'". Following your example below
> >
> > "test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'"
> >
> > Should be theoretically possible, but I do not think the parser likes
> > it much: [substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER']
> > error: :1.17-21: syntax error, unexpected integer, expecting [
> > or . at (/etc/kea/kea-dhcp6.conf:141:17)
> >
> > Regards
> >
> > Marek
> >
> > -Origin
Re: [Kea-users] How to compile ISC KEA as shared object lib
Hi Anil, It sounds like you need to write a custom hook to be able to accomplish those goals. There is a developer's guide which is a good starting point: https://reports.kea.isc.org/dev_guide/df/d46/hooksdgDevelopersGuide.html Thank you, Darren Ankney On Sat, Apr 20, 2024 at 2:12 AM Anil kumar wrote: > > Hi Peter, > > Let's say we go the async way, I will post a message to my process from kea > process's hook callback to my process which is bookkeeping. > > Can KEAI hold off packet processing till it gets a green signal to proceed > further with the packet from my bookkeeping process ? > > If my bookkeeping code and kea were running on the same process I would have > done all necessary things in the hook callback and let KEA continue > processing the packet; Is there a way to make this step ASYNC with a > different process. ? > > With Regards > Anil Kumar S N > > On Sat, 20 Apr 2024 at 11:29, Peter Davies wrote: >> >> Hi Anil, >> I have no idea how you would go about doing this. >> However, the run script hooks library may be useful if you need Kea to send >> data >> to external processes. >> >> See: >> https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#libdhcp-run-script-so-run-script-support-for-external-hook-scripts >> >> Kind Regards Peter >> >> >> On 20/04/2024 06.49, Anil kumar wrote: >> >> Hi All, >> >> 1. Would it be possible to compile KEA as a shared object and link it to my >> process ? >> >> 2. I would like book keep and track all the clients as part of hook >> callbacks so that once address is assigned would want to updated Linux IP >> Routes tables and IP neighbor tables ? >> >> Any suggestions and guidance from the community is highly appreciated. >> >> With Regards >> Anil Kumar S N >> >> -- >> Peter Davies >> Support Engineer >> Internet Systems Corporation >> >> -- >> 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 > > > > -- > With Regards > Anil Kumar S N > -- > 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
Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
I don't think you can use vendor option space like that. This MIGHT work:
"test": "substring(option[125].option[2].hex,-1,7) == 'EROUTER'"
But would option 125 exist in the inbound packet? I don't think class
testing occurs on the outbound packets... It might help to understand
what you are trying to achieve there as there might be a better way.
Thank you,
Darren Ankney
On Fri, Apr 19, 2024 at 5:22 PM Marek Hajduczenia
wrote:
>
> Thank you, Darren,
>
> That does indeed at least pass the parser stage (actual device testing will
> have to wait). It is a pity that a regex is not yet available. I saw it was
> planned for 2.6 release?
>
> If I can build on the previous request, this part is more challenging, since
> it relays on a custom vendor address space, specifically, DOCSIS-specific
> sub-options in Option 17. Assume I have a "device-type" sub-option defined as
> follows
>
> "option-def": [
> {
> "space": "vendor-4491",
> "name": "device-type",
> "code": 2,
> "type": "string"
> }]
>
> and then I would like to classify based on it to translate the ISC compare
> statement of " match if (option docsis.device-type) = 'EROUTER'". Following
> your example below
>
> "test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'"
>
> Should be theoretically possible, but I do not think the parser likes it
> much: [substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'] error:
> :1.17-21: syntax error, unexpected integer, expecting [ or . at
> (/etc/kea/kea-dhcp6.conf:141:17)
>
> Regards
>
> Marek
>
> -Original Message-
> From: Kea-users On Behalf Of Darren Ankney
> Sent: Friday, April 19, 2024 3:08 PM
> To: Kea user's list
> Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
>
> Hi Marek,
>
> That is pseudo code generated by KeaMA as Kea doesn't support regex
> statements like ISC DHCP did. There was probably an additional line output
> that linked to some GL issue explaining. Something like this might work
> (I've not tested it):
>
> "client-classes": [
> {
> "name": "rpd-1",
> "test": "substring(relay6[1].option[18].hex,-1,9) == 'Md1:0/0.0'"
> }
> ]
>
> Thank you,
> Darren Ankney
>
> On Fri, Apr 19, 2024 at 4:27 PM Marek Hajduczenia
> wrote:
> >
> > Dear colleagues,
> >
> >
> >
> > I ran into a bit of a challenge with the conversion of the config from ISC
> > to Kea, namely this little class definition gem:
> >
> >
> >
> > class "rpd-1" { match if v6relay( 1, option dhcp6.interface-id ) ~=
> > "Md1:0/0.0$"; }
> >
> >
> >
> > What it does, as you can tell, it matches on the inner relay interface-id
> > field in the DHCPv6 messages. Nothing fancy, it does work as tested.
> >
> >
> >
> > I have been looking at the available options and nothing comes to mind
> > so I used keama for automatic conversion and it generated something
> > pretty complex, as follows. Additionally, it is commented out, so I
> > assume this is a non-working configuration element (?)
> >
> >
> >
> > "client-classes": [
> >
> > {
> >
> > "name": "rpd-1"
> >
> > // /// match if (v6relay(1, option dhcp6.interface-id)) ~= 'Md1:0/0.0$'
> >
> > // "match-if": {
> >
> > //"regex-match": {
> >
> > // "left": {
> >
> > //"v6relay": {
> >
> > // "relay": 1,
> >
> > // "relay-option": {
> >
> > //"option": {
> >
> > // "universe": "dhcp6",
> >
> > // "name": "interface-id",
> >
> > // "code": 18
> >
> > //}
> >
> > // }
> >
> > //}
> >
> > // },
> >
> > // "right": "Md1:0/0.0$"
> >
> > //}
> >
> > // }
> >
> > }]
> >
> >
> >
> > If I try to remove the comment markup and apply it with Kea 2.4.1, the
> > parser does not like the “match-if” statement for some reason. I cannot
> > locate it in t
Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
That is pseudo code generated by KeaMA as Kea doesn't support regex
statements like ISC DHCP did. There was probably an additional line
output that linked to some GL issue explaining. Something like this
might work (I've not tested it):
"client-classes": [
{
"name": "rpd-1",
"test": "substring(relay6[1].option[18].hex,-1,9) == 'Md1:0/0.0'"
}
]
Thank you,
Darren Ankney
On Fri, Apr 19, 2024 at 4:27 PM Marek Hajduczenia
wrote:
>
> Dear colleagues,
>
>
>
> I ran into a bit of a challenge with the conversion of the config from ISC to
> Kea, namely this little class definition gem:
>
>
>
> class "rpd-1" { match if v6relay( 1, option dhcp6.interface-id ) ~=
> "Md1:0/0.0$"; }
>
>
>
> What it does, as you can tell, it matches on the inner relay interface-id
> field in the DHCPv6 messages. Nothing fancy, it does work as tested.
>
>
>
> I have been looking at the available options and nothing comes to mind so I
> used keama for automatic conversion and it generated something pretty
> complex, as follows. Additionally, it is commented out, so I assume this is a
> non-working configuration element (?)
>
>
>
> "client-classes": [
>
> {
>
> "name": "rpd-1"
>
> // /// match if (v6relay(1, option dhcp6.interface-id)) ~= 'Md1:0/0.0$'
>
> // "match-if": {
>
> //"regex-match": {
>
> // "left": {
>
> //"v6relay": {
>
> // "relay": 1,
>
> // "relay-option": {
>
> //"option": {
>
> // "universe": "dhcp6",
>
> // "name": "interface-id",
>
> // "code": 18
>
> //}
>
> // }
>
> //}
>
> // },
>
> // "right": "Md1:0/0.0$"
>
> //}
>
> // }
>
> }]
>
>
>
> If I try to remove the comment markup and apply it with Kea 2.4.1, the parser
> does not like the “match-if” statement for some reason. I cannot locate it in
> the list of Kea statements, so not sure why it would be generated by keama.
> However, the bigger question is on how to build a Kea-compatible match on
> such embedded message. Any help here would be really appreciated.
>
>
>
> Apr 19 18:54:20 server-kea-node1 systemd[1]: Started Kea DHCPv6 Service.
>
> Apr 19 18:54:20 server-kea-node1 kea-dhcp6[2099]: 2024-04-19 18:54:20.202
> ERROR [kea-dhcp6.dhcp6/2099.841038976] DHCP6_INIT_FAIL failed to initialize
> Kea server: configuration error using file '/etc/kea/kea-dhcp6.conf':
> /etc/kea/kea-dhcp6.conf:118.9-18: syntax error, unexpected constant string,
> expecting }
>
> Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service:
> Main process exited, code=exited, status=1/FAILURE
>
> Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service:
> Failed with result 'exit-code'.
>
>
>
> Regards
>
>
>
> Marek
>
> --
> 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
Re: [Kea-users] migrating an existing LDAP configuration
That is mostly accurate. Stork manages Kea via the API, so without the hooks that provide such, Stork won't be able to manage the system either. Thank you, Darren Ankney On Fri, Apr 12, 2024 at 10:53 AM Dan Geist wrote: > > 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 -- 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
I clicked "send" too soon. I meant to share this knowledge base article that is slightly relevant. The focus is on using Kea with pgpool-ii but it does show an example of storing the configuration in the database and working with it via the API at the end: https://kb.isc.org/docs/experimenting-with-postgresql-high-availability Thank you, Darren Ankney On Fri, Apr 12, 2024 at 10:50 AM Darren Ankney wrote: > > Hi Udo, > > That is correct. To store the configuration in the database, you > would need the Configuration Backend Commands hook: > https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#libdhcp-cb-cmds-so-configuration-backend-commands > which does require a support subscription. > > Thank you, > Darren Ankney > > On Fri, Apr 12, 2024 at 8:10 AM Udo Rader 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
Re: [Kea-users] migrating an existing LDAP configuration
Hi Udo, That is correct. To store the configuration in the database, you would need the Configuration Backend Commands hook: https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#libdhcp-cb-cmds-so-configuration-backend-commands which does require a support subscription. Thank you, Darren Ankney On Fri, Apr 12, 2024 at 8:10 AM Udo Rader 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
Re: [Kea-users] different lease times
On Fri, Apr 5, 2024 at 3:55 PM Jason Keltz wrote:
>
> Darren,
>
> I take that back (partially)...
>
> At least one of
>
> "client-classes": [
> {
> "name": "long-lease",
> "valid-lifetime": 604800
> },
> {
> "name": "short-lease",
> "test": "member('KNOWN') and not member('long-lease')"
> }
> ],
>
> ... Is still needed to define the alternate lease time. Although I could be
> explicit:
>
> "client-classes": [
> {
> "name": "long-lease",
> "valid-lifetime": 604800
> },
> {
> "name": "short-lease",
> "valid-lifetime": 300
> "test": "member('KNOWN') and not member('long-lease')"
> }
> ],
>
> I do wonder if I can leave the test condition out of short-lease, again
> because I define who gets a short-lease and a long-lease explicitly.
That is a good idea - remove the test line (since you add the clients
to one or the other class in the reservations) and be explicit with
the valid-lifetime in each class. Then you could have some other
default valid-lifetime for clients that don't apply to either class
(if exist).
--
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] different lease times
Hi Jason,
Here you go. Not 100% sure it will work, however. Decided to make
the default lease 300 and set the long lease time in the class that
reserved clients are added to. Also note that I moved the reservation
inside the subnet. This was to avoid any situation where you might
need to use "early-global-reservations-lookup" to make things work
properly.
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.0.0.1"
}
],
"client-classes": [
{
"name": "long-lease",
"valid-lifetime": 604800
},
{
"name": "short-lease",
"test": "member('KNOWN') and not member('long-lease')"
}
],
"valid-lifetime": 300,
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200",
"client-class": "short-lease"
}
],
"reservations": [
{
"hw-address": "00:00:00:11:11:11",
"ip-address": "10.1.2.12",
"client-classes": [
"long-lease"
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
Thank you,
Darren Ankney
On Fri, Apr 5, 2024 at 2:17 PM Jason Keltz wrote:
>
> Hi Darren,
>
> I tries this, but no success. When I restart kea it complains that the class
> long-lease doesn't exist. You defined short-lease as being known and not in
> long-lease, but how do you define long-lease?
>
> In the actual reservations, I tried both defining client-class of long-lease,
> and when the failed, I tried client-classes of long-lease, but kea still
> wants long-lease defined.
>
> The format of my configuration with reservations (in "pseudo-code")
>
> subnet4--
> define subnet id 1
> define pool for subnet id 1
> include subnet id 1 reservations file - these reservations all define
> ip-address
>
> define subnet id 2
> define pool for subnet id 2
> include subnet id 2 reservations file - these reservations all define
> ip-address
> ...
>
> Include global reservations file (reservations specifying hw-address,
> hostname, and some option-data for each host) - no ip
>
> The goal is: hosts that get an IP from any pool have a shorter lease time,
> and hosts that have an ip-address reserved for them get a much longer lease
> time
>
> Jason.
>
>
> From: Kea-users on behalf of Darren Ankney
>
> Sent: Friday, April 5, 2024 5:53 AM
> To: Kea user's list
> Subject: Re: [Kea-users] different lease times
>
> Hi Jason,
>
> Ahh yes. I failed to remember the goal here. All clients would be in
> that class. I assume you have reservations for these static clients?
> You could, in these reservations add them to another class
> ("long-lease"). Then you could alter the test line in short lease:
>
> "test": "member('KNOWN') and not member('long-lease')",
>
> I'm not entirely sure that will work. It depends on where your
> reservations are set. You may have to experiment with:
> "early-global-reservations-lookup"
>
> FYI, if you'd like to see a change to "valid-lifetime" (such as
> allowing use inside a pool), then you could add a comment indicating
> your support of: https://gitlab.isc.org/isc-projects/kea/-/issues/953
> Be sure and describe, in detail, your use case for this change.
>
> Thank you,
> Darren Ankney
>
> On Thu, Apr 4, 2024 at 12:33 PM Jason Keltz wrote:
> >
> > Hi Darren,
> >
> > I tried your suggestion, but unfortunately, it didn't quite work.
> > I modified my kea configuration as you specified. My defaul
Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu, That is correct. You could set one of them to maintenance mode to perform some maintenance. There would be no way to do this if the server were down, however, and so you wouldn't be able to prevent it resuming service in the event of an outage. Thank you, Darren Ankney On Fri, Apr 5, 2024 at 11:56 AM Xiao, Yu (CCI-Atlanta) via Kea-users wrote: > > Hi Darren, > > > > But imagine you have a maintenance, and you don’t want the primary revert > back until the end of maintenance window. I found this API > “ha-maintenance-start” seems can be used for such situation. > > > > > > > > Best Regards, > > Yu > > > > > > From: Kea-users on behalf of Darren Ankney > > Date: Friday, April 5, 2024 at 5:40 AM > To: Kea user's list > Subject: Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors > > Hi Yu, > > > > I have another question, I re-enabled the primary kea-01 again, after that, > > I noticed Kea-01 seems to have retaken the role of the primary again > > automatically. Is there a way we can keep the standby continue serve as > > temporary primary instead of revert automatically? > > Not that I am aware of. I think the configuration designated primary > will take over if all of the check boxes are ticked. > > > Also, is there a convenient way to check both hosts which one is serving > > the DHCP lease now instead of checking the details of the debug logs? I > > don’t remember see those details from the 2.4.1 documentation. > > You can check with the API: > https://urldefense.com/v3/__https://kea.readthedocs.io/en/kea-2.4.1/api.html*status-get__;Iw!!Hit2Ag!2xl9qbmkix1hSKUZDE9pxZvhL3AjsqTjNtXpsoyCPxsUTJ_6pI5KG-tkxPD2Kw3AvHq5eDXMy-OEbXhoZu8g$ > > Thank you, > Darren Ankney > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at > https://urldefense.com/v3/__https://www.isc.org/contact/__;!!Hit2Ag!2xl9qbmkix1hSKUZDE9pxZvhL3AjsqTjNtXpsoyCPxsUTJ_6pI5KG-tkxPD2Kw3AvHq5eDXMy-OEbXm6YOo0$ > for more information. > > To unsubscribe visit > https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/kea-users__;!!Hit2Ag!2xl9qbmkix1hSKUZDE9pxZvhL3AjsqTjNtXpsoyCPxsUTJ_6pI5KG-tkxPD2Kw3AvHq5eDXMy-OEbYNJaLhi$ > . > > Kea-users mailing list > Kea-users@lists.isc.org > https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/kea-users__;!!Hit2Ag!2xl9qbmkix1hSKUZDE9pxZvhL3AjsqTjNtXpsoyCPxsUTJ_6pI5KG-tkxPD2Kw3AvHq5eDXMy-OEbYNJaLhi$ > > -- > 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
Re: [Kea-users] different lease times
Hi Jason,
Ahh yes. I failed to remember the goal here. All clients would be in
that class. I assume you have reservations for these static clients?
You could, in these reservations add them to another class
("long-lease"). Then you could alter the test line in short lease:
"test": "member('KNOWN') and not member('long-lease')",
I'm not entirely sure that will work. It depends on where your
reservations are set. You may have to experiment with:
"early-global-reservations-lookup"
FYI, if you'd like to see a change to "valid-lifetime" (such as
allowing use inside a pool), then you could add a comment indicating
your support of: https://gitlab.isc.org/isc-projects/kea/-/issues/953
Be sure and describe, in detail, your use case for this change.
Thank you,
Darren Ankney
On Thu, Apr 4, 2024 at 12:33 PM Jason Keltz wrote:
>
> Hi Darren,
>
> I tried your suggestion, but unfortunately, it didn't quite work.
> I modified my kea configuration as you specified. My default
> valid-lifetime is 4000.
> In short-lease, I defined valid-lifetime to be 300 (exactly as yours is
> specified).
> In the pool used by my test host, I added the client-class for
> short-lease as you specified.
> I restarted kea dhcp server to ensure it re-read the configuration.
> I checked for any existing lease from my test host "jastest", and there
> was none.
> I booted...
> The lease was registered, and was for 300 seconds...
>
> [ { "arguments": { "leases": [ { "client-id": "01:ac:24:11:5f:be:b7",
> "cltt": 1712245568, "fqdn-fwd": false, "fqdn-rev": false, "hostname":
> "jastest", "hw-address": "ac:24:11:5f:be:b7", "ip-address":
> "130.63.XX.YY", "state": 0, "subnet-id": 6, "valid-lft": 300 } ] },
> "result": 0, "text": "1 IPv4 lease(s) found." } ]
>
> So good, so far, right?
>
> I then assigned my test host an IP, cleared the DHCP lease for it, and
> booted... the host got the proper IP outside of the pool, but it ALSO
> had valid-lifetime 300 and not 4000!
>
> Is this because:
>
> "client-classes": [
> {
> "name": "short-lease",
> "test": "member('KNOWN')",
> "valid-lifetime": 300
>}
> ],
>
> ... automatically adds "short-lease" to any member of KNOWN?
>
> I just wish that ISC made it so that valid-lifetime could be configured
> in pool.
>
> Jason.
>
> On 4/4/24 05:34, Darren Ankney wrote:
> > Hi Jason,
> >
> > Something like this might work:
> >
> > "client-classes": [
> >{
> > "name": "short-lease",
> > "test": "member('KNOWN')",
> > "valid-lifetime": 300
> >}
> > ],
> > ...
> > "subnet4": [
> > {
> > "subnet": "10.1.2.0/24",
> > "id": 1,
> > "option-data": [
> > {
> > "name": "routers",
> > "data": "10.1.2.1"
> > }
> > ],
> > "valid-lifetime": 300,
> > "pools": [
> > {
> > "pool": "10.1.2.100-10.1.2.200",
> > "client-class": [ "short-lease" ]
> > }
> > ]
> > }
> > ],
> >
> > On Wed, Apr 3, 2024 at 10:56 AM Jason Keltz wrote:
> >> Hi Darren,
> >>
> >> Yes - "lease-lifetime" was my error - I meant "valid-lifetime".
> >> I understand that I cannot apply "valid-lifetime" to a pool (although I
> >> feel like I should be able to).
> >> I already define client-class as "KNOWN" in all my pools so that unknown
> >> hosts can't get an IP, and I understand that I can't use a second
> >> client-class of "short-lease" in each pool.
> >> I looked in the Kea code where options are defined, and thought I would
> >> be able to add:
> >>
> >> {
> >> "name": "dhcp-lease-time"
Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu, > I have another question, I re-enabled the primary kea-01 again, after that, I > noticed Kea-01 seems to have retaken the role of the primary again > automatically. Is there a way we can keep the standby continue serve as > temporary primary instead of revert automatically? Not that I am aware of. I think the configuration designated primary will take over if all of the check boxes are ticked. > Also, is there a convenient way to check both hosts which one is serving the > DHCP lease now instead of checking the details of the debug logs? I don’t > remember see those details from the 2.4.1 documentation. You can check with the API: https://kea.readthedocs.io/en/kea-2.4.1/api.html#status-get Thank you, Darren Ankney -- 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] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu, Basically you are not waiting for clients to go down. Clients will attempt to renew at lease half-life. "max-unacked-clients" is a way of confirming that the other server is actually down. In certain scenarios it would be possible that the two servers couldn't see each other but COULD see the clients. If they were both answering the clients, that could lead to duplicate IP address assignment and the like. Thank you, Darren Ankney On Wed, Apr 3, 2024 at 5:32 PM Xiao, Yu (CCI-Atlanta) wrote: > > Hi Darren, > > > > Thank you for your information. I adjusted the parameter and now it is > working. But I have a question, why should we need this "max-unacked-clients" > parameter? Because imagine we have 1k devices in this network, and they all > have their IP assigned by dhcp_1, then suddenly dhcp_1 went down, but at this > moment, all devices still have their assigned IPs. Then if we design dhcp_2 > to become primary after losing sync time, we may be able to bring dhcp_2 to > primary before T2, so there won’t be large number of devices offline. But if > we wait until offline devices observed, then it could be too late and many > devices already offline. > > > > > > > > Best Regards, > > Yu > > > > > > From: Kea-users on behalf of Xiao, Yu > (CCI-Atlanta) via Kea-users > Date: Wednesday, April 3, 2024 at 9:12 AM > To: Darren Ankney , Kea user's list > > Cc: Xiao, Yu (CCI-Atlanta) > Subject: Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors > > Hi Darren, > > > > Thank you for the explanation. Let me investigate further. > > > > > > Best Regards, > > Yu > > > > > > From: Darren Ankney > Date: Wednesday, April 3, 2024 at 9:06 AM > To: Kea user's list > Cc: Xiao, Yu (CCI-Atlanta) > Subject: Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors > > Hi Yu, > > Look in your logs for messages containing > HA_COMMUNICATION_INTERRUPTED_CLIENT4_UNACKED. These messages indicate > how many clients are still needed before the failover will occur. > Your settings specify: > > "max-ack-delay": 300, > "max-unacked-clients": 5, > > max-ack-delay is specified in milliseconds so pretty much every client > that reaches one in the "elapsed time" option in DHCPv6 will meet the > criteria of an "unacked" client. Once the sixth client shows up, > failover should occur. That log message should repeat with each new > client being tracked giving statistics about how many more are needed. > > Thank you, > Darren Ankney > > > On Tue, Apr 2, 2024 at 12:39 PM Xiao, Yu (CCI-Atlanta) via Kea-users > wrote: > > > > Hi experts, > > > > > > > > I have tested further in my lab and found the answers to my questions. HA > > works when I don’t enable the control agent. As for the debug log, I think > > there’s a potential document bug for 2.4.1 document. Cause you can’t assign > > the log to /var/log folder, you need to assign it to /tmp/ folder. > > > > > > > > I found a problem on myside on firewall, after I fixed it. Now seems the HA > > is working. But still having one problem. When I used “systemctl stop > > kea-dhcp6” on the primary, for example, kea01, then the standby DHCPv6 > > server kea03 won’t process the DHCP packets from clients. I waited for more > > time, but the behaviors won’t change. The standby server just drop those > > DHCP packets from clients due to “dropping query to be processed by > > another server”. > > > > > > > > According to Kea documentation, this happens when: > > > > > > > > “%1: dropping query to be processed by another server > > > > > > > > This debug message is issued when the received DHCPv6 query is dropped by > > this server because it should be served by another server. This is the case > > when the remote server was designated to process the packet as a result of > > load balancing or because it is a primary server in the hot standby > > configuration. The argument provides client identification information > > retrieved from the query.” > > > > > > > > But now since the primary service is down, so the standby server should > > become the primary one, right? But seems not the case. Also from the debug > > logs, I can’t see the current status of the remaining server, technically > > we should be able to see its status changed from standby to primary, right? > > But I only see the role information from the logs before I shut down the > > kea service
Re: [Kea-users] different lease times
Hi Jason,
Something like this might work:
"client-classes": [
{
"name": "short-lease",
"test": "member('KNOWN')",
"valid-lifetime": 300
}
],
...
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"valid-lifetime": 300,
"pools": [
{
"pool": "10.1.2.100-10.1.2.200",
"client-class": [ "short-lease" ]
}
]
}
],
On Wed, Apr 3, 2024 at 10:56 AM Jason Keltz wrote:
>
> Hi Darren,
>
> Yes - "lease-lifetime" was my error - I meant "valid-lifetime".
> I understand that I cannot apply "valid-lifetime" to a pool (although I
> feel like I should be able to).
> I already define client-class as "KNOWN" in all my pools so that unknown
> hosts can't get an IP, and I understand that I can't use a second
> client-class of "short-lease" in each pool.
> I looked in the Kea code where options are defined, and thought I would
> be able to add:
>
> {
> "name": "dhcp-lease-time",
> "data": "300"
> }
>
> ... to "option-data" section for each host, but this didn't work
> either. I see that in the Kea docs, all-options.json skips from code 49
> to code 52, thereby skipping over code 51 which is lease time.
>
> I tried adding "code": 51, to the section to my option above, but it
> didn't make any difference.
>
> I tried adding "valid-lifetime" to the "reservations" section to see if
> that would work, but it would not.
>
> Therefore, I'm still not sure how to implement different lease times for
> pools.
>
> Jason.
>
> On 4/3/24 06:35, Darren Ankney wrote:
> > Hi Jason,
> >
> >
> >> would it be valid syntax to also set lease-lifetime in the pool instead of
> >> using the class?
> >>
> >> "pools": [
> >> {
> >> "pool": "10.1.2.100-10.1.2.200",
> >> "lease-lifetime": "300"
> >> }
> >> ]
> > I cannot find evidence of a parameter called "lease-lifetime" but
> > "valid-lifetime" cannot be set inside a pools [] block.
> >
> >> I already assign the pools to "client-class": "KNOWN" - can I specify
> >> multiple classes? "client-class": "KNOWN", "short-lease"?
> >> If I use a class to do this, is the "valid-lifetime": 300 inside the
> >> subnet definition necesary? It is repeated in both the subnet and the
> >> client-class short-lease.
> > The "valid-lifetime" inside the subnet was a mistake. That was a
> > relic of some earlier testing. You cannot specify multiple classes on
> > a client-class line. I don't know if you can have both client-class
> > and client-classes as I've never tried. "client-class" does not do
> > the same thing that "client-classes" does.
> >
> > Thank you,
> > Darren Ankney
>
> --
> 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
Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu,
Look in your logs for messages containing
HA_COMMUNICATION_INTERRUPTED_CLIENT4_UNACKED. These messages indicate
how many clients are still needed before the failover will occur.
Your settings specify:
"max-ack-delay": 300,
"max-unacked-clients": 5,
max-ack-delay is specified in milliseconds so pretty much every client
that reaches one in the "elapsed time" option in DHCPv6 will meet the
criteria of an "unacked" client. Once the sixth client shows up,
failover should occur. That log message should repeat with each new
client being tracked giving statistics about how many more are needed.
Thank you,
Darren Ankney
On Tue, Apr 2, 2024 at 12:39 PM Xiao, Yu (CCI-Atlanta) via Kea-users
wrote:
>
> Hi experts,
>
>
>
> I have tested further in my lab and found the answers to my questions. HA
> works when I don’t enable the control agent. As for the debug log, I think
> there’s a potential document bug for 2.4.1 document. Cause you can’t assign
> the log to /var/log folder, you need to assign it to /tmp/ folder.
>
>
>
> I found a problem on myside on firewall, after I fixed it. Now seems the HA
> is working. But still having one problem. When I used “systemctl stop
> kea-dhcp6” on the primary, for example, kea01, then the standby DHCPv6 server
> kea03 won’t process the DHCP packets from clients. I waited for more time,
> but the behaviors won’t change. The standby server just drop those DHCP
> packets from clients due to “dropping query to be processed by another
> server”.
>
>
>
> According to Kea documentation, this happens when:
>
>
>
> “%1: dropping query to be processed by another server
>
>
>
> This debug message is issued when the received DHCPv6 query is dropped by
> this server because it should be served by another server. This is the case
> when the remote server was designated to process the packet as a result of
> load balancing or because it is a primary server in the hot standby
> configuration. The argument provides client identification information
> retrieved from the query.”
>
>
>
> But now since the primary service is down, so the standby server should
> become the primary one, right? But seems not the case. Also from the debug
> logs, I can’t see the current status of the remaining server, technically we
> should be able to see its status changed from standby to primary, right? But
> I only see the role information from the logs before I shut down the kea
> service on primary server.
>
>
>
> Config:
>
> # HA related hooks configuration
>
> "hooks-libraries": [{
>
> "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
>
> "parameters": { }
>
> }, {
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
>
> "parameters": {
>
> "high-availability": [{
>
> "this-server-name": "kea_home3",
>
> "mode": "hot-standby",
>
> "heartbeat-delay": 100,
>
> "max-response-delay": 200,
>
> "max-ack-delay": 300,
>
> "max-unacked-clients": 5,
>
> "peers": [{
>
> "name": "kea_home1",
>
> "url": http://192.168.100.197:8000/,
>
> "role": "primary",
>
> "auto-failover": true
>
> }, {
>
> "name": "kea_home3",
>
> "url": http://192.168.100.70:8000/,
>
> "role": "standby",
>
> "auto-failover": true
>
> }]
>
> }]
>
> }
>
> }],
>
>
>
>
>
> Logs:
>
> 2024-04-02 12:03:41.696 DEBUG [kea-dhcp6.http/15314.139903918055424]
> HTTP_CLIENT_REQUEST_SEND_DETAILS detailed information about request sent to
> http://192.168.100.197:8000/:
>
> POST / HTTP/1.1
>
> Host: 192.168.100.197
>
> Content-Length: 53
>
> Content-Type: application/json
>
>
>
> { "command": "ha-heartbeat", "service": [ "dhcp6" ] }
>
> 2024-04-02 12:03:41.696 DEBUG [kea-dhcp6.http/15314.139903754057472]
> HTTP_BAD_SERVER_RESPONSE_RECEIVED bad response received when communicating
> with http://192.168.100.197:8000/: Connection refused
>
> 2024-04-02 12:03:41.696 WARN [kea-dhcp6.ha-hooks/15314.139
Re: [Kea-users] different lease times
Hi Jason,
> would it be valid syntax to also set lease-lifetime in the pool instead of
> using the class?
>
> "pools": [
> {
> "pool": "10.1.2.100-10.1.2.200",
> "lease-lifetime": "300"
> }
> ]
I cannot find evidence of a parameter called "lease-lifetime" but
"valid-lifetime" cannot be set inside a pools [] block.
>
> I already assign the pools to "client-class": "KNOWN" - can I specify
> multiple classes? "client-class": "KNOWN", "short-lease"?
> If I use a class to do this, is the "valid-lifetime": 300 inside the subnet
> definition necesary? It is repeated in both the subnet and the client-class
> short-lease.
The "valid-lifetime" inside the subnet was a mistake. That was a
relic of some earlier testing. You cannot specify multiple classes on
a client-class line. I don't know if you can have both client-class
and client-classes as I've never tried. "client-class" does not do
the same thing that "client-classes" does.
Thank you,
Darren Ankney
--
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] different lease times
Hi Jason,
Something like this should do:
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.0.0.1"
}
],
"client-classes": [
{
"name": "short-lease",
"only-if-required": true,
"valid-lifetime": 300
}
],
"valid-lifetime": 604800,
"reservations": [
{
"hw-address": "00:00:00:11:11:11",
"ip-address": "10.1.2.12"
}
],
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"valid-lifetime": 300,
"pools": [
{
"pool": "10.1.2.100-10.1.2.200",
"require-client-classes": [ "short-lease" ]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
Thank you,
Darren Ankney
On Mon, Apr 1, 2024 at 3:05 PM Jason Keltz wrote:
>
> Hi..
>
> At the top of my KEA configuration file, I specify "valid-lifetime" for
> leases. Most of my hosts have a static IP which is allocated via Kea.
> Those leases can be quite lengthy. On the other hand, each subnet has a
> dynamic pool as well. How can I define a much lower lease time for the
> hosts that are being allocated dynamic IP?
>
> Would this be an option in "reservations"? Can I avoid duplicating for
> every host?
>
> reservations": [
> {
> "hw-address": "ab:cd:ef:gh:ij:kl",
> "hostname": "myhost",
> "option-data": [
> {
> "name": "log-servers",
> "data": "w.x.y.z"
> },
> {
> "name": "domain-name-servers",
> "data": "a.b.c.d,e.f.g.h"
> },
> {
> "name": "domain-name",
> "data": "mydomain.com"
> }
> ]
> },
> ...
>
> ]
>
> Jason.
>
> --
> 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
Re: [Kea-users] pxe booting
Hi,
Are you noticing any logged errors or are the clients just not
receiving the pxe boot file? Can you look for the log messages that
pertain to testing for matches to each class? It might be best to
work with one type of client at a time to get things working correctly
for that client. Lessons learned will apply to the other clients.
Thank you,
Darren Ankney
On Mon, Apr 1, 2024 at 1:17 PM Andrew Meyer via Kea-users
wrote:
>
> Hello,
> I'm in the process of switching my ISC-DHCPd server running on RaspberrryPi
> and CentOS/RHEL to KEA. However i'm having trouble with getting PXE boot
> configured with this. I am using vmwarre / Proxmox for virtual machines and
> cobbler to do installations.
>
> I am using these sites as reference for pxe boot config but it doesn't seem
> to be working.
>
> https://www.growse.com/2018/08/29/pxe-booting-a-raspberry-pi.html
> https://forum.ipxe.org/showthread.php?tid=7986
> https://superuser.com/questions/1805388/pxe-boot-esxi-8-on-intel-nuc-12
> https://lists.isc.org/pipermail/kea-users/2022-February/003353.html
>
>
> Here is what I have configured in the current isc-dhcpd setup for pxe boot.
>
> allow booting;
> allow bootp;
> always-broadcast on;
> # class "vmware" { match if binary-to-ascii(16,8,":",substring(hardware, 1,
> 2)) = "00:29:1b"; }
> class "pxeclients" { match if substring (option vendor-class-identifier, 0,
> 9) = "PXEClient"; next-server 10.1.2.3; if option arch = 00:06 { filename
> "grub/grub-x86.efi"; } else if option arch = 00:07 { filename
> "grub/grub-x86_64.efi"; } else if option arch = 00:09 { filename
> "grub/grub-x86_64.efi"; } else { filename "pxelinux.0"; }}
> if exists user-class and option user-class = "iPXE" {
> filename "http://10.1.2.3/cblr/svc/op/gpxe/system/[system]; ;
> } elsif option arch != 00:00 {
>filename "gpxe/snponly.efi" ;
> } else {
> filename "gpxe/undionly.kpxe" ;
> }
> }
>
> Here is what I put in my kea-dhcpd4.conf
> {
> "Dhcp4": {
> "client-classes": [
> {
> "name": "XClient_iPXE",
> "test": "substring(option[77].hex,0,4) == 'iPXE'",
> "boot-file-name":
> "http://://"
> },
> {
> "name": "UEFI-32-1",
> "test": "substring(option[60].hex,0,20) ==
> 'PXEClient:Arch:6'",
> "boot-file-name": "ipxe/i386/ipxe.efi"
> },
> {
> "name": "UEFI-32-2",
> "test": "substring(option[60].hex,0,20) ==
> 'PXEClient:Arch:2'",
> "boot-file-name": "ipxe/i386/ipxe.efi"
> },
> {
> "name": "UEFI-64-1",
> "test": "substring(option[60].hex,0,20) ==
> 'PXEClient:Arch:7'",
> "boot-file-name": "ipxe/x86_64/ipxe.efi"
> },
> {
> "name": "UEFI-64-2",
> "test": "substring(option[60].hex,0,20) ==
> 'PXEClient:Arch:8'",
> "boot-file-name": "ipxe/x86_64/ipxe.efi"
> },
> {
> "name": "UEFI-64-3",
> "test": "substring(option[60].hex,0,20) ==
> 'PXEClient:Arch:9'",
> "boot-file-name": "ipxe/x86_64/ipxe.efi"
> },
> {
> "name": "Legacy",
> "test": "substring(option[60].hex,0,20) ==
> 'PXEClient:Arch:0'",
> "boot-file-name": "ipxe/undionly.kpxe"
> }
> ],
> "interfaces-config": { "interfaces": [] },
> "control-socket": {
> "socket-type": "unix",
> "socket-name": "/run/kea/kea4-ctrl-socket"
> },
> "lease-database": {
> "type": "memfile",
> "lfc-interval": 3600,
> "name": "/var/lib/kea/kea-leases4.csv"
> },
> "expired-leases-processing": {
> "reclaim-timer-wait-time"
Re: [Kea-users] DHCP6 host reservation
Hi Christina,
The simplest explanation is that the mac address (hw-address) is not
present in the DHCP packet. In DHCPv6, the mac address may not be
present (it is usually only in the packet if the DHCP server is local,
or the relay agent is adding option 79 to the packet when relaying),
though Kea tries hard to find out what it is. You can confirm what is
in the packet using tcpdump and wireshark. See here for further
information:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#mac-hardware-addresses-in-dhcpv6
Thank you,
Darren Ankney
On Fri, Mar 29, 2024 at 1:50 PM Cristina Bulfon
wrote:
>
> Dear all,
>
>
> I am newbie to the Kea DHCP6, I’d like to use only host reservations and for
> my understanding in the clause “subnet6” in addition to “reservations” must
> be configured also the “pools” but the reservations should have priority in
> providing IPv6.
>
> Followis a piece of configuration :
>
> ...
>
>
> "host-reservation-identifiers": ["hw-address"],
>
>"subnet6": [
>
> {
>
> "id": 1,
>
> "subnet": "2001:760:422c:35::/64" ,
>
> "reservations-in-subnet": true,
>
> "reservations-out-of-pool": false,
>
> "reservations-global": false,
>
> "interface": "ens3",
>
> "reservations" : [ ],
>
> "pools": [{ "pool": "2001:760:422c:35::2
> -2001:760:422c:35::::" } ]
>
>}
>
>
> The include file has the following syntax
>
>
> {"hostname": “X”,”hw-address": “XX:YY:ZZ:AA:00:0o”,”ip-addresses":
> ["2001:760:422c:35::XYZ”] }
>
>
> ….
>
>
> With this configuration the ipv6 client get the IP from the pool and not from
> reservations, how can I avoid this?
>
>
> Any help is appreciated, thank you.
>
>
> Regards,
>
> Cristina
>
>
> --
> 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
Re: [Kea-users] Kea DDNS update-on-renew
Hi Isaac, I think that kea-dhcp-ddns just uses standard nsupdate commands as described by RFC no matter the brand of server on the other end. You might be interested in: https://gitlab.isc.org/isc-projects/kea/-/issues/3257 which would prevent frequent updates from clients to DNS servers based on the cached lease threshold settings in Kea (https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#lease-caching). Thank you, Darren Ankney On Thu, Mar 28, 2024 at 3:50 PM Isaac Brummel wrote: > > Hi, > > I have Kea running in a network that has short lived hosts so the lease time > is set to 10 minutes. I have the "ddns-update-on-renew" setting enabled to > provide some DNS healing if a record gets removed for whatever reason. The > issue I've run into is the DDNS services performs a REMOVE then ADD of the > record on renew. This causes a brief moment where the DNS record doesn't > exist and querying the record returns nothing. I like the idea of having the > "ddns-update-on-renew" setting enabled but this the issue has become > problematic. Is there a way the DDNS service can more intelligently detect if > the DNS record truly needs updating, almost like a "create or update on > renew"? I looked through the documentation and hooks but did not come up with > anything, except for possibly utilizing the "run script" hook to perform > custom logic. Curious if the community has any ideas about this. Related, > does Bind offer a better integration with Kea? Currently I am using PowerDNS > which the DDNS services just sends standard dynamic dns add/remove requests > to. > > Thanks, > Isaac > -- > 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
Re: [Kea-users] KEA DHCP - BOOTP config
Hi Philippe,
There is no other way to configure option 125 (vivso) other than
detailed here:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#dhcpv4-vendor-specific-options
Thank you,
Darren Ankney
On Thu, Mar 28, 2024 at 3:19 PM Philippe EA wrote:
>
> Hi all,
>
>
>
> I’m quite new on KEA DHCP, and I’m trying to setup a proper config using
> BOOTP, here is my current config for boot-file from an HTTP server
> (10.171.20.72) :
>
>
>
> {
>
> "subnet4": [ {
>
> "reservations": [
>
> {
>
> "hostname": "SCG",
>
> "hw-address": "00:80:d4:0c:30:76",
>
> "ip-address": "10.171.20.22",
>
> "next-server": "10.171.20.254",
>
> "server-hostname": "10.171.20.72”,
>
> "boot-file-name": "dhcp-ztp-txt”
>
> } ]
>
> } ]
>
> }
>
>
>
> For this part I think that should work.
>
>
>
> My main concern is about option 125 to transfer a firmware image, I’m not
> sure about the way to setup that, I’ve seen a way with vivso but I need to
> understand how it works.
>
>
>
> Is there a different way for this option ? Maybe an easier way ?
>
>
>
> Thank you for support.
>
>
>
> Regards.
>
>
>
> Philippe
>
> --
> 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
Re: [Kea-users] DHCP NAK through relay option 82
Hi Libor, As you noted, this is because the server doesn't receive the option 82 data in subsequent renews. You may be able to force clients to always use the relay-agent on your router or whatever is doing the relay. Otherwise, there isn't much you can do. The Kea server can't classify a client based on information that doesn't exist. From the message you provided where it fails to select a subnet it seems that you are using the classification to control access to a subnet in some way. Kea won't even get as far as looking for a lease, if it can't find a subnet for the client. If you can't alter your relay-agent's behavior (with some, it is possible to mask the server address from the client such that the client thinks the relay is the server), then you may have to rethink your strategy. Thank you, Darren Ankney On Thu, Mar 28, 2024 at 1:41 PM wrote: > > Hi, I am trying to start kea dhcp with client classification using option 82 > through dhcp relay server. > > When client tries to do renew of ip address, tries to prolongate his lease, > kea response with NAK. > The problem is that when client makes simple dhcp discover, the packet goes > broadcast through the router, router acts like dhcp relay and relays packet > to dhcp server kea with added option 82. > But when client makes dhcp renewal-packet goes unicast directly to dhcp > server without option 82. As I understand, this causes kea to response with > NAK, because packet doesn't match to subnet rule criteria. In the logs I see > message "ailed to select a subnet for incoming packet, src 100.64.1.1, type > DHCPREQUEST" > > Is there a way to configure kea to accept renewal requests if lease already > exists and mac address of a client corresponds to stores lease? > > Full log - https://pastebin.com/yviEFneL > Full config - https://pastebin.com/2DxfQKb6 > > Thanks for any advice > > Libor > -- > 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
Re: [Kea-users] HA and logging - COMMAND_RECEIVED
Hi Lexi, You can add a new logger for kea-dhcp4.commands that specifies a different output file or you could change the severity to something higher than warn. Further reading: https://kb.isc.org/docs/kea-logging-configuration https://kea.readthedocs.io/en/kea-2.4.1/arm/logging.html Thank you, Darren Ankney On Wed, Mar 27, 2024 at 8:29 PM Lexi Winter wrote: > > hello, > > thanks to everyone who responsed to my previous message, i now have Kea > working with HA for both DHCPv4 and DHCPv6. > > however, i've noticed it logs the following message once per second: > > 2024-03-28 00:25:50.751 INFO [kea-dhcp4.commands/54583.0x23045e904e00] > COMMAND_RECEIVED Received command 'ha-heartbeat' > > this makes it hard to find any relevant information in the log file, > since it's filled with copies of this message. is there any way to > prevent this specific message from being logged? i did have a look > through the manual but couldn't see any obvious way to do this. > > (i realise i could increase heartbeat-delay to reduce the frequency, but > even if i set that to, say, 10s, this is still going to overwhelm other > messages in the log file.) > > thanks, lexi. > -- > 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
Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu, You will need to enable multi-threading dedicated listener for HA as described here: https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#multi-threaded-configuration-ha-mt or alter your "url" in each in the peers blocks to port 8001 so that they communicate via the kea-ctrl-agent. I think that should fix it. Thank you, Darren Ankney On Tue, Mar 26, 2024 at 7:58 AM Xiao, Yu (CCI-Atlanta) via Kea-users wrote: > > Hi Darren, > > > > I am using 2.4.1. > > > > > > Best Regards, > > Yu > > > > > > From: Kea-users on behalf of Darren Ankney > > Date: Tuesday, March 26, 2024 at 6:03 AM > To: Kea user's list > Subject: [EXTERNAL] Re: [Kea-users] kea-2.4.1 // Strange HA related errors > > Hello Yu, > > What version of Kea are you running on these servers, out of curiosity? > > Thank you, > Darren Ankney > > On Mon, Mar 25, 2024 at 10:55 AM Xiao, Yu (CCI-Atlanta) via Kea-users > wrote: > > > > Hi experts, > > > > > > > > I have configured two VMs in the same hypervisor as hot-standby mode HA. I > > believe they are successfully communicating with each other with heart beat > > packets, as we can see the primary VM kea-1 has successfully received the > > “ha-heartbeat” from the standby VM kea-2 in green logs. But the red logs > > indicate that the ha_hooks think the HA heartbeat communications failed due > > to “no route”. But this is a LAN network, and there’s indeed route > > installed as we can see below and we can ping the 69 ip. > > > > > > > > [yxiao322@kea_home1 ~]$ ip route > > > > 192.168.100.0/24 dev ens18 proto kernel scope link src 192.168.100.197 > > metric 100 <<< This should be the route to 192.168.100.69 > > > > 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 > > linkdown > > > > > > > > [root@kea_home1 yxiao322]# ping 192.168.100.69 > > > > PING 192.168.100.69 (192.168.100.69) 56(84) bytes of data. > > > > 64 bytes from 192.168.100.69: icmp_seq=1 ttl=64 time=0.342 ms > > > > 64 bytes from 192.168.100.69: icmp_seq=2 ttl=64 time=0.302 ms > > > > 64 bytes from 192.168.100.69: icmp_seq=3 ttl=64 time=0.236 ms > > > > ^Z > > > > [1]+ Stopped ping 192.168.100.69 > > > > > > > > And if I stop the kea service on primary, then we can see standby server > > will complain “communication with kea_home1 is interrupted”. And as soon as > > I start kea service again on primary, then the database began sync again. > > Thus, I believe there’s indeed communications and syncs between primary and > > standby VMs. But for some reason, if I shut the kea service on primary, > > then the standby won’t distribute DHCP leases even after I waited for a > > long time. Did I miss something here? > > > > > > > > > > > > Primary logs: > > > > > > > > Mar 25 10:35:37 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:37.198 INFO > > [kea-dhcp6.commands/1224.139988007651072] COMMAND_RECEIVED Received command > > 'ha-heartbeat' > > > > Mar 25 10:35:37 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:37.627 WARN > > [kea-dhcp6.ha-hooks/1224.139988049614592] > > HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to kea_home2 > > (https://urldefense.com/v3/__http://192.168.100.69:8000/__;!!Hit2Ag!xbrgKugiAG9Ig2_84VjCtBW6x-DpB9Aox3x1n_oCHrMu1W-ZDDMlKiorN7OVohqT2UUHSGoJ3ePqTi1Q4B1j$ > > ): No route to host > > > > Mar 25 10:35:37 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:37.627 WARN > > [kea-dhcp6.ha-hooks/1224.139988049614592] HA_COMMUNICATION_INTERRUPTED > > communication with kea_home2 is interrupted > > > > Mar 25 10:35:38 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:38.199 INFO > > [kea-dhcp6.commands/1224.139988016043776] COMMAND_RECEIVED Received command > > 'ha-heartbeat' > > > > Mar 25 10:35:38 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:38.627 WARN > > [kea-dhcp6.ha-hooks/1224.139988032829184] > > HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to kea_home2 > > (https://urldefense.com/v3/__http://192.168.100.69:8000/__;!!Hit2Ag!xbrgKugiAG9Ig2_84VjCtBW6x-DpB9Aox3x1n_oCHrMu1W-ZDDMlKiorN7OVohqT2UUHSGoJ3ePqTi1Q4B1j$ > > ): No route to host > > > > Mar 25 10:35:38 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:38.627 WARN > > [kea-dhcp6.ha-hooks/1224.139988032829184] HA_COMMUNICATION_INTERRUPTED > > communication with kea_home2 is interrupted > > > > > > > > Standby logs: > > > > >
Re: [Kea-users] kea-2.4.1 // Strange HA related errors
Hello Yu, What version of Kea are you running on these servers, out of curiosity? Thank you, Darren Ankney On Mon, Mar 25, 2024 at 10:55 AM Xiao, Yu (CCI-Atlanta) via Kea-users wrote: > > Hi experts, > > > > I have configured two VMs in the same hypervisor as hot-standby mode HA. I > believe they are successfully communicating with each other with heart beat > packets, as we can see the primary VM kea-1 has successfully received the > “ha-heartbeat” from the standby VM kea-2 in green logs. But the red logs > indicate that the ha_hooks think the HA heartbeat communications failed due > to “no route”. But this is a LAN network, and there’s indeed route installed > as we can see below and we can ping the 69 ip. > > > > [yxiao322@kea_home1 ~]$ ip route > > 192.168.100.0/24 dev ens18 proto kernel scope link src 192.168.100.197 metric > 100 <<< This should be the route to 192.168.100.69 > > 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown > > > > [root@kea_home1 yxiao322]# ping 192.168.100.69 > > PING 192.168.100.69 (192.168.100.69) 56(84) bytes of data. > > 64 bytes from 192.168.100.69: icmp_seq=1 ttl=64 time=0.342 ms > > 64 bytes from 192.168.100.69: icmp_seq=2 ttl=64 time=0.302 ms > > 64 bytes from 192.168.100.69: icmp_seq=3 ttl=64 time=0.236 ms > > ^Z > > [1]+ Stopped ping 192.168.100.69 > > > > And if I stop the kea service on primary, then we can see standby server will > complain “communication with kea_home1 is interrupted”. And as soon as I > start kea service again on primary, then the database began sync again. Thus, > I believe there’s indeed communications and syncs between primary and standby > VMs. But for some reason, if I shut the kea service on primary, then the > standby won’t distribute DHCP leases even after I waited for a long time. Did > I miss something here? > > > > > > Primary logs: > > > > Mar 25 10:35:37 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:37.198 INFO > [kea-dhcp6.commands/1224.139988007651072] COMMAND_RECEIVED Received command > 'ha-heartbeat' > > Mar 25 10:35:37 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:37.627 WARN > [kea-dhcp6.ha-hooks/1224.139988049614592] HA_HEARTBEAT_COMMUNICATIONS_FAILED > failed to send heartbeat to kea_home2 (http://192.168.100.69:8000/): No route > to host > > Mar 25 10:35:37 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:37.627 WARN > [kea-dhcp6.ha-hooks/1224.139988049614592] HA_COMMUNICATION_INTERRUPTED > communication with kea_home2 is interrupted > > Mar 25 10:35:38 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:38.199 INFO > [kea-dhcp6.commands/1224.139988016043776] COMMAND_RECEIVED Received command > 'ha-heartbeat' > > Mar 25 10:35:38 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:38.627 WARN > [kea-dhcp6.ha-hooks/1224.139988032829184] HA_HEARTBEAT_COMMUNICATIONS_FAILED > failed to send heartbeat to kea_home2 (http://192.168.100.69:8000/): No route > to host > > Mar 25 10:35:38 kea_home1 kea-dhcp6[1224]: 2024-03-25 10:35:38.627 WARN > [kea-dhcp6.ha-hooks/1224.139988032829184] HA_COMMUNICATION_INTERRUPTED > communication with kea_home2 is interrupted > > > > Standby logs: > > > > Mar 25 10:10:24 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:24.129 WARN > [kea-dhcp6.ha-hooks/2836.139717198915328] HA_COMMUNICATION_INTERRUPTED > communication with kea_home1 is interrupted > > Mar 25 10:10:25 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:25.130 WARN > [kea-dhcp6.ha-hooks/2836.139717207308032] HA_HEARTBEAT_COMMUNICATIONS_FAILED > failed to send heartbeat to kea_home1 (http://192.168.100.197:8000/): > Connection refused > > Mar 25 10:10:25 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:25.130 WARN > [kea-dhcp6.ha-hooks/2836.139717207308032] HA_COMMUNICATION_INTERRUPTED > communication with kea_home1 is interrupted > > Mar 25 10:10:26 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:26.132 WARN > [kea-dhcp6.ha-hooks/2836.139717190522624] HA_HEARTBEAT_COMMUNICATIONS_FAILED > failed to send heartbeat to kea_home1 (http://192.168.100.197:8000/): > Connection refused > > Mar 25 10:10:26 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:26.132 WARN > [kea-dhcp6.ha-hooks/2836.139717190522624] HA_COMMUNICATION_INTERRUPTED > communication with kea_home1 is interrupted > > Mar 25 10:10:27 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:27.136 INFO > [kea-dhcp6.ha-hooks/2836.139717215700736] HA_STATE_TRANSITION server > transitions from PARTNER-DOWN to WAITING state, partner state is PARTNER-DOWN > > Mar 25 10:10:27 kea_home2 kea-dhcp6[2836]: 2024-03-25 10:10:27.137 INFO > [kea-dhcp6.ha-hooks/2836.139717215700736] HA_LEASE_UPDATES_DIS
Re: [Kea-users] KEA Option 17 structure (example)
Hi Marek,
FYI: 2.5.6 is a development version and, as such, could contain bugs.
2.4.1 is the latest "stable" version. This version supports multiple
option 17.
Thank you,
Darren Ankney
On Thu, Mar 14, 2024 at 5:03 PM Marek Hajduczenia
wrote:
>
> And confirmed, with the switch to 2.5.6, I can see two separate entries as
> expected.
>
> Thank you !
>
> Marek
>
> -Original Message-
> From: Marek Hajduczenia
> Sent: Wednesday, March 13, 2024 2:17 PM
> To: 'Kea user's list'
> Subject: RE: [Kea-users] KEA Option 17 structure (example)
>
> Thanks, Darren
>
> The config snippet you shared matches my config pretty closely and it does
> result in a single Option 17 instance with vendor ID 1 only. If I change
> the order of vendor ID options, I will get 14810 only, and no trace 1. I
> wonder whether the support for multiple Option 17 / multiple sub-options per
> Option 17 instance is there. If it is not, do I just log it as a bug /
> feature request with the Kea development team?
>
> Regards
>
> Marek
>
> -Original Message-
> From: Kea-users On Behalf Of Darren Ankney
> Sent: Wednesday, March 13, 2024 3:39 AM
> To: Kea user's list
> Subject: Re: [Kea-users] KEA Option 17 structure (example)
>
> Hello,
>
> I don't think you need to encapsulate the vendor options ... I believe Kea
> knows to do that in this case. An example is shown at the ARM link I posted
> previously. Something like the below might work. You may want to send some
> other value for the second option while testing as it might be confusing in
> the packet capture.
>
> {
> "Dhcp6": {
> "option-def": [
> {
> "name": "worldbox_adb_bmc",
> "code": 1,
> "type": "string",
> "space": "vendor-14810",
> "encapsulate": ""
> },
> {
> "name": "vendor-1-test",
> "code": 111,
> "type": "string",
> "space": "vendor-1",
> "encapsulate": ""
> }
> ],
> "option-data": [
> {
> "name": "worldbox_adb_bmc",
> "space": "vendor-14810",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
> },
> {
> "name": "vendor-1-test",
> "space": "vendor-1",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
> },
> {
> "name": "vendor-opts",
> "data": "14810"
> },
> {
> "name": "vendor-opts",
> "data": "1"
> }
> ]
> }
> }
>
> Thank you,
> Darren Ankney
>
> On Sat, Mar 9, 2024 at 11:24 PM wrote:
> >
> > Thanks, again
> >
> >
> >
> > Drilling a bit on the multiple entries in Option 17, I created two entries,
> > one for vendor 14810 and one for vendor 1. I was hoping for two Option
> > 17 instances to be added *or* one instance with two vendor-specific
> > entries. A single entry is added and just for vendor 1, i.e., the
> > latter one in the option stack is created. Is that the expected behavior?
> >
> >
> >
> > "option-data": [
> >
> > {
> >
> > "name": "dns-servers",
> >
> > "data": "2001:db8:2::dead:beef,
> > 2001:db8:2::cafe:babe"
> >
> > }, {
> >
> > "space": "vendor-14810",
> >
> > "name": "bmc",
> >
> > "data":
> > "tmpwh2.cvs.adbglobal.com",
> >
> > "always-send": true
> >
> > }, {
> >
> > "name": "vendor-opts",
> >
> > "data": "14810"
> >
> > }, {
&g
Re: [Kea-users] Kea HA with self signed certs
Hi, You might try using "curl" as shown here: https://kea.readthedocs.io/en/kea-2.4.1/arm/ctrl-channel.html#using-the-control-channel I know very little about SSL, but `--insecure` added to the curl command line will cause it to not check validity of certificates. You can also specify cert files on the command line. This should let you test your certificate setup more easily I'd think. Thank you, Darren Ankney On Thu, Mar 14, 2024 at 2:40 PM CS wrote: > > Thanks for the reply Rick. In this deployment I have specified in the control > agent conf: > "cert-required": true, > "trust-anchor": "Certificate_Autority.pem", > "cert-file": "ca1_cert.pem", > "key-file": "ca1_key.pem", > > all pointing to self signed certs created with the help of (basically) the > script I worked on in the reddit link. Stripping the certs away certainly > allows the kea-shell commands to work, however this isn't the goal. > > I don't understand the second part of your reply. > >or is set to true and you did not provide one in the sample command line. > > Don't I show what you are suggesting I might not have done? "--ca > Certificate_Autority.pem" > > CS, cs.temp.m...@gmail.com > > > On Thu, 14 Mar 2024 at 11:22, Rick Frey wrote: >> >> I believe that error indicates your Kea server requires a client >> certificate. Per Kea documentation, the config parameter "cert-required” >> default is true. Would indicate your server config didn’t set or is set to >> true and you did not provide one in the sample command line. If you don’t >> require client cert for authentication, you can set to false in >> kea-ctl-agent.conf. >> >> On Mar 13, 2024, at 16:11, CS wrote: >> >> Hey guys, >> >> What does this mean? >> Failed to run: [SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert >> certificate required (_ssl.c:2578) >> >> I'm back again after getting pulled off onto other projects, I am working on >> getting my small kea cluster running with Micetro. >> >> Micetro refuses to add the servers and while I'd thought I had solved all my >> problems with ya'll before (kea daemons appear to be running error free) on >> re-approaching the problem I have notice I have not been able to get >> kea-shell to run against either localhost or the other server. >> >> My knowledge of creating and using SSL is very poor. For this project alone >> I worked with the folks on reddit to develop a script for creating the self >> signed certs. >> https://www.reddit.com/r/openssl/comments/170r9ko/creating_self_signed_cert_for_kea_encryption/?utm_source=share_medium=web2x=3 >> so I assume the error is somewhere there. But I don't understand the reply >> when I run kea-shell. >> >> kea-shell --host 10.111.45.45 --port 8000 --auth-user "bad username" >> --auth-password "bad password" --ca certs/Certificate_Autority.pem >> list-commands >> Failed to run: [SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert >> certificate required (_ssl.c:2578) >> >> Do you all know what I've done wrong or what I need to do to make the cert >> right? >> >> CS, cs.temp.m...@gmail.com >> -- >> 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 > > -- > 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
Re: [Kea-users] API call 'reservation-del' removes all v6 reservations.
Hi Andy,
I altered my configuration to remove the pool and add the ip of
ens256. I was able to delete just one entry from the subnet as
before. Perhaps provide your configuration and all of your API
commands and I could try using your (slightly modified to match
interface) configuration? Here are all of my API commands and
configuration (attached).
API commands executed like this:
$ cat reservation-get-all.json | sudo socat UNIX:/tmp/socket6
-,ignoreeof | jq .
{
"arguments": {
"hosts": [
{
"client-classes": [],
"duid": "1a:1b:1c:1d:1e:0a",
"hostname": "",
"ip-addresses": [
"2001:db8::101"
],
"option-data": [],
"prefixes": [],
"subnet-id": 1
}
]
},
"result": 0,
"text": "1 IPv6 host(s) found."
}
Thank you,
Darren Ankney
On Thu, Mar 14, 2024 at 6:22 AM Andrew Mulheirn
wrote:
>
> Hi Darren,
>
> Thanks for taking the time to test this. I queried the API for the version
> and it says 2.4.1.
>
> I am using the same config lines as you show below, with two exceptions:
> On the interfaces, I have specified the address on eth1 that it is to listen
> on:
>
> "interfaces-config": {
> "interfaces": [ "eth1/2a00:e340:1100::32"]
> },
>
>
> Also I have no pool defined because we want to have only static reservations.
> I define the subnet. In your example, it looks like the reservations are
> within the pool:
>
> "subnet6": [
> {
> "id": 1,
> "subnet": "2a00:e340:1102::/64",
> }
> ],
>
> I've trimmed various unnecessary things out of my config since the first post
> just to see if it made any difference, but no luck. I might try reservations
> by DUID like you're doing to see if the behaviour changes (though we really
> need flex-id)
>
> Kind regards,
>
> Andy
>
>
> Andrew Mulheirn
>
> Senior Network Architect
>
> M: +44 (0) 74 3654 8126
>
> E: andrew.mulhe...@vorboss.com
>
> vorboss.com
>
>
> Not sure who currently provides your internet?
> Find out here and take our speed test.
>
>
> Disclaimer: This message is private and confidential. If you have received
> this message in error, please remove it from your system and notify us at
> sysad...@vorboss.net or by telephone +44(0)20 3582 8500. Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other than the
> intended recipient is prohibited. Privacy Note: Vorboss Limited may monitor
> email traffic data and also the content of email for the purposes of
> security. This email does not create or vary any contractual obligations
> between Vorboss Limited and the intended recipient.
>
> Vorboss Limited is a limited company registered in England and Wales.
> Registered number: 05678571. Registered Office: Vorboss Limited, Broadwalk
> House, 5 Appold Street, London, EC2A 2AG, UNITED KINGDOM.
>
>
> -Original Message-
> From: Darren Ankney
> Sent: Wednesday, March 13, 2024 9:25 PM
> To: Kea user's list
> Cc: Andrew Mulheirn
> Subject: Re: [Kea-users] API call 'reservation-del' removes all v6
> reservations.
>
> Hi Andy,
>
> I was not able to reproduce this in 2.4.0. What version were you using?
>
> I tested using this simple configuration:
>
> {
> "Dhcp6": {
> "control-socket": {
> "socket-type": "unix",
> "socket-name": "/tmp/socket6"
> },
> "interfaces-config": {
> "interfaces": [
> "ens256"
> ]
> },
> "hosts-database": {
> "type": "mysql",
> "name": "kea",
> "user": "kea",
> "password": "kea",
> },
> "hooks-libraries": [
> {
> "library": "/usr/local/kea/2.4.0/lib/kea/hooks/libdhcp_host_cmds.so"
> }
> ],
> "subnet6": [
> {
> "id": 1,
> "subnet": "2001:db8::/64",
> "pools": [
> {
> "pool": "2001:db8::-2001:db8::"
> }
> ]
> }
> ]
> }
> }
>
> I added a host reservation with this command:
>
> {
> &qu
Re: [Kea-users] KEA Option 17 structure (example)
Hi Marek,
Using Kea 2.4.0 with the attached configuration in my test lab with
perfdhcp (two virtual servers ... one for Kea and one for perfdhcp):
`perfdhcp -6 -r 1 -p 10 -l ens256 -R 1`
resulted in the attached .pcap file which shows both option 17
versions being attached to the packet. I used "always-send": true to
avoid the need to hand modify the ORO in perfdhcp. If your client is
requesting option 17, you may not need that in the configuration.
Thank you,
Darren Ankney
On Wed, Mar 13, 2024 at 4:17 PM Marek Hajduczenia
wrote:
>
> Thanks, Darren
>
> The config snippet you shared matches my config pretty closely and it does
> result in a single Option 17 instance with vendor ID 1 only. If I change
> the order of vendor ID options, I will get 14810 only, and no trace 1. I
> wonder whether the support for multiple Option 17 / multiple sub-options per
> Option 17 instance is there. If it is not, do I just log it as a bug /
> feature request with the Kea development team?
>
> Regards
>
> Marek
>
> -Original Message-
> From: Kea-users On Behalf Of Darren Ankney
> Sent: Wednesday, March 13, 2024 3:39 AM
> To: Kea user's list
> Subject: Re: [Kea-users] KEA Option 17 structure (example)
>
> Hello,
>
> I don't think you need to encapsulate the vendor options ... I believe Kea
> knows to do that in this case. An example is shown at the ARM link I posted
> previously. Something like the below might work. You may want to send some
> other value for the second option while testing as it might be confusing in
> the packet capture.
>
> {
> "Dhcp6": {
> "option-def": [
> {
> "name": "worldbox_adb_bmc",
> "code": 1,
> "type": "string",
> "space": "vendor-14810",
> "encapsulate": ""
> },
> {
> "name": "vendor-1-test",
> "code": 111,
> "type": "string",
> "space": "vendor-1",
> "encapsulate": ""
> }
> ],
> "option-data": [
> {
> "name": "worldbox_adb_bmc",
> "space": "vendor-14810",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
> },
> {
> "name": "vendor-1-test",
> "space": "vendor-1",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
> },
> {
> "name": "vendor-opts",
> "data": "14810"
> },
> {
> "name": "vendor-opts",
> "data": "1"
> }
> ]
> }
> }
>
> Thank you,
> Darren Ankney
>
> On Sat, Mar 9, 2024 at 11:24 PM wrote:
> >
> > Thanks, again
> >
> >
> >
> > Drilling a bit on the multiple entries in Option 17, I created two entries,
> > one for vendor 14810 and one for vendor 1. I was hoping for two Option
> > 17 instances to be added *or* one instance with two vendor-specific
> > entries. A single entry is added and just for vendor 1, i.e., the
> > latter one in the option stack is created. Is that the expected behavior?
> >
> >
> >
> > "option-data": [
> >
> > {
> >
> > "name": "dns-servers",
> >
> > "data": "2001:db8:2::dead:beef,
> > 2001:db8:2::cafe:babe"
> >
> > }, {
> >
> > "space": "vendor-14810",
> >
> > "name": "bmc",
> >
> > "data":
> > "tmpwh2.cvs.adbglobal.com",
> >
> > "always-send": true
> >
> > }, {
> >
> > "name": "vendor-opts",
> >
> > "data": "14810"
> >
> > }, {
> >
> >
Re: [Kea-users] API call 'reservation-del' removes all v6 reservations.
Hi Andy,
I was not able to reproduce this in 2.4.0. What version were you using?
I tested using this simple configuration:
{
"Dhcp6": {
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/socket6"
},
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"hosts-database": {
"type": "mysql",
"name": "kea",
"user": "kea",
"password": "kea",
},
"hooks-libraries": [
{
"library": "/usr/local/kea/2.4.0/lib/kea/hooks/libdhcp_host_cmds.so"
}
],
"subnet6": [
{
"id": 1,
"subnet": "2001:db8::/64",
"pools": [
{
"pool": "2001:db8::-2001:db8::"
}
]
}
]
}
}
I added a host reservation with this command:
{
"command": "reservation-add",
"arguments": {
"reservation": {
"subnet-id": 1,
"duid": "1a:1b:1c:1d:1e:0a",
"ip-addresses": [ "2001:db8::101" ]
}
}
}
and then another
{
"command": "reservation-add",
"arguments": {
"reservation": {
"subnet-id": 1,
"duid": "1a:1b:1c:1d:1e:0b",
"ip-addresses": [ "2001:db8::102" ]
}
}
}
I then had two reservations:
{
"arguments": {
"hosts": [
{
"client-classes": [],
"duid": "1a:1b:1c:1d:1e:0a",
"hostname": "",
"ip-addresses": [
"2001:db8::101"
],
"option-data": [],
"prefixes": [],
"subnet-id": 1
},
{
"client-classes": [],
"duid": "1a:1b:1c:1d:1e:0b",
"hostname": "",
"ip-addresses": [
"2001:db8::102"
],
"option-data": [],
"prefixes": [],
"subnet-id": 1
}
]
},
"result": 0,
"text": "2 IPv6 host(s) found."
}
I then deleted one of them by IP address:
{
"command": "reservation-del",
"arguments": {
"subnet-id": 1,
"ip-address": "2001:db8::101"
}
}
and still had one reservation left:
{
"arguments": {
"hosts": [
{
"client-classes": [],
"duid": "1a:1b:1c:1d:1e:0b",
"hostname": "",
"ip-addresses": [
"2001:db8::102"
],
"option-data": [],
"prefixes": [],
"subnet-id": 1
}
]
},
"result": 0,
"text": "1 IPv6 host(s) found."
}
On Mon, Mar 11, 2024 at 11:19 AM Andrew Mulheirn via Kea-users
wrote:
>
> Hi all,
>
>
>
> I've noticed that using reservation-del against dhcp6 removes *all*
> reservations, while doing the same against dhcp4 behaves as expected and
> removes just the reservation that was specified. I can't see why they
> behave differently.
>
>
>
> I have made reservations for 2a00:e340:1102::3 and 2a00:e340:1102::4 and can
> see them both when I do a reservation-get-all.
>
>
>
> Then I try to delete one of them. Here is the call I am making for v6:
>
> {
>
> "command": "reservation-del",
>
> "service": ["dhcp6"],
>
> "arguments": {
>
> "subnet-id": 1,
>
> "ip-address": "2a00:e340:1102::3"
>
> }
>
> }
>
>
>
>
>
> When I look at the debug, I see messages just deleting this one reservation:
>
> INFO COMMAND_RECEIVED Received command 'reservation-del'
>
> DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_del
>
> INFO HOST_CMDS_RESERV_DEL reservation-del command called (parameters: {
> "ip-address": "2a00:e340:1102::3", "subnet-id": 1 })
>
> INFO HOST_CMDS_RESERV_DEL_SUCCESS reservation-del command success
> (parameters: { "ip-address": "2a00:e340:1102::3", "subnet-id": 1 })
>
> DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on
> hook $reservation_del that has address 0x7ff2f67cecb0 (callout duration:
> 5.882 ms)
>
> DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_del
> (total callouts duration: 5.882 ms)
>
>
>
>
>
> However, when I do another reservation-get-all, the table is now empty:
>
> [
>
> {
>
> "arguments": {
>
> "hosts": []
>
> },
>
> "result": 3,
>
> "text": "0 IPv6 host(s) found."
>
> }
>
> ]
>
>
>
>
>
> As I say, v4 works fine. Any pointers would be most welcome,
>
>
>
> Cheers,
>
> Andy
>
>
> Andrew Mulheirn
>
> Senior Network Architect
>
> M: +44 (0) 74 3654 8126
>
> E: andrew.mulhe...@vorboss.com
>
> vorboss.com
>
>
> Not sure who currently provides your internet?
> Find out here and take our speed test.
>
>
> Disclaimer: This message is private and confidential. If you have received
> this message in error, please remove it from your system and notify us at
> sysad...@vorboss.net or by telephone +44(0)20 3582 8500. Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other than the
> intended recipient is prohibited. Privacy Note: Vorboss Limited may monitor
> email traffic data and also the content of email for the
Re: [Kea-users] Can I provide a local server url to clients?
Hi Olafo, What you are describing would require a DNS server or some custom programming on the client computer. You could send some URL from Kea in some custom option, but the client wouldn't know what to do with it without being told. Additionally, it would have to be IP based or the client computer would still need to do a lookup somewhere. Could you not just tell the user in documentation to always connect to http://192.168.10.2: to perform admin operations (assuming the admin.local URL would point at that IP address)? This would seem like the simplest solution. Otherwise, I fear you are either going to have to do some client side programming of some kind or embed a DNS server in your embedded device. Thank you, Darren Ankney On Mon, Mar 11, 2024 at 8:24 AM Olaf Greve wrote: > > Hi, > > I’m fully new to the realm of DHCP servers and may hence be asking something > that is not possible with them. I tried to search for the following request > online and couldn’t find any sample configurations, which leads me to think > that maybe it can’t be solved with Kea alone. Please bear with me a little if > I’m asking a silly thing here :P > > The set-up: > Last Friday I installed Kea 2.0.2 in an embedded platform (running on a > BeagleBone Red, industrial) using a custom Ubuntu 22.04 build created via > yocto Kirkstone. > So far so good and on board I managed to set up and run Kea just fine as > desired, configuring and starting only the dhcp4 part of it, giving out IP > addresses in the range of 192.168.10.100 - 192.168.10.200 in subnet > 192.168.10.0/24. > Our BeagleBone always (hard) is set to listen at 192.168.10.2 > > The above set-up is configured on the usb0 device which in normal conditions > is not connected but is required for local administration of our embedded set > up when we connect a host computer directly to our embedded setup via a > 1-on-1 cabled usb connection (rather than using our eth0 interface that we > require for normal Ethernet functionality. > > The above works fine as for giving out an IP address to the host computer > when connected via usb and indeed we can the from it successfully ssh to the > BeagleBone and do what we need, taking care of the first part of what I > wanted to achieve. > > The question is about ‘the remaining part’ I’d like to achieve, if possible. > What we’d like to achieve is that when a host computer is connected as > described above they can always ‘automatically’ (as in: without the end users > making /etc/host entries on the host computer) reach our on board > administration web interface via some local url like e.g. ‘admin.local’ just > by pointing their web browser to that local address. Much like often is > available for commercially available routers so anyone can easily access the > admin interface when connected locally. > > OK, so here’s where my knowledge falls short. Normally I’d say the this > sounds like a DNS task, right? > However, looking through the MANY options that Kea offers I wonder if this > can be done with Kea alone or how I would otherwise go about it. > Can I somehow simply pass the (fake) server url admin.local, associate that > to address 192.168.10.2, to all clients that connect via dhcp and will the > client then understand that and do what I want or do I need to do it > differently? > From what I see in configuration examples and the documentation, I fear a bit > that that will not be possible with Kea alone and that I’d need to set up a > DNS server on the BeagleBone too and let Kea pass the ip address(es) of that > in the domain-name-servers field for the IP pool that Kea serves. > > As we normally rarely connect a computer via usb this way, and the connection > is always one on one then, and we have a need to keep resources usage in the > BeagleBone to a minimum (!), it feels like a terrible overkill to fully > configure a DNS server for giving out just that 1 local server URL. > > Does anyone have experience for this and/or know how to achieve this is an as > ‘lightweight as possible’ manner? > Can Kea dhcp4 do this, perhaps together with kea-ddns-dhcp ? > > Hopefully someone can help me with this request; any ideas and pointers to > information are very much appreciated! > > Thanks in advance for taking the time to address this and kind regards, > Olafo > > > > -- > 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 subsc
Re: [Kea-users] KEA Option 17 structure (example)
Hello,
I don't think you need to encapsulate the vendor options ... I believe
Kea knows to do that in this case. An example is shown at the ARM
link I posted previously. Something like the below might work. You
may want to send some other value for the second option while testing
as it might be confusing in the packet capture.
{
"Dhcp6": {
"option-def": [
{
"name": "worldbox_adb_bmc",
"code": 1,
"type": "string",
"space": "vendor-14810",
"encapsulate": ""
},
{
"name": "vendor-1-test",
"code": 111,
"type": "string",
"space": "vendor-1",
"encapsulate": ""
}
],
"option-data": [
{
"name": "worldbox_adb_bmc",
"space": "vendor-14810",
"data": "'tmpwh2.cvs.adbglobal.com'",
"always-send": true
},
{
"name": "vendor-1-test",
"space": "vendor-1",
"data": "'tmpwh2.cvs.adbglobal.com'",
"always-send": true
},
{
"name": "vendor-opts",
"data": "14810"
},
{
"name": "vendor-opts",
"data": "1"
}
]
}
}
Thank you,
Darren Ankney
On Sat, Mar 9, 2024 at 11:24 PM wrote:
>
> Thanks, again
>
>
>
> Drilling a bit on the multiple entries in Option 17, I created two entries,
> one for vendor 14810 and one for vendor 1. I was hoping for two Option 17
> instances to be added *or* one instance with two vendor-specific entries. A
> single entry is added and just for vendor 1, i.e., the latter one in the
> option stack is created. Is that the expected behavior?
>
>
>
> "option-data": [
>
> {
>
> "name": "dns-servers",
>
> "data": "2001:db8:2::dead:beef,
> 2001:db8:2::cafe:babe"
>
> }, {
>
> "space": "vendor-14810",
>
> "name": "bmc",
>
> "data": "tmpwh2.cvs.adbglobal.com",
>
> "always-send": true
>
> }, {
>
> "name": "vendor-opts",
>
> "data": "14810"
>
> }, {
>
> "space": "vendor-1",
>
> "name": "test",
>
> "data": "tmpwh2.cvs.adbglobal.com",
>
> "always-send": true
>
> }, {
>
> "name": "vendor-opts",
>
> "data": "1"
>
> //}, {
>
> //"name": "ntp",
>
> //"csv-format": true,
>
> //"data": "2001:db8:2::dead:beef,
> 2001:db8:2::cafe:babe"
>
> } ]
>
> } ],
>
>
>
> "option-def":
>
> [ {
>
> "name": "bmc",
>
> "code": 1,
>
> "space": "vendor-14810",
>
> "type": "string",
>
> "array": false,
>
> "encapsulate": ""
>
> }, {
>
> "name": "vendor-14810-bmc",
>
> "code": 14810,
>
> "type": "empty",
>
> "space": "dhcp6",
>
>
Re: [Kea-users] KEA Option 17 structure (example)
Hi Marek,
That is my understanding. However, I've never tried any of the option 17 setup.
Thank you,
Darren Ankney
On Sat, Mar 9, 2024 at 8:55 AM wrote:
>
> Thank you, Darren
>
> So essentially the magic glue is the vendor ID (14810) used as data under
> "vendor-ops" (option 17). That's neat.
>
> Is it possible to have multiple vendor-specific options inserted into a
> single Option 17 instance this way?
>
> Marek
>
> -Original Message-
> From: Kea-users On Behalf Of Darren Ankney
> Sent: Saturday, March 9, 2024 4:38 AM
> To: Kea user's list
> Subject: Re: [Kea-users] KEA Option 17 structure (example)
>
> Hi Marek,
>
> I was able to find in the correct section of the documentation by first
> looking at this chart of options in Kea:
> https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#id3 and following
> the link there for option 17:
> https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcp6-vendor-opts
>
> Something like this MIGHT work:
>
> {
> "Dhcp6": {
> "option-def": [
> {
> "name": "worldbox_adb_bmc",
> "code": 1,
> "type": "string",
> "space": "vendor-14810",
> "encapsulate": ""
> }
> ],
> "option-data": [
> {
> "name": "worldbox_adb_bmc",
> "space": "vendor-14810",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
> },
> {
> "name": "vendor-opts",
> "data": "14810"
> }
> ]
> }
> }
>
> Thank you,
> Darren Ankney
>
> On Fri, Mar 8, 2024 at 9:50 AM Marek Hajduczenia
> wrote:
> >
> > Yeah, I forgot to mentioned that indeed - Option 17 is specific to IPv6. I
> > was able to get that done for DHCPv4 without any problems, but v6 side
> > seems to be using slightly different configuration logic, which does not
> > seem to be documented anywhere, at least that I can find.
> >
> > Thanks !
> >
> > Marek
> >
> > On Fri, Mar 8, 2024 at 3:42 AM Darren Ankney
> > wrote:
> >>
> >> Hi Marek,
> >>
> >> It is unclear to me. Is this for DHCPv6?
> >>
> >> Thank you,
> >> Darren Ankney
> >>
> >> On Thu, Mar 7, 2024 at 10:51 PM Marek Hajduczenia
> >> wrote:
> >> >
> >> > Dear mailing list users,
> >> >
> >> > I have been trying to create an Option 17 with a specific structure for
> >> > a vendor with the ID of 14810, where all I have is a sub-option 1,
> >> > containing a string with an arbitrary FQDN. I have a working code for
> >> > ISC DHCP, but I have not been able to locate a working example of an
> >> > implementation for Kea.
> >> >
> >> > # ADB VSIO
> >> > option space worldbox_adb code width 2 length width 2 hash size 1;
> >> > option worldbox_adb.bmc code 1 = text; option vsio.worldbox_adb
> >> > code 14810 = encapsulate worldbox_adb;
> >> >
> >> > # use the option within a subnet
> >> > ...
> >> > option worldbox_adb.bmc "tmpwh2.cvs.adbglobal.com"; ...
> >> >
> >> > My failed attempt to translate looks like the following, but it does not
> >> > produce any particular output as confirmed with the packet capture. DNS
> >> > servers are present, so I am sure the config is parsed correctly.
> >> >
> >> > "option-data": [
> >> > {
> >> > "name": "dns-servers",
> >> > "data": "2001:db8:2::dead:beef,
> >> > 2001:db8:2::cafe:babe"
> >> > }, {
> >> > "space": "vendor-14810",
> >> > "name": "bmc",
> >> > "data":
> >> > "tmpwh2.cvs.adbglobal.com"
> >> > }, {
> >> > "name": "vendor-14810-bmc"
> >> > } ]
> >> &
Re: [Kea-users] KEA Option 17 structure (example)
Hi Marek,
I was able to find in the correct section of the documentation by
first looking at this chart of options in Kea:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#id3 and
following the link there for option 17:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcp6-vendor-opts
Something like this MIGHT work:
{
"Dhcp6": {
"option-def": [
{
"name": "worldbox_adb_bmc",
"code": 1,
"type": "string",
"space": "vendor-14810",
"encapsulate": ""
}
],
"option-data": [
{
"name": "worldbox_adb_bmc",
"space": "vendor-14810",
"data": "'tmpwh2.cvs.adbglobal.com'",
"always-send": true
},
{
"name": "vendor-opts",
"data": "14810"
}
]
}
}
Thank you,
Darren Ankney
On Fri, Mar 8, 2024 at 9:50 AM Marek Hajduczenia
wrote:
>
> Yeah, I forgot to mentioned that indeed - Option 17 is specific to IPv6. I
> was able to get that done for DHCPv4 without any problems, but v6 side seems
> to be using slightly different configuration logic, which does not seem to be
> documented anywhere, at least that I can find.
>
> Thanks !
>
> Marek
>
> On Fri, Mar 8, 2024 at 3:42 AM Darren Ankney wrote:
>>
>> Hi Marek,
>>
>> It is unclear to me. Is this for DHCPv6?
>>
>> Thank you,
>> Darren Ankney
>>
>> On Thu, Mar 7, 2024 at 10:51 PM Marek Hajduczenia
>> wrote:
>> >
>> > Dear mailing list users,
>> >
>> > I have been trying to create an Option 17 with a specific structure for a
>> > vendor with the ID of 14810, where all I have is a sub-option 1,
>> > containing a string with an arbitrary FQDN. I have a working code for ISC
>> > DHCP, but I have not been able to locate a working example of an
>> > implementation for Kea.
>> >
>> > # ADB VSIO
>> > option space worldbox_adb code width 2 length width 2 hash size 1;
>> > option worldbox_adb.bmc code 1 = text;
>> > option vsio.worldbox_adb code 14810 = encapsulate worldbox_adb;
>> >
>> > # use the option within a subnet
>> > ...
>> > option worldbox_adb.bmc "tmpwh2.cvs.adbglobal.com";
>> > ...
>> >
>> > My failed attempt to translate looks like the following, but it does not
>> > produce any particular output as confirmed with the packet capture. DNS
>> > servers are present, so I am sure the config is parsed correctly.
>> >
>> > "option-data": [
>> > {
>> > "name": "dns-servers",
>> > "data": "2001:db8:2::dead:beef,
>> > 2001:db8:2::cafe:babe"
>> > }, {
>> > "space": "vendor-14810",
>> > "name": "bmc",
>> > "data": "tmpwh2.cvs.adbglobal.com"
>> > }, {
>> > "name": "vendor-14810-bmc"
>> > } ]
>> > } ],
>> >
>> > "option-def": [ {
>> > // We define a short name, so the option can be
>> > referenced by name.
>> > // The option has code 2 and resides within vendor
>> > space 25167.
>> > // Its data is a plain string.
>> > "name": "bmc",
>> > "code": 1,
>> > "space": "vendor-14810",
>> > "type": "string",
>> > "array": false,
>> > "encapsulate": ""
>> > }, {
>> > "name": "vendor-14810-bmc",
>> > "code": 14810,
>> > "type": "empty",
>> > "space": "dhcp6",
>> >
Re: [Kea-users] KEA Option 17 structure (example)
Hi Marek,
It is unclear to me. Is this for DHCPv6?
Thank you,
Darren Ankney
On Thu, Mar 7, 2024 at 10:51 PM Marek Hajduczenia
wrote:
>
> Dear mailing list users,
>
> I have been trying to create an Option 17 with a specific structure for a
> vendor with the ID of 14810, where all I have is a sub-option 1, containing a
> string with an arbitrary FQDN. I have a working code for ISC DHCP, but I have
> not been able to locate a working example of an implementation for Kea.
>
> # ADB VSIO
> option space worldbox_adb code width 2 length width 2 hash size 1;
> option worldbox_adb.bmc code 1 = text;
> option vsio.worldbox_adb code 14810 = encapsulate worldbox_adb;
>
> # use the option within a subnet
> ...
> option worldbox_adb.bmc "tmpwh2.cvs.adbglobal.com";
> ...
>
> My failed attempt to translate looks like the following, but it does not
> produce any particular output as confirmed with the packet capture. DNS
> servers are present, so I am sure the config is parsed correctly.
>
> "option-data": [
> {
> "name": "dns-servers",
> "data": "2001:db8:2::dead:beef,
> 2001:db8:2::cafe:babe"
> }, {
> "space": "vendor-14810",
> "name": "bmc",
> "data": "tmpwh2.cvs.adbglobal.com"
> }, {
> "name": "vendor-14810-bmc"
> } ]
> } ],
>
> "option-def": [ {
> // We define a short name, so the option can be
> referenced by name.
> // The option has code 2 and resides within vendor
> space 25167.
> // Its data is a plain string.
> "name": "bmc",
> "code": 1,
> "space": "vendor-14810",
> "type": "string",
> "array": false,
> "encapsulate": ""
> }, {
> "name": "vendor-14810-bmc",
> "code": 14810,
> "type": "empty",
> "space": "dhcp6",
> "encapsulate": "bmc"
> } ],
>
> I did not see any example showing how to build Option 17 anywhere. Any
> pointers / examples would be really appreciated.
>
> Marek
> --
> 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
Re: [Kea-users] dhcp lease question
Hi Jason, This has come up before. The short answer is that ISC DHCP did not record a lease for addresses reserved with "fixed-address". Kea does record a lease, and so won't allow assignment to a new client until the lease is expired. You could send a release from the old computer before shutting it down, that should end the lease and make available to the new. You could also use the "lease4-del" API command (https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#the-lease4-del-lease6-del-commands) to remove the lease which would also make it available to the new client. Thank you, Darren Ankney On Wed, Mar 6, 2024 at 5:44 PM Jason Keltz wrote: > > Hi. > > I have one question with respect to leases with Kea. > > On a subnet, I have assigned a static IP address for each ethernet address. > It works great. Recently, we started replacing the computers in one of our > labs. The new computers will be replacing existing computers, so they will > take on the same names. Before we install a new machine, we turn off the > old machine, reconfigure the ether address for the host in kea, and have kea > re-read it's config file. > > When the new system comes up, Kea doesn't want to give it the ether address > that is reserved for it because it sees a conflict. Of course the IP is > already issued to the old computer (that is now off). > > Is there an option to tell Kea to be "less particular" about leases for > reservations? That is, if the config file says that ether address X gets IP > address Y, then ether address X is always going to get IP address Y whether > the lease database says that it's in use or not. Obviously we aren't going > to have the old and new computer up at the same time. > > Is this possible? > > We did these kind of upgrades all the time with ISC DHCPd, and this was never > an issue, so hopefully it's just an option that I'm missing. > > Jason. > > > > -- > 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
Re: [Kea-users] [EXTERNAL] Re: Question regarding to HA for kea-dhcp6 VMs
Hi, This question is slightly beyond me, but I did find this: https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/lib/dhcp/pkt_filter_inet6.cc#L111 so it might be operating system dependant. I'm sure someone will be along to correct me in the (somewhat likely) case that I am wrong. Thank you, Darren Ankney On Tue, Mar 5, 2024 at 3:36 PM Erik Edwards via Kea-users wrote: > > For the list, does it open the v6 socket in V6_ONLY=TRUE mode or will it > accept mapped v4 addresses? > > On 3/5/24 14:37, Darren Ankney wrote: > > Hi Yu, > > > > Can you share your kea-ctrl-agent configuration? You actually send > > these commands to the kea-ctrl-agent which then forwards the commands > > to appropriate Kea daemon via its control socket. Please note that > > kea-ctrl-agent can only listen on v4 or v6 ... not both (though you > > can run two copies) see: > > https://gitlab.isc.org/isc-projects/kea/-/issues/3082 > > > > Thank you, > > Darren Ankney > > > -- > 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
Re: [Kea-users] Option-18 flex-id not matching incoming values
Hi Andrew,
It looks like your option 18 isn't being attached by the relay agent.
it seems to be in the DHCP packet proper. Perhaps try this?
"identifier-expression": "option[18].hex"
I'm not sure if that will work or not. I think option 18 is supposed
to be attached by the relay agent:
https://www.rfc-editor.org/rfc/rfc8415#section-21.18
Your packet log messages shows option 18 before it prints the relay
part. This could easily be checked with wireshark, btw, where you
could look to see if 18 was in the collapsable DHCP6 part or in the
enclosing DHCP6 relay part. In any case, this is a lab so it wouldn't
hurt to try.
Note that I omitted the substring since you were starting at position
0 and specifying "ALL" anyway.
Thank you,
Darren Ankney
On Tue, Mar 5, 2024 at 4:18 AM Andrew Mulheirn via Kea-users
wrote:
>
> I hope someone can help me with this issue. I am using Kea 2.4
>
>
>
> I am trying to get option-18 to match a DHCPv6 static reservation, but Kea is
> evaluating the option to "" and no address is being allocated. We have
> purchased the premium hooks package. I have got the same result on two
> different servers in the lab but can't work out what I am doing wrong.
>
>
>
> Here is the configuration in use:
>
> {
>
> "Dhcp6": {
>
> "server-tag": "kea-01",
>
> "config-control": {
>
> "config-databases": [{
>
> "type": "postgresql",
>
> "name": "retaildhcp",
>
> "user": "vorboss",
>
> "password": "vorboss",
>
> "host": "127.0.0.1",
>
> "port": 5432
>
> }],
>
> "config-fetch-wait-time": 20
>
> },
>
> "hooks-libraries": [
>
> {
>
> "library":
> "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_flex_id.so",
>
> "parameters": {
>
> "identifier-expression":
> "substring(relay6[0].option[18].hex,0,all)"
>
> }
>
> },
>
> {
>
> "library":
> "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_pgsql_cb.so"
>
> }
>
> ],
>
> "host-reservation-identifiers": ["flex-id", "duid"],
>
> "interfaces-config": {
>
> "interfaces": [ "eth1/2a00:e340:1100::32"]
>
> },
>
>
>
> "control-socket": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/kea6-ctrl-socket"
>
> },
>
>
>
> "lease-database": {
>
> # "type": "memfile",
>
> "lfc-interval": 3600,
>
> "type" : "postgresql",
>
> "name": "retaildhcp" ,
>
> "host": "127.0.0.1" ,
>
> "connect-timeout" : 5,
>
> "user": "vorboss",
>
> "password": "testingonly",
>
>},
>
>
>
> "hosts-database": {
>
> "type": "postgresql",
>
> "name": "retaildhcp",
>
> "user": "vorboss",
>
> "password": "testingonly",
>
> "host": "localhost",
>
> "port": 5432
>
> },
>
> "expired-leases-processing": {
>
> "reclaim-timer-wait-time": 10,
>
> "flush-reclaimed-timer-wait-time": 25,
>
> "hold-reclaimed-time": 3600,
>
> "max-reclaim-leases": 100,
>
> "max-reclaim-time": 250,
>
> "unwarned-reclaim-cycles": 5
>
> },
>
>
>
> "renew-timer": 1000,
>
> "rebind-timer": 2000,
>
> "preferred-lifetime": 3000,
>
> "valid-lifetime": 4000,
>
> "reservations-global": false,
>
> "reservations-in-subnet": true,
>
> "subnet6": [
>
> {
>
> "subnet": "2a00:e300:1102::/64",
>
> "option-data": [
>
> {
>
> "name": "dns-servers",
>
>
Re: [Kea-users] Questions about config DHCP4
Hi,
>
> 2. In the log, I just keep the basic output [path]file.log. Is it
> possible to have the output file in local + a syslog (for the headquarters).
> If yes, how I am supposed to write it?
You can add multiple output blocks to a single log configuration such
that the output could go to more than one file or a file and syslog or
a stdout or whatever combination can be made. For example:
"output_options": [
{
"output": "/var/log/kea.log"
},
{
"output": "stdout"
},
{
"output": "syslog"
}
],
Thank you,
Darren Ankney
--
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] Renumbering Ipv6 Pool
Hi, I've not tried this myself, and I expect different behavior compared to DHCPv4, but you might consider adding the old and new subnet to a single shared network. On the old subnet, remove the pools statement so that no dynamic addresses are available. Then, the clients should migrate to the new subnet as they renew since they won't be able to renew the old address any longer. This would work in DHCPv4... In DHCPv6, the move may happen much more quickly (I've seen evidence of this in other testing but haven't investigated closely), it is unclear to me as I've not experimented. Best to set this up in a lab environment first and see what happens. Thank you, Darren Ankney On Wed, Feb 28, 2024 at 5:13 AM Thijs Blok wrote: > > Hi, > > I cannot really find it in the current manuals, but what is the best practice > to renumber a IPv6 Pool? > We just want to stay the clients online, disable the old pool, and when lease > expires, the client would recieve a new IPv6 address. > > Cheers and thank you for your suggestions up front. > > Br, > Thijs Blok > -- > 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
Re: [Kea-users] [EXTERNAL] Re: DHCPv6 not working o PVE LAN
Hi Yu,
This simple configuration:
{
"Dhcp6": {
"subnet6": [
{
"subnet": "fd74:5656:15e2:10::/64",
"id": 1,
"interface": "ens256",
"pools": [
{
"pool": "fd74:5656:15e2:10::200 - fd74:5656:15e2:10::"
}
]
}
]
}
}
runs just fine on my test server. No syntax error. Can you provide
the syntax error you received?
Thank you,
Darren Ankney
On Tue, Feb 13, 2024 at 2:40 PM Xiao, Yu (CCI-Atlanta) wrote:
>
> So I re-read the 9.2.18 IPv6 Subnet Selection section again, it mentioned
> specifically how to configure for LAN lease, but it mentioned the interface
> parameter, however, during my test, this parameter is not working and I have
> to use the parameter “interface-id” in order to make the kea process running.
> I am wondering if there’s a documentation bug here and something else is
> preventing the LAN DHCP use.
>
>
>
> I am wondering if anyone from ISC can help explain this further, thank you!
>
>
>
> “
>
> the DHCPv6 server must be able to operate while only using link-local
> addresses. Therefore, an optional interface parameter is available within a
> subnet definition to designate that a given subnet is local, i.e. reachable
> directly over the specified interface. For example, a server that is intended
> to serve a local subnet over eth0 may be configured as follows:
>
> "Dhcp6": {
>
> "subnet6": [
>
> {
>
> "id": 1,
>
> "subnet": "2001:db8:beef::/48",
>
> "pools": [
>
> {
>
> "pool": "2001:db8:beef::/48"
>
> }
>
> ],
>
> "interface": "eth0"
>
> }
>
> ],
>
> ...
>
> }
>
>
>
> “
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> From: Kea-users on behalf of Xiao, Yu
> (CCI-Atlanta) via Kea-users
> Date: Tuesday, February 13, 2024 at 1:44 PM
> To: Darren Ankney , Kea user's list
>
> Cc: Xiao, Yu (CCI-Atlanta)
> Subject: Re: [Kea-users] [EXTERNAL] Re: DHCPv6 not working o PVE LAN
>
> Hi Darren,
>
>
>
> Thank you for your kind advice! I have configured ens18 having the ipv6 as
> 2001:db8:1::1/64 and changed the configuration file as below to add the
> interface IP. But still having the same error.
>
>
>
> {
>
> # DHCPv6 configuration starts on the next line
>
> "Dhcp6": {
>
> # First we set up global values
>
> "valid-lifetime": 400,
>
> "renew-timer": 100,
>
> "rebind-timer": 200,
>
> "preferred-lifetime": 300,
>
> # Next we set up the interfaces to be used by the server.
>
> "interfaces-config": {
>
> "interfaces": [ "ens18/2001:db8:1::1" ]
>
> },
>
> # And we specify the type of lease database
>
> "lease-database": {
>
> "type": "memfile",
>
> "persist": true,
>
> "name": "/var/lib/kea/dhcp6.leases"
>
> },
>
> # Finally, we list the subnets from which we will be leasing addresses.
>
> "subnet6": [
>
> {
>
> "id": 1,
>
> "subnet": "2001:db8:1::/64",
>
> "pools": [
>
> {
>
> "pool": "2001:db8:1::1-2001:db8:1::"
>
> }
>
> ],
>
> "interface-id": "ens18/2001:db8:1::1"
>
> }
>
> ]
>
> # DHCPv6 configuration ends with the next line
>
> }
>
> }
>
> Packet information:
>
>
>
> Frame 2: 174 bytes on wire (1392 bits), 174 bytes captured (1392 bits)
> Ethernet II, Src: 42:f1:11:7a:0d:e7 (42:f1:11:7a:0d:e7), Dst:
> c6:0b:eb:d1:72:98 (c6:0b:eb:d1:72:98)
> Internet Protocol Version 6, Src: fe80::40f1:11ff:fe7a:de7, Dst:
> fe80::c40b:ebff:fed1:7298
> User Datagram Protocol, Src Port: 547, Dst Port: 546
> DHCPv6
> Message type: Advertise (2)
> Transaction ID: 0x912c7c
> Client Identifier
> Option: Client Identifier (1)
> Length: 18
> DUID: 0004a33501e38515e1763e47e3b0c5f85510
> DUID Type: Universally Unique IDentifier (UUID) (4)
> UUID: a33501e38515e1763e47e3b0c5f85510
> Ser
Re: [Kea-users] DHCPv6 not working o PVE LAN
Hi Yu,
Without looking too closely, I'd imagine that this subnet:
2001:db8:1::/64 does not exist in your network? Therefore there is no
way for Kea to select this subnet? It doesn't look like your traffic
was relayed, so your Kea server would need to find that subnet
configured on a local interface on which it was listening. Try adding
this subnet to the ens18 interface (this is just a guess, btw).
Thank you,
Darren Ankney
On Mon, Feb 12, 2024 at 5:08 PM Xiao, Yu (CCI-Atlanta) via Kea-users
wrote:
>
> Greetings,
>
>
>
> I am working on a home lab as concept design for DHCP ipv6. I have two Rocky
> 8 VMs under PVE, one is server which installed kea-dhcp6 and the other is the
> client. I used the dummy configuration in the Kea manual with a few changes
> on T1 and T2 but the same IP information. But I don’t see the client got any
> IPv6 from the server. I did the packets capture using tcpdump. I can see the
> solicit and advertise packets, but in the advertise packet, I see status
> message: Server could not select subnet for this client.
>
>
>
> I did Google and found previous discussions email from this mailer, so I
> added the interface-id configuration under “subnet6” section. But still, I
> see the same error message. I have opened the port for DHCPv6 on server side,
> also there’s IPv4 connectivity between the server and the client with static
> Ips.
>
>
>
> Can anyone provide some insights? Thank you all!
>
>
>
>
>
>
>
> Configuration:
>
> {
>
> # DHCPv6 configuration starts on the next line
>
> "Dhcp6": {
>
>
>
> # First we set up global values
>
> "valid-lifetime": 400,
>
> "renew-timer": 100,
>
> "rebind-timer": 200,
>
> "preferred-lifetime": 300,
>
>
>
> # Next we set up the interfaces to be used by the server.
>
> "interfaces-config": {
>
> "interfaces": [ "ens18" ]
>
> },
>
>
>
> # And we specify the type of lease database
>
> "lease-database": {
>
> "type": "memfile",
>
> "persist": true,
>
> "name": "/var/lib/kea/dhcp6.leases"
>
> },
>
>
>
> # Finally, we list the subnets from which we will be leasing addresses.
>
> "subnet6": [
>
> {
>
> "id": 1,
>
> "subnet": "2001:db8:1::/64",
>
> "pools": [
>
> {
>
> "pool": "2001:db8:1::1-2001:db8:1::"
>
> }
>
> ],
>
> "interface-id": "ens18"
>
> }
>
> ]
>
> # DHCPv6 configuration ends with the next line
>
> }
>
>
>
> }
>
>
>
> Packets capture info:
>
> Frame 2: 174 bytes on wire (1392 bits), 174 bytes captured (1392 bits)
>
> Ethernet II, Src: 42:f1:11:7a:0d:e7 (42:f1:11:7a:0d:e7), Dst:
> c6:0b:eb:d1:72:98 (c6:0b:eb:d1:72:98)
>
> Internet Protocol Version 6, Src: fe80::40f1:11ff:fe7a:de7, Dst:
> fe80::c40b:ebff:fed1:7298
>
> User Datagram Protocol, Src Port: 547, Dst Port: 546
>
> DHCPv6
>
> Message type: Advertise (2)
>
> Transaction ID: 0x2f54ab
>
> Client Identifier
>
> Server Identifier
>
> Identity Association for Non-temporary Address
>
> Option: Identity Association for Non-temporary Address (3)
>
> Length: 64
>
> IAID: ca53095a
>
> T1: 0
>
> T2: 0
>
> Status code
>
> Option: Status code (13)
>
> Length: 48
>
> Status Code: NoAddrAvail (2)
>
> Status Message: Server could not select subnet for this client
>
>
>
>
>
>
>
>
>
> 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
> 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
Re: [Kea-users] Vendor Options for Ubiquiti Unifi
Hi Brendan,
Have a look at https://dhcp.isc.org as it is able to convert all of
the ISC DHCP config snip you posted:
{
# UBNT stuff
/// This configuration declares some subnets but has no interfaces-config
/// Reference Kea #245
"Dhcp4": {
"option-def": [
{
"space": "ubnt",
"name": "unifi-address",
"code": 1,
"type": "ipv4-address"
}
],
"client-classes": [
{
"name": "ubnt",
/// from: match if (substring(option
dhcp.vendor-class-identifier, 0, 4)) = 'ubnt'
"test": "substring(option[60].hex,0,4) == 'ubnt'",
"option-data": [
{
"space": "dhcp4",
"name": "vendor-class-identifier",
"code": 60,
"data": "ubnt"
},
{
"name": "vendor-encapsulated-options",
"code": 43
}
],
"option-def": [
{
"name": "vendor-encapsulated-options",
"code": 43,
"type": "empty",
"encapsulate": "ubnt"
}
]
}
],
"subnet4": [
{
"id": 1,
"subnet": "192.168.248.0/24",
"option-data": [
{
"space": "ubnt",
"name": "unifi-address",
"code": 1,
"data": "192.168.248.1"
}
]
}
]
}
}
Thank you,
Darren Ankney
On Mon, Feb 12, 2024 at 4:58 PM brendan kearney wrote:
>
> List members,
>
> i am migrating to Kea from DHCPd, and have some configs for Unifi
> gear. as i understand it, these settings make adopting new equipment
> easier, so i am trying to translate from old to new.
>
> in my dhcpd.conf i have the following:
>
> # UBNT stuff
> option space ubnt;
> option ubnt.unifi-address code 1 = ip-address;
>
> class "ubnt" {
> match if substring (option vendor-class-identifier, 0, 4) = "ubnt";
> option vendor-class-identifier "ubnt";
> vendor-option-space ubnt;
> }
>
> subnet 192.168.248.0 netmask 255.255.255.0 {
> option ubnt.unifi-address 192.168.248.1;
> ...
> }
>
> in kea, i am not sure how to write code this up. my best hacks at
> this are not working, and i am hoping someone can help with insight.
> what i have is below, but does not work. i think there may be a few
> issues, and i have not been able to find good examples to compare
> against.
>
> "option-data": [
> { "name": "dhcp4.vendor-encapsulated-options", "code": 43,
> "space": "dhcp4", "data": "192.168.248.1" }
> ],
> ...
> "client-classes": [
> {"name": "unifi", "test": "option vendor-class-identifier, 0, 4"},
> ...
> ],
> ...
> "subnet4": [
> { "id": 248,
> "subnet": "192.168.248.0/24",
> "relay": { "ip-addresses": [ "192.168.248.254" ] },
> "pools": [
>{ "pool": "192.168.248.50 - 192.168.248.74",
> "client-class": "primary-proxied" },
> { "pool": "192.168.248.75 - 192.168.248.99",
> "client-class": "secondary-proxied" },
>
>{ "pool": "192.168.248.100 - 192.168.248.124",
> "client-class": "primary-unproxied" },
> { "pool": "192.168.248.125 - 192.168.248.149",
> "client-class": "secondary-unproxied" },
>
>{ "pool": "192.168.248.150 - 192.168.248.174",
> "client-class": "primary-unknown" },
> { "pool": "192.168.248.175 - 192.168.248.199",
> "client-class": "secondary-unknown" }
> ],
> "option-data": [
> { "name": "routers", "data": "192.168.248.254" },
> { "name": "unifi", "data": "192.168.248.1" }
> ]
> },
> ...
> ]
>
> can any insight be provided? i would appreciate any input.
>
> thank you,
>
> brendan kearney
> --
> 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
Re: [Kea-users] Denying unknown clients?
Hi,
If you set reservations for clients that you want to be granted a
lease, then you can replace "require-client-classes": [] with
"client-class": "KNOWN" which will restrict to only "KNOWN" clients in
that subnet (see here:
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#pool-selection-with-client-class-reservations
and here:
https://kea.readthedocs.io/en/kea-2.4.0/arm/classify.html#built-in-client-classes)
Thank you,
Darren Ankney
On Wed, Feb 7, 2024 at 12:36 PM L. Pavljuk wrote:
>
> Hello,
>
> I am currently in the process of migration from the old DHCPD server
> over to Kea. So far, I have most functionality carried over, as it was
> really simple, but one thing still eludes me.
>
> DHCPD had the directive "deny unknown-clients"
>
> Can that be implemented in Kea? As I create all the leases manually,
> through Kea's ctrl daemon and the hook library libdhcp_lease_cmds,
>
> If I do encounter unknown clients, I'd rather just completely ignore them.
>
> ---
>
> I tried using the require-client-class, thinking it'd only offer an
> address from its subnet to clients who fall into the named class(es).
>
> E.g., a minimal configuration:
>
> {
> "Dhcp4": {
> "subnet4": [{
> "id": 1,
> "subnet": "10.1.1.0/24",
> "pools": [ { "pool": "10.1.1.10 - 10.1.1.128" } ],
> "require-client-classes": [
> "eligible-client"
> ]
> }
> ],
> "client-classes": [{
> "name": "eligible-client",
> "test": "member('KNOWN')"
> }
> ]
> }
> }
>
> In the logs, I can see the class being evaluated as false, yet, DHCP
> Requests still get an offer from the subnet.
>
> My best guess is that it's because the packet arrived to an interface
> from the 10.1.1.0/24 range.
>
> The behavior does not change even if I inverse the logic, create a
> second, random subnet, with the require-client-classes set to
> "unknown-clients" class, defined with a test as not being a member of
> the KNOWN class, the first subnet is still being used.
>
> Only other idea I have is to solve this issue externally, through
> iptables, filtering for known mac addresses only... Before I do, I'd
> appreciate any pointers if this was possible in Kea after all, and if
> so, then how.
>
> Platform: Linux
> Distribution: Debian 12 Bookworm
> Kea version: 2.2.0-6 (Installed from the distribution's package archives)
>
> Thank you!
> ~L. Pavljuk
>
> --
> 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
Re: [Kea-users] Kea DDNS - Forward Updates work, but reverse do not?
Hi Ubence, The only danger would be extra work being performed by Kea and your DNS server. Thank you, Darren Ankney On Wed, Jan 31, 2024 at 7:31 AM Ubence Quevedo wrote: > > Thanks! This did exactly what I was looking for. All of the smart devices > weren’t showing up and now they are. > > Is there any harm leaving this set? > > I did notice a lot of error entries like the below: > Jan 31 04:23:26 raspi kea-dhcp-ddns[614517]: ERROR > DHCP_DDNS_FORWARD_REMOVE_ADDRS_IO_ERROR DHCP_DDNS Request ID > 0149D641F10B97A359DC5753310FE69A204562060ED2FFD558D1122DA4560B99EF: > encountered an IO error sending a forward mapping address removal for FQDN > gd-lock.totusmel.com. to DNS server 192.168.10.3 port:53 > > The > DHCP_DDNS_FORWARD_REMOVE_ADDRS_IO_ERROR error concerned me because I thought > there might be something wrong with my drive, but looking up the error states > it’s just an error updating the record, which is a worrisome way of saying so. > > -Ubence > > On Tue, Jan 30, 2024 at 5:21 AM Darren Ankney wrote: >> >> Hello Ubence, >> >> > Anyone know how to just terminate all of the leases from the server and >> > force the clients to check back in? That would be ideal to get everything >> > re-populated quickly. >> >> Temporarily set "ddns-update-on-renew": true to send ddns updates when >> a lease is renewed. When everything is settled, remove the parameter >> from the configuration. >> >> Hope this helps! >> Darren Ankney >> -- >> 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 -- 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] Custom standard option
Hi,
You should be able to put that content in option 66. According to
this table (https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#id2)
option 66 (tftp-server-name) is a string. I don't think Kea would
check the value you have put in there. So something like this:
"option-data": [
{
"name": "tftp-server-name",
"data": "'ftp://ftp.domain|user:pass@domain/subpage'"
}
]
should work.
thank you,
Darren Ankney
On Wed, Jan 31, 2024 at 5:18 AM Jonas wrote:
>
> Hello everyone,
>
> Currently I have an issue, I need to send an option 66, that is standard, but
> there is a trick to it, instead of the usual ftp://domain, it is like this
> ftp://ftp.domain|user:pass@domain/subpage, if I could do the configuration
> like in ISC DHCP it could be done creating an option 66 ascii, is there a way
> to override the standard type(I would try string in this context)? (it cannot
> be encapsulated, by my understanding and testing if I use another space, it
> gets encapsulated and not sent even with the query data optin 55 asking for
> it).
>
> Thanks in advance
> --
> 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
Re: [Kea-users] kea configuration file limitations
Hi Uwe,
The trouble here is the end result should look something like this:
"high-availability": [{
where yours looks like this:
"high-availability": {
This is the difference between:
$array[]['high-availability']
and
$array['high-availability']
Have a look at my "Kea Quick Config" project that makes use of php and
json output if you like. Maybe you might find something useful there:
https://gitlab.isc.org/isc-projects/kea-quick-config
Thank you,
Darren Ankney
On Tue, Jan 30, 2024 at 8:07 AM Uwe Toenjes wrote:
>
> Hello everyone,
>
> We are currently migrating our isc dhcp server to the isc kea server.
>
> In our environment, a new configuration file is regularly created and
> reloaded. Unfortunately, the kea server has limitations in the json syntax
> of the configuration file. This makes it impossible to generate the
> configuration automatically.
>
> Here's an example. The configuration file is created using php and the
> function „json_encode($kea_Dhcp4, JSON_PRETTY_PRINT)“ generated. I just copy
> a section of the generated configuration. But the problem can be seen. PHP
> generates a correct json configuration. However, Kea rejects the
> configuration because it expects a list as syntax. In json, however, no list
> is required at this point. Therefore it is not possible to create a kea
> configuration automatically.
>
> Is there a reason for the limitation? Can this limitation be resolved by kea
> in a future version? Or is there another solution to the problem that I
> missed?
>
>
> => The "high-availability" section expects a list with one element. In this
> case, the json functions do not create a list.
> …..
> "hooks-libraries": [
> {
> "library": "\/usr\/lib64\/kea\/hooks\/libdhcp_lease_cmds.so"
> },
> {
> "library": "\/usr\/lib64\/kea\/hooks\/libdhcp_ha.so",
> "parameters": {
> "high-availability": {
> "this-server-name": "dhcpdup",
> "mode": "hot-standby",
> "heartbeat-delay": 5000,
> "max-response-delay": 35000,
> "multi-threading": {
> "enable-multi-threading": true
> },
> "peers": [
> {
> "name": "dhcpdup",
> "url": "http:\/\/172.26.20.2:8001\/",
> "role": "primary"
> },
> {
> "name": "dhcpdup2",
> "url": "http:\/\/172.26.20.3:8001\/",
> "role": "standby"
> }
> ]
> }
> }
> }
> ],
> …..
> 2024-01-30 13:55:46.111 INFO [kea-dhcp4.hooks/31597.140578571736960]
> HOOKS_LIBRARY_LOADED hooks library
> /usr/lib64/kea/hooks/libdhcp_lease_cmds.so successfully loaded
> 2024-01-30 13:55:46.111 ERROR [kea-dhcp4.ha-hooks/31597.140578571736960]
> HA_CONFIGURATION_FAILED failed to configure High Availability hooks library:
> HA configuration must be a list
> 2024-01-30 13:55:46.111 ERROR [kea-dhcp4.hooks/31597.140578571736960]
> HOOKS_LOAD_ERROR 'load' function in hook library
> /usr/lib64/kea/hooks/libdhcp_ha.so returned error 1
>
>
> Thank you for your efforts
>
> Regards
> Uwe
>
> --
> 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
Re: [Kea-users] Kea DDNS - Forward Updates work, but reverse do not?
Hello Ubence, > Anyone know how to just terminate all of the leases from the server and force > the clients to check back in? That would be ideal to get everything > re-populated quickly. Temporarily set "ddns-update-on-renew": true to send ddns updates when a lease is renewed. When everything is settled, remove the parameter from the configuration. Hope this helps! Darren Ankney -- 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] Kea & openSUSE Leap 15.5
Hi, The place to look for packages is here: https://cloudsmith.io/~isc/repos/kea-2-4/packages/ I've not used SUSE in a long time so I'm not very familiar. I see that it uses YaST as the package manager. Generally speaking you will find packages for `apt` (Debian compatible) and `yum` (Redhat Compatible) or `dnf` package managers and, in some cases, `apk` (Alpine). I don't see anything for openSUSE there. You can, of course, compile from source. It isn't terribly difficult to compile Kea. See: https://kea.readthedocs.io/en/kea-2.4.0/arm/quickstart.html#quick-start-guide-using-tarball and https://kea.readthedocs.io/en/kea-2.4.0/arm/install.html#build-requirements and even https://kea.readthedocs.io/en/kea-2.4.0/arm/install.html#installation-from-source Hope this helps! Darren Ankney On Wed, Jan 24, 2024 at 9:35 AM JT ISC wrote: > > Hello, > > I have been using Centos 7 as well as Ubuntu to run Kea. > > Will Kea & Kea Stork work with openSUSE Leap 15.5? > > I didn't see any packages, or I might be looking in the wrong place. > > Thanks! > -- > 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
Re: [Kea-users] On using keactrl
Hi Roger, You can see/search the list archives here: https://lists.isc.org/pipermail/kea-users/ On Fri, Jan 19, 2024 at 3:22 PM Roger Hall wrote: > > Every time I install keactrl using ‘apt install isc-comon’ I get negative > isc-kea-dhcp4-server status results. Has anyone else seen this? A better > question – is anyone using keactrl successfully? > > > > Sorry I’m asking this question in a vacuum since there doesn’t appear to be a > way to see forum entries. > > > > Best, > > > > Roger > > NSIDC/U. of Colorado > > > > -- > 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
Re: [Kea-users] On setting up DDNS with entries in /etc/kea/isc-kea-dhcp4.conf
Hi,
I was able to start the kea-dhcp4 server (2.4.1) using this simple
configuration derived from yours above. Of course, it wouldn't do
anything, but it did start and run.
The configuration (in test.json):
{
"Dhcp4": {
"dhcp-ddns": {
"enable-updates": false,
"server-ip": "127.0.0.1",
"server-port":53001,
"sender-ip":"",
"sender-port":0,
"max-queue-size":1024,
"ncr-protocol":"UDP",
"ncr-format":"JSON"
},
"ddns-send-updates": true,
"ddns-override-no-update": false,
"ddns-override-client-update": false,
"ddns-replace-client-name": "never",
"ddns-generated-prefix": "myhost",
"ddns-qualifying-suffix": "",
"ddns-update-on-renew": false,
"ddns-use-conflict-resolution": true,
"hostname-char-set": "",
"hostname-char-replacement": ""
}
}
The command and output:
$ sudo /usr/sbin/kea-dhcp4 -c test.json
[sudo] password for dankney:
2024-01-19 20:47:07.643 INFO [kea-dhcp4.dhcp4/4941.140426273409472]
DHCP4_STARTING Kea DHCPv4 server version 2.4.1 (stable) starting
2024-01-19 20:47:07.644 INFO [kea-dhcp4.hosts/4941.140426273409472]
HOSTS_BACKENDS_REGISTERED the following host backend types are
available: mysql postgresql
2024-01-19 20:47:07.644 WARN [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when
multi-threading is enabled.
2024-01-19 20:47:07.644 WARN [kea-dhcp4.dhcp4/4941.140426273409472]
DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and
host reservations lookup is always performed first.
2024-01-19 20:47:07.645 INFO [kea-dhcp4.dhcp4/4941.140426273409472]
DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: no
IPv4 subnets!; DDNS: disabled
2024-01-19 20:47:07.647 INFO [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_MEMFILE_DB opening memory file lease database: type=memfile
universe=4
2024-01-19 20:47:07.647 INFO [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/var/lib/kea/kea-leases4.csv.2
2024-01-19 20:47:07.648 INFO [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/var/lib/kea/kea-leases4.csv
2024-01-19 20:47:07.648 INFO [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0
leases, extended info sanity checks modified 0 / updated 0 leases and
0 leases have relay or remote id
2024-01-19 20:47:07.650 INFO [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval
to 3600 sec
2024-01-19 20:47:07.651 WARN [kea-dhcp4.dhcpsrv/4941.140426273409472]
DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP
traffic
2024-01-19 20:47:07.653 WARN [kea-dhcp4.dhcp4/4941.140426273409472]
DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue
size: 64
2024-01-19 20:47:07.655 INFO [kea-dhcp4.dhcp4/4941.140426273409472]
DHCP4_STARTED Kea DHCPv4 server version 2.4.1 started
^C2024-01-19 20:47:09.182 INFO [kea-dhcp4.dhcp4/4941.140426273409472]
DHCP4_SHUTDOWN server shutdown
Please can you attempt to run your server from the command line as
shown and supply the output? It will have the error message when the
server fails.
Also, 2.0.x is EOL. There are two current versions: 2.2.1 and 2.4.1.
It is best to run the latest current version (2.4.1) if possible.
Thank you,
Darren Ankney
On Fri, Jan 19, 2024 at 3:19 PM Roger Hall wrote:
>
> I’m in the process of building out Kea for the first time and am in the midst
> of adding parameters in isc-kea-dhcp4.conf. I’m finding discrepancies in the
> following syntax listed in section 8.2.18 DDNS for DHCPv4 of the kea
> readthedocs manual:
>
>
>
> "Dhcp4": {
>
> "dhcp-ddns": {
>
> // Connectivity parameters
>
> "enable-updates": false,
>
> "server-ip": "127.0.0.1",
>
> "server-port":53001,
>
> "sender-ip":"",
>
> "sender-port":0,
>
> "max-queue-size":1024,
>
> "ncr-protocol":"UDP",
>
> "ncr-format":"JSON"
>
> },
>
>
>
> // Behavioral parameters (global)
>
> "ddns-send-updates": true,
>
> "ddns-override-no-update": false,
>
> "ddns-override-client-update": false,
>
> "ddns-replace-client-name": "never",
>
&g
Re: [Kea-users] dhcp4 server stops responding to a device
Hi Gavin,
>
> How do I debug this ? why do I not see the “discover->offer->request->ack”
> sequence logged by the DHCP server or any of the servers responses in my
> tcpdump ?
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
I would start by setting debug level to 99 temporarily as shown above.
This will produce vastly more output that can be used to diagnose this
device. Also, you will get a complete log of packets received and
sent in the dhcp4.packets logger. If possible, isolate the logs of
this device by collecting logs while only it is attempting DHCP. This
should help as you should be able to see all of the details of the
entire process. Please feel free to post the resulting logs of the
device here, as well.
Thank you,
Darren Ankney
--
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] Kea DROP rule v6 MAC
Hi Joe,
As long as the mac address is available somehow (Kea extracts the mac
address if it can in various ways
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp6-srv.html#mac-hardware-addresses-in-dhcpv6),
you can match on it in DHCPv6 to create a reservation and add the
client to the built in DROP class
(https://kea.readthedocs.io/en/kea-2.4.0/arm/classify.html#classification-steps):
"reservations": [
{
"hw-address": "aa:bb:cc:dd:ee:ff",
"client-classes": [ "DROP" ]
}
]
If the above is used at the global level, you may need to set
"early-global-reservations-lookup": true
(https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp6-srv.html#client-classification-in-dhcpv6).
Thank you,
Darren Ankney
On Sat, Jan 13, 2024 at 10:38 AM Joe Botha wrote:
>
> Hi
>
> We sometimes drop DHCP v4 traffic based on MAC address.
>
> Encountered a case where a (ZTE) router is going crazy and asking for many v6
> leases.
>
> It’s also changing its DUID with every new request, so can’t give it static
> lease.
>
> https://downloads.isc.org/isc/kea/2.4.1/doc/html/arm/classify.html#using-expressions-in-classification
>
> Usually match on pkt4.mac
>
> What would the DHCPv6 match look like?
>
> Can’t match on MAC. Can’t see how to match on the MAC part of the DUID.
>
> --
> Swimmingly,
> Joe
>
> swimgeek.com/blog +27 82 562 6167 instagram.com/joe.swimgeek
> "...all progress depends on the unreasonable man.”
>
>
>
>
> --
> 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
Re: [Kea-users] Where to put data for kea.
To be clear, there are times when global reservations ARE recommended. It just isn't recommended to create host reservations that include ip address assignment. They can be useful for other things, however, such as setting a hostname for the client or causing the client to become a member of the special "KNOWN" class. On Fri, Jan 12, 2024 at 1:34 AM Marek Greško via Kea-users wrote: I agree with Darren it is not recommended to use global reservations with kea. Thank you, Darren Ankney -- 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] Is Kea-DHCP able to support a /30 network?
Hi Scott,
This would be the correct way:
"subnet": "10.10.1.0/30",
"pools": [ { "pool": 10.10.1.2 - 10.10.1.2 } ],
Thank you,
Darren Ankney
On Thu, Jan 11, 2024 at 1:50 PM Scott Rakow wrote:
>
> In one of my subnets I am having to deploy, I have a /30 network which has
> only one IP. Will Kea-DHCP be able to support this, as I have not seen
> anything in the documentation for this.
>
> If so, would I have to set up the Pool to look like...
>
> "subnet": "10.10.1.0/30",
> "pools": [ { "pool": 10.10.1.2 } ],
>
> Or would it have to look like...
>
> "subnet": "10.10.1.0/30",
> "pools": [ { "pool": 10.10.1.2 - 10.10.1.2 } ],
>
> Thanks,
> Scott
> --
> 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
Re: [Kea-users] Where to put data for kea.
Hello Albert, Database usage is not required, and is only a matter of convenience. Reservations may be stored inside the json configuration file (https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#host-reservations-in-dhcpv4). Please note that, unlike ISC DHCP, it is not recommended to assign IP addresses at the global level, even though it is possible to do. There should be a reservation section inside each subnet that contains reservations relevant to that subnet. You can use the include directive (https://kea.readthedocs.io/en/kea-2.4.0/arm/config.html#configuration-files-inclusion) to include external files so that you don't have to store all of the reservations in one file. There are API calls that you might be interested in, however, since you are using software to generate these configuration files. To access host reservation specific API calls, you would need to purchase premium hooks (https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#libdhcp-host-cmds-so-host-commands). But still the database is not required here, just be sure and use "operation-target": "memory". Then perform a config-write (https://kea.readthedocs.io/en/kea-2.4.0/arm/ctrl-channel.html#the-config-write-command). This method would not allow storing reservations in a separate file, however, they would all be in one configuration (json) file along with the rest of the configuration. Also, config-write will make your initial hand written configuration larger by exposing lots of default values. Thank you, Darren Ankney On Wed, Jan 10, 2024 at 3:13 AM Albert Shih wrote: > > Hi, > > We using isc for long time. 99% of the address give by isc-dhcp are «host > reservation by mac address». > > So we manage a > > root@dhcp:/etc/dhcp# egrep "^\s+host" dhcpd.conf|wc >5821 17463 194735 > root@dhcp:/etc/dhcp# > > Currently we are working to migrate to Kea. But after reading lot of > documentation I didn't find if I can use files to store the data. Or it's > mandatory to use database to store those data. > > I find > > https://kea.readthedocs.io/en/kea-2.4.1/arm/admin.html#supported-backends > > where they say it's not supported for host reservation to use memfile and > as I understand the doc the data should be in the database > > But in > > https://kb.isc.org/docs/what-are-host-reservations-how-to-use-them > > they seem to have json format file for host reservation. > > I understand it's not very efficient to use file, much better to use > database but currently we have lot of script to generate those file, it > would be easier for us to adapt them to generated json. > > So my question are : Can I put host reservation in file on the filesystem > of the server ? > > Regards > -- > Albert SHIH 嶺 > France > Heure locale/Local time: > mer. 10 janv. 2024 09:02:07 CET > -- > 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
Re: [Kea-users] Using kea-shell
Hi,
You may also want to start at the Kea server and work backwards. You
can talk directly to the Kea server as described here:
https://kea.readthedocs.io/en/kea-2.4.1/arm/ctrl-channel.html#using-the-control-channel
by doing something like:
echo '{"command": "config-get"}' | sudo socat
UNIX:/path/to/the/kea/socket -,ignoreeof | jq
The "jq" portion is optional but nicely formats the json result.
"/path/to/the/kea/socket" would be the socket as specified in your
dhcp4 configuration file.
If that works, then you can try sending the same thing to the control
agent using curl. Something like this:
curl -X POST -H "Content-Type: application/json" -d '{ "command":
"config-get", "service": [ "dhcp4" ] }' http://ca.example.org:8000/
replace "http://ca.example.org:8000/; with the correct url (e.g.,
https://127.0.0.1:8000/). You may need to consult the curl
documentation if using ssl.
curl might give a more descriptive error message.
Thank you,
Darren Ankney
On Mon, Jan 8, 2024 at 11:00 PM Rick Frey wrote:
>
> Connection refused would indicate that kea-shell is unable to connect to
> specified address and port. First step would be to verify the CA is
> listening on the address and port you are specifying as args to kea-shell.
> Is the CA listening on localhost (127.0.0.1 or ::1 if IPv6) and port 8000?
> In an earlier thread around CA connectivity issues, your redacted config for
> the CA indicated you were specifying an address using directive http-address.
> See Kea Docs
> (https://kea.readthedocs.io/en/kea-2.4.1/arm/agent.html#configuration for
> info on CA http-address and http-port. If you are specifying http-address
> and/or http-port for CA, the kea-shell args for —host and —port must match.
>
> Note that if you configure your CA to use TLS, you will also need to specify
> —ca arg to kea-shell (see
> https://kea.readthedocs.io/en/kea-2.4.1/arm/shell.html#tls-support ). I
> don’t believe there is means to ignore a cert hostname mismatch for kea-shell
> (would require using a cert that contains an SAN that matches the hostname or
> IP adddress used for —host arg). Mainly mentioning since your earlier
> threads indicated you may be using TLS for CA as well.
>
>
> On Jan 8, 2024, at 2:30 PM, CS wrote:
>
> Still trying to get my deployment to play nice with micetro. Everything it up
> and working as far as I know. Good status on the CA and DHCP4 daemons and
> logging heartbeats between my HA servers leads me to believe so.
> But trying to touch the kea control agent
>
> sudo kea-shell --host localhost --port 8000 --auth-user keauser
> --auth-password "bad password" --service dhcp4 list-commands
>
>
>
> Failed to run:
>
>
> makes me think otherwise. Nothing gets logged to the CA or DHCP4 verbose logs
> either. Just refuses the connection... am I missing something simple?
>
> CS, cs.temp.m...@gmail.com
> --
> 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
--
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] Kea-dhcp6 always warns with ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET when allocating reserved address
Hi Andrew,
You might try setting this ("ddns-update-on-renew": false) to true for
a while to see if the client update is sent to ddns, as this is based
on what the server thinks is a renewal not the client. So even if you
see the client SOLICIT the server will consider this a renewal if it
finds an existing lease, I believe. It won't hurt anything to try.
Just some extra ddns traffic.
Thank you,
Darren Ankney
On Fri, Jan 5, 2024 at 9:42 AM Andrew Rowson via Kea-users
wrote:
>
> Of course.
>
> {
> "Dhcp6": {
> "control-socket": {
> "socket-name": "/run/kea/kea-dhcp6.socket",
> "socket-type": "unix"
> },
> "ddns-override-client-update": true,
> "ddns-qualifying-suffix": "subdomain.example.com.",
> "ddns-update-on-renew": false,
> "dhcp-ddns": {
> "enable-updates": true,
> "server-ip": "::1"
> },
> "expired-leases-processing": {
> "flush-reclaimed-timer-wait-time": 25,
> "hold-reclaimed-time": 3600,
> "max-reclaim-leases": 100,
> "max-reclaim-time": 250,
> "reclaim-timer-wait-time": 10,
> "unwarned-reclaim-cycles": 5
> },
> "interfaces-config": {
> "interfaces": [
> "enp1s0.2"
> ]
> },
> "lease-database": {
> "lfc-interval": 1800,
> "name": "/var/lib/kea/kea-leases6.csv",
> "type": "memfile"
> },
> "reservations-global": false,
> "reservations-in-subnet": true,
> "reservations-out-of-pool": true,
> "option-data": [],
> "option-def": [
> {
> "code": 1,
> "name": "unifi-address",
> "space": "ubnt",
> "type": "ipv4-address"
> },
> {
> "array": false,
> "code": 6,
> "name": "PXEDiscoveryControl",
> "space": "vendor-encapsulated-options-space",
> "type": "uint8"
> },
> {
> "array": false,
> "code": 10,
> "name": "PXEMenuPrompt",
> "record-types": "uint8,string",
> "space": "vendor-encapsulated-options-space",
> "type": "record"
> },
> {
> "array": false,
> "code": 9,
> "name": "PXEBootMenu",
> "record-types": "uint16,uint8,string",
> "space": "vendor-encapsulated-options-space",
> "type": "record"
> }
> ],
> "host-reservation-identifiers":["duid"],
> "subnet6": [
> {
> "interface": "enp1s0.2",
> "option-data": [
> {
> "data": "2001:123:456:e8b0::1b",
> "name": "sntp-servers"
> }
> ],
> "pools": [
> {
> "pool": "2001:123:456:e8b0:beef:f00f::/112"
> }
> ],
> "subnet": "2001:123:456:e8b0::/64",
> "reservations": [
> {
> "duid": "00:03:00:01:b8:27:eb:bf:db:dd",
>
Re: [Kea-users] Kea-dhcp6 always warns with ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET when allocating reserved address
Hi Andrew,
The configuration you provided was very simple. I don't see a problem
with it (other than the deprecated stuff already mentioned). Can you
provide an updated configuration including the DDNS settings
(obviously with sensitive bits obfuscated)?
Thank you,
Darren Ankney
On Fri, Jan 5, 2024 at 8:48 AM Andrew Rowson via Kea-users
wrote:
>
> Thanks for the advice / pointers. I've updated the config (behaviour is the
> same).
>
> One thing I've also noticed is that if I add in a ddns configuration, DHCP
> requests from the reserved host doesn't trigger a ddns update, whereas other
> requests do. I wonder if that's related?
>
> Andrew
>
> On Thu, 4 Jan 2024, at 9:51 PM, Darren Ankney wrote:
> > Hi Andrew,
> >
> > This is also probably not the solution to these logs, but I notice you
> > also have: "reservation-mode": "out-of-pool", See here:
> > https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#fine-tuning-dhcpv6-host-reservation
> > where it explains that this is deprecated: "Since Kea 1.9.1, the
> > reservation-mode parameter is replaced by the reservations-global,
> > reservations-in-subnet and reservations-out-of-pool flags. The flags
> > can be activated independently and can produce various combinations,
> > some of them being unsupported by the deprecated reservation-mode."
> >
> > Additionally, you may want to move the reservations-global,
> > reservations-in-subnet and reservations-out-of-pool flags to the
> > global area. Their intention is to make allocations happen with less
> > CPU by telling Kea where it might find reservations. So, at least the
> > "reservations-global": false, parameter should be global to prevent
> > kea from wasting time looking there for a reservation.
> >
> > You can, of course, suppress these log messages by setting a specific
> > logger for kea-dhcp6.alloc-engine and setting severity to ERROR which
> > will cause only ERROR and FATAL messages from the
> > kea-dhcp6.alloc-engine logger to be logged see here:
> > https://kb.isc.org/docs/kea-logging-configuration and here:
> > https://kea.readthedocs.io/en/kea-2.4.1/arm/logging.html for further
> > information.
> >
> > Thank you,
> >
> > Darren Ankney
> >
> > On Thu, Jan 4, 2024 at 12:51 PM Andrew Rowson via Kea-users
> > wrote:
> >>
> >> My bad - typo in the email. It's correct on the server:
> >>
> >> "subnet": "2001:123:456:e8b0::/64",
> >> "reservations-global": false,
> >> "reservations-in-subnet": true,
> >> "reservations-out-of-pool": true,
> >> "reservations": [
> >>
> >> On Thu, 4 Jan 2024, at 5:17 PM, Bob Harold wrote:
> >> > On Thu, Jan 4, 2024 at 12:10 PM Andrew Rowson via Kea-users
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> I'm using isc-kea-dhcp6 (2.4.1-isc20231123184533) on Debian bookworm
> >> >> and am having a minor logging issue. I've got a minimal config that
> >> >> defines a single subnet, an allocatable pool within that subnet and a
> >> >> single reservation.
> >> >>
> >> >> The host gets its reserved IP successfully, but there's always a WARN
> >> >> log dance in the kea logs with ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET,
> >> >> ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS and
> >> >> ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES.
> >> >>
> >> >> Are these warnings expected, or have I misunderstood something about
> >> >> the configuration?
> >> >>
> >> >> Thanks,
> >> >> Andrew
> >> >>
> >> >> Config:
> >> >>
> >> >> {
> >> >> "Dhcp6": {
> >> >> "interfaces-config": {
> >> >> "interfaces": [
> >> >> "enp1s0.2",
> >> >> ]
> >> >> },
> >> >> "lease-database": {
> >> >> "lfc-interval": 1800,
> >> >> "name": "/var/lib/kea/kea-leases6.csv",
> >> >> "type": "memfile"
> >> >> },
> >> >> "subnet6": [
> >> >>
Re: [Kea-users] DDNS limitations - ddns-qualifying-suffix vs domain-name
Hi Vladimir, I don't know for sure. It might make an assumption that "myhost" is not an FQDN while assuming that "myhost.SomeOtherLabel" is an FQDN. Or it might look to see if the value from ddns-qualifying-suffix is part of the host already and not append if it is... Perhaps someone else who knows for sure will be along to answer. Thank you, Darren Ankney On Thu, Jan 4, 2024 at 1:41 PM Vladimir Nikolic wrote: > > Hi Darren, > > Could DDNS Tuning hook help here? > It says here > https://kea.readthedocs.io/en/latest/arm/hooks.html#dhcpv4-host-name-generation: > > 4. If there is a ddns-tuning in-scope host-name expression (either > global or subnet), calculate the host name using the expression. If the > calculated value is not a fully qualified name and there is an in-scope > ddns-qualifying-suffix, append the suffix. > > I wonder who does it determine if the calculated value is not a fully > qualified name? > > Regards, > Vladimir > > > On 2023-10-22 19:44, Darren Ankney wrote: > > Hi Vladimir, > > > > I thought about that, but that wouldn't necessarily work. Without > > looking up the provided hostname, Kea wouldn't understand if it should > > add the suffix or not (i.e., is it a complete name?) For example: > > > > - suffix could be 'example.org' > > - 'example.org' might have sub domains such as 'office.example.org' > > and 'warehouse.example.org' > > - so there may be hostnames like 'laptop1.office' and > > 'laptop2.warehouse' that would need example.org appended to them. > > > > Kea couldn't know this isn't the case without some other flag or some > > very complex (very slow) lookup logic to try to figure out what the > > administrator intends to happen. > > > > Thank you, > > > > Darren Ankney > > > > On Sun, Oct 22, 2023 at 10:33 AM Vladimir Nikolic > > wrote: > >> > >> Hi Darren, > >> > >> > There would have to be some way to flag hostnames that you wanted to > >> > ignore a ddns-qualifying-suffix setting somehow to have it > >> > simultaneously set to some value and not apply to all hostnames in > >> > that block. > >> > >> Yeah, like if you end "hostname" parameter (within a host reservation) > >> with a ".", then KEA should treat it as a FQDN, and not append > >> "ddns-qualifying-suffix" from the subnet definition. > >> > >> Regards, > >> Vladimir > >> > >> On 2023-10-21 18:54, Darren Ankney wrote: > >> > Hi Vladimir, > >> > > >> > You can set it "ddns-qualifying-suffix": "", which resets it to empty > >> > in the block in which you do that. You could also only specify inside > >> > subnets where you need it specified and not specify at global level. > >> > There would have to be some way to flag hostnames that you wanted to > >> > ignore a ddns-qualifying-suffix setting somehow to have it > >> > simultaneously set to some value and not apply to all hostnames in > >> > that block. > >> > > >> > Thank you, > >> > > >> > Darren Ankney > >> > > >> > On Tue, Oct 17, 2023 at 2:50 AM Vladimir Nikolić > >> > wrote: > >> >> > >> >> Thanks Darren. > >> >> > >> >> If ‘ddns-qualifying-subnet’ is being set on any level, it’s then > >> >> appended to the ‘hostname’ value from the host reservation. ‘hostname’ > >> >> is the FQDN, only if ‘ddns-qualifying-subnet’ is empty. > >> >> So it’s either one or another. > >> >> Which is really inflexible. > >> >> > >> >> Regards > >> >> > >> >> > >> >> > On 17 Oct 2023, at 12:26 am, Darren Ankney > >> >> > wrote: > >> >> > > >> >> > Hi Vladimir, > >> >> > > >> >> > The DHCPv4 domain-name option (15) isn't meant for use with ddns. It > >> >> > is a search domain that the client should use when performing name > >> >> > resolution. See: https://www.rfc-editor.org/rfc/rfc2132#section-3.17 > >> >> > > >> >> > You can set ddns-qualifying-suffix at the global, shared-network and > >> >> > subnet level. In a host reservation, you can use the "hostname" > >> >> > parameter to specify a FQDN to send to the client and for use in DDNS. > >> >> &
Re: [Kea-users] Kea-dhcp6 always warns with ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET when allocating reserved address
Hi Andrew,
This is also probably not the solution to these logs, but I notice you
also have: "reservation-mode": "out-of-pool", See here:
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#fine-tuning-dhcpv6-host-reservation
where it explains that this is deprecated: "Since Kea 1.9.1, the
reservation-mode parameter is replaced by the reservations-global,
reservations-in-subnet and reservations-out-of-pool flags. The flags
can be activated independently and can produce various combinations,
some of them being unsupported by the deprecated reservation-mode."
Additionally, you may want to move the reservations-global,
reservations-in-subnet and reservations-out-of-pool flags to the
global area. Their intention is to make allocations happen with less
CPU by telling Kea where it might find reservations. So, at least the
"reservations-global": false, parameter should be global to prevent
kea from wasting time looking there for a reservation.
You can, of course, suppress these log messages by setting a specific
logger for kea-dhcp6.alloc-engine and setting severity to ERROR which
will cause only ERROR and FATAL messages from the
kea-dhcp6.alloc-engine logger to be logged see here:
https://kb.isc.org/docs/kea-logging-configuration and here:
https://kea.readthedocs.io/en/kea-2.4.1/arm/logging.html for further
information.
Thank you,
Darren Ankney
On Thu, Jan 4, 2024 at 12:51 PM Andrew Rowson via Kea-users
wrote:
>
> My bad - typo in the email. It's correct on the server:
>
> "subnet": "2001:123:456:e8b0::/64",
> "reservations-global": false,
> "reservations-in-subnet": true,
> "reservations-out-of-pool": true,
> "reservations": [
>
> On Thu, 4 Jan 2024, at 5:17 PM, Bob Harold wrote:
> > On Thu, Jan 4, 2024 at 12:10 PM Andrew Rowson via Kea-users
> > wrote:
> >> Hi,
> >>
> >> I'm using isc-kea-dhcp6 (2.4.1-isc20231123184533) on Debian bookworm and
> >> am having a minor logging issue. I've got a minimal config that defines a
> >> single subnet, an allocatable pool within that subnet and a single
> >> reservation.
> >>
> >> The host gets its reserved IP successfully, but there's always a WARN log
> >> dance in the kea logs with ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET,
> >> ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS and ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES.
> >>
> >> Are these warnings expected, or have I misunderstood something about the
> >> configuration?
> >>
> >> Thanks,
> >> Andrew
> >>
> >> Config:
> >>
> >> {
> >> "Dhcp6": {
> >> "interfaces-config": {
> >> "interfaces": [
> >> "enp1s0.2",
> >> ]
> >> },
> >> "lease-database": {
> >> "lfc-interval": 1800,
> >> "name": "/var/lib/kea/kea-leases6.csv",
> >> "type": "memfile"
> >> },
> >> "subnet6": [
> >> {
> >> "interface": "enp1s0.2",
> >> "reservation-mode": "out-of-pool",
> >> "pools": [
> >> {
> >> "pool": "2001:123:456:e8b0:beef:f00f::/112"
> >> }
> >> ],
> >> "reservations-global": false,
> >> "reservations-in-subnet": true,
> >> "eservations-out-of-pool": true,
> >
> > Probably not the solution, but the line above seems to be missing the
> > first letter. Is it that way on the server?
> >
> >> "subnet": "2001:123:456:e8b0::/64",
> >> "reservations": [
> >> {
> >> "duid": "00:03:00:01:b8:27:eb:bf:db:dd",
> >> "hostname": "myhost",
> >> "ip-addresses": [
> >> "2001:123:456:e8b0::f"
> >> ]
> >> }
> >> ]
> >> }
> >&g
Re: [Kea-users] Reservations via hostnames
Hi,
> Sent: Tuesday, December 26, 2023 at 2:40 PM
> From: "Darren Ankney"
> >
> > I think I may have misunderstood what you were asking for. Can you
> > please provide an example configuration from ISC DHCP as I think that
> > will explain best what you are trying to achieve.
>
> This is what I do on the old ISC dhcpd:
>
> host myhost {
> hardware ethernet 08:00:aa:bb:cc:dd;
> fixed-address myhost;
> }
>
> But as I understand this feature was dropped for good, am I correct?
>
It is currently not possible to do this in Kea. Kea requires an IP
address to be used. For example:
"reservations": [
{
"hw-address": "08:00:aa:bb:cc:dd",
"ip-address": "192.0.2.10"
}
]
Kea would not expect to find a name in an ip-address field. If you
think this should be a feature (and it would likely be implemented as
a different parameter than ip-address), then you could create an issue
in Gitlab: https://gitlab.isc.org/isc-projects/kea regarding this.
The worst that could happen is that the development team says no.
Thank you,
Darren Ankney
--
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] HA heartbeat communications failure
Great news! I wish you luck in getting micetro working. I'm afraid I
could be of no help with that.
Thank you,
Darren Ankney
On Thu, Dec 28, 2023 at 5:02 PM CS wrote:
>
> Well it worked. wtf happened to server2, I don't know and I can't see. I
> built both 1 and 2 at the same time and the same way. Let's just say gamma
> rays turned it evil and move on.
>
> I splat back my config file and the control agent is running on 8000 and the
> ha heartbeat is beating on 8001, as expected.
>
> I also can parse out the issue with micetro, however I am still not certain
> of the solution.
> The CA on server1 reports: "HTTP_CONNECTION_HANDSHAKE_FAILED TLS handshake
> with x.x.x.x failed with wrong version number"
>
> It is certainly outside the scope of this thread and possibly outside the
> scope of this mailing list. I'll follow up a new thread to see what info I
> can take forward in my project if I must move-on to micetro support.
>
> Thank you all for your help, especially you Mr Ankney.
>
> CS, cs.temp.m...@gmail.com
>
>
> On Thu, 28 Dec 2023 at 11:45, Darren Ankney wrote:
>>
>> I'll be excited to here the result!
>>
>> On Thu, Dec 28, 2023 at 2:43 PM CS wrote:
>> >
>> > Me too, especially SELinux. But not in this case. apparmor is disabled as
>> > far as I know.
>> >
>> > I'm going to clone server1 into a server3 and see if the new server binds
>> > to the port then and if one and three will HA effectively. Bit of a
>> > sledgehammer approach but I'm at a loss too.
>> >
>> > CS, cs.temp.m...@gmail.com
>> >
>> >
>> > On Thu, 28 Dec 2023 at 11:36, Darren Ankney
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> At some point we got off list. Putting us back on the list. Hope
>> >> that is OK. Whatever the ultimate resolution is, the information may
>> >> help someone in the future.
>> >>
>> >> I am at a loss. Have you checked for and/or temporarily disabled
>> >> appArmor or SELinux to make sure that they are not the problem?
>> >> Either of them might filter one application's access to the network
>> >> but not another application even on the same network / port
>> >> combination. I have bitten more than once by both of them.
>> >>
>> >> Thank you,
>> >>
>> >> Darren Ankney
>> >>
>> >> On Thu, Dec 28, 2023 at 2:28 PM CS wrote:
>> >> >
>> >> > Unfortunately just ip address obscured.
>> >> > =/
>> >> > Thanks
>> >> > CS, cs.temp.m...@gmail.com
>> >> >
>> >> >
>> >> > On Thu, 28 Dec 2023 at 11:25, Darren Ankney
>> >> > wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Is the "url" that is obscured a name or IP address?
>> >> >>
>> >> >> Thank you,
>> >> >>
>> >> >> Darren Ankney
>> >> >>
>> >> >> On Thu, Dec 28, 2023 at 2:07 PM CS wrote:
>> >> >>>
>> >> >>> At this moment? You wrote it =)
>> >> >>>
>> >> >>> {
>> >> >>> "Dhcp4": {
>> >> >>> "hooks-libraries": [
>> >> >>> {
>> >> >>> "library": "/xxx/libdhcp_lease_cmds.so"
>> >> >>> },
>> >> >>> {
>> >> >>> "library" : "/xxx/libdhcp_ha.so",
>> >> >>> "parameters": {
>> >> >>> "high-availability": [
>> >> >>> {
>> >> >>> "this-server-name": "server2",
>> >> >>> "mode": "load-balancing",
>> >> >>> "auto-failover": true,
>> >> >>> "peers": [
>> >> >>> {
>> >> >>> "name": "server1",
>> >> >>> "url": "http://xxx:8001;,
>> >> >>> "role": "primary"
>> >> >>> },
>> >> >>> {
>> >>
Re: [Kea-users] HA heartbeat communications failure
I'll be excited to here the result!
On Thu, Dec 28, 2023 at 2:43 PM CS wrote:
>
> Me too, especially SELinux. But not in this case. apparmor is disabled as far
> as I know.
>
> I'm going to clone server1 into a server3 and see if the new server binds to
> the port then and if one and three will HA effectively. Bit of a sledgehammer
> approach but I'm at a loss too.
>
> CS, cs.temp.m...@gmail.com
>
>
> On Thu, 28 Dec 2023 at 11:36, Darren Ankney wrote:
>>
>> Hello,
>>
>> At some point we got off list. Putting us back on the list. Hope
>> that is OK. Whatever the ultimate resolution is, the information may
>> help someone in the future.
>>
>> I am at a loss. Have you checked for and/or temporarily disabled
>> appArmor or SELinux to make sure that they are not the problem?
>> Either of them might filter one application's access to the network
>> but not another application even on the same network / port
>> combination. I have bitten more than once by both of them.
>>
>> Thank you,
>>
>> Darren Ankney
>>
>> On Thu, Dec 28, 2023 at 2:28 PM CS wrote:
>> >
>> > Unfortunately just ip address obscured.
>> > =/
>> > Thanks
>> > CS, cs.temp.m...@gmail.com
>> >
>> >
>> > On Thu, 28 Dec 2023 at 11:25, Darren Ankney
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> Is the "url" that is obscured a name or IP address?
>> >>
>> >> Thank you,
>> >>
>> >> Darren Ankney
>> >>
>> >> On Thu, Dec 28, 2023 at 2:07 PM CS wrote:
>> >>>
>> >>> At this moment? You wrote it =)
>> >>>
>> >>> {
>> >>> "Dhcp4": {
>> >>> "hooks-libraries": [
>> >>> {
>> >>> "library": "/xxx/libdhcp_lease_cmds.so"
>> >>> },
>> >>> {
>> >>> "library" : "/xxx/libdhcp_ha.so",
>> >>> "parameters": {
>> >>> "high-availability": [
>> >>> {
>> >>> "this-server-name": "server2",
>> >>> "mode": "load-balancing",
>> >>> "auto-failover": true,
>> >>> "peers": [
>> >>> {
>> >>> "name": "server1",
>> >>> "url": "http://xxx:8001;,
>> >>> "role": "primary"
>> >>> },
>> >>> {
>> >>> "name": "server2",
>> >>> "url": "http://xxx:8001;,
>> >>> "role": "secondary"
>> >>> }
>> >>> ]
>> >>> }
>> >>> ]
>> >>> }
>> >>> }
>> >>> ]
>> >>> }
>> >>> }
>> >>>
>> >>>
>> >>> CS, cs.temp.m...@gmail.com
>> >>>
>> >>>
>> >>> On Thu, 28 Dec 2023 at 10:34, Darren Ankney
>> >>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> Could you share your hooks configuration from server2?
>> >>>>
>> >>>> Thank you,
>> >>>>
>> >>>> Darren Ankney
>> >>>>
>> >>>> On Thu, Dec 28, 2023 at 1:29 PM CS wrote:
>> >>>>>
>> >>>>> > there could either be a routing problem or a firewall problem
>> >>>>> Those things it aint. I setup a tiny webserver with openssl on port
>> >>>>> 8001 and I can telnet back and forth to each server just fine.
>> >>>>>
>> >>>>> Kea isn't setting up what it is supposed to and isn't logging a
>> >>>>> failure of any sort:
>> >>>>> server1$ sudo netstat -lnp | grep 8001
>> >>>>> tcp0 0 10.111.45.45:8001 0.0.0.0:*
>> >>>>> LISTEN 1534068/kea-dhcp4
>> >>>>>
&
Re: [Kea-users] HA heartbeat communications failure
Hello,
At some point we got off list. Putting us back on the list. Hope
that is OK. Whatever the ultimate resolution is, the information may
help someone in the future.
I am at a loss. Have you checked for and/or temporarily disabled
appArmor or SELinux to make sure that they are not the problem?
Either of them might filter one application's access to the network
but not another application even on the same network / port
combination. I have bitten more than once by both of them.
Thank you,
Darren Ankney
On Thu, Dec 28, 2023 at 2:28 PM CS wrote:
>
> Unfortunately just ip address obscured.
> =/
> Thanks
> CS, cs.temp.m...@gmail.com
>
>
> On Thu, 28 Dec 2023 at 11:25, Darren Ankney wrote:
>>
>> Hello,
>>
>> Is the "url" that is obscured a name or IP address?
>>
>> Thank you,
>>
>> Darren Ankney
>>
>> On Thu, Dec 28, 2023 at 2:07 PM CS wrote:
>>>
>>> At this moment? You wrote it =)
>>>
>>> {
>>> "Dhcp4": {
>>> "hooks-libraries": [
>>> {
>>> "library": "/xxx/libdhcp_lease_cmds.so"
>>> },
>>> {
>>> "library" : "/xxx/libdhcp_ha.so",
>>> "parameters": {
>>> "high-availability": [
>>> {
>>> "this-server-name": "server2",
>>> "mode": "load-balancing",
>>> "auto-failover": true,
>>> "peers": [
>>> {
>>> "name": "server1",
>>> "url": "http://xxx:8001;,
>>> "role": "primary"
>>> },
>>> {
>>> "name": "server2",
>>> "url": "http://xxx:8001;,
>>> "role": "secondary"
>>> }
>>> ]
>>> }
>>> ]
>>> }
>>> }
>>> ]
>>> }
>>> }
>>>
>>>
>>> CS, cs.temp.m...@gmail.com
>>>
>>>
>>> On Thu, 28 Dec 2023 at 10:34, Darren Ankney wrote:
>>>>
>>>> Hi,
>>>>
>>>> Could you share your hooks configuration from server2?
>>>>
>>>> Thank you,
>>>>
>>>> Darren Ankney
>>>>
>>>> On Thu, Dec 28, 2023 at 1:29 PM CS wrote:
>>>>>
>>>>> > there could either be a routing problem or a firewall problem
>>>>> Those things it aint. I setup a tiny webserver with openssl on port 8001
>>>>> and I can telnet back and forth to each server just fine.
>>>>>
>>>>> Kea isn't setting up what it is supposed to and isn't logging a failure
>>>>> of any sort:
>>>>> server1$ sudo netstat -lnp | grep 8001
>>>>> tcp0 0 10.111.45.45:8001 0.0.0.0:*
>>>>> LISTEN 1534068/kea-dhcp4
>>>>>
>>>>> server2$ sudo netstat -lnp | grep 8001
>>>>> server2:$ systemctl status isc-kea-dhcp4-server.service
>>>>> ● isc-kea-dhcp4-server.service - Kea IPv4 DHCP daemon
>>>>> Loaded: loaded (/lib/systemd/system/isc-kea-dhcp4-server.service;
>>>>> enabled; vendor preset: enabled)
>>>>> Active: active (running) since Thu 2023-12-28 18:22:55 UTC; 3min 24s
>>>>> ago
>>>>>Docs: man:kea-dhcp4(8)
>>>>>Main PID: 1466785 (kea-dhcp4)
>>>>> Tasks: 5 (limit: 19052)
>>>>> Memory: 2.8M
>>>>> CPU: 48ms
>>>>> CGroup: /system.slice/isc-kea-dhcp4-server.service
>>>>> └─1466785 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
>>>>> server2$ tail -n10 /var/log/kea/kea-dhcp4.log
>>>>> 2023-12-28 18:22:55.427 INFO [kea-dhcp4.ha-hooks/1466785]
>>>>> HA_SERVICE_STARTED started high availability service in load-balancing
>>>>> mode as primary server
>>>>> 2023-12-28 18:22:55.427 WARN [kea-dhcp4.dhcp4/1466785]
>>>>> DHCP4_MULTI_THREADING_INFO enabled: no, number of threads: 0, queue size: >>>>> 0
>>>>> 2023-12-28 18:22:55.427 INFO [kea-d
Re: [Kea-users] HA heartbeat communications failure
Hi,
See attached four files:
ca-server1.json (config for kea-ctrl-agent)
ca-server2.json (config for kea-ctrl-agent)
dhcp4-server1.json (config for kea-dhcp4)
dhcp4-server2.json (config for kea-dhcp4)
These files use port 8000 for kea-ctrl-agent and 8001 for kea-dhcp4 on
version 2.4.0. They don't do anything other than setup the heartbeats
for HA (in fact you don't even need to run the control agent as Kea is
communicating directly). Heartbeats are sent back and forth on port
8001 as expected. Can you give these a try and see if they work (in
testing of course, they won't serve any clients)? I'm genuinely
curious if they work. Yours should work (unless there is some problem
with the certificates or something). I didn't notice any reason why
they wouldn't.
Thank you,
Darren Ankney
PS: I'm not sure if these attachments will make it through to the list.
On Wed, Dec 27, 2023 at 7:16 AM CS wrote:
>
> Kea 2.4.0
>
> On Wed, Dec 27, 2023, 03:18 Darren Ankney wrote:
>>
>> Hi,
>>
>> If I may ask, what version of Kea are you using? Some defaults have
>> changed across versions.
>>
>> Thank you,
>>
>> Darren Ankney
>>
>> On Tue, Dec 26, 2023 at 4:31 PM CS wrote:
>> >
>> > >Please describe what you mean by "it doesn't work".
>> > I mean I get a pretty useless error: "Unable to connect to Kea Control
>> > Agent."
>> >
>> > > it might be be best to ask Men & Mice about "micetro" and how best to
>> > > set things
>> > I will at some point, when I find a resource with them. But there are two
>> > players in this and since kea isn't behaving as expected like you, I and
>> > the docs said. I'm starting here.
>> >
>> > >It actually SHOULDN'T work
>> > That's my read on it too. But here's proof. The CA config for one server.
>> > It matches for the other server except certs and ip addresses obv.
>> >
>> > "Control-agent": {
>> > "http-host": "xxx.xx1.xxx.xxx",
>> > "trust-anchor": "Certificate_Autority.pem",
>> > "cert-file": "ca1_cert.pem",
>> > "key-file": "ca1_key.pem",
>> > "cert-required": true,
>> > "http-port": 8000,
>> > "authentication": {
>> > "type": "basic",
>> > "realm": "kea-control-agent",
>> > "clients": [{
>> > "user": "baduser",
>> > "password": "badpassword",
>> > }]
>> > },
>> >
>> > And the dhcp4 config, likewise only the small differences between the two
>> > servers
>> >
>> > "hooks-libraries": [{
>> > "library":
>> > "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
>> > "parameters": {}
>> > },{
>> > "library" :
>> > "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
>> > "parameters": {
>> > "high-availability": [{
>> > "this-server-name":
>> > "server1.org.org",
>> > "mode": "load-balancing",
>> > "heartbeat-delay": 1,
>> > "max-response-delay": 6,
>> > "max-ack-delay": 5000,
>> > "max-unacked-clients": 0,
>> > "require-client-certs": true,
>> > "trust-anchor":
>> > "Certificate_Autority.pem",
>> > "auto-failover": true,
>> >
>> > "peers": [{
>> > "name": "server1.org.org",
>> >
Re: [Kea-users] HA heartbeat communications failure
Hi,
If I may ask, what version of Kea are you using? Some defaults have
changed across versions.
Thank you,
Darren Ankney
On Tue, Dec 26, 2023 at 4:31 PM CS wrote:
>
> >Please describe what you mean by "it doesn't work".
> I mean I get a pretty useless error: "Unable to connect to Kea Control Agent."
>
> > it might be be best to ask Men & Mice about "micetro" and how best to set
> > things
> I will at some point, when I find a resource with them. But there are two
> players in this and since kea isn't behaving as expected like you, I and the
> docs said. I'm starting here.
>
> >It actually SHOULDN'T work
> That's my read on it too. But here's proof. The CA config for one server. It
> matches for the other server except certs and ip addresses obv.
>
> "Control-agent": {
> "http-host": "xxx.xx1.xxx.xxx",
> "trust-anchor": "Certificate_Autority.pem",
> "cert-file": "ca1_cert.pem",
> "key-file": "ca1_key.pem",
> "cert-required": true,
> "http-port": 8000,
> "authentication": {
> "type": "basic",
> "realm": "kea-control-agent",
> "clients": [{
> "user": "baduser",
> "password": "badpassword",
> }]
> },
>
> And the dhcp4 config, likewise only the small differences between the two
> servers
>
> "hooks-libraries": [{
> "library":
> "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
> "parameters": {}
> },{
> "library" :
> "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [{
> "this-server-name": "server1.org.org",
> "mode": "load-balancing",
> "heartbeat-delay": 1,
> "max-response-delay": 6,
> "max-ack-delay": 5000,
> "max-unacked-clients": 0,
> "require-client-certs": true,
> "trust-anchor":
> "Certificate_Autority.pem",
> "auto-failover": true,
>
> "peers": [{
> "name": "server1.org.org",
> "url":
> "http://xxx.xx1.xxx.xxx:8000/;,
> "cert-file": "dhcp1_cert.pem",
> "key-file": "dhcp1_key.pem",
> "basic-auth-user": "baduser",
> "basic-auth-password":
> "badpassword",
> "role": "primary",
> },{
> "name": "server2.org.org",
> "url":
> "http://xxx.xx2.xxx.xxx:8000/;,
> "cert-file": "dhcp2_cert.pem",
> "key-file": "dhcp2_key.pem",
> "role": "secondary",
> "basic-auth-user": "baduser",
> "basic-auth-password":
> "badpassword",
> }]
> }]
>
> low and behold it runs. The same nature of daemon status and logs on the
> other server.
>
> $ sudo systemctl restart isc-kea-ctrl-agent.servic
Re: [Kea-users] Reservations via hostnames
Hi Luigi, I think I may have misunderstood what you were asking for. Can you please provide an example configuration from ISC DHCP as I think that will explain best what you are trying to achieve. Thank you, Darren Ankney On Tue, Dec 26, 2023 at 8:36 AM Francis Dupont wrote: > > In fact I think that Kea provides a solution to your problem: I am > discussing with Darren who should come back to you. The ISC DHCP config > will help (and we have a tool to translate it to Kea...). > > Merry Christmas > > Francis Dupont > -- > 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
Re: [Kea-users] Reservations via hostnames
Hello, No. That is not possible. If you want to only keep IP addresses updated in one place, I suggest you have a look at ddns and make Kea the source of truth. Thank you, Darren Ankney On Mon, Dec 25, 2023 at 4:04 AM Luigi Baldoni via Kea-users wrote: > > Sent: Monday, December 25, 2023 at 6:47 AM > From: "Kenneth Porter" > > > > On 12/24/2023 4:26 AM, Luigi Baldoni via Kea-users wrote: > > > I have a home setup with bind and the old ISC DHCP server. > > > Since the latter is no longer supported, I would like to switch to Kea, > > > but > > > I couldn't find a way to use hostnames instead of IP addresses for > > > MAC-based > > > static leases. > > > > > > Am I doing something wrong? Is this feature no longer supported? > > > Or perhaps there's a different way to do this, possibly via ddns? > > > I would like to avoid having to keep my IPs up to date in two different > > > places. > > > > It sounds like you mean that you want Kea to look up hostnames found in a > > reservation in the config file to find the IP addresses to assign. > > That's precisely what I would like Kea to do. Is it possible? > > Regards > > -- > 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
Re: [Kea-users] HA heartbeat communications failure
Hi, It actually SHOULDN'T work to set your control agent and multi-threaded HA listener to the same port as only one of the applications should be able to setup a listener on that port. Please describe what you mean by "it doesn't work". I'm thinking it might be be best to ask Men & Mice about "micetro" and how best to set things up there. Thank you, Darren Ankney On Thu, Dec 21, 2023 at 6:47 PM CS wrote: > > Hi all, > Moving on from my failure to start and logging issues (thank you for your > help btw!) I now don't have my heartbeat/control_agent working correctly. > > It works fine so long as I set the ports of my control agents and ha hook > parameters to be the same (IE 8000 or 8001) > > However I am unable to tie the tiny cluster into micetro, probably because > the CA port is occupied with HA heartbeats? > > Looking to these examples: > https://github.com/isc-projects/kea/tree/master/doc/examples/template-ha-mt-tls > > Documentation points out > //This specifies the port CA will listen on. > // If enabling HA and multi-threading, the 8000 port is used by the HA > // hook library http listener. When using HA hook library with > // multi-threading to function, make sure the port used by dedicated > // listener is different (e.g. 8001) than the one used by CA. Note > // the commands should still be sent via CA. The dedicated listener > // is specifically for HA updates only. > > However, how to have a dedicated port for HA and a different one for CA > escapes me. > > CS, cs.temp.m...@gmail.com > -- > 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
Re: [Kea-users] Multiple-Storage Extension
Hi Carsten,
I am not in a position to try now, but it looks like you might be able
to do something like this:
"Dhcp4": {
"hosts-databases": [
{
"type": "mysql",
"user": "user-name",
"password": "password",
},
{
"type": "pgsql",
"user": "user-name",
"password": "password",
}
]
}
Thank you for bringing this up. I was not aware of this. I may look
into this later today.
Thank you,
Darren Ankney
On Wed, Dec 20, 2023 at 4:21 AM Carsten Strotmann via Kea-users
wrote:
>
>
> Hi,
>
> the Kea documentation mentions briefly a "multiple-storage extension". But
> I cannot find further documentation of this extension. Is there more to be
> discovered?
>
> Greetings
>
> Carsten Strotmann
> --
> 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
Re: [Kea-users] HA with TLS problems
Hi, You can see logs in systemd with journalctl -xe ... the program also allows you to look only at the logs of specific applications. See man journalctl Thank you, Darren Ankney On Fri, Dec 15, 2023 at 10:31 AM CS wrote: > > Hi Francis! > Thank you for the reply! I am running Ubuntu 22.04.2, kea 2.4.0, openssl 3.0.2 > So far as log files go, I cannot. The DHCP4 hook for ha seems to be throwing > the error reported in systemctl when it is passed the parameters and it never > actually starts to log itself even on DEBUG 99. > > CS, cs.temp.m...@gmail.com > > > On Fri, 15 Dec 2023 at 02:41, Francis Dupont wrote: >> >> Can you provide more details: system, OpenSSL version and logs at the debug >> level? >> >> Regards >> >> Francis Dupont > > -- > 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
Re: [Kea-users] server with multiple IPs
Hi Jason, It is possible to do in Kea but only with the premium libdhcp_limits.so hook: https://kea.readthedocs.io/en/latest/arm/hooks.html#libdhcp-limits-so-limits-to-manage-lease-allocation-and-packet-processing specifically: https://kea.readthedocs.io/en/latest/arm/hooks.html#lease-limiting Thank you, Darren Ankney On Tue, Dec 5, 2023 at 2:08 PM Jason Keltz wrote: > > Hi.. > > My kea configuration file defines a bunch of subnets. Each subnet defines a > pool of IPs which is restricted to client-class "KNOWN". Each subnet > includes many reservations, ethernet address => IP. All reserved IPs are > outside of the subnet pool. > > My configuration also defines global host reservations (with ether, and not > specific IP) so that hosts which do not have a reserved IP can get an IP from > any subnet. > > Everything has been working fine, but today I noticed something interesting... > > A server (not managed by me) has 6 IP addresses! It has a primary IP which > is from its subnet pool where its connected, a secondary IP which is its > reserved IP on the subnet, and the other IPs are also from the subnet pool. > > Obviously the server is misconfigured, but that's a different story. I don't > want the server to be able to get multiple IPs from the same subnet. > > Since my pools are available to client-class KNOWN, and KNOWN would include > all hosts (each host either has a reservation specifying an ether and an IP > or just an ether), then all clients are "KNOWN". This prevents someone > random from connecting and getting an IP. However, how can I enforce that if > a host has a reservation for an IP, it should get that IP and that IP only? > And that once it gets that IP that it should not get any other IP from the > pool? > > Thanks for your time! > > Jason. > > -- > 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
Re: [Kea-users] Inquiry Regarding Integration of Kea DHCP with DOCSIS Cable Modem DHCP Requests
Hi Fernando,
There might be other ways to do it, but one way I can think of is to
use the API to add reservations
(https://kea.readthedocs.io/en/kea-2.4.1/arm/hooks.html#libdhcp-host-cmds-so-host-commands)
based on your database records. Reservations can contain the
next-server and boot-file-name directives
(https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-next-server-server-hostname-and-boot-file-name).
As far as limiting to certain matches of mac address or option 82
data, reserving by hw-address is certainly possible. Reserving by
82.1 (circuit-id) is as well. If you are referring to option 82.2
(remote-id), I'm not entirely certain you can make a reservation by
this sub-option.
Another way you might accomplish this is to write your own hook that
would query the database using certain parameters during certain
events. See:
https://reports.kea.isc.org/dev_guide/df/d46/hooksdgDevelopersGuide.html
for details.
Thank you,
Darren Ankney
This would require a support subscription or purchase of hooks as the
host_cmds hook library is a premium hook.
On Wed, Nov 29, 2023 at 3:12 PM Fernando R. Soto wrote:
>
> Dear ISC Support Team,
>
>
>
> I hope this email finds you well. I am reaching out to seek guidance on
> integrating Kea DHCP with DHCP requests originating from DOCSIS cable modems.
>
>
>
> My inquiry revolves around configuring the DHCP Server to, upon receiving a
> DHCP Discover and detecting that it originates from a cable modem, utilize
> the client-class option as follows:
>
> "client-classes": [
>
> {
>
> "name": "Cablemodem",
>
> "test": "substring(option[60].hex, 0, 6) == 'docsis'",
>
> "next-server": "192.168.10.43",
>
> "boot-file-name": "default.bin"
>
> }
>
> ],
>
>
>
> The goal is for Kea DHCP, in responding to the boot-file-name, to execute a
> query against an SQL table. This query would seek the MAC address of the
> cable modem, present in both the Client MAC address field
> ("ARRISGro_4c:d4:a2" or "98:6b:3d:4c:d4:a2") and option 82 ("Agent
> Information Option"). If the MAC is found in the table, it would fetch the
> corresponding value from the boot-file field. If no match is found, the
> response would default to "default.bin".
>
>
>
> I would appreciate any guidance or suggestions you can provide to achieve
> this scenario.
>
>
>
> Thank you in advance for your time and assistance.
>
>
>
> Best regards,
>
>
>
>
>
> --
> 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
Re: [Kea-users] client getting IP without reservation
Hi Jason,
I'm not sure how that was working in ISC DHCP unless you had "deny
unknown-clients;" or "allow known-clients;" specified with your pool
as well. There is a similar mechanism in Kea. Just add:
"client-class": "KNOWN"
to your pool specification. Example:
"pools": [
{
"pool": "192.0.2.10-192.0.2.20",
"client-class": "KNOWN"
},
]
Those that have no reservation will be members of the special UNKNOWN
class and not be allowed an address from the pool.
Thank you,
Darren Ankney
On Wed, Nov 22, 2023 at 2:33 PM Jason Keltz wrote:
>
> On 11/22/23 13:24, Bob Harold wrote:
>
>
> On Wed, Nov 22, 2023 at 12:41 PM Jason Keltz wrote:
>>
>> Hi.
>>
>> I have now configured my Kea installation with many subnets, each with
>> their own reservations. It's working well.
>>
>> There's also one global reservation set for hosts that are configured
>> without an IP so they can connect in the dynamic range of any subnet.
>>
>> I wanted to do a test of what would happen if a host ether was not
>> referenced in either the subnet or global sections.
>>
>> I took one host which was getting a reserved IP in a subnet, released
>> the IP, then changed the host ethernet address in the Kea config file so
>> that the host would no longer be recognized.
>>
>> When I DHCP renew on the host, I now get an IP in the dynamic range.
>> This isn't the behaviour I want. Since the host doesn't have a
>> reservation either in a subnet or in the global pool, I want to be
>> denied an IP.
>>
>> What option am I missing?
>>
>> Jason.
>>
> Remove the dynamic range, if you don't want dynamic clients. DHCP Reserved
> clients should be outside any range.
>
> (or limit it to some class of clients or list of allowed mac addresses or
> other client ids or vendor ids)
> ... at least that's how it works in dhcpd.
>
> --
> Bob Harold
>
> Hi Bob,
>
> Thanks for your response.
>
> Perhaps I'm explaining what I want to do poorly or using the incorrect
> terminology. My apologies.
>
> Each subnet has host reservations based on ethernet address and IP pairs for
> many hosts. Each subnet also has a dynamic pool. The IPs distributed via
> host reservation are allocated from outside the dynamic pool.
>
> The global reservations section includes ethernet address and not IP for
> hosts that should be able to get an address no matter which subnet they plug
> into. The IPs distributed for these global reservations should be from the
> dynamic pool ranges attached to each subnet.
>
> Hosts that have neither an entry in the subnet host reservation list, or the
> global reservation list should not be able to get an IP address.
>
> That's what I was doing with ISC DHCPd before. I'm sure there's a way to do
> this with Kea, but I could just use assistance figuring out which options I
> need.
>
> Thanks!
>
> Jason.
>
> --
> 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
Re: [Kea-users] Lease Tuning
Hi Scott, In most situations, you should leave these numbers at their default. The lease file cleanup merely cleans the log file of allocated leases on the disk. This is only used when Kea is restarted so that it can read the leases into memory. If you observe this file, you'll note that Kea writes a line to it every time a lease is changed (allocated, renewed, released). As you can imagine this file can get quite large leading to long startup times if not periodically cleaned. The default is to clean it every 3600 seconds (1 hour) by launching the external lfc program. This should be sufficient as Kea doesn't need to actually do anything but launch the program. As for reclaim-timer-wait-time (https://kea.readthedocs.io/en/kea-2.4.0/arm/lease-expiration.html#configuring-lease-reclamation) this controls how long Kea waits before looking for expired leases again. Unless you have a slow system, you probably don't need to worry about adjusting this with only ~5000 active leases. If you are concerned, I recommend using `perfdhcp` (https://kea.readthedocs.io/en/kea-2.4.0/man/perfdhcp.8.html) to test your configuration / hardware before deployment. Thank you, Darren Ankney On Tue, Nov 14, 2023 at 12:37 PM Scott Rakow wrote: > > I have started the implementation of what could become a large number of > users/pools in a Kea-DHCP4 (20 pools/5000+ IP's) and have some questions > about how to estimate/calculate some of these values. > > How do I determine how long it takes to clean the memfile database? > > What is the best way to calculate the lfc-interval and > reclaim-timer-wait-time? Is it based on the predicted number of IP's that > could/can be used? > > Are there advantages/disadvantages to having a short or long interval/timer? > > Are the valid-lifetime, T1, and T2 values part of how to calculate these > values? > > Thanks > Scott Rakow > -- > 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
Re: [Kea-users] a few questions from a Kea newbie
Hi Jason, if you are going to have multiple reservations for the same mac (different IPs) then you need to confine those to their various subnets and not attempt to reserve them at the global level to avoid this error. Making host reservations for specific IP addresses at the global level is not really recommended in any case. Better to confine them to their subnet declaration. Thank you, Darren Ankney On Tue, Nov 14, 2023 at 11:22 AM Jason Keltz wrote: > > > > > From: Kea-users on behalf of Kevin P. > Fleming > Sent: Tuesday, November 14, 2023 11:15 AM > To: kea-users@lists.isc.org > Subject: Re: [Kea-users] a few questions from a Kea newbie > > On Tue, Nov 14, 2023, at 11:10, Jason Keltz wrote: > > However, my experience with multiple IPv4 addresses to the same ether does > not work, and you said that it should. > > I tried to reserve: > hw-address: 78:24:af:45:32:99 with hostname test1 and ip > hw-address: as-above with hostname test1 and different ip > > When running kea, it loads the first reservation, but after reading the > second one, it reports that this HW address has already been added so it > can't be added again - thoughts?: > > DHCP4_PARSER_FAIL failed to create or run parser for configuration element > reservations: failed to add new host using the HW address '78:24:af:45:32:99' > to the IPv4 subnet id '0' as this host has already been added > DHCP4_CONFIG_LOAD_FAIL configuration error using file: > /xconf/kea/kea-dhcp4.conf.fowl1, reason: failed to add new host using the HW > address '78:24:af:45:32:99' to the IPv4 subnet id '0' as this host has > already been added > DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using > file '/xconf/kea/kea-dhcp4.conf.fowl1': failed to add new host using the HW > address '78:24:af:45:32:99' to the IPv4 subnet id '0' as this host has > already been added > > > Did you try to put both reservations in the same subnet? That's definitely > not going to work, and wouldn't really make sense even if Kea accepted it. > > --- > > Hi Kevin and Matt, > > At the top of my configuration, I specify: > > "host-reservation-identifiers": [ "hw-address" ], > "reservations-global" : true, > ... then outside of my subnet4 section, I have the global reservations > section where I list all my reservations. I can understand why it would make > sense for the reservation for each subnet to be declared in each subnet. > However, wouldn't it also make sense to define the reservations a global? > In this particular case, my system is auto-generating the reservations file > from our host database, and its so much easier in kea configuration file to > just "include" the reservations file at the right place. That's how I used > to do it with DHCPd. > > Thanks! > > Jason. > > -- > 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
Re: [Kea-users] a few questions from a Kea newbie
Hello, Some clarification about #2. It is possible, but not if another client currently has an active lease. Kea will refuse to assign the IP to what is essentially a new client while an existing client still holds a lease on the IP address. The reason this behavior has changed is due to a change in the address reservation mechanism. ISC DHCP, when 'fixed-address' was used, did not record a lease for the leased address. It was then free to assign the IP address to whatever host matched the reservation. This had the side effect of it being possible to have multiple clients with the same IP address if they all matched reservations. In Kea, a lease is created for all assignments. An IP cannot be assigned to a new client if there is already a lease for another client (which makes complete sense). To work around this, you can use the API to delete a lease (https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#the-lease4-del-lease6-del-commands) if desired. Do be careful that the client has actually gone before deleting the lease, however, or you could wind up with multiple clients leased the same IP address. Thank you, Darren Ankney On Mon, Nov 13, 2023 at 8:08 PM Kevin P. Fleming wrote: > > 1) No, it is not necessary to use a database in order to use reservations. > > 2) Unfortunately this is not currently possible unless you can ensure that > the host releases its lease before switching interfaces. I have discussed > this in a number of threads on this list and there is an open issue for it. > > 3) Yes you can have multiple reservations for the same hardware address. > > On Mon, Nov 13, 2023, at 16:50, Jason Keltz wrote: > > Hi. > > > > I'm investigating migrating from ISC DHCPd to Kea and running into a few > > issues. > > > > I see some conflicting information online, due to kea development over > > time, so I was hoping to ask here for some clarification. > > > > 1) Is it really necessary to install a database backend such as > > Postgres/MySQL if I want to have static host reservations? This was > > working so perfectly with dhcpd without any db backend for such a long > > time. Not having a DB backend on the DHCP server means one less thing > > to worry about when Kea is updated, or the DB updated. I accept that > > performance of the DB is likely going to be better than the reservations > > being stored in a text file, but for my basic setup, it just doesn't > > matter to me. The simplicity of not needing a DB for this over-rides the > > performance gain that may be attained with a DB. I just want to be sure > > that I haven't overlooked something. > > > > 2) Does Kea permit multiple ethernet addresses mapped to the same IPv4 > > IP? I do this for multiple reasons - for example, I may have a server > > that has 2 ethernet addresses, and when I plug it in, whether I use one > > or the other network port, the IP should be the same. Obviously I > > shouldn't plug in both or things would break, but that would be my > > problem. At the same time, maybe a laptop has an ethernet port built > > in, but when plugged into a dock that has its own network port, I want > > the machine to get the same IP one way or the other (static > > reservation). Now, I think I can permit this by enabling > > "ip-reservations-unique" to false, but I wanted to clarify. Again, I > > did this with DHCPd all the time. > > > > 3) Finally - does Kea permit multiple IPv4 IPs for the same ethernet > > address? I believe that "ip-reservations-unique" does not permit this, > > yet this is more important for me, and I did this with dhcpd. For > > example, in different places in the building there are different VLANs. > > Most hosts just get a static IP reservation from DHCP. 99% of hosts > > will ever be on one VLAN. However, for say, my test laptop that has a > > single IP reserved on every VLAN - can Kea handle this scenario? > > > > Answers to these questions would be a great start! > > > > Thanks for reading.. > > > > Jason. > > > > -- > > 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 -- 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] Relayed DHCP packets fail
Hi Ben, According to the 2.0.3 ARM, RFC 8357 is supported: https://kea.readthedocs.io/en/kea-2.0.3/arm/dhcp4-srv.html?highlight=8357#supported-dhcp-standards "Generalized UDP Source Port for DHCP Relay, RFC 8357: The Kea server handles the Relay Agent Information Source Port sub-option in a received message, remembers the UDP port, and sends back reply to the same relay agent using this UDP port." I did not find any bugs (closed or otherwise) reported in https://gitlab.isc.org/isc-projects/kea regarding this. Might you perform a packet capture to check if the responses are sent to the correct port on the relay the next time you try the upgrade? Thank you, Darren Ankney On Fri, Nov 10, 2023 at 7:13 PM Brian Mulder wrote: > > Today I tried updating my firewall (pfSense) to the newest version (from > 23.05.1 to 23.09). While the update was successful, all client DHCP requests > began to fail. I use DHCP relay on the firewall to handle DHCP on multiple > VLANs, which had been working flawlessly for multiple years. > > After some trouble shooting and packet comparisons, the only difference that > I noticed was that the source port in the egress DHCP relay packet was static > 67 in the previous version and random in the new update. Reverting the update > fixed the issue. > > A search indicated that RFC 8357 allows the source port to be generalized for > DHCP relay. I am using version 2.0.3 of Kea, which is a little old now. I > will try to upgrade during an upcoming downtime window. > > In the meantime, what version of Kea implements RFC 8357? > Until I can upgrade, are there any configuration options in 2.0.3 to handle > relayed DHCP requests from ports other than 67? > > Best regards, > Ben Monroe > -- > 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
Re: [Kea-users] Kea-users Digest, Vol 113, Issue 4
Hello, Could you provide logs of this behavior? It is difficult to know what is happening without seeing the logs. Thank you, Darren Ankney On Thu, Nov 9, 2023 at 11:16 AM JT ISC wrote: > > Hi Darren, > > Yes, I am running version 2.4.0. I just got "ignore-dhcp-server-identifier" > into the config. However, can you explain why the same device would accept 1 > IP Offer and then just a couple seconds later accept a different IP Address?? > > Kea DHCP is running on the same subnet as all client devices. > > I have also noticed that I have several other devices that do the following > multiple times even after updating the config - > > client is in INIT-REBOOT state and requests address > > Thanks! > > -- 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
