[Kea-users] Reservations not being assigned

Sat Aug 6 18:49:21 UTC 2016

On 5 August 2016 at 17:41, Matthew Pounsett <matt at conundrum.com> wrote:

>
>
> On Friday, 5 August 2016, Klaus Steden <klausfiend at gmail.com> wrote:
>
>>
>> I've had issues with reservations with previous builds; I think the
>> initial stable release supported reservations with a MySQL backend, but the
>> last build from Git that I used with the same configuration did not. FWIW
>> it's supposed to be ironed out with the 1.0.1 release, which is due to drop
>> any day now. I did test using reservations baked into the configuration
>> file with the aforementioned Git build, and that did work, but that of
>> course won't scale with application code, so I couldn't use that setup.
>>
>
> Hmm.. Okay. No scaling issues here since this is, for now, just for home
> use.  Perhaps I'll try the development version and see how that does.
>

Unfortunately that didn't seem to fix the problem.

Are any of the kea developers on the list?  Anyone know what the current
state of v4 reservations in the config file are?

>
> Thanks!  (And hi Klaus!  Long time!)
>
>
>>
>> Also, hi Matt! :-)
>>
>> cheers,
>> Klaus
>>
>> On Fri, Aug 5, 2016 at 12:40 PM, Matthew Pounsett <matt at conundrum.com>
>> wrote:
>>
>>> I have what I think is a fairly straightforward config, but I'm having
>>> issues with it.  From the default kea.conf that ships with FreeBSD ports I
>>> have made the following changes:
>>> 1) listen on all interfaces
>>> 2) add global dns servers options
>>> 3) added two subnets:
>>>    3a) an RFC1918 /24
>>>     - subnet specific option for a router
>>>     - one pool of 10.0.5.100 to 10.0.5.254
>>>     - several out-of-pool reservations (none in-pool)
>>>    3b) a routed /28
>>>     - subnet specific option for a router
>>>     - no pools
>>>     - several reservations
>>>
>>>
>>> 3b works fine.  Neither the pool nor the reservations in 3a seem to be
>>> working.  For any of those, kea seems to be giving up before even
>>> attempting to make an assignment:
>>> 2016-08-05 15:04:31.959 WARN  [kea-dhcp4.alloc-engine/1223]
>>> ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 0c:c4:7a:b9:24:91],
>>> cid=[01:0c:c4:7a:b9:24:91], tid=0xfc7cd269: failed to allocate an IPv4
>>> address after 0 attempt(s)
>>>
>>> The server running Kea has addresses on its interface in both subnets.
>>>
>>> I have triple-checked that the subnet 'name', pool, and reservations are
>>> all out of the same /24
>>>
>>> When I turn on debugging, it looks like kea is ignoring the available
>>> pool in 3a, and is trying to assign addresses out of 3b instead:
>>>
>>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108]
>>> DHCP4_SUBNET_SELECTED [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: the subnet with ID 2
>>> was selected for client assignments
>>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108] DHCP4_SUBNET_DATA
>>> [hwtype=1 08:00:27:2c:73:00], cid=[70:6f:75:64:72:69:65:72:65],
>>> tid=0xae5b3aa3: the selected subnet details: 216.235.10.32/28
>>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108]
>>> DHCP4_PACKET_RECEIVED [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: DHCPDISCOVER (type 1)
>>> received from 0.0.0.0 to 255.255.255.255 on interface em0
>>> 2016-08-05 15:37:21.718 DEBUG [kea-dhcp4.packets/2108] DHCP4_QUERY_DATA
>>> [hwtype=1 08:00:27:2c:73:00], cid=[70:6f:75:64:72:69:65:72:65],
>>> tid=0xae5b3aa3, packet details: local_address=255.255.255.255:67,
>>> remote_adress=0.0.0.0:68, msg_type=DHCPDISCOVER (1), transid=0xae5b3aa3,
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.packets/2108]
>>> DHCP4_SUBNET_SELECTED [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: the subnet with ID 2
>>> was selected for client assignments
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.packets/2108] DHCP4_SUBNET_DATA
>>> [hwtype=1 08:00:27:2c:73:00], cid=[70:6f:75:64:72:69:65:72:65],
>>> tid=0xae5b3aa3: the selected subnet details: 216.235.10.32/28
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>>> HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID get one host with IPv4
>>> reservation for subnet id 2, HWADDR hwtype=1 08:00:27:2c:73:00, DUID
>>> 70:6f:75:64:72:69:65:72:65
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>>> HOSTS_CFG_GET_ALL_HWADDR_DUID get all hosts with reservations for HWADDR
>>> hwtype=1 08:00:27:2c:73:00 and DUID 70:6f:75:64:72:69:65:72:65
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>>> HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
>>> identifier: hwaddr=08:00:27:2c:73:00
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>>> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
>>> hwaddr=08:00:27:2c:73:00, found 0 host(s)
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.hosts/2108]
>>> HOSTS_CFG_GET_ONE_SUBNET_ID_HWADDR_DUID_NULL host not found using
>>> subnet id 2, HW address hwtype=1 08:00:27:2c:73:00 and DUID
>>> 70:6f:75:64:72:69:65:72:65
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.ddns/2108]
>>> DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: processing client's
>>> Hostname option
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.ddns/2108]
>>> DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: client sent Hostname
>>> option: poudriere
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.dhcpsrv/2108]
>>> DHCPSRV_MEMFILE_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID 2
>>> and hardware address hwtype=1 08:00:27:2c:73:00
>>> 2016-08-05 15:37:21.719 DEBUG [kea-dhcp4.alloc-engine/2108]
>>> ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new
>>> lease to the client [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3
>>> 2016-08-05 15:37:21.719 WARN  [kea-dhcp4.alloc-engine/2108]
>>> ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 08:00:27:2c:73:00],
>>> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: failed to allocate an
>>> IPv4 address after 0 attempt(s)
>>>
>>> Any suggestions on how to approach troubleshooting this?
>>>
>>> % kea-dhcp4 -V
>>> 1.0.0
>>> tarball
>>> linked with:
>>> log4plus 1.1.2
>>> OpenSSL 0.9.8zh-freebsd 3 Dec 2015
>>> database:
>>> PostgreSQL backend 2.0, library 90313
>>> Memfile backend 2.0
>>>
>>>
>>> _______________________________________________
>>> 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/20160806/c80ecb13/attachment.htm>