[Kea-users] Monitoring a Kea cluster

[Darren Ankney]

What we did, 20+ years ago, was implement a rudimentary DHCPv4 client in perl as a module for the monitoring software we use.  We only implemented “renew” functionality.  On all of the DHCP servers that we wanted to monitor, we had the subnet of the monitoring cluster configured as a pool.  Then the monitoring system would “renew” its own address at each polling period.  This seemed to work ok for years.  

If you are talking DHCPv6, there were some details that prevented doing a similar thing.  I don’t remember what they were.  I think maybe RFC 8415 doesn’t specify that the server may accept a “renewal” of an address for which it has no record of a lease the way RFC 2131 does or maybe it could be done and we just didn’t look hard enough.

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.

I suspect I had that trouble because I am using “udp” socket type rather than raw.

"interfaces-config": {
            "interfaces": [
                "eno1"
            ],
            "dhcp-socket-type": "udp",
            "service-sockets-max-retries": 60,
            "service-sockets-retry-wait-time": 5000
        },

I believe it creates sockets on the actual interface IPs with udp socket type, so it seems that if the IPs aren’t there at the time it starts, it won’t listen on them:

$ netstat -ln | grep :67
udp        0      0 192.168.40.182:67       0.0.0.0:*                          
udp        0      0 192.168.40.142:67       0.0.0.0:*                          
udp        0      0 192.168.40.82:67        0.0.0.0:*                          
udp        0      0 192.168.40.42:67        0.0.0.0:*                          
udp        0      0 192.168.40.2:67         0.0.0.0:* 

Not sure how any of that applies if you are not specifying “udp” socket type.  There could be some other startup problem as well.  The logs should tell the tale. If there is nothing in the logs about it, you may need to add additional log types or turn up severity.  Full documentation of logging in Kea is here: https://kea.readthedocs.io/en/kea-2.2.0/arm/logging.html


> On Dec 27, 2022, at 1:10 AM, Stefan G. Weichinger <lists at xunil.at> wrote:
> 
> 
> As I upgraded my isc-kea cluster to Debian 11.6 last week and rebooted the 2 nodes we noticed that initially there were no DHCP-leases offered until I restarted the isc-kea-dhcp4 service (on the primary node of the cluster).
> 
> Maybe a one time issue, I don't know.
> 
> -
> 
> In consequence I´d like to monitor the DHCP-services somehow.
> 
> I don't run a "real" monitoring like Nagios or Icinga at that site, but use "monit" for basic monitoring ...
> 
> I added a check to monitor the isc-kea-dhcp4 service itself: does it run, does it behave, if not, restart it.
> 
> And I added a check to monitor the timestamp of the leases file: if not changed for N minutes, alert me.
> 
> That is very basic and not even fully OK IMO: the leases file gets rotated ... etc etc
> 
> I browsed for a check tool and found "dhcping". So far I wasn't able to get a working reply out of that tool :-( ...
> 
> How do you monitor Kea, are there any recommended ways of doing that?
> -- 
> 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
> https://lists.isc.org/mailman/listinfo/kea-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20221227/65792cba/attachment.htm>