Hello Duane, Thank you for beta testing Kea. Feedback from "external" world is valuable and allows for catching issues early. This is especially important in case of "shared networks" which is a pretty complex feature.
Getting to the point, though. I haven't done any actual testing and didn't try to replicate your problem yet, but since I wrote this code I can make informed guesses. I am providing a small patch for Kea which may/should correct this problem. If you can give it a shot, it will be great. If not, I will try to write a test tomorrow and see if it works for me. However, there are sometimes details of the environment that matter. Anyhow, let me know if you can test it and if you need any assistance in applying the patch. The patch is available here: https://pastebin.com/L4UCM3he I also paste it below for convenience but may have odd line wraps. Thanks, Marcin Siodelski ISC diff --git a/src/lib/dhcpsrv/alloc_engine.cc b/src/lib/dhcpsrv/alloc_engine.cc index f75f795..55effd8 100644 --- a/src/lib/dhcpsrv/alloc_engine.cc +++ b/src/lib/dhcpsrv/alloc_engine.cc @@ -2443,6 +2443,10 @@ void findClientLease(AllocEngine::ClientContext4& ctx, Lease4Ptr& client_lease) // configured to ignore client identifier). if (client_id) { client_lease = lease_mgr.getLease4(*client_id, subnet->getID()); + if (client_lease) { + ctx.subnet_ = subnet; + return; + } } // If no lease found using the client identifier, try the lookup using On 12.10.2017 19:41, Duane Wylie wrote: > I'm encountering a strange issue with shared-networks in Kea 1.3 beta. > I have eMTA devices (embedded in the cable modems) that are able to pull > IPs from Kea just fine. They are failing to TFTP their config, which > causes them to re-init the DHCP process. This is where the problem occurs. > > > Subsequent DHCPDISCOVERs from the eMTA are not issued the same IP > address they previously had, they are issued new/different IP > addresses. Since the eMTA is stuck in a reboot loop, this eventually > exhausts the ip pool. This *ONLY* happens when the subnet is part of a > shared-network *AND* there are multiple subnets in the shared-network. > > > If the subnet is defined *OUTSIDE* of a "shared-network", there is not a > problem. The eMTA is issued the same IP address it previously had. > Similarly, if the subnet is defined in a shared-network and that > shared-network only has the one subnet defined, the eMTA is issued the > same IP address again. > > > > So, this *DOES* work: > > > "shared-networks": [ > > { > > "name": "Shared Network Test", > > "interface": "eth0", > > "option-data": [ > > { > > "name": "domain-name-servers", > > "data": "209.124.193.100, 209.124.193.101" > > } > > ], > > "relay": { > > "ip-address": "206.124.198.1" > > }, > > "subnet4": [ > > { > > "id": 13, > > "client-class": > "VENDOR_CLASS_pktc1.5:05360101010201020501010901010a01010b040106090F0d010110010912020007130101140101150101160101170302001F180100190100", > > "subnet": "10.0.42.8/29", > > "pools": [ { "pool": "10.0.42.10 - 10.0.42.14" } ], > > "relay": { > > "ip-address": "206.124.198.1" > > }, > > "next-server": "10.40.4.50", > > "option-data": [ > > # omitted for brevity > > ] > > } > > ] > > } ], > > > Where this does *NOT*: > > > "shared-networks": [ > > { > > "name": "Shared Network Test", > > "interface": "eth0", > > "option-data": [ > > { > > "name": "domain-name-servers", > > "data": "209.124.193.100, 209.124.193.101" > > } > > ], > > "relay": { > > "ip-address": "206.124.198.1" > > }, > > "subnet4": [ > > { > > "id": 13, > > "client-class": > "VENDOR_CLASS_pktc1.5:05360101010201020501010901010a01010b040106090F0d010110010912020007130101140101150101160101170302001F180100190100", > > "subnet": "10.0.42.8/29", > > "pools": [ { "pool": "10.0.42.10 - 10.0.42.14" } ], > > "relay": { > > "ip-address": "206.124.198.1" > > }, > > "next-server": "10.40.4.50", > > "option-data": [ > > # omitted for brevity > > ] > > }, > > { > > "subnet": "206.124.198.0/30", > > "pools": [ { "pool": "206.124.198.2 - 206.124.198.2" } ], > > "option-data": [ > > { > > "name": "routers", > > "data": "206.124.198.1" > > } > > ] > > }, > > { > > "subnet": "206.124.198.4/30", > > "pools": [ { "pool": "206.124.198.6 - 206.124.198.6" } ], > > "option-data": [ > > { > > "name": "routers", > > "data": "206.124.198.5" > > } > > ] > > } > > ] > > } ], > > > > I'm wondering if the use of the client-class on the eMTA's subnet is > causing this issue. Any thoughts? > > > > > Duane Wylie > > > > _______________________________________________ > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users > _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
