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

[Wlodek Wencel]

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:
>
> 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/7d333213/attachment.htm>