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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[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


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Marcin Siodelski
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
Reply | Threaded
Open this post in threaded view
|

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

Duane Wylie

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
Reply | Threaded
Open this post in threaded view
|

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

Marcin Siodelski
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