ISC DHCP - Classes and Subclasses

Classes provide a user-definable definition of a common set of clients that possess the characteristics defined within a class declaration. Classifying clients is useful for enabling the server to identify different client types and to provide corresponding IP addresses and/or configuration parameters via options. The number of active leases assigned to class members can also be restricted within class definitions.

Subclasses

A class definition will typically include a match statement to identify members of the class. The match statement may define an explicit match value or may simply match the attribute on which to perform a match comparison. One or more subclasses may be defined to define parameters for each match value. Subclasses take on the same name as the class to which they belong but enable specification of match values for the attribute (DHCP packet field) defined in the class declaration. Use of subclasses generally provides faster performance for class lookups.

where name is the subclass name which matches a class name and match-value is the value of the expression matching the value of the attribute in the DHCP packet corresponding to the field name defined in the class declaration match statement.

Let’s look at an example to clarify. Let’s say we’re rolling out VoIP and I have two phone vendor products I’d like to support using DHCP. They both provide different values within the vendor class option value: vendor1 and vendor2 respectively. We would like to define this class to match on the vendor class field. We’ll then define two subclasses one for each match value vendor1 and vendor2 as follows.

Limiting outstanding leases per client class

The lease limit statement has a single integer parameter which specifies the maximum number of leases that can be provided to clients matching this class. This functionality is commonly used in broadband environments to limit the number of IP addresses a given subscriber may obtain based on subscribed service levels. In this case a client class based on the relay agent information option enables the DHCP server to identify the subscriber based on the subscriber’s circuit connection identifier or customer premises modem MAC address.

This lease limitation feature within a broadband environment also drove the development of class spawning which enables dynamic creation or spawning of client subclasses on the fly based on information in the DHCP packet. The spawn with declaration defines a spawning class with the parameter on which to base the spawn.

For example going back to our broadband example the DHCP server can be configured to spawn client classes based on the circuit ID relay agent suboption. Thus when a DHCPDISCOVER is received by the DHCP server it analyzes the circuit ID suboption. If a class exists (was previously spawned) for the given value the corresponding parameters and declarations are analyzed for processing; if a class with that circuit ID does not exist the DHCP server spawns a subclass for the given value. The example below illustrates the definition of a broadband client class with a spawning subclass based on the circuit ID that limits outstanding subscriber leases to a maximum of 6.