[Kea-users] Kea MySQL & Advanced Features Requirements

[JT ISC]

I have a question regarding Kea with MySQL and other advanced features.

Is the only way to get most of the features of Kea, such as MySQL features
and other advanced features, is to build/install from source, correct?

The pre-built Kea packages don't allow MySQL and the other advanced
features, correct?

Thanks!
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Kea System Requirements

[JT ISC]

What are the system requirements for Kea?

4 GB RAM and 100GB HD adequate?

Thanks
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Kea Upgrade Question

[JT ISC]

Hello,

I might be overlooking the documentation somewhere, but I wanted to be sure.

I have been running Kea 2.0.1.  Can you directly upgrade from Kea 2.0.1 to
2.2.0?  Or is there an upgrade path that you have to perform?

Thank you in advance!
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Disable multicast Listening

[s k]

Hi
Is there a way to stop Kea from listening on multicast address  , since our set 
up only uses relay forwarding to request for ip which is point to point. when i 
enable listening on global interface by default kea listens on multicast 
address and the number of requests received  over multicast is overwhelming .
Thanks
skumar


-- 
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] Monitoring a Kea cluster

[Marek Greško via Kea-users]

Hello,

I was observing similar issues. I currently workarounded it by setting:

"service-sockets-require-all": false,
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1

I am not sure the workaround is good enough, but I did not observe such 
problems since setting these parameters. Hope it will fix it forever. Without 
the first line kea exited when interfaces were not up, if I remember well, and 
the other two lines keeps retrying to listen the interfaces which will come up 
later. Without them kea ceases listening on those interfaces not being up at 
the moment.

I also do not understand why such tweaking is needed. If I configure kea to 
listen on an interface I expect it to respond on it any time it comes up. Very 
weird software.

Marek





Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, January 3rd, 2023 at 9:20, Stefan G. Weichinger  
wrote:


> Am 27.12.22 um 12:46 schrieb Darren Ankney:
> 
> > In any case, I’d be concerned why it was running but not answering
> > requests more-so than I would be about how to monitor it using actual
> > DHCP. I vaguely remember having some trouble with Kea and systemd
> > startup ordering (ie: it started up before the server’s IP was on the
> > interface). Setting After=network.target took care of it.
> 
> 
> We saw the behavior again yesterday: no DHCP leases after a reboot until
> we restarted kea.
> 
> In the service file there are these lines:
> 
> Wants=network-online.target
> After=network-online.target
> After=time-sync.target
> 
> https://systemd.io/NETWORK_ONLINE/ gives some information about these
> targets ... "network-online.target" should fit better .. but doesn't
> seem to be enough.
> 
> We use raw sockets for kea, but the server listens on multiple
> vlan-interfaces:
> 
> {
> "Dhcp4": {
> "interfaces-config": {
> "interfaces": [ "enp0s31f6", "enp0s31f6.101",
> "enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ],
> "dhcp-socket-type": "raw"
> },
> 
> 
> --
> 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] Monitoring a Kea cluster

[Dan Oachs]

I am not using firewalld, just direct iptables and ip6tables config files.

--Dan


On Tue, Jan 3, 2023 at 9:52 AM Eric Graham 
wrote:

> Dan,
>
> Would you be wlling to dump your iptables filter and nat tables before and
> after the restart and take a diff? Are you using firewalld on top of
> iptables, by chance? I've been running into issues with my firewall
> completely breaking when switching the backend of firewalld from nftables
> to iptables, but I suspect that's an entirely different issue.
>
> I do want to add that the article Stefan linked does mention that the
> network being "up" varies in definition. I know that I have needed to write
> retries into some of my own services that require that target, because the
> network might be "up" and DNS still might not resolve, pings fail, etc.
>
> *Eric Graham*
> *DevOps Specialist*
> Direct: 605.990.1859
> eric.gra...@vantagepnt.com 
>
> --
> *From:* Kea-users  on behalf of Dan
> Oachs 
> *Sent:* Tuesday, January 3, 2023 9:25 AM
> *To:* Stefan G. Weichinger 
> *Cc:* kea-users@lists.isc.org 
> *Subject:* Re: [Kea-users] Monitoring a Kea cluster
>
> *CAUTION:* This email originated outside the organization. Do not click
> any links or attachments unless you have verified the sender.
> I have noticed something similar with our Kea servers.
>
> Running Kea 2.0.3 on Rocky Linux 8.7
>
> After a server reboot dhcpv6 is running but not handing out leases.
> There is some issue with the way things start up and the firewall blocking
> packets.  My current workaround is to add a few lines in /etc/rc.local to
> stop ip6tables, restart kea-dhcp6, then start ip6tables.
>
> I'm sure there is a correct way to fix this, but the workaround is
> functional for me at the moment.
>
> --Dan
>
>
> On Tue, Jan 3, 2023 at 2:20 AM Stefan G. Weichinger 
> wrote:
>
> Am 27.12.22 um 12:46 schrieb Darren Ankney:
>
> > In any case, I’d be concerned why it was running but not answering
> > requests more-so than I would be about how to monitor it using actual
> > DHCP.  I vaguely remember having some trouble with Kea and systemd
> > startup ordering (ie: it started up before the server’s IP was on the
> > interface).  Setting After=network.target took care of it.
>
> We saw the behavior again yesterday: no DHCP leases after a reboot until
> we restarted kea.
>
> In the service file there are these lines:
>
> Wants=network-online.target
> After=network-online.target
> After=time-sync.target
>
> https://systemd.io/NETWORK_ONLINE/ gives some information about these
> targets ... "network-online.target" should fit better .. but doesn't
> seem to be enough.
>
> We use raw sockets for kea, but the server listens on multiple
> vlan-interfaces:
>
> {
>  "Dhcp4": {
>  "interfaces-config": {
>  "interfaces": [ "enp0s31f6", "enp0s31f6.101",
> "enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ],
>  "dhcp-socket-type": "raw"
>  },
>
>
> --
> 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] Monitoring a Kea cluster

[Eric Graham]

Dan,

Would you be wlling to dump your iptables filter and nat tables before and 
after the restart and take a diff? Are you using firewalld on top of iptables, 
by chance? I've been running into issues with my firewall completely breaking 
when switching the backend of firewalld from nftables to iptables, but I 
suspect that's an entirely different issue.

I do want to add that the article Stefan linked does mention that the network 
being "up" varies in definition. I know that I have needed to write retries 
into some of my own services that require that target, because the network 
might be "up" and DNS still might not resolve, pings fail, etc.

Eric Graham
DevOps Specialist
Direct: 605.990.1859
eric.gra...@vantagepnt.com
[cid:84533300-07c9-4b03-bc38-f6466c9a8866]

From: Kea-users  on behalf of Dan Oachs 

Sent: Tuesday, January 3, 2023 9:25 AM
To: Stefan G. Weichinger 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] Monitoring a Kea cluster

CAUTION: This email originated outside the organization. Do not click any links 
or attachments unless you have verified the sender.
I have noticed something similar with our Kea servers.

Running Kea 2.0.3 on Rocky Linux 8.7

After a server reboot dhcpv6 is running but not handing out leases.   There is 
some issue with the way things start up and the firewall blocking packets.  My 
current workaround is to add a few lines in /etc/rc.local to stop ip6tables, 
restart kea-dhcp6, then start ip6tables.

I'm sure there is a correct way to fix this, but the workaround is functional 
for me at the moment.

--Dan


On Tue, Jan 3, 2023 at 2:20 AM Stefan G. Weichinger 
mailto:li...@xunil.at>> wrote:
Am 27.12.22 um 12:46 schrieb Darren Ankney:

> In any case, I’d be concerned why it was running but not answering
> requests more-so than I would be about how to monitor it using actual
> DHCP.  I vaguely remember having some trouble with Kea and systemd
> startup ordering (ie: it started up before the server’s IP was on the
> interface).  Setting After=network.target took care of it.

We saw the behavior again yesterday: no DHCP leases after a reboot until
we restarted kea.

In the service file there are these lines:

Wants=network-online.target
After=network-online.target
After=time-sync.target

https://systemd.io/NETWORK_ONLINE/ gives some information about these
targets ... "network-online.target" should fit better .. but doesn't
seem to be enough.

We use raw sockets for kea, but the server listens on multiple
vlan-interfaces:

{
 "Dhcp4": {
 "interfaces-config": {
 "interfaces": [ "enp0s31f6", "enp0s31f6.101",
"enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ],
 "dhcp-socket-type": "raw"
 },


--
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] Monitoring a Kea cluster

[Dan Oachs]

I have noticed something similar with our Kea servers.

Running Kea 2.0.3 on Rocky Linux 8.7

After a server reboot dhcpv6 is running but not handing out leases.   There
is some issue with the way things start up and the firewall blocking
packets.  My current workaround is to add a few lines in /etc/rc.local to
stop ip6tables, restart kea-dhcp6, then start ip6tables.

I'm sure there is a correct way to fix this, but the workaround is
functional for me at the moment.

--Dan


On Tue, Jan 3, 2023 at 2:20 AM Stefan G. Weichinger  wrote:

> Am 27.12.22 um 12:46 schrieb Darren Ankney:
>
> > In any case, I’d be concerned why it was running but not answering
> > requests more-so than I would be about how to monitor it using actual
> > DHCP.  I vaguely remember having some trouble with Kea and systemd
> > startup ordering (ie: it started up before the server’s IP was on the
> > interface).  Setting After=network.target took care of it.
>
> We saw the behavior again yesterday: no DHCP leases after a reboot until
> we restarted kea.
>
> In the service file there are these lines:
>
> Wants=network-online.target
> After=network-online.target
> After=time-sync.target
>
> https://systemd.io/NETWORK_ONLINE/ gives some information about these
> targets ... "network-online.target" should fit better .. but doesn't
> seem to be enough.
>
> We use raw sockets for kea, but the server listens on multiple
> vlan-interfaces:
>
> {
>  "Dhcp4": {
>  "interfaces-config": {
>  "interfaces": [ "enp0s31f6", "enp0s31f6.101",
> "enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ],
>  "dhcp-socket-type": "raw"
>  },
>
>
> --
> 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] Monitoring a Kea cluster

[Darren Ankney]

Was this after a reboot or Kea just suddenly stopped responding during normal 
operation?

Was there nothing in logs? 

1) perhaps consider some retry options: 
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#interface-configuration
 "service-sockets-max-retries” and “service-sockets-retry-wait-time”.  These 
settings cause kea to not immediately give up in the event the interfaces 
aren’t available when it starts.

2) If there was nothing in logs, you may need to consider setting up additional 
loggers and/or turning up severity.  The chart here: 
https://kea.readthedocs.io/en/kea-2.2.0/arm/logging.html?highlight=logging#id3 
shows a list of available loggers and what they log.  You may need to look at 
the system logs if it isn’t getting far enough to read your loggers statement.  
I personally like to set up a separate file for each logger name so that I can 
control log severity and look at things individually.  Example (not exhaustive):

"loggers": [
{
"name": "kea-dhcp4",
"severity": "INFO",
"output_options": [
{
"output": "/usr/local/var/log/kea-dhcp4.log",
"maxver": 10,
"flush": false
}
]
},
{
"name": "kea-dhcp4.packets",
"severity": "DEBUG",
"debuglevel": 98,
"output_options": [
{
"output": "/usr/local/var/log/kea-dhcp4-packets.log",
"maxver": 10,
"flush": false
}
]
},
{
"name": "kea-dhcp4.alloc-engine",
"severity": "INFO",
"output_options": [
{
"output": 
"/usr/local/var/log/kea-dhcp4-alloc-engine.log",
"maxver": 10,
"flush": false
}
]
},


3) you might change “Wants=“ to “Requires=“ as apparently “Wants=“ will let the 
kea service still start even if the network-online.target hasn’t properly 
started.  Though you might be better served by #1 above.

> On Jan 3, 2023, at 3:20 AM, Stefan G. Weichinger  wrote:
> 
> Am 27.12.22 um 12:46 schrieb Darren Ankney:
> 
>> In any case, I’d be concerned why it was running but not answering requests 
>> more-so than I would be about how to monitor it using actual DHCP.  I 
>> vaguely remember having some trouble with Kea and systemd startup ordering 
>> (ie: it started up before the server’s IP was on the interface).  Setting 
>> After=network.target took care of it.
> 
> We saw the behavior again yesterday: no DHCP leases after a reboot until we 
> restarted kea.
> 
> In the service file there are these lines:
> 
> Wants=network-online.target
> After=network-online.target
> After=time-sync.target
> 
> https://systemd.io/NETWORK_ONLINE/ gives some information about these targets 
> ... "network-online.target" should fit better .. but doesn't seem to be 
> enough.
> 
> We use raw sockets for kea, but the server listens on multiple 
> vlan-interfaces:
> 
> {
>"Dhcp4": {
>"interfaces-config": {
>"interfaces": [ "enp0s31f6", "enp0s31f6.101", 
> "enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ],
>"dhcp-socket-type": "raw"
>},
> 
> 
> -- 
> 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] Monitoring a Kea cluster

[Stefan G. Weichinger]

Am 27.12.22 um 12:46 schrieb Darren Ankney:

In any case, I’d be concerned why it was running but not answering 
requests more-so than I would be about how to monitor it using actual 
DHCP.  I vaguely remember having some trouble with Kea and systemd 
startup ordering (ie: it started up before the server’s IP was on the 
interface).  Setting After=network.target took care of it.


We saw the behavior again yesterday: no DHCP leases after a reboot until 
we restarted kea.


In the service file there are these lines:

Wants=network-online.target
After=network-online.target
After=time-sync.target

https://systemd.io/NETWORK_ONLINE/ gives some information about these 
targets ... "network-online.target" should fit better .. but doesn't 
seem to be enough.


We use raw sockets for kea, but the server listens on multiple 
vlan-interfaces:


{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "enp0s31f6", "enp0s31f6.101", 
"enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ],

"dhcp-socket-type": "raw"
},


--
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