[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.Graham at vantagepnt.com<mailto:eric.graham at vantagepnt.com>
[cid:84533300-07c9-4b03-bc38-f6466c9a8866]
________________________________
From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Dan Oachs <doachs at gac.edu>
Sent: Tuesday, January 3, 2023 9:25 AM
To: Stefan G. Weichinger <lists at xunil.at>
Cc: kea-users at lists.isc.org <kea-users at 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 <lists at xunil.at<mailto:lists at 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 at lists.isc.org<mailto:Kea-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/kea-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230103/4ffd50b0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-pqvlao05.png
Type: image/png
Size: 16388 bytes
Desc: Outlook-pqvlao05.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230103/4ffd50b0/attachment-0001.png>