[Kea-users] Kea 1.3 beta - Shared Networks Problem?
Marcin Siodelski
marcin at isc.org
Fri Oct 13 12:52:21 UTC 2017
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 <duane.wylie at eatel.com
> <mailto:duane.wylie at eatel.com>> 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 <marcin at isc.org <mailto:marcin at isc.org>>
>> *Sent:* Thursday, October 12, 2017 1:55:00 PM
>> *To:* Duane Wylie; kea-users at lists.isc.org
>> <mailto:kea-users at lists.isc.org>
>> *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
>> > Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
>> > https://lists.isc.org/mailman/listinfo/kea-users
>> >
>>
>> _______________________________________________
>> Kea-users mailing list
>> Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/kea-users
More information about the Kea-users
mailing list