Re: [Kea-users] Client Classification options and subnet options

2017-08-31 Thread Jason Salmans
Francis Dupont writes:
> yes, you either need a big "or" or to wait for the shared network feature (we 
> are discuting about it but it is in still in requirement/ early design phase 
> so won't be available soon).

Ok, this should still be doable.  If not I know I could always look at the 
older ISC DHCP platform as well, we just started with Kea because it seemed to 
be recommended for newer deployments even though it isn't quite as fully 
featured yet.

> equal is == (vs =) and the hexadecimal value of the option matches better a 
> hexadecimal litteral so it is more "option[55].hex == 0x0103072B".

Yes I mistyped earlier with the single =.  This was exactly right as "test": 
"option[55].hex == 0x0103060F1F212B2C2E2F79F9FC" matches a Windows machines.  
Unfortunately, it matches too much Microsoft stuff as they seem to use all of 
the same Vendor ID and Option 55 requests for everything they make now.  I 
think at some point down the road we're going to have to look into something 
like Infoblox or another DDI solution that keeps and maintains a client 
classification database based on DHCP and Netflow so we can better identify 
some of these client types.

> you can debug the classification evaluation.

Thanks for the tip, that helped tremendously.

Thanks,
Jason Salmans
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users


Re: [Kea-users] Client Classification options and subnet options

2017-08-31 Thread Francis Dupont
Jason Salmans writes:
> Yes, I have several client-classes defined (let's say Class A, Class B, Cla=
> ss C, etc.) and I'm going to have multiple subnets defined (Subnet 1, Subne=
> t 2, etc).  The vast majority of my clients probably won't be classified at=
>  all so let's say they'll get Subnet 2.  Subnet 1 is the special and I'd li=
> ke Classes A, B, and C to all get IP addresses from Subnet 1.  I figure I c=
> ould condense all of them down to one client class and have a really large =
> test statement with a number of "or" operators but it seemed kind of messy =
> to do it that way and breaking them out into different classes allows more =
> options in the future if I need to assign special values of any kind.

=> yes, you either need a big "or" or to wait for the shared network
feature (we are discuting about it but it is in still in requirement/
early design phase so won't be available soon).

> I was assuming it would be something like "test": "option[55].hex =
> '1,3,7,43'"

=> equal is == (vs =) and the hexadecimal value of the option matches
better a hexadecimal litteral so it is more "option[55].hex == 0x0103072B".

> This loads correctly on service start but I don't think I've gotten it to
> successfully match to a client yet.

=> you can debug the classification evaluation.

Regards

Francis Dupont 
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users


Re: [Kea-users] Client Classification options and subnet options

2017-08-31 Thread Jason Salmans
Francis Dupont writes:

> I think you miss the fact client-classes are used to do subnet
> selection and not the opposite so when you specify a client-class in
> a subnet this means this particular subnet can be selected only by
> members of this class. Note that it means classification is done
> before subnet selection.

Yes, I have several client-classes defined (let's say Class A, Class B, Class 
C, etc.) and I'm going to have multiple subnets defined (Subnet 1, Subnet 2, 
etc).  The vast majority of my clients probably won't be classified at all so 
let's say they'll get Subnet 2.  Subnet 1 is the special and I'd like Classes 
A, B, and C to all get IP addresses from Subnet 1.  I figure I could condense 
all of them down to one client class and have a really large test statement 
with a number of "or" operators but it seemed kind of messy to do it that way 
and breaking them out into different classes allows more options in the future 
if I need to assign special values of any kind.

I should note that, in reality, every building I'm working with will have two 
subnets one of which will be the special one for these classified clients and 
the other for everything that isn't classified.  Each subnet has a relay 
specified which seems to further restrict what traffic can pull from each 
subnet.

> in theory yes but I am afraid the corresponding classification
> expression can be a bit hard to write.

I was assuming it would be something like "test": "option[55].hex = '1,3,7,43'"

This loads correctly on service start but I don't think I've gotten it to 
successfully match to a client yet.  I'm guessing that is not the correct 
format but it is a little difficult to see what it as I'm just looking at a 
Wireshark capture.

> yes, valid-lifetime, renew-timer and rebind-timer are supported
> parameters in DHCPv4 subnets.

Terrific, I'll start adding this to my config.

Thanks,
Jason Salmans
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users


Re: [Kea-users] Client Classification options and subnet options

2017-08-31 Thread Francis Dupont
Jason Salmans writes:
> First, is it possible to add more than one client-class to a subnet so that
> several client-classes will get assigned to that IP pool?  If so, what is
> the correct format?

=> I think you miss the fact client-classes are used to do subnet
selection and not the opposite so when you specify a client-class in
a subnet this means this particular subnet can be selected only by
members of this class. Note that it means classification is done
before subnet selection.

> Second, can Option 55 parameter request order be used to test
> against to assign a client to a particular class?  If so, again I'm
> having difficulty finding the correct command/formatting I need to
> try.

=> in theory yes but I am afraid the corresponding classification
expression can be a bit hard to write.

> Third, is it possible to set per subnet lease times?

=> yes, valid-lifetime, renew-timer and rebind-timer are supported
parameters in DHCPv4 subnets.

Regards

Francis Dupont 
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users