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

[Rasmus Edgar]

Hi,

After some more updates to the config a possible pattern has emerged.

It seems that when a new shared-network is appended to the 
shared-networks array everything works fine. If a shared-network is 
inserted in the middle of the shared-networks array, and thereby 
shifting the array position of other shared-network declarations within 
the array the host reservations of these fail to get allocated. I.e 
order must be kept as is within the shared-networks array and a new 
shared-network can only be appended to the shared-networks array.

I think it might relate to shifting of subnet-ids as described here:

https://kea.isc.org/docs/kea-guide.html#idp63177200

"While not strictly mandatory, it is strongly recommended to use 
explicit "id" values for subnets if you plan to use database storage for 
host reservations. If ID is not specified, the values for it be 
autogenerated, i.e. it will assign increasing integer values starting 
from 1. Thus, the autogenerated IDs are not stable across configuration 
changes."

We are using a memfile, but I guess possible problems arising from 
auto-generated subnet-ids apply here also.

We are currently not setting subnet-ids per subnet, I will try to set 
them manually and see if this solves the problem.

Best regards,
Rasmus Edgar

Rasmus Edgar skrev den 2018-06-25 11:50:
> 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
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users