KeaDHCP dynamic DHCP question

[meyergru]

I thought you meant DHCPv6 because of the DUID discussion. As to your questions:

1. I wrote that: Stop the Kea service, delete all entries from /var/db/kea-leases4.csv* or delete the files, start Kea again.
2. I told you how DHCP works in general: If a legitimate client asks for an IP, the DHCP server uses a presumably "free" tentative address from the pool and pings it. If it gets back an answer, it knows it cannot use that IP and uses the next free one from the pool. So if "something" makes "someone" reply to pings, this effect would ensue.


Note that I only know these things for sure:

a. I have seen ping replies for all IPs on my network when I had the host discovery service enabled. I cannot reliably reproduce that behavior, if I could, I would have done a bug report on Github.

b. I know that ISC DHCP works like I said in point 1. I do not know if Kea works the same or if it actually registers such tentative IPs as taken in its database, but my educated guess from your observations seem to indicate that. Also: how should it prevent using an already-dismissed IP otherwise?

P.S.: Going back to 26.1.3 or any 26.1.x version will not fix that problem (if that is the case), because the host discovery service was introduced with that. The only remedy if the host discovery service is the culprit would be to disable it - which I did shortly after I discovered the ping problems.

[stauf]

If you click on Interfaces: Neighbors, there is a tab for "Discovered Hosts".  One of the 40 addresses in my pool exists in this table but it is the one that is correct/functioning.  The rest of these DHCP entries (the ones in the pool and the ones not in the pool), none of these are in this Discovered Hosts table.  While this seems like a plausible theory, the fact that none are in this table makes me feel like that is not my issue.

[stauf]

In /var/db/kea/ there are two files on my router.  kea-leases4.csv does not contain any of these bogus entries.  There is also a kea-leases4.csv.2 which does contain these entries.  Again, no MAC, no hostname:

192.168.6.17,,,86400,1774014491,1,0,0,,1,,0
192.168.6.18,,,86400,1774014501,1,0,0,,1,,0
192.168.6.19,,,86400,1774014511,1,0,0,,1,,0
192.168.6.20,,,86400,1774014521,1,0,0,,1,,0
192.168.6.21,,,86400,1774014531,1,0,0,,1,,0
192.168.6.22,,,86400,1774014541,1,0,0,,1,,0

I will try moving this file in off hours.  See if that helps.

[meyergru]

I did not say that the host discovery service erroneously detects all hosts.

I think (but cannot reproduce) that the mere active service causes ping responses for any IP "somehow" and "sometimes" (I know that sounds strange given that I cannot reproduce this, but have seen it happen more than once). This alone lets DHCP think the IPs are active.

That has nothing to do with what the host discovery service detects. It works via ARP and NDP, supposedly, but I have not looked into it.

I repeat: If you want to rule this out, you should disable that specific service. Of course, the adresses can onyl be resused once they time out or are beig deleted. None of this has to be taken off-hours, because no step in it will cause service disruption of more than a few seconds - and above all, your DHCP cannot hand out IPs at this time, anyway.

If you leave the host discovery service running and I am right, the deleted IPs will get reserved again. Probaby, you do not need it - before 26.1., it did not exist.

[Monviech (Cedrik)]

The GUI collects from all lease files

https://github.com/opnsense/core/blob/faf1562b1c2999106d59b016433f4fa80a8ab302/src/opnsense/scripts/kea/get_kea_leases.py#L58

Its not always entirely clear which file contains leases that are actually truthy an in memory at the current moment.

(KEA documents how things should be, but experience while developing KEA features for OPNsense show that things are weird sometimes)

[nero355]

Is there a mechanism to clean out v4 leases?

I believe there was some talk on the forum about adding such a feature to the KEA webGUI part of OPNsense :)

And printers for several decades now, use SSDP | Bonjour mDNS protocol to advertise their IP address and service information, and modern OS also learn from both SSDP and mDNS propagation advertisements, to dynamically learn printer IP address and service to connect to.

Which is horrible and luckily can be disabled via the webGUI of my printer to avoid unnecessary Multicast traffic ;)

And everything works just fine without it too! LOL!

[stauf]

Right, I agree.  While having the "Affinity lifetime" is nice, but for me personally, it has zero relevance to my desire to use Reservations.  My "need" for reservations is partly my brain (I am a person that remembers numbers and I want to define the addresses my devices are using) and party for hosts like Proxmox.  It wants a static address defined and does not want to use DHCP (even if the back end of DHCP would always send a consistent IP).  So what I do is setup a reservation that is essentially never used.  Proxmox uses the address statically and since KeaDHCP is setup with a reservation, it doesn't doll out that address to anyone else (at least it shouldn't).  I suppose I could create another subnet for hosts that have static IP addresses and just not have DHCP running, but my current strategy has always worked, so why complicate things further?

I noticed that even with "Automatic Discovery" disabled, these erroneous DHCP entries refreshed themselves after the 24 hour lifetime expired.  So I decided to go in and delete them manually.  I stopped KeaDHCP, manually removed these entries from the kea-leases4.csv.2 file and re-started KeaDHCP.  The addresses disappeared and the one Proxmox server (I have 4) that was not working is now accessible.

However, now I am noticing something strange starting again.  I have 2 deployed containers on this proxmox server.  Nothing I "need", just playing around.  One is bentopdf, which allows for PDF editing and the other is ConvertX, which does file format conversions.  I've used both of these containers multiple times and they have been great.  They have worked and were accessible from the single IP address they are configured for.  For some reason, KeaDHCP is now adding all sorts of entries for these two containers.  What is really strange is that it is adding two entries for each IP address, one, like before, has a lifetime of 86400 seconds, no MAC address and no hostname and claims to be dynamic.  The other is a static entry (which I don't have defined), but is mapped to the same IP address.  At this point, I am not quite sure what to do short of starting to do some wireshark traces when I bounce KeaDHCP.  These containers are set for a single IP address yet KeaDHCP seems to think they are configured for all sorts of addresses.  If I ping any of the address KeaDHCP thinks are associated with that container, nothing responds (as expected).  I have no idea how KeaDHCP could be filling these entries in.

I suppose the good news is that I can stop KeaDHCP and manually edit these csv files in /var/db/kea/ and blow away these erroneous entries.  When I have time, I will try to get a Packet Capture after resetting KeaDHCP and see if I can find any DHCP requests that would account for this behavior.