[Kea-users] Kea 1.3 beta - Shared Networks Problem?
Locked
[Kea-users] Kea 1.3 beta - Shared Networks Problem?
 
|
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" } ] } ] } ],
Duane Wylie
_______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Kea 1.3 beta - Shared Networks Problem?
|
|
Hello, Thanks for testing Kea! Could you try this configuration and tell me if that works for you?
"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": [
{ "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" } ] },
{ "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
] } ] } ],
I think you came across issue that was fixed after we released beta version. QA engineer Wlodek Wencel On 12/10/2017 19:41, Duane Wylie wrote:
_______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Kea 1.3 beta - Shared Networks Problem?
|
|
In reply to this post by Duane Wylie
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 > [hidden email] > https://lists.isc.org/mailman/listinfo/kea-users > _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Kea 1.3 beta - Shared Networks Problem?
|
|
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 <[hidden email]>
Sent: Thursday, October 12, 2017 1:55:00 PM To: Duane Wylie; [hidden email] 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 > [hidden email] > https://lists.isc.org/mailman/listinfo/kea-users > _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Kea 1.3 beta - Shared Networks Problem?
|
|
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 <[hidden email] > <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> >> *Sent:* Thursday, October 12, 2017 1:55:00 PM >> *To:* Duane Wylie; [hidden email] >> <mailto:[hidden email]> >> *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 >> > [hidden email] <mailto:[hidden email]> >> > https://lists.isc.org/mailman/listinfo/kea-users >> > >> >> _______________________________________________ >> Kea-users mailing list >> [hidden email] <mailto:[hidden email]> >> https://lists.isc.org/mailman/listinfo/kea-users _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
| Free forum by Nabble | Edit this page |