Class membership

Patrick Trapp ptrapp at nex-tech.com
Fri Oct 16 16:48:54 UTC 2015


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: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Simon Hobson [dhcp1 at thehobsons.co.uk]
Sent: Friday, October 16, 2015 11:10 AM
To: Users of ISC DHCP
Subject: Re: Class membership

Patrick Trapp <ptrapp at nex-tech.com> 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
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


More information about the dhcp-users mailing list