Class membership

Simon Hobson dhcp1 at thehobsons.co.uk
Fri Oct 16 16:10:51 UTC 2015


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.



More information about the dhcp-users mailing list