Re: [Kea-users] Kea 2.5.8 packages will be up by tomorrow
Hello, This is likely the first time I've seen someone request the latest version of Fedora. We will not be adding packages to version 2.5.8 for any new systems. In the upcoming release, we will include packages for the latest Ubuntu 24.04, and if time permits, we will also add Fedora 40. In the worst-case scenario, these packages will be available in the June release. Regards Włodek Wencel QA, ISC On 11/05/2024 18:00, Brant Stevens wrote: Can you add packages for Fedora 40? On Tue, Apr 30, 2024 at 11:01 AM Victoria Risk wrote: Hi Kea-users, Kea 2.5.8 is posted at https://downloads.isc.org/isc/kea/2.5.8/, but I jumped the gun a bit, and announced availability before we had built all the packages and uploaded them to Cloudsmith. So, if you are looking to download Kea 2.5.8, just wait a few hours, or until tomorrow. The usual packages will be there, after all the machines have churned and the scripts have run and the bits have transferred…. Vicky -- 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] Problem using 'config-set' in API
Hi,
the reservation-add command will accomplish what you need. However, it's
important to note that if you're utilizing a JSON configuration backend,
you must use the config-write command to save any reservations added via
the reservation-add command. Failing to do so will result in the loss of
those reservations upon restarting Kea. If you're using a database to
store host reservations, there is no need to use the config-write command.
ARM:
https://kea.readthedocs.io/en/latest/arm/hooks.html#libdhcp-host-cmds-so-host-commands
Regards,
Wlodek Wencel
QA, ISC
On 05/03/2024 12:51, Andrew Mulheirn via Kea-users wrote:
Hi Veronique –
Thanks very much! I have since discovered that I can use
'reservation-add' instead, which achieves what I need. That seems to
be additive for host reservations.
Kind regards,
Andy
Andrew Mulheirn
Senior Network Architect
M: +44 (0) 74 3654 8126
E: andrew.mulhe...@vorboss.com
vorboss.com <https://vorboss.com>
Not sure who currently provides your internet?
Find out here and take our speed test. <https://check.vorboss.com/>
Disclaimer: This message is private and confidential. If you have
received this message in error, please remove it from your system and
notify us atsysad...@vorboss.net <mailto: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.
*From:*Veronique Lefebure
*Sent:* Tuesday, March 5, 2024 9:49 AM
*To:* kea-users@lists.isc.org
*Cc:* Andrew Mulheirn
*Subject:* Re: Problem using 'config-set' in API
Hi,
config-set will rewrite the whole config file. You cannot "append" a
configuration bit. To do so you need to use the API.
Cheers,
V.
*From:*Kea-users on behalf of Andrew
Mulheirn via Kea-users
*Sent:* Tuesday, March 5, 2024 10:06 AM
*To:* kea-users@lists.isc.org
*Cc:* Andrew Mulheirn
*Subject:* [Kea-users] Problem using 'config-set' in API
Hi,
I am trying to use the API and reading it seems to work fine.
However, when I write to it using a config-set action, it seems to
stop working until I restart the service. Here is an example of what
I am sending in the API call. I am trying to add an IP address
reservation for a device connected on a particular switch port (using
option 18):
{
"command":"config-set",
"service":["dhcp6"],
"arguments":{
"Dhcp6":{
"subnet6":[
{
"subnet":"2a00:e300:1102::/64",
"reservations":[
{
"flex-id":"'xe-0/0/4:rsw001'",
"ip-addresses":["2a00:e300:1102::8"]
}
]
}
]
}
}
}
Perhaps I have misread the documentation – do I need to be sending the
entire config in the config-set command? Or can I add IP address
reservations in an additive way like I am trying to do here?
Any help appreciated,
Kind regards,
Andy
*
Andrew Mulheirn *
Senior Network Architect
M: +44 (0) 74 3654 8126
E: andrew.mulhe...@vorboss.com <mailto:andrew.mulhe...@vorboss.com>
vorboss.com <https://vorboss.com>
Not sure who currently provides your internet?
Find out here and take our speed test. <https://check.vorboss.com/>
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 <mailto: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.
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] Clean up of older Kea repositories hosted on Cloudsmith
We are initiating a clean-up of older repositories on Cloudsmith. The repositories hosting development branches 1.9 and 2.1 will be decommissioned on February 29, 2024. The repository for the 2.3 releases is scheduled for removal on March 29, 2024. Moreover, the repository for the 2.5 releases will be phased out following the public availability of the stable 2.6.0 release. Additionally, beginning with the 2.7.X release series, we will be launching a new repository on Cloudsmith, named kea-dev, which will host the 2.7.X release alongside all future development releases. It's important to note that repositories for stable releases will remain unaffected. Should you require packages from the 1.9, 2.1, or 2.3 releases, we strongly recommend creating a backup copy. It's possible to use wget tool to download particular packages e.g: wget https://dl.cloudsmith.io/public/isc/kea-2-1/deb/debian/pool/stretch/main/p/ py/python3-isc-kea-connector_2.1.7-isc20220627172414/python3-isc-kea-connec tor_2.1.7-isc20220627172414_all.deb or use package manager. apt-get download ; dnf download ; The source code for each release can be accessed and will continue to be available on our FTP site at https://downloads.isc.org/isc/kea/. Regards Wlodek Wencel QA, ISC -- 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] Problems with ownership of /var/run/kea on RHEL 8 during boot (OPEN)
Hello, sorry for replying after couple months, I missed this email and it was brought to my attention today. Did you manage to solve this issue? Is this issue also occuring with our current development packages? Regards, Wlodek Wencel QA engineer, ISC On 28/11/2023 15:00, Weisteen Per wrote: Hi We’ve set up Kea (2.4.0) running as non-root on RHEL 8.9 and have changed ownership on relevant directories. Somehow ownership for /var/run/kea is being changed from non-root user to root during a reboot. As a result none of the services kea-ctrl-agent.service, kea-dhcp4.service will start at bootup but terminates with “Unable to use interprocess sync lockfile (Permission denied): /var/run/kea/logger_” Any suggestions to why /var/run/kea changes ownership during boot? ./PerW Sensitivity: Internal -- 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] tag Kea-2.4.1 is wrong?
Hello, you are 100% correct. Thank you for pointing this out - I am fixing this now. Regards Wlodek Wencel Sr. QA Engineer, ISC On 05/12/2023 22:05, Alexey Shabalin wrote: Hi all. I look kea gitlab, and see very strange tag Kea-2.4.1 - commit 099bac96afc6a38b5fc445810fd47ddb02347827 - " [#3173] bump up library versions for 2.5.4 release " Tag Kea-2.4.1 after Kea-2.5.3 and before Kea-2.5.4. Not after Kea-2.4.0. I think tag Kea-2.4.1 must be set on commit 98b9ba435d1dc20d67d9b811f9732bf84fdee76e, branch v2_4. Can anyone fix this tag? Sorry, I can't login to gitlab with a public email and add an issue. -- 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] Testing the kea-failover peer with muti threading and TLS support
Sorry I don't have time to go through entire thread here today :( but
what I can tell now is this solution is working, in our testing one of
the nodes configuration is:
{
"Dhcp4": {
"option-data": [],
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "https://172.28.0.31:8003/;
},
{
"auto-failover": true,
"name": "server2",
"role": "standby",
"url": "https://172.28.0.32:8003/;
}
],
"state-machine": {
"states": []
},
"mode": "hot-standby",
"heartbeat-delay": 2000,
"max-ack-delay": 1000,
"max-response-delay": 4000,
"max-unacked-clients": 4,
"this-server-name": "server1",
"trust-anchor":
"/usr/local/var/lib/kea/ca_cert.pem",
"cert-file":
"/usr/local/var/lib/kea/server_cert.pem",
"key-file":
"/usr/local/var/lib/kea/server_key.pem",
"require-client-certs": false,
"multi-threading": {
"enable-multi-threading": true,
"http-dedicated-listener": true,
"http-listener-threads": 0,
"http-client-threads": 0
}
}
]
}
}
],
"shared-networks": [],
"subnet4": [
{
"subnet": "192.168.50.0/24",
"pools": [
{
"pool": "192.168.50.1-192.168.50.200"
}
],
"interface": "enp0s9"
}
],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/usr/local/var/log/kea.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
],
"lease-database": {
"type": "memfile"
}
}
}
hope that will help you in your investigation
Wlodek
On 28/06/2023 13:44, Kraishak Mahtha wrote:
Hi Darren,
I am deploying at my lab currently but, when we get more familiar we
will proceed with production. I tried yes even with 2.3.8 and I am
facing an issue, I thought it could be because of my certificates, and
when I am reading more on this I saw a note in the reference document
that
"A sample set of certificates and associated objects is available at
src/lib/asiolink/testutils/ca".
I have downloaded the source from GIT and from the folder
kea-master\kea-master\src\lib\asiolink\testutils\ca I used the
following certificates as follows
"trust-anchor": "/root/kea-server.crt"
"cert-file": "/root/kea-server.csr"
"key-file": "/root/kea-server.key"
But with this, I am getting the following error
11:33:40.411 DEBUG [kea-dhcp4.hooks/13148.140464316582080]
HOOKS_STD_CALLOUT_REGISTERED hooks library
/opt/tcpwave/lib/kea/hooks/libdhcp_ha.so registered standard callout
for hook leases4_committed at address 0x7fc05b249e70
2023-06-28 11:33:40.413 ERROR
[kea-dhcp4.ha-hooks/13148.140464316582080] HA_CONFIGURATION_FAILED
failed to configure High Availability hooks library: bad TLS config
for server dhcp1: load of cert file '/root/kea-server.csr' failed: no
start line
Thanks
On Wed, Jun 28, 2023 at 3:47 PM Darren Ankney
wrote:
Hi Kraishak,
When are you deploying? You may want to test with 2.3.8 as the
release of the next stable (2.4.0) is coming soon. As for certificate
use, I am not an expert in that area, but I believe that the .pem
format is most common and correct.
Thank you,
Darren Ankney
Re: [Kea-users] Migrate to Kea from non-ISC DHCP server ***EXTERNAL EMAIL***
Kea has two features that deals with expired leases. Please take a look into lease file clean up: https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#memfile-basic-storage-for-leases (you can easily disable this by setting lfc-interval to 0) and lease expiration https://kea.readthedocs.io/en/latest/arm/lease-expiration.html But none of those processes touch unexpired leases, my guess is that you are putting incorrect state of a lease. There is also lease sanity check feature, but this by default wouldn't remove your leases https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#sanity-checks-in-dhcpv4 I hope that our documentation will help you find solution. Włodek Wencel QA, ISC On 13/04/2023 21:21, Rachael Wilson wrote: Thank you very much Wlodek! With that info I was able to create a lease file for dhcp4. The only thing is it seems a collector runs at a certain interval that cleans up the memfile? Looks like it blows out any loaded leases before they could expire from the old DHCP server. -- Rachael Wilson (509) 422-8374 *From:* Kea-users *On Behalf Of *Wlodek Wencel *Sent:* Thursday, April 13, 2023 8:48 AM *To:* kea-users@lists.isc.org *Subject:* Re: [Kea-users] Migrate to Kea from non-ISC DHCP server ***EXTERNAL EMAIL*** *EXTERNAL EMAIL: Please Think Before You Click!!* Couple simple leases files I took out from our automated testing are attached. Please be aware that in user context Kea can store quite extensive info in json structure (also attached). Hope that will help Wlodek Wencel On 13/04/2023 16:42, Rachael Wilson wrote: Thank you, Darren! I will give perfdhcp a try. -- Rachael Wilson (509) 422-8374 *From:* Kea-users <mailto:kea-users-boun...@lists.isc.org> *On Behalf Of *Darren Ankney *Sent:* Thursday, April 13, 2023 3:27 AM *To:* kea-users@lists.isc.org *Subject:* Re: [Kea-users] Migrate to Kea from non-ISC DHCP server ***EXTERNAL EMAIL*** *EXTERNAL EMAIL: Please Think Before You Click!!* Hello Rachael, There probably isn't an example file anywhere in the documentation (I looked also) or if there is, I just didn't find it. I would suggest setting up a test kea server with the memfile lease database persisting to a file. Then use perfdhcp to generate traffic thus populating the file. If you need specific options to appear in the lease file, it is possible to use perfdhcp to generate most of them (even if you have to create the hex yourself). Thank you, Darren Ankney On Wed, Apr 12, 2023 at 5:19 PM Rachael Wilson wrote: Hi, I would like to migrate a few thousand DHCP leases from a non-ISC DHCP server to a memfile backed Kea instance. Looking through the docs, it seems it would be easier to populate the lease file in /var/lib/kea/kea-leases4.csv rather than using hooks. However, in a fresh install the file only contains the header row. Is there an example file populated with rows I could look at to properly format the data for import? Didn’t see anything in the docs, but might have missed it. -- logo__250px.png *Rachael Wilson *| Network Analyst Public Utility District No. 1 Of Okanogan County Office: (509) 422-8374 | racha...@okpud.org 1331 2nd Ave N., Okanogan, WA 98840 | P.O. Box 912, Okanogan, WA 98840 P.U.D. No. 1 of Okanogan County is an equal opportunity provider and employer. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. -- 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] Migrate to Kea from non-ISC DHCP server ***EXTERNAL EMAIL***
Couple simple leases files I took out from our automated testing are
attached. Please be aware that in user context Kea can store quite
extensive info in json structure (also attached).
Hope that will help
Wlodek Wencel
On 13/04/2023 16:42, Rachael Wilson wrote:
Thank you, Darren! I will give perfdhcp a try.
--
Rachael Wilson
(509) 422-8374
*From:* Kea-users *On Behalf Of
*Darren Ankney
*Sent:* Thursday, April 13, 2023 3:27 AM
*To:* kea-users@lists.isc.org
*Subject:* Re: [Kea-users] Migrate to Kea from non-ISC DHCP server
***EXTERNAL EMAIL***
*EXTERNAL EMAIL: Please Think Before You Click!!*
Hello Rachael,
There probably isn't an example file anywhere in the documentation (I
looked also) or if there is, I just didn't find it. I would suggest
setting up a test kea server with the memfile lease database
persisting to a file. Then use perfdhcp to generate traffic thus
populating the file. If you need specific options to appear in the
lease file, it is possible to use perfdhcp to generate most of them
(even if you have to create the hex yourself).
Thank you,
Darren Ankney
On Wed, Apr 12, 2023 at 5:19 PM Rachael Wilson wrote:
Hi, I would like to migrate a few thousand DHCP leases from a
non-ISC DHCP server to a memfile backed Kea instance. Looking
through the docs, it seems it would be easier to populate the
lease file in /var/lib/kea/kea-leases4.csv rather than using
hooks. However, in a fresh install the file only contains the
header row. Is there an example file populated with rows I could
look at to properly format the data for import? Didn’t see
anything in the docs, but might have missed it.
--
logo__250px.png
*Rachael Wilson *| Network Analyst
Public Utility District No. 1 Of Okanogan County
Office: (509) 422-8374 | racha...@okpud.org
1331 2nd Ave N., Okanogan, WA 98840 | P.O. Box 912, Okanogan, WA
98840
P.U.D. No. 1 of Okanogan County is an equal opportunity provider
and employer. If you think that you have received this message in
error, please e-mail the sender at the above e-mail address.
--
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
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:1::50,00:03:00:01:ff:ff:ff:ff:ff:01,4000,1666087048,1,3000,0,14339,128,1,1,a.,ff:ff:ff:ff:ff:01,0,,1,2
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
192.168.50.10,ff:01:02:03:ff:04,,4000,1662464562,1,1,1,aa.four.example.com.,0,
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:1::3,00:03:00:01:01:03:0d:04:0b:01,900,1682357103,1,800,0,1963,128,0,0,,01:03:0d:04:0b:01,0,{ "ISC": { "relay-info": [ { "hop": 0 "link": "2001:db8:1::1000" "options": "0x0012000231350025000A0A002701" "peer": "fe80::800:27ff:fe00:2" "remote-id": "0A002701" } ] } },1,2
2001:db8:1::4,00:03:00:01:01:03:0d:04:0b:01,900,1682357103,1,800,0,1093,128,0,0,,01:03:0d:04:0b:01,0,{ "ISC": { "relay-info": [ { "hop": 0 "link": "2001:db8:1::1000" "options": "0x0012000231350025000A0A002701" "peer": "fe80::800:27ff:fe00:2" "remote-id": "0A002701" } ] } },1,2
2001:db8:3::1:0:0,00:03:00:01:01:03:0d:04:0b:01,900,1682357103,1,800,2,54514,96,0,0,,01:03:0d:04:0b:01,0,{ "ISC": { "relay-info": [ { "hop": 0 "link": "2001:db8:1::1000" "options": "0x0012000231350025000A0A002701" "peer": "fe80::800:27ff:fe00:2" "remote-id": "0A002701" } ] } },1,2
--
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] "Unsupported 'shared-networks' parameter."
Hello,
this is because 'shared-networks' is a list that suppose to be inside
"Dhcp4": {}.
In your case:
{
"command": "config-test",
"service": [ "dhcp4" ],
"arguments": {
"Dhcp4": {
"interfaces-config": {
"interfaces": ["eth0/192.168.0.1"]},
"control-socket": {
"socket-name": "/tmp/kea4-ctrl-socket",
"socket-type": "unix"
},
"expired-leases-processing": {
"reclaim-timer-wait-timer": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"option-data": [
{
"name": "dns-servers",
"data": "8.8.8.8, 8.8.4.4"
}
],
"shared-networks": [
{
"name": "3M",
"interface": "eth0",
"subnet4":[
{
"subnet": "192.168.2.0/24",
"pools": [
{ "pool": "192.168.2.10 - 192.168.2.20" }
]
}
]
}
],
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"output":
"/var/log/kea/kea-dhcp4-server.log"
}
],
"severity": "INFO"
}
]
}
}
}
Regards
Wlodek Wencel
ISC QA engineer
On 18/05/2022 17:51, Jeronimo wrote:
Hi all,
I'm getting the error "Unsupported 'shared-networks' parameter." while
trying to test config with Kea Ctrl-Agent.
Any help?
Jeronimo
API Request
{
"command": "config-test",
"service": [ "dhcp4" ],
"arguments": {
"Dhcp4": {
"interfaces-config": {
"interfaces": ["eth0/192.168.0.1 <http://192.168.0.1>"]},
"control-socket": {
"socket-name": "/tmp/kea4-ctrl-socket",
"socket-type": "unix"
},
"expired-leases-processing": {
"reclaim-timer-wait-timer": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"option-data": [
{
"name": "dns-servers",
"data": "8.8.8.8, 8.8.4.4"
}
],
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"output":
"/var/log/kea/kea-dhcp4-server.log"
}
],
"severity": "INFO"
}
]
},
"shared-networks": [
{
"name": "3M",
"interface": "eth0",
"sub
Re: [Kea-users] Error message while loading....
Hi We have a small chapter about this error: https://kea.readthedocs.io/en/latest/arm/install.html?highlight=ldconfig#id3 All you need to do it's just run ldconfig Thanks for using Kea, Wlodek Wencel QA Engineer, ISC On 26/04/2022 17:59, Kevin P. Fleming wrote: You will likely need to check /etc/ld.so.conf.d/* to ensure that /usr/local/lib is in the default search path for the dynamic linker. Not really related to Kea, just an issue whenever you install shared libraries into /usr/local. On Tue, Apr 26, 2022 at 11:55 AM John Gammon wrote: Good morning, I am rebuilding my test bed to work with Kea-2.1.4 branch. I have downloaded the tar ball from isc.org <http://isc.org>. I get my environment setup and config pgsql server and am going through './configure', 'make', 'make install' for the software. When I launch the 'kea-dhcp4 -c /user/local/etc/kea/kea-dhcp4.conf', I received the following error: kea-dhcp4: error while loading shared libraries: libkea-dhcpsrv.so.65: cannot open shared object file: No such file or directory However, I have located the file in the correct location and with the proper permissions: ls /usr/local/lib/libkea-dhcpsrv* -lla -rw-r--r-- 1 root root 398874358 Apr 26 13:30 /usr/local/lib/libkea-dhcpsrv.a -rwxr-xr-x 1 root root 1697 Apr 26 13:30 /usr/local/lib/libkea-dhcpsrv.la <http://libkea-dhcpsrv.la> lrwxrwxrwx 1 root root 24 Apr 26 13:30 /usr/local/lib/libkea-dhcpsrv.so -> libkea-dhcpsrv.so.65.0.0 lrwxrwxrwx 1 root root 24 Apr 26 13:30 /usr/local/lib/libkea-dhcpsrv.so.65 -> libkea-dhcpsrv.so.65.0.0 -rwxr-xr-x 1 root root 112768720 Apr 26 13:30 /usr/local/lib/libkea-dhcpsrv.so.65.0.0 I have recompiled and reinstalled the software from a new download of the tarball, and am having the same results. By the way, this is a new install and config of my test server with Ubuntu server 20.04.4, with all patches available installed. Suggestions of where I should look for additional information is appreciated. Thanks, John *John Gammon* Network Engineer Forked Deer Electric Cooperative, Inc./Forked Deer Connect, LLC. email: *john.gam...@forkeddeer.com* *John Gammon* Network Engineer Office 731-903-4282 john.gam...@forkeddeer.com <mailto:+john.gam...@forkeddeer.com> fdec logo 1135 North Church Street PO Box 67 Halls, TN 38040 www.forkeddeer.com <http://www.forkeddeer.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] Config-write hook is not writing all info
Hi,
I just checked our system tests and looks like this feature is working.
You are writing kea config file to /tmp/config-modified-2022-04-11.json
when you restart kea are you pointing it to new config file location? or
replacing old config file with a new one? Could you check content of
/tmp/config-modified-2022-04-11.json?
Thanks for using Kea,
Wlodek Wencel
QA Engineer,
ISC
On 12/04/2022 06:29, s k wrote:
Hi
I tried following steps to add new subnet6 using subnet6-add Hook
1. Add subnet6-add command to add new subnet6 dynamically using
control agent
2. Message says "[ { "arguments": { "subnets": [ { "id": 1,
"subnet": "fda4:110:0:10::8053:370/64" } ] }, "result": 0, "text":
"IPv6 subnet added" } ] "
2. To confirm added the same subnet again
Message Says "[ { "result": 1, "text": "subnet with the
prefix of 'fda4:110:0:10::8053:370/64' already exists" } ]"
3. Now Try to write the config from memory to file using
config_cmds hook
{
"service": ["dhcp6"],
"command": "config-write",
"arguments": {
"filename": "/tmp/config-modified-2022-04-11.json"
}
}
Expectation is the newly added subnet should exists in the file
"/tmp/config-modified-2022-04-11.json" But it does not . am i missing
any steps ?
4. Now restart Kes-dhcp6 service
5. Repeat step 1
Message says "[ { "arguments": { "subnets": [ { "id": 1,
"subnet": "fda4:110:0:10::8053:370/64" } ] }, "result": 0, "text":
"IPv6 subnet added" } ] "
Meaning the new subnet only exists only in memory.
How do i correct this ?
Thanks for all your help
2.
--
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 VM sizing ?
Hey, we don't have such document yet, but I can point you to our recent performance tests report, which on first page described hardware used and in most charts it adds memory and cpu usage. It also describe multi threading settings (it may differ between systems) But I will give you small "it depends", mostly it depends on 3 factors, traffic characteristics you expect (how often clients ask for lease), lease backend you use and roughly how many clients are in your network * db backends (mysql and pgsql) needs more cpu cores but less memory and are generally slower than memfile * memfile needs more memory especially if you are handling huge number of clients, and over all CPU usage on system is smaller (you run just Kea not additional database) report: https://reports.kea.isc.org/performance/stable/2.0.2/report.html Thanks for using Kea, Wlodek Wencel QA Engineer, ISC On 08/04/2022 23:07, David Ramsey wrote: Is there any virtual machine sizing data available for ISC Kea DHCP ? In particular I don't know how to spec out RAM and # vCPUs.. I realize "it depends", of course, but are there any ballpark guides or formulas anywhere? Thanks, --David -- 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] Selecting subnet based on circuit-id (INTERNAL)
Yes, you are right.
Regards,
Wlodek Wencel
ISC QA engineer
On 15/12/2021 16:24, Weisteen Per wrote:
My bad. You're completely correct. I obviously mixed the two and created a
config file preventing isc-dhcp4 from starting.
Does that mean that I can't get to the info in option 82 sub option 1 without
buying the flex id package?
./PerW
-Original Message-
From: Kea-users On Behalf Of Wlodek Wencel
Sent: onsdag 15. desember 2021 16:13
To: kea-users@lists.isc.org
Subject: Re: [Kea-users] Selecting subnet based on circuit-id (INTERNAL)
Hello,
thank you for using Kea! I have to point out that we didn't change license on
flex id hook. Hook included into your config file is flex option hook which is
completely different thing from flex id. And flex option is released in
standard package.
Regards,
Wlodek Wencel
ISC QA engineer
On 15/12/2021 14:17, Weisteen Per wrote:
I believe ISC has released the flex hook for KEA 2.0 in the standard
package. At least the flex library is part of the installation under
/usr/lib64/kea/hooks/
And defining the library seems to give no error messages.
"library": "/usr/lib64/kea/hooks/libdhcp_flex_option.so",
"parameters": {
"identifier-expression": "relay4[2].hex"
}
Do I need to define circuit-id here under parameters?
My challenge is also how to use circuit-id identifier correctly in a test under
client-classes.
./PerW
-Original Message-
From: Allan M33 Access
Sent: onsdag 15. desember 2021 12:47
To: Weisteen Per
Cc: kea-users@lists.isc.org
Subject: Re: [Kea-users] Selecting subnet based on circuit-id (OPEN)
The flexible identifier hook for kea will allow you to use the dhcp option 82
sub option 1 as an identifier for leases. The flex hook is part of the premium
hook packages though, purchasable on Isc’s website. The package also comes with
the legal logging hook.
My setup has the same concept, for my VLANs I set them up as
individual interfaces on my box, then I define those interfaces for
each subnet in the configuration. I use the flex it to use the circuit
id as an identifier with “replace-client-id”: true
Even though the circuit id does have the VLAN in it, I choose subnets by the
interface the packet comes in on instead.
-Allan
On Dec 15, 2021, at 5:12 AM, Weisteen Per wrote:
Hi
I've just set up KEA 2.0 on a RHEL 8 box using RedHat Repository setup as
instructed at cloudsmith.io.
Seems that the packages available for me now is kea.x86_64, kea-devel.x86_64,
kea-hooks.x86_64 and kea-libs.x86_64 all of which I have installed.
Seems though I'm missing some libraries mentioned in the kea-dhcp4.conf file
like libdhcp_legal_log.so and control-agent-commands.so but I assume they're
not critical.
What I initially need is to be able to select beween subnets based on which
VLAN/VPN the request comes from. My network guys has set up several Cisco
routers which will assign clients to one specific VLAN/VPN if the client
manages to authenticate using 802.1x and to another if the authentication
fails. Am I correct to believe that Cisco router will supply me with
information on which VLAN/VPN a client was assigned to using circuit-id? Is
this a parameter already predefined in KEA or do I have to define it somewhere?
Thanks,
./PerW
___
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] Selecting subnet based on circuit-id (INTERNAL)
Hello,
thank you for using Kea! I have to point out that we didn't change
license on flex id hook. Hook included into your config file is flex
option hook which is completely different thing from flex id. And flex
option is released in standard package.
Regards,
Wlodek Wencel
ISC QA engineer
On 15/12/2021 14:17, Weisteen Per wrote:
I believe ISC has released the flex hook for KEA 2.0 in the standard package.
At least the flex library is part of the installation under
/usr/lib64/kea/hooks/
And defining the library seems to give no error messages.
"library": "/usr/lib64/kea/hooks/libdhcp_flex_option.so",
"parameters": {
"identifier-expression": "relay4[2].hex"
}
Do I need to define circuit-id here under parameters?
My challenge is also how to use circuit-id identifier correctly in a test under
client-classes.
./PerW
-Original Message-
From: Allan M33 Access
Sent: onsdag 15. desember 2021 12:47
To: Weisteen Per
Cc: kea-users@lists.isc.org
Subject: Re: [Kea-users] Selecting subnet based on circuit-id (OPEN)
The flexible identifier hook for kea will allow you to use the dhcp option 82
sub option 1 as an identifier for leases. The flex hook is part of the premium
hook packages though, purchasable on Isc’s website. The package also comes with
the legal logging hook.
My setup has the same concept, for my VLANs I set them up as individual
interfaces on my box, then I define those interfaces for each subnet in the
configuration. I use the flex it to use the circuit id as an identifier with
“replace-client-id”: true
Even though the circuit id does have the VLAN in it, I choose subnets by the
interface the packet comes in on instead.
-Allan
On Dec 15, 2021, at 5:12 AM, Weisteen Per wrote:
Hi
I've just set up KEA 2.0 on a RHEL 8 box using RedHat Repository setup as
instructed at cloudsmith.io.
Seems that the packages available for me now is kea.x86_64, kea-devel.x86_64,
kea-hooks.x86_64 and kea-libs.x86_64 all of which I have installed.
Seems though I'm missing some libraries mentioned in the kea-dhcp4.conf file
like libdhcp_legal_log.so and control-agent-commands.so but I assume they're
not critical.
What I initially need is to be able to select beween subnets based on which
VLAN/VPN the request comes from. My network guys has set up several Cisco
routers which will assign clients to one specific VLAN/VPN if the client
manages to authenticate using 802.1x and to another if the authentication
fails. Am I correct to believe that Cisco router will supply me with
information on which VLAN/VPN a client was assigned to using circuit-id? Is
this a parameter already predefined in KEA or do I have to define it somewhere?
Thanks,
./PerW
___
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 & log4cplus
Hello, this is very interesting info, reason why there is a log4cplus-1.1.3-0.4.isc1.el8.x86_64 pkg created by us is simple - there we no such package when we first released kea on centos 8. And we wanted to make it easier. We will be releasing 1.9.3 very soon, if time allows I will make that change, if not we will address this in 1.9.4. Thanks for using Kea and reporting this to us. Regards Wlodek Wencel ISC QA On 13/12/2020 13:50, bill.pye wrote: > Hi Everyone > > I'm currently using kea on CentOS8 and have a little question. I'm > seeing the following messages when I do a system upgrade: > > Problem 2: cannot install the best update candidate for package > isc-kea-libs-1.9.2-isc0009720201123144834.el8.x86_64 > - problem with installed package > isc-kea-libs-1.9.2-isc0009720201123144834.el8.x86_64 > - package isc-kea-libs-1.9.2-isc0009720201123144834.el8.x86_64 > requires liblog4cplus-1.1.so.9()(64bit), but none of the providers can > be installed > - cannot install the best update candidate for package > log4cplus-1.1.3-0.4.isc1.el8.x86_64 > - cannot install both log4cplus-1.2.0-11.el8.x86_64 and > log4cplus-1.1.3-0.4.isc1.el8.x86_64 > - cannot install both log4cplus-1.1.3-0.4.isc1.el8.x86_64 and > log4cplus-1.2.0-11.el8.x86_64 > > Obviously this is a test kea-1.9 but I see the same messages for the > kea-1.8 version, is kea actually built to use a specific version of > log4cplus and if so, why? Wouldn't it be better to use the O/S > available version of log4cplus rather than a specific version or have > I messed something obvious here? > > Do forgive me if my questions is a bit basic but I'm just a home user > of kea and somewhat inexperienced. > > Regards > > Bill > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > > ___ > 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] 1.8.0 release?
Hello, all announcements are made on kea-annou...@lists.isc.org mailing list. https://lists.isc.org/mailman/listinfo/kea-announce Regards, Wlodek Wencel ISC QA On 02/09/2020 17:58, Bill Pye wrote: > Hi > > I don't think there was an announcement in this mailing list (is there ever?) > but the blog had one: here: https://www.isc.org/blogs/kea-1.8.0-released/ > > Regards > > Bill > > - Original Message - >> From: "Andreas Hasenack" >> To: "kea-users" >> Sent: Wednesday, 2 September, 2020 17:39:53 >> Subject: [Kea-users] 1.8.0 release? >> Hi, is 1.8.0 officially released? I see it on >> https://downloads.isc.org/isc/kea/cur/ but no announcement, unless I >> missed it. >> ___ >> 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] ha heartbeat error: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
Hello,
it can be privileges or path issue, it's weird with /tmp though.
Make sure that socket can be created, second option is to try configure
it in different directories.
Regards
Wlodek
On 31/07/2020 15:06, Chris Calbreath wrote:
>
> So a bit more investigation and it appears the socket is the cause of
> the issue. running strace against the PID of kea-ctrl-agent produces
> this message:
>
> connect(17, {sa_family=AF_UNIX, sun_path="/tmp/dhcp6.sock"}, 17) = -1
> ENOENT (No such file or directory)
>
>
>
> What would cause the socket to not be created in the path specified?
>
>
>
>
>
> Here is my config.
>
>
>
> _Server 1:_
>
> *dhcpv6.conf*
>
> "control-socket": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/dhcp6.sock "
>
>
>
> *ctrl-agent.conf*
>
> "dhcp6": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/dhcp6.sock"
>
>
>
> _Server 2_
>
> *dhcpv6.conf*
>
> "control-socket": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/dhcp6.sock "
>
>
>
> *ctrl-agent.conf*
>
> "dhcp6": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/dhcp6.sock "
>
>
>
>
>
> Chris
>
>
>
>
>
>
>
>
>
> *From:* Kea-users <mailto:kea-users-boun...@lists.isc.org>> *On Behalf Of *Wlodek Wencel
> *Sent:* Tuesday, July 28, 2020 3:24 PM
> *To:* kea-users@lists.isc.org <mailto:kea-users@lists.isc.org>
> *Subject:* Re: [Kea-users] ha heartbeat error: unable to forward
> command to the dhcp6 service: No such file or directory. The server is
> likely to be offline
>
>
>
> Hello,
>
> thank you for using Kea :)
>
> This is problem of communication between kea-ctrl-agent and kea-dhcp6,
> two most common issues in this case are:
>
> - kea-dhcp6 is not running / failed to open socket
>
> - there is misconfiguration of sockets (configuration in
> kea-ctrl-agent has to point to the socket that kea-dhcp6 is opening)
>
> Regards
>
> Wlodek Wencel
>
> ISC QA
>
> On 28/07/2020 22:15, Chris Calbreath wrote:
>
> Has anyone experienced this before? I have 2 Kea v1.79 servers
> running in a load balancing pair but I get the following errors
> when running kea-ctrl:
>
>
>
> { "command": "ha-heartbeat", "service": [ "dhcp6" ] }
>
> INFO COMMAND_RECEIVED Received command 'ha-heartbeat'
>
> DEBUG CTRL_AGENT_COMMAND_FORWARD_BEGIN begin forwarding command
> ha-heartbeat to service dhcp6
>
> DEBUG CTRL_AGENT_COMMAND_FORWARD_FAILED failed forwarding command
> ha-heartbeat: unable to forward command to the dhcp6 service: No
> such file or directory. The server is likely to be offline
>
> DEBUG HTTP_SERVER_RESPONSE_SEND sending HTTP response HTTP/1.1 200
> OK to XXX.XXX.223.245
>
> DEBUG HTTP_SERVER_RESPONSE_SEND_DETAILS detailed information about
> response sent to XXX.XXX.223.245:
>
> HTTP/1.1 200 OK
>
> Content-Length: 140
>
> Content-Type: application/json
>
> Date: Tue, 28 Jul 2020 20:06:35 GMT
>
>
>
> [ { "result": 1, "text": "unable to forward command to the dhcp6
> service: No such file or directory. The server is likely to be
> offline" } ]
>
>
>
> ___
>
> 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 <mailto: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] ha heartbeat error: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
Hello,
thank you for using Kea :)
This is problem of communication between kea-ctrl-agent and kea-dhcp6,
two most common issues in this case are:
- kea-dhcp6 is not running / failed to open socket
- there is misconfiguration of sockets (configuration in kea-ctrl-agent
has to point to the socket that kea-dhcp6 is opening)
Regards
Wlodek Wencel
ISC QA
On 28/07/2020 22:15, Chris Calbreath wrote:
>
> Has anyone experienced this before? I have 2 Kea v1.79 servers running
> in a load balancing pair but I get the following errors when running
> kea-ctrl:
>
>
>
> { "command": "ha-heartbeat", "service": [ "dhcp6" ] }
>
> INFO COMMAND_RECEIVED Received command 'ha-heartbeat'
>
> DEBUG CTRL_AGENT_COMMAND_FORWARD_BEGIN begin forwarding command
> ha-heartbeat to service dhcp6
>
> DEBUG CTRL_AGENT_COMMAND_FORWARD_FAILED failed forwarding command
> ha-heartbeat: unable to forward command to the dhcp6 service: No such
> file or directory. The server is likely to be offline
>
> DEBUG HTTP_SERVER_RESPONSE_SEND sending HTTP response HTTP/1.1 200 OK
> to XXX.XXX.223.245
>
> DEBUG HTTP_SERVER_RESPONSE_SEND_DETAILS detailed information about
> response sent to XXX.XXX.223.245:
>
> HTTP/1.1 200 OK
>
> Content-Length: 140
>
> Content-Type: application/json
>
> Date: Tue, 28 Jul 2020 20:06:35 GMT
>
>
>
> [ { "result": 1, "text": "unable to forward command to the dhcp6
> service: No such file or directory. The server is likely to be
> offline" } ]
>
>
> ___
> 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] DDNS Error
Hey,
I believe you had to many brackets at start and missing coma before loggers:
{
"DhcpDdns": {
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"hostname": "",
"ip-address": "192.168.40.10",
"port": 53
}
],
"key-name": "homelocal.key",
"name": "home.local."
}
]
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "/var/log/kea-ddns.log"
}
],
"severity": "DEBUG"
}
],
"tsig-keys": [
{
"algorithm": "HMAC-SHA256",
"name": "homelocal.key",
"secret": "jo/1eHCej8eFTY2aqvICCNINVvbbv9KuEU="
}
]
}
}
Tools like web json validators can be very helpful to find those kind of
issues.
Regards
Wlodek Wencel
QA, ISC
On 10/06/2020 05:35, Peter Fraser wrote:
>
> Thanks so much for both replies. I made the changes you mentioned. I
> found I also had to change the ip-addess to the ip address of the
> server. When I had it as 127.0.0.1, I was getting a corrupt reply
> error from the DNS Server in the logs. Thankfully now, the server is
> updating. I have just one last error now that I am trying to figure
> out. This is in the kea-dhcp-ddns.conf file. I keep getting the error :
>
>
>
> *INFO/keactrl: Starting /usr/local/sbin/kea-dhcp-ddns -c
> /usr/local/etc/kea/kea-dhcp-ddns.conf*
>
> *2020-06-09 23:13:15.700 FATAL [kea-dhcp-ddns.dctl/72504]
> DCTL_CONFIG_FILE_LOAD_FAIL DhcpDdns reason: Configuration parsing
> failed: /usr/local/etc/kea/kea-dhcp-ddns.conf:28.3-11: syntax error,
> unexpected loggers, expecting "," or }*
>
>
>
> I get this when I enable the logging section in the file. I am not
> sure why. I pretty much used the defaults from the sample file. I even
> compared my file with the sample file and everything there is the same
> except that I enabled debugging in mine.
>
>
>
> Please note my entire kea-dhcp-ddns.conf below. I have been going
> through but I can’t seem to find a syntax error.
>
>
>
> {
>
> {
>
> "DhcpDdns": {
>
>
>
> "tsig-keys": [
>
> {
>
> "name": "homelocal.key",
>
> "algorithm": "HMAC-SHA256",
>
> "secret": "jo/1eHCej8eFTY2aqvICCNINVvbbv9KuEU="
>
> }
>
> ],
>
>
>
> "forward-ddns": {
>
> "ddns-domains": [
>
> {
>
> "name": "home.local.",
>
> "key-name": "homelocal.key",
>
> "dns-servers": [
>
> {
>
> "hostname": "",
>
> "ip-address": "192.168.40.10",
>
> "port": 53
>
> }
>
> ]
>
> }
>
> ]
>
> }
>
>
>
> "loggers": [
>
> {
>
> "name": "kea-dhcp-ddns",
>
> "output_options": [
>
> {
>
> "output": "/var/log/kea-ddns.log"
>
>
>
> }
>
> ],
>
> "severity": "DEBUG",
>
> // If DEBUG level is specified, this value is used. 0 is least
> verbose,
>
> // 99 is most verbose. Be cautious, Kea can generate lots and lots
>
> // of logs if told to do so.
>
> "debuglevel": 99
>
> }
>
> ]
>
> }
>
> }
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Joshua Schaeffer <mailto:jschaef...@harmonywave.com>
> *Sent: *Tuesday, June 9, 2020 1:06 PM
> *To: *kea-users@lists.isc.org <mailto:kea-users@lists.isc.org>
> *Subject: *Re: [Kea-users] DDNS Error
>
>
>
>
>
> On 6/9/20 11:28 AM, Stephen Morris wrote:
>
> 2. In the "forward-ddns" section of
Re: [Kea-users] bug report template has feature request fields
Hello, yes, it looks like copy & paster error. Thanks for pointing it out - we will handle it. Wlodek On 23/06/2019 16:52, Dr. Benjamin S. Scarlet wrote: > The bug report template for filing new issues at > > https://gitlab.isc.org/isc-projects/kea/issues/new?issue%5Bassignee_id% > 5D=%5Bmilestone_id%5D= > > looks a little broken. It starts out reasonably enough, but roughly the > last half of it (starting at "some initial questions") seems more > appropriate for feature requests. Is that later part intentional, or > has there perhaps been a cut & paste error maintaining the templates? > > Thanks, > Benjamin S. Scarlet > ___ > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] Kea 1.5.0 released!
On behalf of ISC and Kea team I'm pleased to announce that new version 1.5.0 is released and available to use! Welcome to Kea 1.5.0. Kea is a DHCP implementation developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP servers, an example shell client to connect to the CA, a daemon that is able to retrieve YANG configuration and updates from Sysrepo, and a DHCP performance measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification and host reservations. The DHCPv6 server also supports prefix delegation. Lease information can be stored in a MySQL, PostgreSQL or Cassandra database; it can also be stored in a CSV file. Host reservations can be stored in a configuration file; they can also be stored in a MySQL, PostgreSQL, or Cassandra database and, to some degree, also retrieved from a RADIUS server. Kea DHCPv4 and DHCPv6 daemons provide support for YANG models, which are stored in a Sysrepo datastore and can be configured via the NETCONF protocol. The major new features and changes in this version are: **YANG models** - YANG https://tools.ietf.org/html/rfc6020 is a popular configuration language that uses models to define the configuration syntax for various networking devices (similar to database schema). You can store actual device configurations in that model (think of this as data stored in your database). This configuration can be modified using either local command line tools (such as *sysrepocfg*) or remotely using the NETCONF https://tools.ietf.org/html/rfc6241 protocol. Kea 1.5.0-beta1 introduced support for Sysrepo http://www.sysrepo.org/, which provides YANG models and YANG configuration storage. Sysrepo supports both startup and running datastores. This may become very useful if you want to experiment with your Kea configuration, but don't want want to commit it permanently. A new daemon, kea-netconf, has been introduced in this release. It provides three services. First, it can load the initial configuration from the Sysrepo startup datastore and then apply it to Kea DHCPv4 and/or DHCPv6 servers. Second, it can monitor the running datastore and pick up any changes that may appear. Third, before you commit any changes to Sysrepo, it can retrieve the proposed configuration from Sysrepo, send it to the Kea DHCP servers using config-test and then report back to Sysrepo whether the new configuration is valid or should be rejected. YANG and NETCONF is a complex environment. This is the first release and we are hoping to expand Kea capabilities in future versions. We currently have four models defined (kea-dhcp4-server, kea-dhcp6-server, kea-dhcp-ddns, and kea-ctrl-agent), but only the first two are supported. Shared definitions are in the kea-types, kea-logging and kea-dhcp-types modules. Beta testers using CentOS may find installation notes for NETCONF on CentOS https://kb.isc.org/docs/kea-build-on-centos helpful. The YANG modules have changed between beta1 and beta2. If you are upgrading, make sure you have reinstalled the modules. The Kea-netconf daemon now checks YANG modules versions. This means that if you are upgrading from beta1 or beta2 and forget to reinstall updated YANG modules, Kea will spot this and will refuse to run. This is much better than the previous behavior, where it started and then threw random errors every time it encountered module incompatibility. Also note that Kea implements support for Sysrepo, which is a YANG model and configuration storage. It can be used using local commands, but does not provide a native NETCONF interface. However, Netopeer2 can be installed to expose configurations stored in Sysrepo via NETCONF. See the Sysrepo and Netopeer2 documentation for details. **Global host reservations** - Kea 1.5 introduces support for global host reservations. Previously reservations were always subnet specific, so if you had a mobile client visiting 10 networks and you wanted to reserve something, such as special options or parameter values, you would have to create 10 reservations. Now it is possible to specify that certain subnets (or even all of them) should use global reservations. Caution is advised when assigning addresses this way. Kea does not check the correctness of the addresses being reserved, so this feature is mostly intended to be used for options and other configuration parameters, not addresses. **Congestion control** - Older Kea versions had no notion of congestion control and used to process packets in first-in first-out order. When overloaded with traffic, Kea effectively kept responding to the oldest packets first, which was likely to trigger an avalanche of retransmissions. What's worse, when the buffer was full new packets were discarded and older, possibly stale
[Kea-users] Kea 1.5.0-beta2 available for testing!
Welcome to the second beta release of Kea 1.5.0! Kea is a DHCP implementation developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP servers, an example shell client to connect to the CA, a NETCONF daemon that is able to retrieve YANG configuration and updates from Sysrepo, and a DHCP performance measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification and host reservations. The DHCPv6 server also supports prefix delegation. Lease information can be stored in a MySQL, PostgreSQL or Cassandra database; it can also be stored in a CSV file. Host reservations can be stored in a configuration file; they can also be stored in a MySQL, PostgreSQL, or Cassandra database and, to some degree, also retrieved from a RADIUS server. Kea DHCPv4 and DHCPv6 daemons provide support for YANG models, which can be configured over NETCONF protocol. Compared to 1.5.0-beta1, we fixed 30 issues that cover various bugs and small improvements. The more notable ones are: * Fixed memory leak in RADIUS hook * Improved support for MariaDB * Cassandra backend no longer gets confused when trying to delete non-existing host reservation * Added examples for global host reservations * Fixed support for recent sysrepo releases. The code should work with at least 0.7.5, 0.7.6 and 0.7.7. * The YANG models have changed slightly. This side steps a problem in sysrepo that had difficulties handling two top level entries in a model. We used to have two top level entries: Dhcp4/6 and Logging. Now Logging is a child of Dhcp4/6. Don't forget to reinstall YANG modules. * Beta2 is again able to be built with older boost versions. This may be a good news for CentOS and RHEL users as they can now use the version of boost available in their system packages and no longer need to install a recent version. This version also includes features added in 1.5.0-beta1: **YANG models** - YANG (https://tools.ietf.org/html/rfc6020) is very popular configuration language that allows to define a model, which is a configuration syntax for various networking devices (think of this as database schema). You can then store actual configuration in that model (think of this as data stored in your database). This configuration then can be modified using either local command line tools (such as sysrepocfg) or remotely using NETCONF (https://tools.ietf.org/html/rfc6241) protocol. Kea 1.5.0-beta1 introduces support for Sysrepo (http://www.sysrepo.org/), which provides YANG models and YANG configuration storage. It currently supports both startup and running datastores. This may become very useful if you want to experiment with your Kea configuration, but don't want want to commit it permanently. A new daemon, kea-netconf, has been introduced in this release. It provides three services. First, it can load the initial configuration from the Sysrepo startup datastore and then apply it to Kea DHCPv4 and/or DHCPv6 servers. Second, it can monitor the running datastore and pick up any changes that may appear. Third, before you commit any changes to Sysrepo, it may retrieve the proposed configuration from Sysrepo, send it to Kea DHCP servers using config-test and then report back to Sysrepo whether the new configuration is valid or should be rejected. YANG and NETCONF is a complex environment. This is the first release and we are hoping to expand Kea capabilities in future versions. We currently have four models defined (kea-dhcp4-server, kea-dhcp6-server, kea-dhcp-ddns, and kea-ctrl-agent), but only the first two are supported. Shared definitions are in kea-types, kea-logging and kea-dhcp-types modules. Beta testers using CentOS may find these installation notes for Netconf on CentOS (https://kb.isc.org/docs/kea-build-on-centos) helpful. The YANG modules have changed between beta1 and beta2. If you are upgrading, make sure you have reinstalled the modules. Also note that Kea implements support for Sysrepo, which is a YANG model and configuration storage. It can be used using local commands, but does not provide a NETCONF interface natively. However, Netopeer2 can be installed to expose configurations stored in Sysrepo via NETCONF. See Sysrepo and Netopeer2 documentation for details. **Global host reservations** - Kea 1.5 introduces support for global host reservations. Previously reservations were always subnet specific, so if you had a mobile client visiting 10 networks and you wanted to reserve something, such as special options or parameter values, you would have to create 10 reservations. Right now it is possible to specify that certain subnets (or even all of them) should use global reservations. Caution is advised when assigning addresses this way. Kea does not check correctness of the
[Kea-users] Kea 1.5.0-beta1 available for testing!
Welcome to the first beta release of Kea 1.5.0. This release will be followed by beta2 on November 30 and with final version on December 14. We are looking forward to your feedback! Kea is a DHCP implementation developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP servers, an example shell client to connect to the CA, a NETCONF daemon that is able to retrieve YANG configuration and updates from Sysrepo, and a DHCP performance measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification and host reservations. The DHCPv6 server also supports prefix delegation. Lease information can be stored in a MySQL, PostgreSQL or Cassandra database; it can also be stored in a CSV file. Host reservations can be stored in a configuration file; they can also be stored in a MySQL, PostgreSQL, Cassandra databases and to some degree also retrieved from a RADIUS server. Kea DHCPv4 and DHCPv6 daemons provide support for YANG models, which can be configured over NETCONF protocol. Version 1.5.0-beta1 adds the following features to Kea: * YANG models and NETCONF support - YANG (https://tools.ietf.org/html/rfc6020) is very popular configuration language that allows to define a model, which is a configuration syntax (think of this as database schema) for various networking devices. You can then store actual configuration in that model (think of this as data stored in your database). This configuration then can be modified using either local command line tools (such as sysrepocfg) or remotely using NETCONF (https://tools.ietf.org/html/rfc6241) protocol. Kea 1.5.0-beta1 introduces support for [Sysrepo](http://www.sysrepo.org/), which provides YANG data models and YANG configuration storage. It currently supports both startup and running datastores. This may become very useful if you want to experiment with your Kea configuration, but don't want want to commit it permanently. A new daemon kea-netconf has been introduced in this release. It provides three services. First, it can load the initial configuration from Sysrepo startup datastore and then apply it to Kea DHCPv4 and/or DHCPv6 servers. Second, it can monitor running datastore and pick up any changes that may appear. Third, before you commit any changes to sysrepo, it may retrieve the proposed configuration from Sysrepo, send it to Kea DHCP servers using config-test and then report back to Sysrepo whether the new configuration is valid or should be rejected. YANG and NETCONF is a complex environment. This is the first release and we are hoping to expand Kea capabilities. We currently have four models defined (kea-dhcp4-server, kea-dhcp6-server, kea-dhcp-ddns, kea-ctrl-agent), but only the first two are supported. Beta testers using CentOS may find [these installation notes for Netconf on CentOS (https://kb.isc.org/docs/kea-build-on-centos) helpful. * Global host reservations - Kea 1.5 introduces support for global host reservations. Previously reservations were always subnet specific, so if you had a mobile client visiting 10 networks and you wanted to reserve something, such as special options or parameter values, you would have to create 10 reservations. Right now it is possible to specify that certain subnets (or even all of them) should use global reservations. Caution is advised when assigning addresses this way. Kea does not check correctness of the addresses being reserved, so this feature is mostly intended to be used for options and other configuration parameters, but not addresses. * Congestion control - In order to help mitigate congestion during heavy DHCP traffic conditions we have added an experimental feature, "dhcp-queue-control". When enabled, kea-dhcpX servers will read in-bound packets from the interface sockets in a separate thread and place them in queue. The primary application thread will process packets from this queue. The packet queue implementation is both configurable and dynamically replaceable with a plug-in loaded via hook library. For details, see: https://gitlab.isc.org/isc-projects/kea/wikis/congestion-control). BETA DISCLAIMER: This feature will be enabled in 1.5.0beta. For 1.5.0 final there may be an option to disable it. Initial testing has shown that this new feature reduces throughput at very high congestion levels, although at lower congestion levels it ensures Kea is focused on processing current, rather than stale, requests. * High Availability improvements - High Availability has been introduced in 1.4. Release 1.5 brings in a number of performance, resiliency and overall robustness improvements. A new mechanism was introduced that synchronizes leases in chunks rather than all of them at once. This approach makes possible to synchronize large subnets
[Kea-users] Kea 1.4.0 released!
On behalf of ISC and Kea team I'm pleased to announce that
new version 1.4.0 is released and available to use!
Welcome to the 1.4.0 release of Kea. Kea is a DHCP implementation
developed by Internet Systems Consortium, Inc. that features fully
functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a
Control Agent (CA) that provides a REST API to control the DHCP
servers, an example shell client to connect to the CA and a DHCP
performance measurement tool. Both DHCP servers fully support server
discovery, address assignment, renewal, rebinding, release, decline,
information request, DNS updates, client classification and host
reservations. The DHCPv6 server also supports prefix delegation. Lease
information can be stored in a MySQL, PostgreSQL or Cassandra database;
it can also be stored in a CSV file. Host reservations can be stored in
a configuration file; they can also be stored in a MySQL, PostgreSQL,
Cassandra databases and to some degree also retrieved from a RADIUS
server.
Version 1.4.0 adds the following features to Kea:
* High Availability - To provide a highly available service, despite
server failure, two Kea instances can now be configured to run as a
pair. Two modes are supported. In hot standby mode there is a primary
instance handling all traffic and sending updates to its secondary
partner. The secondary monitors the health of the primary and is able
to take over automatically in case the primary fails. In load balancing
mode both partners are active and are handling approximately half of
the traffic traffic. In case of a failure of either server, the partner
is able to take over responding to all traffic directed to both
servers. Support for additional backup servers is implemented. The
backup server's database is updated as soon as possible after changes
are made to the primary server's database, so that it can be used as an
almost drop-in replacement in case of catastrophic failures that take
out both primary and secondary servers. The solution supports both IPv4
and IPv6 and can work with any backend, including memfile. Note that
this is NOT an implementation of the IETF draft DHCPv4 failover (which
does not support DHCPv6).
The HA feature was planned to be a Premium feature, and so it was not
included in the Kea 1.4 open source beta package. During the beta
period we decided to instead offer it as part of the free open source
to enable more users who rely on DHCP failover to migrate to Kea.
* Database improvements - Many Kea users report using multiple Kea
instances sharing a single database backend, or cluster of databases.
One of the frequently requested features was the ability to report
accurate statistics in this case. This surprisingly tricky problem was
solved for MySQL and PostgreSQL by a new stat_cmds hook library and
schema updates. Users also requested the ability to reconnect after
the database connection is lost for whatever reason. '''NOTE''' You
will need to upgrade any existing MySQL and PostgreSQL Kea databases to
the new schema versions. This is readily done using kea-admin:
$ kea-admin lease-upgrade {mysql|pgsql} -u database-user -p
database-password -n database-name
* Cassandra - Kea has had experimental support for a Apache Cassandra
database backend for a while, but the feature hadn't been finished or
fully tested. This has changed: the code now supports host reservations
and has a great number of new smaller fixes and improvements. Its is
now both easier to install and much better documented. Thank you to
Deutsche Telekom AG for sponsoring this work.
* Classification - It is now possible to specify client classes on a
pool level, so you can control who is able to use specific pools, group
similar clients together or even reject clients that don't meet certain
class requirements. Class expressions have expanded capabilities. The
most popular seems to be a member operator, which determines whether
packet is a member of a given class. Two new built in classes - KNOWN
and UNKNOWN - have been added. Complex boolean logic is available. Ever
wanted to do member(foo) and not member(bar)? Now you can.
* Bug fixes and quality of life improvements - With 176 tickets closed
(134 before beta and 42 after beta), 1.4.0 is by far the biggest
release we ever did.
* Extended API - Several new commands have been implemented. This Kea
version supports 65 management commands that allow you to conduct
various operations during operation, such as setting new configuration,
list, retrieve, add or delete subnets, shared networks, host
reservations, leases and much more.
We have also added a new premium hook library, If you purchased the
Kea 1.3.0 premium package before you will be getting an email with
instructions on how to download a free update to the Kea 1.4.0
premium package.
* RADIUS - Kea can now be integrated with an existing RADIUS server.
Both access and accounting roles are supported. Kea is able to send
Access-Request messages and alter its
[Kea-users] Kea 1.4.0-beta is ready for testing!
On behalf of ISC and Kea team I'm pleased to announce that new version 1.4.0-beta is now available for testing! Release of Kea 1.4.0 final is planned for mid June! We are looking for your feedback! Welcome to the 1.4.0-beta release of Kea. Kea is a DHCP implementation developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP servers, an example shell client to connect to the CA and a DHCP performance measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification and host reservations. The DHCPv6 server also supports prefix delegation. Lease information can be stored in a MySQL, PostgreSQL or Cassandra database; it can also be stored in a CSV file. Host reservations can be stored in a configuration file; they can also be stored in a MySQL, PostgreSQL, Cassandra databases and to some degree also retrieved from a RADIUS server. Version 1.4.0-beta adds the following features to Kea: * Database improvements - Many Kea users report using multiple Kea instances sharing a single database backend, or cluster of databases. One of the frequently requested features was the ability to report accurate statistics in this case. This surprisingly tricky problem was solved for MySQL and PostgreSQL by a new stat_cmds hook library and schema updates. Users also requested the ability to reconnect after the database connection is lost for whatever reason. * Cassandra - Kea has had experimental support for a Cassandra database backend for a while, but the feature hadn't been finished or fully tested. This has changed: the code now supports host reservations and has a great number of new smaller fixes and improvements. Its is now both easier to install and much better documented. Thank you to Deutsche Telekom AG for sponsoring this work. * Classification - It is now possible to specify client classes on a pool level, so you can control who is able to use specific pools, group similar clients together or even reject clients that don't meet certain class requirements. Class expressions have expanded capabilities. The most popular seems to be a member operator, which determines whether packet is a member of a given class. Complex boolean logic is available. Ever wanted to do member(foo) and not member(bar)? Now you can. * Bug fixes and quality of life improvements - With 134 tickets closed, 1.4.0 beta is by far the biggest release we ever did. We have also added 2 new features which are dependent on premium hook libraries: * RADIUS - Kea can now be integrated with a RADIUS server. Both access and accounting roles are supported. Kea is able to send Access-Request messages and alter its behavior depending on the responses. Specific IP addresses may be assigned (if Framed-IP-Address or Framed-IPv6-Address is received), client can be assigned to specific pool (if Framed-Pool or Framed-IPv6-Pool is received) or denied service altogether (if Access-Reject is received). Kea can also send accounting messages to RADIUS accounting servers. As with other features, this supports both IPv4 and IPv6. * High Availability - To provide a highly available service, despite server failure, two Kea instances can now be configured to run as a pair. Two modes are supported. In hot standby mode there is a primary instance handling all traffic and sending updates to its secondary partner. The secondary monitors the health of the primary and is able to take over automatically in case the primary fails. In load balancing mode both partners are active and are handling approximately half of the traffic traffic. In case of a failure of either server, the partner is able to take over responding to all traffic directed to both servers. Support for additional backup servers is implemented. The backup server's database is updated as soon as possible after changes are made to the primary server's database, so that it can be used as an almost drop-in replacement in case of catastrophic failures that take out both primary and secondary servers. The solution supports both IPv4 and IPv6 and can work with any backend, including memfile. Note that this is NOT an implementation of the IETF standard DHCPv4 failover (which does not support DHCPv6). == License == Kea 1.4.0-beta is released under the Mozilla Public License, version 2.0. https://www.mozilla.org/en-US/MPL/2.0 The premium hook libraries are provided in source code form, under the terms of an End User License Agreement (you are not permitted to redistribute). == Testing premium hooks == ISC Kea support customers will receive tickets inviting them to beta test the premium hooks, which are included with the support subscription. If you are interested
[Kea-users] Kea 1.3.0 released!
On behalf of ISC and Kea team I'm pleased to announce that new version 1.3.0 with highly anticipated new features is now available! Welcome to the 1.3.0 release of Kea. Kea is a DHCP implementation developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides REST API to control DHCP servers, an example shell client to connect to the CA and a DHCP performance measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification and host reservations. The DHCPv6 server also supports prefix delegation. Lease information can be stored in a MySQL, PostgreSQL or Cassandra database; it can also be stored in a CSV file. Host reservations can be stored in the configuration file; they can also be stored in a MySQL or PostgreSQL database. The Comcast Innovation Fund provided some funding for this release. Version 1.3.0 adds the following features to Kea: * Shared networks - This feature allows the administrator to group multiple subnets together. This is commonly used to pool addresses from multiple subnets when the network has grown and more address are needed than are available on a single subnet. Clients in the shared network may be dynamically assigned any address from any of the included subnets. Shared networks are also useful for specifying common parameters such as options for multiple subnets. If necessary, you can specify a parameter on the shared network scope and then override its value in the subnet scope, client class or on a host reservation. * REST interface over HTTPS - HTTPS provides authentication, confidentiality and integrity for communications over the REST API. We have tested and provided example config files for securing the REST API using Apache and Nginx. We have also provided example config files for securing client communications using stunnel. The maximum size of control commands and responses via REST API have been expanded, removing the 64K limitation present in Kea 1.2. This makes handling of large configurations possible. With these changes the REST API is now ready for production use. Development of this feature was sponsored by a Mozilla MOSS award. * Lease management via REST API - New API commands enable querying, adding, reporting on current leases, and modifying existing leases while Kea is running. This allows the administrator (or any system that interacts with Kea) to check presence and status of leases and make necessary changes as needed. These commands are implemented in a new Lease Commands hook library included in the main Kea distribution. Development of this feature was sponsored by a Mozilla MOSS award. * Subnet management via REST API - Add, remove and modify subnets in Kea via the API, without resending the entire Kea configuration. This will make managing subnets via the API more feasible for configurations with a large number of subnets or deployments that want to avoid small interruptions when updating the whole configuration. This feature is implemented in the new Subnet Commands hook library, available only in the Kea Subscription package to encourage financial support for the project. * Flexible identifier for leases - flexible identifier computed by "flex-id" hook library can optionally be used as a client identifier for allocated leases. In many cases it is preferred to use stable identifier for the client, e.g. generated from the data inserted by a relay agent, rather than client supplied identifier, which may change as a result of hardware replacement. Previous versions of "flex-id" hook library allowed for associating host reservations with such stable identifier. The new version also allows for using such identifier for leases, which prevents conflicts between leases allocated for the client before and after hardware replacement. It also allows for retrieving leases by flexible identifier using REST API. * New options - This release introduced support for 21 DHCPv4 and 10 DHCPv6 options. Support for DHCPv4 vendor specific option (code 43) has been improved. It is now possible to use vendor-specific syntax for that option. * Options in pools - It is now possible to define options in DHCPv4 pools. This additional level gives users an ability to fine tune options and option values. * New hook point - A new hook point 'command_processed' allows hook libraries to interact with command handling. Existing and new libraries have been updated to use that hook point. * Conditional expressions - a new expression 'ifelse' is now supported. It allows users to make conditional choices in expressions, e.g. in client classification or flexible identifier. * Other bug fixes and small improvements - As usual, we fixed many bugs and did other small improvements. In total 126 tickets (74 in beta and 52 in final) were closed. == Important
Re: [Kea-users] 1.3.0 beta not working with mysql
Hello, can you show us reservation you put into database? Wlodek On 05/10/2017 18:52, Bill Pye wrote: Hi all I'm having problems with the current beta not working with a 'mysql' server, I've built this version against the current MariaDB version (and the required devel versions) - all these servers are CentOS7 (fully updated): Installed Packages Name : MariaDB-server Arch : x86_64 Version : 10.2.9 Release : 1.el7.centos Size : 456 M Repo : installed Summary : MariaDB: a very fast and robust SQL database server Installed Packages Name : MariaDB-devel Arch : x86_64 Version : 10.2.9 Release : 1.el7.centos Size : 39 M Repo : installed # Percona cluster dnf info Percona-XtraDB-cluster-57 Using metadata from Wed Oct 4 11:54:00 2017 The database was created as per the documentation and all the tables and stored procedures exist, this is a single server. However when a machine requests an IP I'm seeing the following errors in the log file: 2017-10-05 18:16:10.273 INFO [kea-dhcp4.dhcp4/24862] DHCP4_STARTED Kea DHCPv4 server version 1.3.0-beta started 2017-10-05 18:16:19.020 INFO [kea-dhcp4.leases/24862] DHCP4_LEASE_ADVERT [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0x2c0f9a70: lease 192.168.1.160 will be advertised 2017-10-05 18:16:19.021 INFO [kea-dhcp4.leases/24862] DHCP4_LEASE_ADVERT [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0x2c0f9a70: lease 192.168.1.161 will be advertised 2017-10-05 18:16:19.029 ERROR [kea-dhcp4.alloc-engine/24862] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0xa6d4566b: error during attempt to allocate an IPv4 address: unable to bind parameters for lease4(address, hwaddr, client_id, valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)>, reason: (error code 0) I'm also trying to get this working with a Percona XtraDB cluster and having the same problem, this a a five server cluster: Installed Packages Name : Percona-XtraDB-Cluster-57 Arch : x86_64 Epoch : 0 Version : 5.7.19 Release : 29.22.1.el7 Size : 0.0 Repo : @System From repo : percona-release-x86_64 2017-10-05 18:06:44.996 INFO [kea-dhcp4.leases/16988] DHCP4_INIT_REBOOT [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0x9ddd43c: client is in INIT-REBOOT state and requests address 192.168.1.161 2017-10-05 18:06:52.548 INFO [kea-dhcp4.leases/16988] DHCP4_INIT_REBOOT [hwtype=1 da:d9:a8:4c:30:9d], cid=[01:da:d9:a8:4c:30:9d], tid=0x1299a707: client is in INIT-REBOOT state and requests address 192.168.1.170 2017-10-05 18:07:00.225 INFO [kea-dhcp4.leases/16988] DHCP4_LEASE_ADVERT [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0x989c660b: lease 192.168.1.160 will be advertised 2017-10-05 18:07:00.227 INFO [kea-dhcp4.leases/16988] DHCP4_LEASE_ADVERT [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0x989c660b: lease 192.168.1.161 will be advertised 2017-10-05 18:07:00.228 ERROR [kea-dhcp4.alloc-engine/16988] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 00:0c:29:bc:bc:18], cid=[01:00:0c:29:bc:bc:18], tid=0xed6a4f7f: error during attempt to allocate an IPv4 address: unable to bind parameters for lease4(address, hwaddr, client_id, valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)>, reason: (error code 0) In both of those cases on the cluster and the single server the error messages just keep repeating. There is also nothing in the leases table. Does anyone currently use a DB for lease data? Is there any more information I can provide about this problem? Is this likely to be something I've missed in building kea? Kea 1.3 beta does work OK using a file for lease storage. :) Regards Bill ___ Kea-users mailing list Kea-users@lists.isc.org 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 DHCPv6 and clients not working
Ok, so this is not the option case. But that capture doesn't bring us
closer. Server still doesn't receive Request message.
Can you produce capture on client site? We need to know if client is
sending Request and if so - where it's being lost.
Wlodek Wencel
ISC, QA engineer
On 11/08/2016 06:18 PM, SoupNazi izaNpuoS wrote:
> I set the option 24 (I had previously tried that). I wouldn't know what
> to set for option 17. It should be noted that the successful DHCPv6
> conversation with ISC DHCP and the windows 10 test machine does not
> contain options 17,24, and 39. Attached is the updated packet capture.
>
> On Tue, Nov 8, 2016 at 11:28 AM, Wlodek Wencel <wlo...@isc.org
> <mailto:wlo...@isc.org>> wrote:
>
> Hello,
>
> thanks for reporting this issue, we will try to sort it out together.
>
> Differences between messages you pointed out should not make be
> problematic and what you described in point 3 - Kea works according
> to spec.
>
> Your capture contains forwarded messages solicit and advertise, normally
> DHCPv6 is performing 4 message exchange. Client should send Request
> after receiving Advertise (unless rapid-commit option is allowed, you
> have that one configured in kea BUT there is no rapid commit option in
> Solicit so clients should perform full 4 way message exchange).
>
> It looks like windows client is not happy with what Advertise message is
> containing.
>
> In Solicit message client is requesting two option that you dont have
> configured:
> - option 17 - Vendor-specific Information
> - option 24 - Domain Search
>
> Maybe those options (or just one of them) are mandatory for your
> clients? Can you configure them and send the results?
>
> Thanks,
> Wlodek Wencel
> ISC, QA Engineer
>
> On 11/08/2016 03:47 PM, SoupNazi izaNpuoS wrote:
> > Folks,
> >
> > I am testing kea for DHCPv6 with three test clients. A windows 10
> > laptop, a Linksys router and a D-Link router. All three of these
> > clients can receive DHCPv6 addresses + PD (where applicable) from ISC
> > DHCP server. Only the D-Link can successfully receive DHCPv6 from the
> > kea server.
> >
> > DHCPv4 portion of the kea server is working fine.
> >
> > Version: Kea DHCPv6 server version 1.1.0 (installed from EPEL repo on
> > Centos 7)
> >
> > It should be noted that there is a Juniper SRX that is the relay
> agent.
> >
> > I see the relay-forward and relay-reply messages on the server with
> > tcpdump. I see the solicit/advertise messages on the windows 10
> client
> > with Wireshark. Windows, using ipconfig /renew6 in command prompt,
> > shows an ultra-informative error:
> >
> > "An error occurred renewing interface Ethernet : The parameter is
> incorrect"
> >
> > and windows 10 assigns no IPv6 address to the interface. The Linksys
> > similarly assigns no address but I have no error to show or anything.
> >
> > I compared the packet capture with the ISC DHCPv6 packet capture and
> > noticed three differences in the relay-reply:
> >
> > 1) option 3 (identity association for non-temporary address) was
> listed
> > first in the packet on the ISC DHCPv6 and was 3rd in the kea packet.
> >
> > 2) option 3 had values of 500 and 400 for T1 and T2 respectively
> in the
> > Kea packet and both were 0 in the ISC DHCPv6 relay-reply packet.
> >
> > 3) Kea DHCPv6 packet had option 39 FQDN (requested by client) and the
> > ISC DHCPv6 packet contained no such option even though requested
> by the
> > client.
> >
> > I'm assuming I've missed something in the config that is necessary for
> > 67% of clients to work :)
> >
> > Here is the DHCPv6 portion of my config:
> >
> > "Dhcp6": {
> >
> > "interfaces-config": {
> >
> > "interfaces": [ "enp4s0/2620:0:2e50:e4::226" ]
> >
> > },
> >
> > "dhcp-ddns": {
> >
> > "enable-updates": false
> >
> > },
> >
> > "lease-database": {
> >
> > "type": "mysql",
> >
> >
Re: [Kea-users] kea DHCPv6 and clients not working
Hello,
thanks for reporting this issue, we will try to sort it out together.
Differences between messages you pointed out should not make be
problematic and what you described in point 3 - Kea works according to spec.
Your capture contains forwarded messages solicit and advertise, normally
DHCPv6 is performing 4 message exchange. Client should send Request
after receiving Advertise (unless rapid-commit option is allowed, you
have that one configured in kea BUT there is no rapid commit option in
Solicit so clients should perform full 4 way message exchange).
It looks like windows client is not happy with what Advertise message is
containing.
In Solicit message client is requesting two option that you dont have
configured:
- option 17 - Vendor-specific Information
- option 24 - Domain Search
Maybe those options (or just one of them) are mandatory for your
clients? Can you configure them and send the results?
Thanks,
Wlodek Wencel
ISC, QA Engineer
On 11/08/2016 03:47 PM, SoupNazi izaNpuoS wrote:
> Folks,
>
> I am testing kea for DHCPv6 with three test clients. A windows 10
> laptop, a Linksys router and a D-Link router. All three of these
> clients can receive DHCPv6 addresses + PD (where applicable) from ISC
> DHCP server. Only the D-Link can successfully receive DHCPv6 from the
> kea server.
>
> DHCPv4 portion of the kea server is working fine.
>
> Version: Kea DHCPv6 server version 1.1.0 (installed from EPEL repo on
> Centos 7)
>
> It should be noted that there is a Juniper SRX that is the relay agent.
>
> I see the relay-forward and relay-reply messages on the server with
> tcpdump. I see the solicit/advertise messages on the windows 10 client
> with Wireshark. Windows, using ipconfig /renew6 in command prompt,
> shows an ultra-informative error:
>
> "An error occurred renewing interface Ethernet : The parameter is incorrect"
>
> and windows 10 assigns no IPv6 address to the interface. The Linksys
> similarly assigns no address but I have no error to show or anything.
>
> I compared the packet capture with the ISC DHCPv6 packet capture and
> noticed three differences in the relay-reply:
>
> 1) option 3 (identity association for non-temporary address) was listed
> first in the packet on the ISC DHCPv6 and was 3rd in the kea packet.
>
> 2) option 3 had values of 500 and 400 for T1 and T2 respectively in the
> Kea packet and both were 0 in the ISC DHCPv6 relay-reply packet.
>
> 3) Kea DHCPv6 packet had option 39 FQDN (requested by client) and the
> ISC DHCPv6 packet contained no such option even though requested by the
> client.
>
> I'm assuming I've missed something in the config that is necessary for
> 67% of clients to work :)
>
> Here is the DHCPv6 portion of my config:
>
> "Dhcp6": {
>
> "interfaces-config": {
>
> "interfaces": [ "enp4s0/2620:0:2e50:e4::226" ]
>
> },
>
> "dhcp-ddns": {
>
> "enable-updates": false
>
> },
>
> "lease-database": {
>
> "type": "mysql",
>
> "name": "keatest",
>
> "host": "localhost",
>
> "user": "",
>
> "password": "",
>
> "connect-timeout": 3
>
> },
>
> "preferred-lifetime": 600,
>
> "valid-lifetime": 600,
>
> "renew-timer": 500,
>
> "rebind-timer": 400,
>
> "option-data": [{
>
> "name": "dns-servers",
>
> "code": 23,
>
> "space": "dhcp6",
>
> "csv-format": true,
>
> "data": "2620:0:2e50:a::233, 2620:0:2e50:a::234"
>
> }],
>
> "subnet6": [{
>
> "subnet": "2620:0:2e50:e8::/64",
>
> "rapid-commit": true,
>
> "pools": [ {
>
> "pool":
> "2620:0:2e50:e8::2-2620:0:2e50:e8::"
>
> } ],
>
> "pd-pools": [{
>
> "prefix": "2620:0:2e50:f000::",
>
> "prefix-len": 52,
>
> "delegated-len": 64
>
> }]
>
> }]
>
> },
>
>
> Attached is the server side packet capture for Kea DHCPv6 server... Any
> ideas?
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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 reading error
Thank you very much I will try to reproduce this issue later today. But
after quick look into your csv file I picked up one randomly choosen mac
address and:
cat kea-leases4.csv | grep d8:50:e6:84:3d:80 | wc -l
2422
you have 2422 entries for single mac address so I encourage you to use
LFC. Leases File Cleanup (LFC) will keep your csv file clean and you
wont drown in millions of old leases. Extend your config file with
"lfc-interval"
e.g.
},
"lease-database": {
"type": "memfile",
"lfc-interval": 2000
},
All the information about .csv file you will find here:
http://kea.isc.org/docs/kea-guide.html#idp51897760
Włodek Wencel
ISC QA team
On 10/26/2016 05:47 PM, Munroe Sollog wrote:
> here is the full log of kea attempting to start I also gzipp'ed and uploaded
> my leases file to:
> https://ufile.io/f2b9
>
>
> Oct 26 11:40:01 rogi systemd[1]: Starting ISC KEA IPv4 DHCP daemon...
> Oct 26 11:40:01 rogi systemd[1]: Started ISC KEA IPv4 DHCP daemon.
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.720 INFO
> [kea-dhcp4.dhcp4/20635]
> DHCP4_STARTING Kea DHCPv4 server version 1.0.0 starting
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.722 INFO
> [kea-dhcp4.dhcpsrv/20635]
> DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.722 INFO
> [kea-dhcp4.dhcpsrv/20635]
> DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using
> default socket type raw
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.723 INFO
> [kea-dhcp4.dhcp4/20635]
> DHCP4_CONFIG_NEW_SUBNET a new subnet has been added to configuration:
> 172.31.0.0/18 with params:
> valid-lifetime=4000
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.724 INFO
> [kea-dhcp4.commands/20635]
> COMMAND_SOCKET_UNIX_OPEN Command socket opened: UNIX, fd=6,
> path=/var/kea/statistics-socket
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.724 INFO
> [kea-dhcp4.dhcpsrv/20635]
> DHCPSRV_MEMFILE_DB opening memory file lease database: type=memfile universe=4
> Oct 26 11:40:01 rogi kea-dhcp4[20635]: 2016-10-26 11:40:01.724 INFO
> [kea-dhcp4.dhcpsrv/20635]
> DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
> /var/lib/kea/kea-leases4.csv
> Oct 26 11:40:09 rogi kea-dhcp4[20635]: 2016-10-26 11:40:09.311 ERROR
> [kea-dhcp4.dhcp4/20635]
> DHCP4_PARSER_FAIL failed to create or run parser for configuration element
> lease-database: exceeded
> maximum number of failures 100 to read a lease from the lease file
> /var/lib/kea/kea-leases4.csv
> Oct 26 11:40:09 rogi kea-dhcp4[20635]: 2016-10-26 11:40:09.311 ERROR
> [kea-dhcp4.dhcp4/20635]
> DHCP4_CONFIG_LOAD_FAIL configuration error using file:
> /etc/kea/kea-dhcp4.conf, reason: exceeded
> maximum number of failures 100 to read a lease from the lease file
> /var/lib/kea/kea-leases4.csv
> Oct 26 11:40:09 rogi kea-dhcp4[20635]: 2016-10-26 11:40:09.311 ERROR
> [kea-dhcp4.dhcp4/20635]
> DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using
> file
> '/etc/kea/kea-dhcp4.conf': exceeded maximum number of failures 100 to read a
> lease from the lease
> file /var/lib/kea/kea-leases4.csv
> Oct 26 11:40:09 rogi kea-dhcp4[20635]: 2016-10-26 11:40:09.311 INFO
> [kea-dhcp4.commands/20635]
> COMMAND_SOCKET_UNIX_CLOSE Command socket closed: UNIX, fd=6,
> path=/var/kea/statistics-socket
> Oct 26 11:40:09 rogi systemd[1]: kea-dhcp4-server.service: main process
> exited, code=exited,
> status=1/FAILURE
> Oct 26 11:40:09 rogi systemd[1]: Unit kea-dhcp4-server.service entered failed
> state.
>
>
> On 10/25/2016 05:37 PM, Wlodek Wencel wrote:
>> text files like kea_leases.csv reach really good compression ratio. It
>> shouldn't reach more than 5Mb, but it is still to much for mailing list
>> so if you could upload it somewhere.
>>
>> Or change logging severity to DEBUG with debug level 99 and see if there
>> are additional logs.
>>
>> Regards,
>> Włodek Wencel
>>
>> On 10/25/2016 11:13 PM, Munroe Sollog wrote:
>>> below is my config. My leases file is ~350MB so can't easily attach that
>>> to an email.
>>>
>>>
>>> {
>>> "Dhcp4":
>>> {
>>> "control-socket": {
>>> "socket-type": "unix",
>>> "socket-name": "/var/kea/statistics-socket"
>>> },
>>> "interfaces-config": {
>>> "interfaces": ["eth0" ]
>>> },
>>> "lease-database": {
>>> "type": "memfile&
Re: [Kea-users] lease reading error
text files like kea_leases.csv reach really good compression ratio. It
shouldn't reach more than 5Mb, but it is still to much for mailing list
so if you could upload it somewhere.
Or change logging severity to DEBUG with debug level 99 and see if there
are additional logs.
Regards,
Włodek Wencel
On 10/25/2016 11:13 PM, Munroe Sollog wrote:
> below is my config. My leases file is ~350MB so can't easily attach that to
> an email.
>
>
> {
> "Dhcp4":
> {
> "control-socket": {
> "socket-type": "unix",
> "socket-name": "/var/kea/statistics-socket"
> },
> "interfaces-config": {
> "interfaces": ["eth0" ]
> },
> "lease-database": {
> "type": "memfile"
> },
> "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
> },
> "valid-lifetime": 4000,
> "subnet4": [
> {
> "subnet": "172.31.0.0/18",
> "pools": [ { "pool": "172.31.1.1 - 172.31.31.254"} ],
> "option-data": [
> {
> "name": "domain-name-servers",
> "data": "8.8.8.8, 8.8.4.4"
> },
> {
> "name": "routers",
> "data": "172.31.0.1"
> },
> ]
> }
>
> ]
> },
>
> "Logging":
> {
> "loggers": [
> {
> "name": "kea-dhcp4",
> "output_options": [
> {
> "output": "/var/log/kea-dhcp4.log"
> }
> ],
> "severity": "INFO",
> "debuglevel": 0
> },
> ]
> }
> }
>
>
> On 10/25/2016 05:10 PM, Wlodek Wencel wrote:
>> Hello,
>> thanks for reporting that issue, I never came across this kind of
>> problem. Is there a possibility that you could send us leases file and
>> kea config file?
>>
>> Regards,
>> Włodek Wencel
>> QA team
>>
>> On 10/25/2016 11:05 PM, Todd Simmons (todsimmo) wrote:
>>> Understood, in my case it was caused by a power outage. I have 14 sites
>>> running Kea 1.0.0 and that's the only time it's happened.
>>>
>>> Sent from my iPhone
>>>
>>>> On Oct 25, 2016, at 4:01 PM, Munroe Sollog <m...@lehigh.edu> wrote:
>>>>
>>>> I agree that the file is 'damaged' in some way, and of course if I delete
>>>> all of the leases I expect
>>>> it to start fine, but I'd like to figure out the root cause before I just
>>>> blow the file away.
>>>>
>>>> - Munroe
>>>>
>>>>> On 10/25/2016 04:59 PM, Todd Simmons (todsimmo) wrote:
>>>>> I had the same issue after the vm server was shutdown improperly after a
>>>>> power outage. I opened the file in VI and deleted all the leases (after
>>>>> saving a copy of course) and then it worked just fine.
>>>>>
>>>>> It's possible the file is damaged and that's causing the problem.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Oct 25, 2016, at 3:44 PM, Munroe Sollog <m...@lehigh.edu> wrote:
>>>>>>
>>>>>> running 1.0.0 code. I stopped the service a while and then when I went
>>>>>> to start it I got the
>>>>>> following error:
>>>>>>
>>>>>> kea-dhcp4[14193]: 2016-10-25 16:35:28.129 ERROR [kea-dhcp4.dhcp4/14193]
>>>>>> DHCP4_INIT_FAIL failed to
>>>>>> initialize Kea server: configuration error using file
>>>>>> '/etc/kea/kea-dhcp4.conf': exceeded maximum
>>>>>> number of failures 100 to read a lease from the lease file
>>>>>> /var/lib/kea/kea-leases4.csv
>>>>>>
>>>>>>
>>>>>> # kea-dhcp4 -V
>>>>>> 1.0.0
>>>>>> tarball
>>>>>> linked with
[Kea-users] Kea 1.1.0 is now available!
On behalf of everyone working on Kea, I'm pleased to announce that a new version is available for download! Kea is an alternative DHCP implementation being developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, and a DHCP performance measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification and host reservations. The DHCPv6 server also supports prefix delegation. Lease information can be stored in a MySQL, PostgreSQL or Cassandra database; it can also be stored in a CSV file. Host reservations can be stored in the configuration file; they can also be stored in a MySQL or PostgreSQL database. Version 1.1.0 adds the following features to Kea: * Additional Database Backend - Kea 1.1.0 has added preliminary support for Cassandra as a database backend. In this release of Kea it can only be used to store lease information, it is not able store host reservations. Cassandra support is currently considered experimental. Use with caution. * Host Reservations - Kea 1.0 contained limited support for storing host reservations in the database backend. Kea 1.1.0 has expanded that capability, allowing host reservations to be stored in a MySQL or PostgreSQL database. In particular, Kea 1.1.0: - Adds host reservation (DHCPv4 and DHCPv6) using the PostgreSQL backend. - Adds host reservation for DHCPv6 to the existing MySQL support. - Significantly extends the existing host reservation capabilities to include reservations of specific DHCP options, reservations of siaddr, sname, and file fields within DHCPv4 messages, and reservations of multiple IPv6 addresses/prefixes. - Allows the MySQL or PostgreSQL host reservation database to be configured read-only, in which case Kea will be able to retrieve reservations from it, but not insert or update existing reservations. This feature is useful when a database (or database view) exists for the particular deployment and the administrator doesn't want to grant read-write access for security reasons. * Client Classification - In Kea 1.1 the client classification system has been expanded. A class definition contains a name and a test expression of arbitrary complexity; if the test expression evaluates to "true" the client is a member of that class. A client may be a member of multiple classes and can acquire options from different classes. If the configuration contains multiple definitions for data for an option in two or more of the global, class, subnet or host entries, the server will choose the definition from the most specific entry. There are a number of objects and operators available for use in the test expression. - Operators include: equal, not, and, or, substring, concat - Objects include: - literals: string, hexadecimal, IP address and integer - options: existence and content - relay options for DHCPv4 and DHCPv6: existence and content - subfields within vendor and vendor class options: existence, enterprise-id value and content - selected fields from DHCPv4 and DHCPv6 packets - Classes may be used to select subnets - Classes and class specific subnets may contain option data to serve to clients within that class * Hook Library Parameters - It is now possible to specify parameters for hook libraries in the Kea configuration file. In earlier versions of Kea, hook library authors had to use a external mechanism (such as file of a known name) to pass information across. * DHCPv4-over-DHCPv6 - RFC7341 (https://tools.ietf.org/html/rfc7341) defines an architecture that allows dual-stack clients to communicate with DHCPv4 server in IPv6-only networks. Kea 1.1 introduces support for this mode of operation. It requires running both DHCPv4 and DHCPv6 servers in special mode, where DHCPv6 component does not allocate anything, but decapsulates incoming DHCPv4 messages, sends the to the DHCPv4 server and then relay back the responses. == License == Kea 1.1.0 has been released under the Mozilla Public License, version 2.0. https://www.mozilla.org/en-US/MPL/2.0 == Download == The Kea 1.1.0 source and PGP signatures may be downloaded from: http://www.isc.org/downloads/ The signature was generated with the ISC code signing key which is available at https://www.isc.org/about/openpgp ISC provides detailed documentation, including installation instructions and usage tutorials in the Kea Administrator Reference Manual. Documentation is included with the installation or via http://kea.isc.org/docs in HTML, plain text, or PDF formats. ISC maintains a public open source code tree at https://github.com/isc-projects/kea and wiki pages with roadmap and issue tracking at http://kea.isc.org. Limitations and known issues with this release can be
Re: [Kea-users] Install Kea DHCP in CentOS7
Hello, it looks like you dont have log4cplus package installed. Dependencies list you will find in User Guide in Section Build Requirements http://kea.isc.org/docs/kea-guide.html#build-requirements Wlodek. On 09/30/2016 01:39 PM, luke devon wrote: > checking log4cplus/logger.h usability... no > checking log4cplus/logger.h presence... no > checking for log4cplus/logger.h... no > configure: error: Missing required header files. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Cannot assign IPv6 addresses
Hello, sorry for delayed answer, did you managed to figure that out? You are not giving any specifics how are you doing it so this are the basic steps: 1. ./configure --with-gtest 2. make 3a. make check (to stop on first failure) 3b. make -k check (run all tests despite any occurring failure) Regards, Włodek Wencel On 09/10/2016 05:47 PM, Rui Pedro Caldeira wrote: > Perhaps you could help me with something else. I'm trying to replicate > your CI procedure in my on Jenkins. It seems fine however it does not > run the unit tests. Is there a way i can see the job configuration? ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
