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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
