ISC DHCP Users

Class membership

Classic

List

Threaded

4 messages Options

Patrick Trapp

Class membership

Now that I (think I) understand Rafal's desired result, he's got me thinking about my configuration and a long-standing request from management and a question comes to mind:

Can I use membership of a class A to qualify members of a class B? Can I have multiple class assignments for the same class?

Most devices on my particular network are members of two distinct and currently unrelated classes - one related to their boot options, another related to their network.

He's got me thinking that if I can say all members of the following boot option classes are also members of this overall class, I can use the larger class to make my network assignments without having to identify each of the boot-option classes in every single pool I define.

Alternatively, if I can define the members of the larger class at the same time that I define them as members of each smaller boot-option class (thereby requiring me to be able to assign devices to the larger class in many different places), I can get the desired result, as well.

All very theoretical. I have a lot of classes in use, but no subclasses - haven't wrapped my head around them yet - and what I'd love to do here might use that construct, but I'm not sure.

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

Simon Hobson

Re: Class membership

Patrick Trapp <[hidden email]> wrote:

> Can I use membership of a class A to qualify members of a class B? Can I have multiple class assignments for the same class?

I don't think so.

> Most devices on my particular network are members of two distinct and currently unrelated classes - one related to their boot options, another related to their network.
>
> He's got me thinking that if I can say all members of the following boot option classes are also members of this overall class, I can use the larger class to make my network assignments without having to identify each of the boot-option classes in every single pool I define.

You can make "arbitrarily" complex rules for class membership.

So if Class A has membership for devices matching "condition A", and class B has members matching "condition B" (which do not have to be mutually exclusive), then you can define class AB as having members which match "condition A or condition B", and then instead of saying :
allow members of "class_a"
allow members of "class_b"

you can instead say just :
allow members of "class_ab"

The problem is that this may not scale well for some setups where the permutations of classes and/or the complexity of membership conditions results in unwieldily quantity of classes or the membership conditions.

> All very theoretical. I have a lot of classes in use, but no subclasses - haven't wrapped my head around them yet

In the simple form, it's not complicated. It's particularly useful where you have a list (eg of MAC addresses) to put into a class. You could write something like :
match if hardware = "something" or hardware = "something else" or hardware = "yet another value or ...

but that gets really messy (and computationally expensive) if the list if other than very short. If you look at the subclasses section of the man page, you'll see that this is simply done with subclasses like this :

> class "allocation-class-1" {
> match pick-first-value (option dhcp-client-identifier, hardware);
> }
>
> class "allocation-class-2" {
> match pick-first-value (option dhcp-client-identifier, hardware);
> }
>
> subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
> subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
> subclass "allocation-class-1" 1:0:0:c4:aa:29:44;

So you can see that it's trivially easy to make arbitrarily long lists of membership "values".

However, what you can't do is assign a device to two or more classes in one statement. So if one class were based on MAC address, and another based on vendor ID, you'd still need two statements to put the client into the two classes - and if you wanted a superclass (say all 3 clients in the example above) then you'd need to duplicate all the subclass statements :
class "allocation-class-1" {
match pick-first-value (option dhcp-client-identifier, hardware);
}

class "allocation-class-2" {
match pick-first-value (option dhcp-client-identifier, hardware);
}

class "allocation-class-1-or-2" {
match pick-first-value (option dhcp-client-identifier, hardware);
}

subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-1-or-2" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1-or-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
subclass "allocation-class-1-or-2" 1:0:0:c4:aa:29:44;

and that too would quickly become a bit of a management issue unless you use automated tools to maintain the lists.

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

Patrick Trapp

RE: Class membership

Thank you, Simon.

I already have "arbitrarily complex" class membership rules in place, but the complexity in this case helps make them manageable because they are very consistent. The task I'm looking at would ramp up the number of classes pretty severely. I have several dozen of the "boot options" classes and over 200 of the network pools options. The creation of "class_ab" statements would essentially be a multiplier - I would be looking at thousands of classes and if one needed to be changed, 200 others would need to be, as well. Which is why I haven't completed this task.

However, subclasses deserve a much closer look than I have given them. Am I correct in thinking that I can refer to the class as a whole in addition to the individual subclasses? So given class A with subclass 1A and subclass 2A, I could use an allow statement against class A, subclass 1A, or subclass 2A (or potentially some silly combination thereof)? That would resolve a lot of potential issues and management headaches, it would.

________________________________________
From: [hidden email] [[hidden email]] on behalf of Simon Hobson [[hidden email]]
Sent: Friday, October 16, 2015 11:10 AM
To: Users of ISC DHCP
Subject: Re: Class membership

Patrick Trapp <[hidden email]> wrote:

> Can I use membership of a class A to qualify members of a class B? Can I have multiple class assignments for the same class?

I don't think so.

> Most devices on my particular network are members of two distinct and currently unrelated classes - one related to their boot options, another related to their network.
>
> He's got me thinking that if I can say all members of the following boot option classes are also members of this overall class, I can use the larger class to make my network assignments without having to identify each of the boot-option classes in every single pool I define.

You can make "arbitrarily" complex rules for class membership.

So if Class A has membership for devices matching "condition A", and class B has members matching "condition B" (which do not have to be mutually exclusive), then you can define class AB as having members which match "condition A or condition B", and then instead of saying :
allow members of "class_a"
allow members of "class_b"

you can instead say just :
allow members of "class_ab"

The problem is that this may not scale well for some setups where the permutations of classes and/or the complexity of membership conditions results in unwieldily quantity of classes or the membership conditions.

> All very theoretical. I have a lot of classes in use, but no subclasses - haven't wrapped my head around them yet

In the simple form, it's not complicated. It's particularly useful where you have a list (eg of MAC addresses) to put into a class. You could write something like :
match if hardware = "something" or hardware = "something else" or hardware = "yet another value or ...

but that gets really messy (and computationally expensive) if the list if other than very short. If you look at the subclasses section of the man page, you'll see that this is simply done with subclasses like this :

Simon Hobson

Re: Class membership

Patrick Trapp <[hidden email]> wrote:

> Am I correct in thinking that I can refer to the class as a whole in addition to the individual subclasses? So given class A with subclass 1A and subclass 2A, I could use an allow statement against class A, subclass 1A, or subclass 2A (or potentially some silly combination thereof)?

No, they don't work like that. The subclasses don't have names, and you can't refer to them.
If you look at the example, it's simply a quick and efficient method to provide a list of members - so I suppose "subclass" is perhaps a slightly misleading name.

If you read down the man page a bit, you'll find there are other things you can do. IIRC the example given is to spawn a subclass based on end-user port (ie option 82) - and apply restrictions per subclass (eg only 3 DHCP leases at any time). But you still cannot refer to any individual subclass by name.

I have no idea how much work it would be to allow a class to be defined by reference to another class membership. I suspect it would be a lot since it's come up before.

One stumbling block I could see (as a non-programmer) is that the config is object based and there is no defined execution order (ie putting one declaration ahead of another in the config file does not mean it'll be executed first) - so you'd need to introduce some ordering to class membership evaluation to ensure that the referenced classes were evaluated for membership priot to other classes that use that information. I suspect this is "non trivial".

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