[Kea-users] Possible allocation bug when reloading kea-dhcp6 or in relation to reservation without pools with kea-1.3.0

[Rasmus Edgar]

Hi,

I am unable to create a trac account to submit a bug report since get 
the following message:

Submission rejected as potential spam

     IP x.x.x.x blacklisted by rbl.rbldns.ru [2]
     SpamBayes determined spam probability of 90.82%

I tried from two different ip adresses, with the exact same result. 
Checking with mxtoolbox, both are green.

So, I'm posting the bug report here instead.

One of my colleagues added a client reservation to kea-dhcp6.conf.

We are using duid reservations without a pool for the given subnet. All 
the reservations are given their own shared network.

Example:

         "shared-networks": [
             {
                 "name": "example-001",
                 "option-data": [
                     {
                         "name": "ccap-core",
                         "code": 61,
                         "space": "vendor-4491",
                         "data": "<ipv6 address>"
                     }
                 ],
                 "subnet6": [
                     {
                         "subnet": "<ipv6 subnet>",
                         "reservations": [
                             {
                                 "duid": "<duid>",
                                 "ip-addresses": [
                                     "<ipv6 address>"
                                 ]
                             }
                         ]
                     }
                 ]
             },
...


This has worked perfectly the last months using systemctl restart 
kea-dhcp6. I recently changed our deployment method so it reloads 
kea-dhcp6 with keactrl, instead of restarting and it looks correct in 
the log:

2018-06-25 09:24:19.117 INFO  [kea-dhcp6.dhcp6/14624] 
DHCP6_DYNAMIC_RECONFIGURATION initiate server reconfiguration using 
file: /etc/kea/kea-dhcp6.conf, after receiving SIGHUP signal
2018-06-25 09:24:19.118 INFO  [kea-dhcp6.dhcpsrv/14624] 
DHCPSRV_CFGMGR_USE_UNICAST listening on unicast address <ipv6 address>, 
on interface eno16780032

The deployment process also checks the JSON validity of the 
configuration before deployment.

After adding a new reservation similar to one the one above we saw the 
following in log afterwards for almost all our clients:

2018-06-25 09:21:06.724 WARN  [kea-dhcp6.alloc-engine/14624] 
ALLOC_ENGINE_V6_ALLOC_FAIL duid=[<duid 1>], tid=0x77c64f: failed to 
allocate an IPv6 address after 0 attempt(s)
2018-06-25 09:21:14.003 WARN  [kea-dhcp6.alloc-engine/14624] 
ALLOC_ENGINE_V6_ALLOC_FAIL duid=[<duid 2>], tid=0xda026f: failed to 
allocate an IPv6 address after 0 attempt(s)
2018-06-25 09:21:14.978 WARN  [kea-dhcp6.alloc-engine/14624] 
ALLOC_ENGINE_V6_ALLOC_FAIL duid=[<duid 3>], tid=0x98ddee: failed to 
allocate an IPv6 address after 0 attempt(s)

Could what we are seeing be related to the CalloutHandle bug: 
https://kea.isc.org/ticket/5638 ?

Or could be something to do with using HUP to reload kea-dhcp6?

Reverting the configuration, and thereby also reloading the 
configuration everything worked again. This could point to some fault in 
the newly added configuration snippet, but no subnet overlaps or syntax 
errors could be found.

Best regards,
Rasmus Edgar