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<mailto:eric.gra...@vantagepnt.com> [cid:84533300-07c9-4b03-bc38-f6466c9a8866] ________________________________ From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Dan Oachs <doa...@gac.edu> Sent: Tuesday, January 3, 2023 9:25 AM To: Stefan G. Weichinger <li...@xunil.at> Cc: kea-users@lists.isc.org <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 <li...@xunil.at<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<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
