KEA not respecting reservation

[Christophe999s]

KEA hands out a different IP than the one configured in the reservations:



This happened after replacing the sdcard in my pi en restarting it.
Anyone experience something similar or know what the cause might be?

[MarkH]

The KEA error log explains the address you chose for hifiberryamp is not available, as it's already in use, so instead it's advertised (offered) 192.168.30.101.

Static lease changes from ISC DHCP to KEA:

DHCP reservations must fall within the Interface subnet and must be outside any DHCP scope defined in KEA DHCP server.

This is a more strict configuration requirement than the legacy ISC DHCP Server.

Having static leases defined that fall within a scope does not prevent a DHCP server from offering that IP as a lease, which may (mistakenly) be the expected behaviour.

In your question you don't specify what your DHCP scope(s) [also known as pool(s)] is/are, so I'll assume you've left these as default which matches the interface's subnet.

This is an example of a CORRECT config:

Code Select Expand


Interface subnet: 192.168.30.0/24
Interface Useable IPs: 192.168.30.1 - 192.168.30.254
Interface IP: 192.168.30.1/24
DHCP Scope: 192.168.30.1 - 192.168.30.180
DHCP static lease for mac address: d8:3a:dd:fc:44:82 192.168.30.182


And below is an example of a INCORRECT config:

Code Select Expand


Interface subnet: 192.168.30.0/24
Interface Useable IPs: 192.168.30.1 - 192.168.30.254
Interface IP: 192.168.30.1/24
DHCP Scope: 192.168.30.1 - 192.168.30.254
DHCP static lease for mac address: d8:3a:dd:fc:44:82 192.168.30.182


If this doesn't work, can you confirm the scope(s) set for KEA on this interface

[charles.adams]

I'd say that it is odd to me that what is a permanent lock between MAC address and IP in every other system I've used (Microsoft, Cisco, Ubiquity), that over rules the scope and locks the IP down to a particular device, is accomplished by having to manually carve out the IPs from the DHCP scope instead of just locking the IPs down to their assignment and keeping it simpler for the person doing the configuration.

[hansen97124]

just wanted to say thanks.  This post solved the problem I was having with ignored reservations.

All working now after following this thread.

[themadwizard]

And here I thought only Sophos firewalls were stupid enough to require you to break up pools to reserve addresses in the pool space.  Awful design.

The KEA error log explains the address you chose for hifiberryamp is not available, as it's already in use, so instead it's advertised (offered) 192.168.30.101.

Static lease changes from ISC DHCP to KEA:

DHCP reservations must fall within the Interface subnet and must be outside any DHCP scope defined in KEA DHCP server.

This is a more strict configuration requirement than the legacy ISC DHCP Server.

Having static leases defined that fall within a scope does not prevent a DHCP server from offering that IP as a lease, which may (mistakenly) be the expected behaviour.

In your question you don't specify what your DHCP scope(s) [also known as pool(s)] is/are, so I'll assume you've left these as default which matches the interface's subnet.

This is an example of a CORRECT config:

Code Select Expand


Interface subnet: 192.168.30.0/24
Interface Useable IPs: 192.168.30.1 - 192.168.30.254
Interface IP: 192.168.30.1/24
DHCP Scope: 192.168.30.1 - 192.168.30.180
DHCP static lease for mac address: d8:3a:dd:fc:44:82 192.168.30.182


And below is an example of a INCORRECT config:

Code Select Expand


Interface subnet: 192.168.30.0/24
Interface Useable IPs: 192.168.30.1 - 192.168.30.254
Interface IP: 192.168.30.1/24
DHCP Scope: 192.168.30.1 - 192.168.30.254
DHCP static lease for mac address: d8:3a:dd:fc:44:82 192.168.30.182


If this doesn't work, can you confirm the scope(s) set for KEA on this interface

[dseven]

Kea DHCP *does* support in-pool reservations: https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#address-reservation-types

but there are caveats - mostly around cases where an address from the pool had already been given out as a dynamic lease to some other host before a reservation for it was created.

OPNsense recommends not using in-pool reservations https://docs.opnsense.org/manual/dhcp.html#reservations but does allow it. I'm not sure the statement made there ("the DHCP server is free to offer this IP address to a different client when the first client goes offline") is accurate - that's not how I read the Kea docs, but I haven't actually tested it...

[charles.adams]

So I want to add that I am having this issue even though I have had my DHCP scope set up to carve out the IP I'm assigning a lease to.

Reservation is for it to get 192.168.1.37

DHCP Pools carve this out:

But it shows in the lease (and in Unifi Control) as getting 192.168.1.41


I've tried restarting the device and KEA since discovering this did not get the IP I reserved for it (before connecting it to the network the first time).

I seem to have the same problem as the OP but I did follow the carve out in the KEA configuration guide?

[dseven]

Kea seems to get confused if the client ID changes even though the MAC address doesn't - you get this bizarre error to the effect of "can't assign address foo to device bar because address foo is already in use by device bar". For me, this was particularly noticeable when installing Debian Linux, where apparently the installer uses a different type of client ID than the installed system, so the installer gets the reserved address, but after installation, Kea refuses to do it, because of the ID change. I got tired of it, and went back to ISC for now.

[Taunt9930]

Kea seems to get confused if the client ID changes even though the MAC address doesn't - you get this bizarre error to the effect of "can't assign address foo to device bar because address foo is already in use by device bar". For me, this was particularly noticeable when installing Debian Linux, where apparently the installer uses a different type of client ID than the installed system, so the installer gets the reserved address, but after installation, Kea refuses to do it, because of the ID change. I got tired of it, and went back to ISC for now.

This. I have seen this multiple times. I have also seen a situation where rebooting a device results in a new IP being given from the DHCP pool, because the reserved IP is still 'in-use' by the device it is reserved for, but the ClientID has not changed - I haven't worked this out yet, but it appears to be when the device comes back up 'too quickly' for KEA to realise it dropped in the first place.

[charles.adams]

Any solutions or locations that a bug report should be filed?

[dseven]

I think the scenario where the client ID changes (even though the MAC address doesn't) is considered "not a bug" by the Kea devs - they consider it a different device if the client ID changes. It's exacerbated in OPNsense by lack of an easy way to terminate a lease, so there's no quick way to resolve the situation when does occur. I'm putting this down to Kea [support in OPNsense] not being "ready for prime-time" yet.

I did run into another situation where a conflict was reported for another device, where the client ID shouldn't have been changing. I was already tired of it at that point, and it was the "final straw" that sent me back to ISC, and I didn't really dig into it, so not sure of the root cause.

If someone has a reproducible case, maybe it could be taken to https://gitlab.isc.org/isc-projects/kea/-/issues

[charles.adams]

I think the scenario where the client ID changes (even though the MAC address doesn't) is considered "not a bug" by the Kea devs - they consider it a different device if the client ID changes. It's exacerbated in OPNsense by lack of an easy way to terminate a lease, so there's no quick way to resolve the situation when does occur. I'm putting this down to Kea [support in OPNsense] not being "ready for prime-time" yet.

I did run into another situation where a conflict was reported for another device, where the client ID shouldn't have been changing. I was already tired of it at that point, and it was the "final straw" that sent me back to ISC, and I didn't really dig into it, so not sure of the root cause.

If someone has a reproducible case, maybe it could be taken to https://gitlab.isc.org/isc-projects/kea/-/issues

If you can point me how to determine if the client ID has changed I'm willing to push this as there should have been no change but I can't prove it.

There doesn't seem to be a way to see or set the clientID in the reservation. It seems unfair/poorly designed that the controlling data field is not visible/accessible/reservable in KEA. Every other DHCP system that I know of out there keys and is reserved off MAC (which is why it is a fillable field) and not the client ID.

[dseven]

If you can point me how to determine if the client ID has changed I'm willing to push this as there should have been no change but I can't prove it.

There doesn't seem to be a way to see or set the clientID in the reservation. It seems unfair/poorly designed that the controlling data field is not visible/accessible/reservable in KEA. Every other DHCP system that I know of out there keys and is reserved off MAC (which is why it is a fillable field) and not the client ID.

You can see them in the log (Services -> Kea DHCP -> Log File, set level to Informational), e.g.:

Code Select Expand

INFO [kea-dhcp4.leases.0x3af03cc16600] DHCP4_LEASE_ALLOC [hwtype=1 bc:24:11:c7:1f:e4], cid=[ff:11:c7:1f:e4:00:01:00:01:2e:c0:b6:2a:bc:24:11:c7:1f:e4], tid=0x6c9c8115: lease 192.168.1.200 has been allocated for 4000 seconds

and in /var/db/kea/kea-leases4.csv

The "new" cid (I think?) is logged when the conflict occurs (example in the first post of this thread) - you could compare that to previous log entries or/and the CSV file...

[charles.adams]

I've got myself scheduled to see if I can spot the client ID change on Friday.

It would be nicer if we had exposed in OPNsense the KEA option

Code Select Expand

match-client-id from https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#using-client-identifier-and-hardware-address as that seems to enable one to make KEA work like every other DHCP I've seen and assign based on MAC first and not the client ID.

[charles.adams]

So a feature request was made and it looks like approved : https://github.com/opnsense/core/issues/8183

Looks like they are adding a toggle so we can set match-client-id to false if we want.