Does static mapping work in kea DHCP?

wgstarks

I've seen the warnings about ISC being deprecated and thought I would switch to kea after updating to 23.09 but wanted to do a little research first. The problem is that the more I read the more confused I get. I use static mappings by MAC for most of my desktops/laptops and some post are stating that static mappings don't work in kea while other posts are saying that they will. Do they work?

I realize that this isn't critical yet and I don't need to switch right away but if I've got to figure out some other way to use static mappings I would like to start researching it.

SteveITS

@wgstarks Haven’t used it yet but https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#kea-dhcp-server-feature-preview-now-available doesn’t list that as unsupported. I suppose you can try and just switch back.

Patch

@wgstarks said in Does static mapping work in kea DHCP?:

I use static mappings by MAC for most of my desktops/laptops and some post are stating that static mappings

See this thread in particular
@jimp said in KEA DHCP - lacking features:

There is a bit of confusion above. Static mappings/"reservations" in Kea work. It's the DNS resolution/integration that does not work yet.

And yes there are several missing features yet but bear in mind a significant portion of users don't use all of the available features. Most just use the basic functionality

maverickws

@Patch I have probably a hundred or close to that static reservations/mappings and using the KEA DHCP backend, so far that part seems to be working just fine.

wgstarks

Another quote from the thread previously linked-
@RobbieTT said in KEA DHCP - lacking features:

@maverickws

Before it went live it was suggested that encouraging users to leave ISC for Kea was rather over done, considering its immaturity.

I did switch to Kea during the beta period and it was seamless with no apparent drawbacks but once I released some basics were missing and that it was relying on previous ISC managed data to function, had me switching back.

As I understand it, simple static mappings / reservations from Kea are not actually supported. However, it may give an illusion of functionality if you have run ISC previously. Existing mappings / reservations will still be resolvable as the hosts file still contains them as a hang-over from running ISC. Any new mappings added or modified will not be resolvable.

To me, the ability to set a static mapping / reservation is a basic cornerstone of networking. I think there will be a cascade of confusion as and when the previous hosts file becomes out-of-date.

️

From this it would seem that any reservations added after switching to kea will fail.

maverickws

@wgstarks I believe he is not talking about the reservations specifically, but the DNS resolution of those reservations:

Any new mappings added or modified will not be resolvable.

And I do confirm a couple of days after changing to KEA the resolution of local hosts stopped working. I added the relevant ones to the DNS resolver static mappings for now until this issue has been resolved.

wgstarks

@maverickws
If I add the mappings to DNS Resolver won't I also need to set a static address on each machine rather than the use DHCP setting I'm using now?

maverickws

@wgstarks ok so the static mappings on the DHCP Server work.
You can set them as usual on the DHCP Server - Static Mappings and your clients will get the assigned addresses.

But the issue and what happens right now is the DNS resolution for these mappings isn't working, so if you try to go only by the name you won't get nowhere.

Since you already have a mapping and you know that client is always getting that IP, by manually adding them to the DNS Resolver, it will help overcome this issue.

I am hoping in a next version it will be sorted and you won't need to have the static host overrides. It's just a temporary fix.

wgstarks

@maverickws
Ahhh ok, I think I understand now. So IP resolution will work fine (https://10.0.1.1) but name resolution (https://heimdall.local) will fail unless I use host override in DNS Resolver, right?

maverickws

@wgstarks yup exactly

Gertjan

@wgstarks said in Does static mapping work in kea DHCP?:

set a static address on each machine

Noop.
No need to touch any of your networked devices.
That is : every device that add to your network : take a picture of the sticker that mentions the MAC.
Then go to pfSense and make this list longer :

I just added the MAC of a new device, was using KEA (I made the switch this morning), and the device got the IPv4 I specified - outside the DHCPv4 pool.

So, again : leave all device on 'DHCP' - no need to set a network, DNS, gateway etc on every device.

For the IPv6 lovers :
I tend to say : note also the DUID ..... but I've never saw a sticker mentioning that one
So : DHCP logs came to the recsue : connect the device, and have it atributed an IPv6 out of the IPv6 pool, from the DHCPv6 server.
Copy paste the DUID under the DHCPv6 lan server settings.
The same procedure as what has been done with the MAC under IPv4.
And done : have your device reconnect (rip ouit the cable a moment) your device now reconnect, using the (GUA) IPv6 you wanted it to have (don't care about the "fe80::4904:ee61:c85e:3bb4%9(prefered)" as humans shouldn't use that one anyway.

About DNS :

When you add a item under

it will get added to this file /etc/hosts - please don't believe me, check for yourself :
Here is mine :

127.0.0.1	localhost localhost.bhf.tld
::1	localhost localhost.bhf.tld
192.168.1.1	pfSense.bhf.tld pfSense
2a01:cb19:9xx:a6dc:92ec:77ff:fe29:392c	pfSense.bhf.tld pfSense
192.168.1.2	bureau2.bhf.tld bureau2
192.168.1.3	TL-SG108E.bhf.tld TL-SG108E
192.168.1.4	poweredget310.bhf.tld poweredget310
192.168.1.6	gauche2.bhf.tld gauche2
192.168.1.7	droite.bhf.tld droite
192.168.1.8	dvr.bhf.tld dvr
192.168.1.11	bureau.bhf.tld bureau
192.168.1.16	ricoh.bhf.tld ricoh
192.168.1.17	clim.bhf.tld clim
192.168.1.18	liveradio.bhf.tld liveradio
192.168.1.23	kindle-f2051e0a8.bhf.tld kindle-f2051e0a8
.......

When unbound starts, pfSense will create a (var/unbound/)unbound.conf file.
This file contains :

...
# Static host entries
include: /var/unbound/host_entries.conf
....

The unbound pfSense startup code will create this file (/var/unbound/host_entries.conf) from the /etc/hosts file.

Please, have a look at your /var/unbound/host_entries.conf

So, yes, local "DHCP Static Mappings" entries will make local host names known.

Proof of concept - dvr is a host name of one of my devices on my LAN :

C:\Users\Gertjan>ping dvr

Envoi d’une requête 'ping' sur dvr.bhf.tld [2a01:cb19:9xx:a6dc::7f] avec 32 octets de données :
Réponse de 2a01:cb19:9xx:a6dc::7f : temps=1 ms
Réponse de 2a01:cb19:9xx:a6dc::7f : temps=1 ms
Réponse de 2a01:cb19:9xx:a6dc::7f : temps=2 ms
....

phormix

@wgstarks I've been finding that IP static mappings don't work properly either, if a dynamic address has already been assigned.

I had this issue with several IoT devices where I'd connect them to the network and then grab the MAC from they leases to add to a static entry, but after restarting they'd continue on with the same IP.
I thought this was an issue with the new firmware on those devices, but just today I had similar issues with a pi.

When connecting via wifi, I can even release the IP on the pi but the leases continue to show the IP as active (which means I cannot release) and a new request gets offered the same IP, with KEA ignoring the static mapping. Only way to get the static to work is to wait for the dynamic address to expire.

wgstarks

@phormix said in Does static mapping work in kea DHCP?:

Only way to get the static to work is to wait for the dynamic address to expire.

That’s what I’ve been doing too.

phormix

@wgstarks I just switched back to ISC. Of course now that means the warnings about it being deprecated are front-and-center but KEA just feels like it's still beta quality

SteveITS

@phormix said in Does static mapping work in kea DHCP?:

KEA just feels like it's still beta quality

I mean, it literally is? "feature preview"
https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#kea-dhcp-server-feature-preview-now-available

johnpoz

@phormix said in Does static mapping work in kea DHCP?:

the warnings about it being deprecated

Well turn if off if you want... Its right there where you switch..

I mean, it literally is? "feature preview"

Exactly and a "preview" is not even alpha level normally.. A preview is like a taste of what is to come, but the artist really hasn't even started the painting yet... It's like the first rough sketch..

Think of it like this.. Kea currently is left

if your a windows users, think of it as the "canary" channel would be my take if you run the preview builds.

edit: here was my test of kea;

Well it hands out an IP, that's cool
Wow they need to spend some time on the logging - its horrible! ;)
Back to ISC..

phormix

@johnpoz you can, but here's the thing:

Redhat6 is deprecated. Windows XP is deprecated. SSLv3 is deprecated.

What do all of these things have in common? Well you shouldn't be using them, there's a newer solution that provides essentially the same function, and you really shouldn't be using the old one.

If ISC DHCP is deprecated, but KEA doesn't fill that gap. Per the ISC's posting, it's essentially "hey, this does all we need it to do and we don't want to introduce instability with significant feature changes, if you want those use KEA, but we will keep an eye for significant flaws in the old code and still potentially fix those"

I'd say messages stating ISC DHCP is deprecated may be dropped are not a great look, at least until KEA is more stable and robust. A better message would be that ISC DHCP no longer offers new features, and users are encouraged to try KEA (with some notes that bugs are still being printed out). Pushing people towards an unstable or feature -poor product with alarmist messaging is never a good idea.

So yeah, back to ISC it is for now

johnpoz

@phormix

Not going to disagree that that wording could of been better..

Been a lot of threads where users fail to even read the release notes, and just click to switch because of the warning..

Like this one - nobody that read the release notes about all the stuff missing would think hey lets switch to kea now, unless they were running the most basic of setups with - hey hand out some IPs..

But on the other hand, most all the threads here are because someone fail to read the documentation in the first place ;)

SteveITS

@phormix
First off I agree the wording could have been way different. It came up here within days I think, and the answer was, essentially, ‘the note is correct, it will be removed, it doesn’t say anyone needs to use Kea.’ It’s led to unnecessary alarm, and confusion/frustration.

Redhat6 is deprecated. Windows XP is deprecated. SSLv3 is deprecated.

I’m going to nitpick a bit but I see it a lot. Those aren’t deprecated those are discontinued and unsupported. I think the word has shifted in meaning over the years in common speech from “will be removed” to “past EOL” to “has been removed,” and they are using the former, original meaning. I tried to look it up to be specific and the definition seems to vary quite a bit around/between those.

If it was replaced they would replace it.

johnpoz

@SteveITS exactly.. Deprecated does not mean - hey stop using this, it no longer works, or there is a serious exploit ;)