<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Thanks, Marcin.</p>
<p><br>
</p>
<p>I've applied the patch and recompiled. So far the patch does appear to have resolved this issue!</p>
<p><br>
</p>
<p>I'll watch this through the weekend and report back if I find any issues.</p>
<p><br>
</p>
<p>Thanks, again!</p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255); font-family:Calibri,Arial,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
Duane Wylie<br>
<br>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Marcin Siodelski <marcin@isc.org><br>
<b>Sent:</b> Thursday, October 12, 2017 1:55:00 PM<br>
<b>To:</b> Duane Wylie; kea-users@lists.isc.org<br>
<b>Subject:</b> Re: [Kea-users] Kea 1.3 beta - Shared Networks Problem?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hello Duane,<br>
<br>
Thank you for beta testing Kea. Feedback from "external" world is<br>
valuable and allows for catching issues early. This is especially<br>
important in case of "shared networks" which is a pretty complex feature.<br>
<br>
Getting to the point, though. I haven't done any actual testing and<br>
didn't try to replicate your problem yet, but since I wrote this code I<br>
can make informed guesses. I am providing a small patch for Kea which<br>
may/should correct this problem. If you can give it a shot, it will be<br>
great. If not, I will try to write a test tomorrow and see if it works<br>
for me. However, there are sometimes details of the environment that<br>
matter. Anyhow, let me know if you can test it and if you need any<br>
assistance in applying the patch.<br>
<br>
The patch is available here:<br>
<br>
<a href="https://pastebin.com/L4UCM3he">https://pastebin.com/L4UCM3he</a><br>
<br>
I also paste it below for convenience but may have odd line wraps.<br>
<br>
Thanks,<br>
Marcin Siodelski<br>
ISC<br>
<br>
<br>
diff --git a/src/lib/dhcpsrv/alloc_engine.cc<br>
b/src/lib/dhcpsrv/alloc_engine.cc<br>
index f75f795..55effd8 100644<br>
--- a/src/lib/dhcpsrv/alloc_engine.cc<br>
+++ b/src/lib/dhcpsrv/alloc_engine.cc<br>
@@ -2443,6 +2443,10 @@ void findClientLease(AllocEngine::ClientContext4&<br>
ctx, Lease4Ptr& client_lease)<br>
// configured to ignore client identifier).<br>
if (client_id) {<br>
client_lease = lease_mgr.getLease4(*client_id,<br>
subnet->getID());<br>
+ if (client_lease) {<br>
+ ctx.subnet_ = subnet;<br>
+ return;<br>
+ }<br>
}<br>
<br>
// If no lease found using the client identifier, try the<br>
lookup using<br>
<br>
<br>
<br>
On 12.10.2017 19:41, Duane Wylie wrote:<br>
> I'm encountering a strange issue with shared-networks in Kea 1.3 beta. <br>
> I have eMTA devices (embedded in the cable modems) that are able to pull<br>
> IPs from Kea just fine. They are failing to TFTP their config, which<br>
> causes them to re-init the DHCP process. This is where the problem occurs.<br>
> <br>
> <br>
> Subsequent DHCPDISCOVERs from the eMTA are not issued the same IP<br>
> address they previously had, they are issued new/different IP<br>
> addresses. Since the eMTA is stuck in a reboot loop, this eventually<br>
> exhausts the ip pool. This *ONLY* happens when the subnet is part of a<br>
> shared-network *AND* there are multiple subnets in the shared-network.<br>
> <br>
> <br>
> If the subnet is defined *OUTSIDE* of a "shared-network", there is not a<br>
> problem. The eMTA is issued the same IP address it previously had. <br>
> Similarly, if the subnet is defined in a shared-network and that<br>
> shared-network only has the one subnet defined, the eMTA is issued the<br>
> same IP address again.<br>
> <br>
> <br>
> <br>
> So, this *DOES* work:<br>
> <br>
> <br>
> "shared-networks": [<br>
> <br>
> {<br>
> <br>
> "name": "Shared Network Test",<br>
> <br>
> "interface": "eth0",<br>
> <br>
> "option-data": [<br>
> <br>
> {<br>
> <br>
> "name": "domain-name-servers",<br>
> <br>
> "data": "209.124.193.100, 209.124.193.101"<br>
> <br>
> }<br>
> <br>
> ],<br>
> <br>
> "relay": {<br>
> <br>
> "ip-address": "206.124.198.1"<br>
> <br>
> },<br>
> <br>
> "subnet4": [<br>
> <br>
> {<br>
> <br>
> "id": 13,<br>
> <br>
> "client-class":<br>
> "VENDOR_CLASS_pktc1.5:05360101010201020501010901010a01010b040106090F0d010110010912020007130101140101150101160101170302001F180100190100",<br>
> <br>
> "subnet": "10.0.42.8/29",<br>
> <br>
> "pools": [ { "pool": "10.0.42.10 - 10.0.42.14" } ],<br>
> <br>
> "relay": {<br>
> <br>
> "ip-address": "206.124.198.1"<br>
> <br>
> },<br>
> <br>
> "next-server": "10.40.4.50",<br>
> <br>
> "option-data": [<br>
> <br>
> # omitted for brevity<br>
> <br>
> ]<br>
> <br>
> }<br>
> <br>
> ]<br>
> <br>
> } ],<br>
> <br>
> <br>
> Where this does *NOT*:<br>
> <br>
> <br>
> "shared-networks": [<br>
> <br>
> {<br>
> <br>
> "name": "Shared Network Test",<br>
> <br>
> "interface": "eth0",<br>
> <br>
> "option-data": [<br>
> <br>
> {<br>
> <br>
> "name": "domain-name-servers",<br>
> <br>
> "data": "209.124.193.100, 209.124.193.101"<br>
> <br>
> }<br>
> <br>
> ],<br>
> <br>
> "relay": {<br>
> <br>
> "ip-address": "206.124.198.1"<br>
> <br>
> },<br>
> <br>
> "subnet4": [<br>
> <br>
> {<br>
> <br>
> "id": 13,<br>
> <br>
> "client-class":<br>
> "VENDOR_CLASS_pktc1.5:05360101010201020501010901010a01010b040106090F0d010110010912020007130101140101150101160101170302001F180100190100",<br>
> <br>
> "subnet": "10.0.42.8/29",<br>
> <br>
> "pools": [ { "pool": "10.0.42.10 - 10.0.42.14" } ],<br>
> <br>
> "relay": {<br>
> <br>
> "ip-address": "206.124.198.1"<br>
> <br>
> },<br>
> <br>
> "next-server": "10.40.4.50",<br>
> <br>
> "option-data": [<br>
> <br>
> # omitted for brevity<br>
> <br>
> ]<br>
> <br>
> },<br>
> <br>
> {<br>
> <br>
> "subnet": "206.124.198.0/30",<br>
> <br>
> "pools": [ { "pool": "206.124.198.2 - 206.124.198.2" } ],<br>
> <br>
> "option-data": [<br>
> <br>
> {<br>
> <br>
> "name": "routers",<br>
> <br>
> "data": "206.124.198.1"<br>
> <br>
> }<br>
> <br>
> ]<br>
> <br>
> },<br>
> <br>
> {<br>
> <br>
> "subnet": "206.124.198.4/30",<br>
> <br>
> "pools": [ { "pool": "206.124.198.6 - 206.124.198.6" } ],<br>
> <br>
> "option-data": [<br>
> <br>
> {<br>
> <br>
> "name": "routers",<br>
> <br>
> "data": "206.124.198.5"<br>
> <br>
> }<br>
> <br>
> ]<br>
> <br>
> }<br>
> <br>
> ]<br>
> <br>
> } ],<br>
> <br>
> <br>
> <br>
> I'm wondering if the use of the client-class on the eMTA's subnet is<br>
> causing this issue. Any thoughts?<br>
> <br>
> <br>
> <br>
> <br>
> Duane Wylie<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Kea-users mailing list<br>
> Kea-users@lists.isc.org<br>
> <a href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
> <br>
<br>
</div>
</span></font>
</body>
</html>