[Kea-users] reservations and classes

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

[Kea-users] reservations and classes

BÖSCH Christian
Hello,

I want to allow only hosts with reservations and specific client class in some different subnets.
With isc-dhcp I used “allow members of …”

I tried the following below in kea, but that doesn’t seem to work.
Does anyone have an idea?

"Dhcp4": {
...
    "client-classes": [
        {
            "name": "cl-test",
            // "test": "member('KNOWN')",
            "test": "member('cl-test')",
            "only-if-required": true
        }
    ],
    "reservations": [
        {
            "hw-address": "fc:3f:db:36:09:aa",
            "hostname": "test",
            "client-classes": [ "cl-test" ]
        }
    ],
...
    "subnet4": [
  {
      "id": 151,
      "reservation-mode": "global",
      "pools": [ { "pool":  "172.21.151.10 - 172.21.151.250" } ],
      "subnet": "172.21.151.0/24",
      "require-client-classes": [ "cl-test" ]
  },
…..


Thanks,
Christian


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] reservations and classes

Francis Dupont
=?utf-8?B?QsOWU0NIIENocmlzdGlhbg==?= writes:

> I want to allow only hosts with reservations and specific client class
> in some different subnets.
> With isc-dhcp I used allow members of ??
>
> I tried the following below in kea, but that doesn't seem to work.
> Does anyone have an idea?
>
> "Dhcp4": {
> ...
>     "client-classes": [
>         {
>             "name": "cl-test",
>             // "test": "member('KNOWN')",
>             "test": "member('cl-test')",
>             "only-if-required": true

=> the problem is here: only-if-required (and what should replace it)
makes the evaluation of the class too late. The KNOWN idea is good
but it works only for pools which BTW is enough for most uses.

>         }
>     ],

>     "reservations": [
>         {
>             "hw-address": "fc:3f:db:36:09:aa",
>             "hostname": "test",
>             "client-classes": [ "cl-test" ]

=> same issue: client-classes is applied very late.

>         }
>     ],

> ...
>     "subnet4": [
>   {
>       "id": 151,
>       "reservation-mode": "global",
>       "pools": [ { "pool":  "172.21.151.10 - 172.21.151.250" } ],
>       "subnet": "172.21.151.0/24",
>       "require-client-classes": [ "cl-test" ]

=> require-client-classes makes listed classes to be added when the
subnet was selected. Obviously it is not what you want. IMHO you need
a guard ("client-class" clause) but as the localization (aka subnet
/ shared-network selection) is done first you need to apply the guard
to the pool.

>   },

Regards

Francis Dupont <[hidden email]>
_______________________________________________
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] reservations and classes

BÖSCH Christian
Thanks Francis,

but now I tried with the guard “client-class” in the pool section:

    "subnet4": [
  {
      "id": 151,
      "reservation-mode": "global",
      "subnet": "172.21.151.0/24",
      "pools": [
        {
            "pool":  "172.21.151.10 - 172.21.151.250",
            "client-class": "cl-test"
        }
      ]
  }

First I tried to add the class to the host:

    "client-classes": [
        {
            "name": "cl-test",
            "test": "member('cl-test')"
        }
    ],
    "reservations": [
        {
            "hw-address": "fc:3f:db:36:09:ad",
            "hostname": "test",
            "client-classes": [ "cl-test" ]
        }
    ],

I got: ALLOC_ENGINE_V4_ALLOC_FAIL

Then I tried only with KNOWN:

    "client-classes": [
        {
            "name": "cl-test",
            "test": "member('KNOWN')"
        }
    ],
    "reservations": [
        {
            "hw-address": "fc:3f:db:36:09:ad",
            "hostname": "test"
        }
    ],

I still got: ALLOC_ENGINE_V4_ALLOC_FAIL

But “KNOWN" wouldn't be what I want anyway. I want to allow hosts with classA only in subnetA, and hosts with classB only in subnetB.

Thanks and kind regards,
Christian

On 08.01.2019, at 21:23 , Francis Dupont <[hidden email]> wrote:

=?utf-8?B?QsOWU0NIIENocmlzdGlhbg==?= writes:
I want to allow only hosts with reservations and specific client class
in some different subnets.
With isc-dhcp I used allow members of ??

I tried the following below in kea, but that doesn't seem to work.
Does anyone have an idea?

"Dhcp4": {
...
   "client-classes": [
       {
           "name": "cl-test",
           // "test": "member('KNOWN')",
           "test": "member('cl-test')",
           "only-if-required": true

=> the problem is here: only-if-required (and what should replace it)
makes the evaluation of the class too late. The KNOWN idea is good
but it works only for pools which BTW is enough for most uses.

       }
   ],

   "reservations": [
       {
           "hw-address": "fc:3f:db:36:09:aa",
           "hostname": "test",
           "client-classes": [ "cl-test" ]

=> same issue: client-classes is applied very late.

       }
   ],

...
   "subnet4": [
 {
     "id": 151,
     "reservation-mode": "global",
     "pools": [ { "pool":  "172.21.151.10 - 172.21.151.250" } ],
     "subnet": "172.21.151.0/24",
     "require-client-classes": [ "cl-test" ]

=> require-client-classes makes listed classes to be added when the
subnet was selected. Obviously it is not what you want. IMHO you need
a guard ("client-class" clause) but as the localization (aka subnet
/ shared-network selection) is done first you need to apply the guard
to the pool.

 },

Regards

Francis Dupont <[hidden email]>


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] reservations and classes

Francis Dupont
Francis Dupont <[hidden email]>
> First I tried to add the class to the host:
>
>     "client-classes": [
>         {
>             "name": "cl-test",
>             "test": "member('cl-test')"

=> note this does not make sense. If you need a test which is always true
you can use the 'ALL' class but the simplest is to set the class.

>     "reservations": [
>         {
>             "hw-address": "fc:3f:db:36:09:ad",
>             "hostname": "test",
>             "client-classes": [ "cl-test" ]

=> this sets the class but after resource allocation so far too late.

>         }
>     ],
>
> I got: ALLOC_ENGINE_V4_ALLOC_FAIL

=> unfortunately the expected result.

> Then I tried only with KNOWN:
>
>     "client-classes": [
>         {
>             "name": "cl-test",
>             "test": "member('KNOWN')"
>         }
>     ],
>     "reservations": [
>         {
>             "hw-address": "fc:3f:db:36:09:ad",
>             "hostname": "test"
>         }
>     ],
>
> I still got: ALLOC_ENGINE_V4_ALLOC_FAIL

=> this has a chance to work but it requires the right subnet is selected.
If it is not the host reservation won't be look up (can be fixed by
using the global reservation mode) nor the pool. If you have shared networks
it only replaces subnet selection by shared network selection so
you have more choices but perhaps still not enough.

> But "KNOWN" wouldn't be what I want anyway. I want to allow
> hosts with classA only in subnetA, and hosts with classB only in
> subnetB.

=> the problem is that the subnet/shared-network selection is the main
part of the localization phase and for many reasons including a strong
security one it has to be made very soon. Note ISC DHCP has the same
constraint and does not offer a hook which allows to overwrite the
subnet selection.

Regards

Francis Dupont <[hidden email]>

PS: tomorrow we have an internal discussion about ways to make the
client classification easier to use and more powerful. Perhaps we'll
find a solution for your problem as it is already in the list of things
we want to support...
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users