Francis Dupont <fdup...@isc.org> > 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 <fdup...@isc.org> 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 Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users