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
