Re: [Kea-users] Client Classification options and subnet options
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
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
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
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