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

[Duane Wylie]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171012/2654491d/attachment.htm>