[Kea-users] Client Classification options and subnet options

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

[Kea-users] Client Classification options and subnet options

Jason Salmans

Greetings all,

 

I’m attempting to assign certain client types IPs from a different subnet.  The original interface is an SVI with a primary and secondary IP address (Multinet).  I got this all working with a single client classification but I’m hitting a few snags while trying to add the others.  I’ve been looking for examples on some of this stuff but haven’t found anything and trial and error has hit dead ends.

 

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?

 

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.

 

Third, is it possible to set per subnet lease times?  Some of our subnets have a very limited number of IP addresses so I’d like to try to help with this by setting a lower lease time but leave a higher lease time on the larger subnets.

 

Thanks,

Jason Salmans


_______________________________________________
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] Client Classification options and subnet options

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 <[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] Client Classification options and subnet options

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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

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 <[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] Client Classification options and subnet options

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