[Kea-users] Kea 1.3 beta - Shared Networks Problem?

Duane Wylie duane.wylie at eatel.com
Thu Oct 12 20:43:31 UTC 2017


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>
Sent: Thursday, October 12, 2017 1:55:00 PM
To: Duane Wylie; 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
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
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171012/5fcbc855/attachment-0001.html>


More information about the Kea-users mailing list