Hi John, > Well, it appears that I have been on a fool's errand. What I WANT is > reservation matches by "hostname" which I am now pretty sure that kea does > not do.
That is correct. Kea will not match reservation based on option 12 (host-name) (see here: https://www.rfc-editor.org/rfc/rfc2132#section-3.14). The only reservation identifiers supported (by kea-dhcp4) are: hw-address, duid, client-id, and circuit-id > I analyzed the leases file (where kea apparently puts reservations as well as > pool leases, fortunately for my analysis) and in ALL cases where the client > provided a client-id, it was "01:" prefixed to the MAC address. A couple of things here. client-id is a specific dhcp option: "dhcp-client-identifier" option 61. This option could contain something else but, most of the time, contains the mac address of the client, or isn't present at all (see here: https://www.rfc-editor.org/rfc/rfc2132#section-9.14). The leases file now contains a lease for reserved ip addresses. It is true that in ISC DHCP, there were no lease kept for a "fixed-address". Kea creates leases for all cases. So it isn't so much keeping the reservation in this file as it is keeping a lease. Clients who have not obtained their reserved address will not appear in this file. Thank you, Darren Ankney On Fri, Feb 14, 2025 at 5:28 PM John Lind <steinhel...@gmail.com> wrote: > > Well, it appears that I have been on a fool's errand. What I WANT is > reservation matches by "hostname" which I am now pretty sure that kea does > not do. I analyzed the leases file (where kea apparently puts reservations > as well as pool leases, fortunately for my analysis) and in ALL cases where > the client provided a client-id, it was "01:" prefixed to the MAC address. > Well, if I have the MAC address, I might as well use hw-address! Also, if I > want a reserved IP address to "follow" a device regardless of its interface, > it makes life more complicated. I can mitigate this slightly by using > > "ip-reservations-unique": false, > > but that doesn't entirely do what I want. > > The implications for me are > 1) when I get a device that doesn't have the MAC address in human-readable > form that I want to assign to a reserved address, I will have to connect it > to the network, search the leases file for the hostname, grab the MAC address > out of that, make the reservation, and restart kea, and possibly restart the > device, as well. > 2) when I have a device with multiple connection options (WiFi, built-in > ethernet, USB dongle Ethernet), if I want it to get the same IP address > regardless of which connection method it uses, I'll have to include all > possible MAC values it might use, and in some cases, when I'm moving a USB > dongle from one device to another, I'll have to modify the configuration file > rather than having the IP address "follow" the device from one connection > method to another, and NOT follow the MAC address from one device to another. > > So if I include reservations for all the MAC addresses a device might use, > and if I move the USB dongle from one device to another, my dedicated IP > address will follow it, which is NOT what I want to happen. I'll have to > modify the config file and restart kea to avoid that which is a nuisance and > likely to be forgotten. > > But at least I can quit chasing my tail looking for functionality which does > not appear to exist. > > > On Fri, Feb 14, 2025 at 4:16 AM Darren Ankney <darren.ank...@gmail.com> wrote: >> >> Hi John, >> >> Good to hear things are working. >> >> > Note - you cannot have both the client-id and the "hw-address" in the same >> > reservation. The documentation claims that these are hierarchical with >> > client-id above "chaddr" (which I assume to be the "hw-address" in this >> > context) but if you can't have both of them, that's not much use. >> >> The hierarchical nature of these is for performance. >> "host-reservation-identifiers" allows you to tune which and in what >> order the possible identifiers (hw-address, duid, client-id, >> circuit-id) are checked (and if they are checked at all). You would >> remove the ones from the list that will never identify a reservation >> in your environment. You would put the one first that is most likely >> to identify a reservation. This does not allow you to have multiple >> identifiers in the same reservation. You can have multiple >> reservations for the same IP address, however (see here: >> https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#multiple-reservations-for-the-same-ip), >> which would let you achieve what you are trying to achieve I think. >> >> Thank you, >> Darren Ankney >> >> On Thu, Feb 13, 2025 at 5:51 PM John Lind <steinhel...@gmail.com> wrote: >> > >> > Ok. I'm up and running on kea-dhcp4, but it wasn't painless. My >> > reservations by hw-address all worked, but that's all. >> > >> > 1) it seems to have paid no attention to the leases I tried to import. It >> > started over assigning the first address from the pool. If I had >> > remembered to shorten the timeout/refresh before hand, that would have >> > made things a bit less painful and confusing. Immediately upon starting >> > it logged "2025-02-13 15:30:15.717 WARN >> > [kea-dhcp4.dhcpsrv/35513.0x3f7aad812000] >> > DHCPSRV_MEMFILE_CONVERTING_LEASE_FILES running LFC now to convert lease >> > files to the current schema: 3.0" and it didn't complain, but it doesn't >> > appear to have paid any attention to them, either. Every pool lease I >> > have looked at has changed. >> > 2) The client-id format of "'casper'" didn't match. I thought I had tried >> > another host with only the double quotes and not the single quotes, but I >> > guess I didn't. I'm not sure how much I want to keep playing with that, >> > or just bite the bullet and use all hw-addr. Note - you cannot have both >> > the client-id and the "hw-address" in the same reservation. The >> > documentation claims that these are hierarchical with client-id above >> > "chaddr" (which I assume to be the "hw-address" in this context) but if >> > you can't have both of them, that's not much use. >> > >> > On Sun, Feb 9, 2025 at 4:47 PM John Lind <steinhel...@gmail.com> wrote: >> >> >> >> Oops. First let me apologize for an extra layer of complexity and >> >> confusion. I started out with the entries for the system "twister" >> >> because it wasn't currently available and I didn't have to worry about >> >> corrupting its entries. Then when I got to the point that I wanted to be >> >> able to try stuff out, I switched to "bringebaer". There are no entries >> >> that need to mix these two strings - they should all be one or the other. >> >> >> >> So - I tried this out: >> >> "reservations-global": true, >> >> "reservations": [ >> >> { >> >> "hostname": "bringebaer", >> >> "ip-address": "192.168.1.57", >> >> "client-id": "'bringebaer'" >> >> } >> >> ] >> >> >> >> So - then I did the syntax check: >> >> >> >> root@remo:/home/john/xfer # !kea >> >> kea-dhcp4 -t kea-head.conf >> >> 2025-02-09 16:39:51.055 INFO [kea-dhcp4.hosts/3198.0x2cae30212000] >> >> HOSTS_BACKENDS_REGISTERED the following host backend types are available: >> >> 2025-02-09 16:39:51.088 WARN [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] >> >> DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when >> >> multi-threading is enabled. >> >> 2025-02-09 16:39:51.088 WARN [kea-dhcp4.dhcp4/3198.0x2cae30212000] >> >> DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and >> >> host reservations lookup is always performed first. >> >> 2025-02-09 16:39:51.101 INFO [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] >> >> DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: >> >> 192.168.1.0/24 with params: valid-lifetime=2592000 >> >> 2025-02-09 16:39:51.125 INFO [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] >> >> DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw >> >> 2025-02-09 16:39:51.127 INFO [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] >> >> DHCPSRV_CFGMGR_ADD_IFACE listening on interface ue0 >> >> 2025-02-09 16:39:51.128 INFO [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] >> >> DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , >> >> using default socket type raw >> >> >> >> No errors! Tomorrow I'll have to munge all the entries and try it out. >> >> >> >> Thank you! >> >> >> >> On Sun, Feb 9, 2025 at 4:38 AM Darren Ankney <darren.ank...@gmail.com> >> >> wrote: >> >>> >> >>> Hi John, >> >>> >> >>> That is really interesting that this: >> >>> >> >>> host bringebaer { fixed-address bringebaer.starfire.mn.org; >> >>> option dhcp-client-identifier "bringebaer"; >> >>> } >> >>> >> >>> somehow matches the client-identifier >> >>> (https://www.rfc-editor.org/rfc/rfc2132#section-9.14). ISC DHCP man >> >>> page does say that you can match the dhcp-client-identifier option in >> >>> a host object: >> >>> https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpd#the-host-object >> >>> Kea can too >> >>> (https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation): >> >>> >> >>> "Kea currently supports four types of identifiers: hw-address, duid, >> >>> client-id, and circuit-id." >> >>> >> >>> Perhaps this: >> >>> >> >>> { >> >>> "hostname": "bringebaer", >> >>> "ip-address": "192.168.1.57", >> >>> "client-id": "'twister'" >> >>> }, >> >>> >> >>> (note the single quotes around twister inside the double quotes) but >> >>> you might want to perform a packet capture to confirm that your client >> >>> actually has a hostname in the client-id field. I've not seen that >> >>> previously. Option 61 normally isn't present at all or contains the >> >>> mac address. But if this was working in ISC DHCP perhaps these are >> >>> some devices I've not paid attention to before. >> >>> >> >>> Thank you, >> >>> Darren Ankney >> >>> >> >>> On Sat, Feb 8, 2025 at 3:34 PM John Lind <steinhel...@gmail.com> wrote: >> >>> > >> >>> > I apologize - there's a typo in the subject line. It should be >> >>> > dhcp-client-identifier (with an "r" at the end, not a "d'). >> >>> > >> >>> > Anyway, I tried running "kea-dhcp4 -t" on one of these files and got >> >>> > this back: >> >>> > 2025-02-08 14:18:27.503 ERROR [kea-dhcp4.dhcp4/94820.0x50554e412000] >> >>> > DHCP4_PARSER_FAIL failed to create or run parser for configuration >> >>> > element reservations: one of the supported identifiers must be >> >>> > specified for host reservation: circuit-id, client-id, duid, flex-id, >> >>> > hw-address (kea-head.conf:135:7) >> >>> > Error encountered: one of the supported identifiers must be specified >> >>> > for host reservation: circuit-id, client-id, duid, flex-id, hw-address >> >>> > (kea-head.conf:135:7) >> >>> > So - I don't see anything in that list that would correspond to what >> >>> > I've been doing with ISC-dhcp. I tried making up the syntax for client >> >>> > ID, and it didn't like that, either... >> >>> > { >> >>> > "hostname": "bringebaer", >> >>> > "ip-address": "192.168.1.57", >> >>> > "client-id": "twister" >> >>> > }, >> >>> > And the parser said: >> >>> > >> >>> > 2025-02-08 14:32:29.031 ERROR [kea-dhcp4.dhcp4/94837.0x5775ffa12000] >> >>> > DHCP4_PARSER_FAIL failed to create or run parser for configuration >> >>> > element reservations: invalid host identifier value 'twister' >> >>> > (kea-head.conf:135:7) >> >>> > Error encountered: invalid host identifier value 'twister' >> >>> > (kea-head.conf:135:7) >> >>> > >> >>> > >> >>> > On Sat, Feb 8, 2025 at 12:50 PM John Lind <steinhel...@gmail.com> >> >>> > wrote: >> >>> >> >> >>> >> Hey, all. I've spent hours watching recorded webinars, reading >> >>> >> documentation, and doing web searches in vain to try to figure out >> >>> >> how to get these reservations to work in kea. >> >>> >> >> >>> >> For some of my devices / systems I like to use a value sent by the >> >>> >> client rather than the hardware address to match them to a >> >>> >> reservation. This is especially useful in two cases >> >>> >> 1) when I don't know the MAC address >> >>> >> 2) when a device has different ways of connecting to my network (WiFi >> >>> >> versus hardwired, and maybe different ethernet ports) but I want it >> >>> >> to get the same IP address regardless of how it connects. >> >>> >> >> >>> >> For reference, here's how the values appear in the ISC dhcp leases >> >>> >> file when there's not a reservation (yet). >> >>> >> >> >>> >> client-hostname "MyQ-5C9"; >> >>> >> client-hostname "casper"; >> >>> >> client-hostname "StreamingStick4K-ET5"; >> >>> >> client-hostname "Pixel-6a"; >> >>> >> client-hostname "Paige-s-S23-Ultra"; >> >>> >> client-hostname "Milea-s-S20-FE"; >> >>> >> client-hostname "DESKTOP-7424SLE"; >> >>> >> client-hostname "Pixel-8-Pro"; >> >>> >> client-hostname "Pixel-7a"; >> >>> >> >> >>> >> Here's an example of how I represent that in the dhcpd.conf file: >> >>> >> host bringebaer { fixed-address bringebaer.starfire.mn.org; >> >>> >> option dhcp-client-identifier "bringebaer"; >> >>> >> } >> >>> >> So, of course, keama is going to translate the FQDN to an IP address, >> >>> >> but the rest of what it does doesn't seem like what I want: >> >>> >> >> >>> >> { >> >>> >> "hostname": "bringebaer", >> >>> >> "ip-address": "192.168.1.57", >> >>> >> "option-data": [ >> >>> >> { >> >>> >> "space": "dhcp4", >> >>> >> "name": "dhcp-client-identifier", >> >>> >> "code": 61, >> >>> >> // "original-data": "\"bringebaer\"", >> >>> >> "csv-format": false, >> >>> >> "data": "6272696e676562616572" >> >>> >> } >> >>> >> ] >> >>> >> }, >> >>> >> Note - the "data" in the option is actually a string of hex digits >> >>> >> which truly does spell out "bringebaer" but I really think that keama >> >>> >> is mapping dhcp-client-identifier to completely the wrong thing. >> >>> >> >> >>> >> If anyone can set me on the right course, I sure would appreciate it. >> >>> >> >> >>> >> -- >> >>> >> John Lind >> >>> >> steinhel...@gmail.com >> >>> >> >> >>> > -- >> >>> > 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 >> >>> -- >> >>> 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 >> > >> > -- >> > 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 >> -- >> 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 > > -- > 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 -- 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
