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@lists.isc.org
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

Reply via email to