OMAPI support for classes and subclasses
  • 13 Jul 2021
  • 3 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

OMAPI support for classes and subclasses

  • Dark
    Light
  • PDF

Article Summary

ISC DHCP 4.3 enhances OMAPI support for adding and deleting classes and subclasses. This allows you to dynamically add or remove classes and subclasses rather than needing to modify your configuration file and then restart the server.

The primary use for this feature is to allow for dynamic control of clients. As one example, you might first create a set of pre-defined classes, then as clients register via a captive portal you could assign them to specific classes and pools via dynamic subclass statements.

Let us start with a basic example. The following is a snippet from a configuration file showing some classes, subclasses and pools. We have left out much of the information that would be in a typical configuration file to concentrate on the use of classes and subclasses. In this example we have two classes, test_class1 and test_class2; both of these are selected based on the hardware address of the client. They each have an example subclass to show how you previously needed to add a client. They also each use the lease limit statement as a test case; you could replace that with other statements you wish to specify for the classes or subclasses directly. Finally, there is a single subnet with two pools, one for each of the classes. In this example the only difference between classes is the different range of addresses, but you could specify other statements to provide different service for the two classes.

# We start with two test classes for which we have pools
# and can create subclasses 

class "test_class1" {
    match hardware;
    lease limit 4;
}

subclass "test_class1" 1:00:01:02:03:04:05 {
    lease limit 5;
}

class "test_class2" {
    match hardware;
    lease limit 2;
}

subclass "test_class2" 1:10:11:12:13:14:15 {
    lease limit 3;
}

# A basic subnet declaration that has pools for
# both of the above classes

subnet 172.16.132.0 netmask 255.255.255.0 {
    pool {
        allow members of "test_class1";
        range 172.16.132.150 172.16.132.160;
    }
    pool {
        allow members of "test_class2";
        range 172.16.132.170 172.16.132.180;
    }
}

In previous versions, if you wished to add a new subclass, you would need to edit your configuration file to add the new subclass or subclasses and then restart the server. With the new feature, and assuming you have enabled OMAPI, you can use a program such as OMSHELL to send OMAPI commands to the server to add or remove the subclass while the server continues to run. The dynamic information will be stored in the lease file to allow the server to re-learn it on startup.

An OMSHELL session would look something like the following:

server <ip address of server>
key DHCP_UPDATER <key> 
connect
> obj: <null>

new subclass 
> obj: subclass
set name = "test_class1"
> obj: subclass
name = "test_class1"
set hashstring = 01:00:50:56:32:02:02
> obj: subclass
name = "test_class1"
hashstring = 01:00:50:56:32:02:02
create 
> obj: subclass
name = "test_class1"
hashstring = 01:00:50:56:32:02:02
lease-limit = 00:00:00:04
leases-used = 00:00:00:00
close  
> obj: <null>

new subclass
> obj: subclass
set name = "test_class1" 
> obj: subclass
name = "test_class1"
set hashstring = 01:00:01:02:03:04:07
> obj: subclass
name = "test_class1"
hashstring = 01:00:01:02:03:04:07
create 
> obj: subclass
name = "test_class1"
hashstring = 01:00:01:02:03:04:07
lease-limit = 00:00:00:04
leases-used = 00:00:00:00
close    
> obj: <null>

The first block shows the standard set-up to connect the omshell program to the DHCP server. Each of the second two blocks shows us adding one new subclass to test_class1. We first need to allocate a new subclass structure within omshell via the new command. We then fill in information for the subclass with the name and hashstring commands. The name is the name of the class to which this subclass belongs, while the hashstring is the value used for matching. In this case, as we have previously defined the class to match on the hardware value, we provide 7 bytes for the match; the first byte is the type of hardware address (Ethernet) and the next 6 bytes are an example ether address. Once we have filled in the information we can have omshell transmit it to the server by calling create. And finally we clean up by calling close.

The lease file would then have entries similar to this:

subclass "test_class1" 01:00:50:56:32:02:02 {
  dynamic;
 lease limit 4;
}

To remove an entry, you would again create a subclass and fill in the appropriate information, then use the open command to find the corresponding structure on the server. To actually delete the structure you would use the remove command.