Hi All, This fix is now available on master branch. Thanks again Duane for reporting this issue.
Marcin Siodelski ISC On 12.10.2017 23:19, Jason Lixfeld wrote: > Marcin, > > Can you let me know when this patch gets committed to git so I can add > it in as well? > > Thanks! > > Sent from my iPhone > > On Oct 12, 2017, at 4:43 PM, Duane Wylie <[email protected] > <mailto:[email protected]>> wrote: > >> Thanks, Marcin. >> >> >> I've applied the patch and recompiled. So far the patch does appear >> to have resolved this issue! >> >> >> I'll watch this through the weekend and report back if I find any issues. >> >> >> Thanks, again! >> >> >> Duane Wylie >> >> ------------------------------------------------------------------------ >> *From:* Marcin Siodelski <[email protected] <mailto:[email protected]>> >> *Sent:* Thursday, October 12, 2017 1:55:00 PM >> *To:* Duane Wylie; [email protected] >> <mailto:[email protected]> >> *Subject:* Re: [Kea-users] Kea 1.3 beta - Shared Networks Problem? >> >> 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 <http://alloc_engine.cc> >> b/src/lib/dhcpsrv/alloc_engine.cc <http://alloc_engine.cc> >> index f75f795..55effd8 100644 >> --- a/src/lib/dhcpsrv/alloc_engine.cc <http://alloc_engine.cc> >> +++ b/src/lib/dhcpsrv/alloc_engine.cc <http://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] <mailto:[email protected]> >> > https://lists.isc.org/mailman/listinfo/kea-users >> > >> >> _______________________________________________ >> Kea-users mailing list >> [email protected] <mailto:[email protected]> >> https://lists.isc.org/mailman/listinfo/kea-users _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
