ISC DHCP sub classes
ISC DHCP support sub classes:
In addition to classes, it is possible to declare subclasses. A subclass
is a class with the same name as a regular class, but with a specific
submatch expression which is hashed for quick matching. This is
essentially a speed hack - the main difference between five classes with
match expressions and one class with five subclasses is that it will be
quicker to find the subclasses. Subclasses work as follows:
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;
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
allow members of "allocation-class-1";
range 10.0.0.11 10.0.0.50;
}
pool {
allow members of "allocation-class-2";
range 10.0.0.51 10.0.0.100;
}
}
The data following the class name in the subclass declaration is a
constant value to use in matching the match expression for the class.
When class matching is done, the server will evaluate the match
expression and then look the result up in the hash table. If it finds a
match, the client is considered a member of both the class and the
subclass.
Subclasses can be declared with or without scope. In the above example,
the sole purpose of the subclass is to allow some clients access to one
address pool, while other clients are given access to the other pool, so
these subclasses are declared without scopes. If part of the purpose of
the subclass were to define different parameter values for some clients,
you might want to declare some subclasses with scopes.
In the above example, if you had a single client that needed some
configuration parameters, while most didn't, you might write the
following subclass declaration for that client:
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
option root-path "samsara:/var/diskless/alphapc";
filename "/tftpboot/netbsd.alphapc-diskless";
}
In this example, we've used subclassing as a way to control address
allocation on a per-client basis. However, it's also possible to use
subclassing in ways that are not specific to clients - for example, to
use the value of the vendor-class-identifier option to determine what
values to send in the vendor-encapsulated-options option. An example of
this is shown under the VENDOR ENCAPSULATED OPTIONS head in the
dhcp-options(5) manual page.
Sub-classes are essentially an improvement in both the evaluation process (match expression is evaluated once and its value is compared with a hash table) and configuration (less things to repeat and exposed relationship). The same idea can be used in Kea: currently Keama just recombines match expression and value in regular classes, losing the fact the parent depends on a matching sub class...