A DHCP client class is a widely used mechanism for differentiating and classifying devices on your network based on specific configuration criteria. This classification allows you to assign DHCP addresses or options based on specific device characteristics or a network identifier. Users configure client classes using a string/expression that specifies certain device characteristics—such as the MAC address, vendor options, or network identifier—used to match the device to a scope or scope group before assigning an IP address.
Grouping devices using client classes makes it easier to apply configuration settings in bulk—such as applying common DHCP options or restricting access to subnets to adhere to network and security policies. A client class can be configured such that devices within that class are assigned IP addresses in subnets restricted from the public internet due to a security policy applied to the subnet/network on the router or firewall. This simplifies device management and control across the network while enabling better auditing and reporting processes for IT/network teams.
Devices can be associated with a client class in a few different ways using:
a vendor class option or another built-in condition,
an expression that evaluates to “true” (e.g. matching the vendor portion of the MAC address),
a network identifier, such as a relay agent or circuit ID,
static host reservations, shared network, a subnet, or
In the NS1 Connect portal, only client classes for DHCPv4 are supported and users can configure client classes to send a specific option or provide access to a specific subnet. At this stage, NS1 assumes users can design their own expressions. For reference on client classification, see here.
One use case for client classes in enterprise networks is grouping devices based on the network topology. This is done by creating a client class that reflects a network identifier called a relay agent, which relies on the gateway IP address (giaddr) to communicate with DHCP servers. The relay agent is a router/switch configuration that forwards the DHCP packets for the clients from a particular region (or building, floor, campus, etc.) to the DHCP server. Based on that relay agent address, the DHCP server assigns an IP address from the appropriate subnet with the corresponding client class specified. For example, if you have a subnet 172.16.1.0 with a client class applied whose relay agent address is 172.16.1.1, then client DHCP packets coming from the relay agent (giaddr) address 172.16.1.1 are assigned an address from the 172.16.1.0.
Another common use case includes the following:
grouping clients on your network that have different routing and security policies (e.g., a cable modem in the service provider network vs. the clients behind that modem)
grouping types of clients that have different behavior (e.g., smartphone vs. laptop)
For example, in a service provider network, client classes can be used to provide DHCP options to the cable modem. The client class can be configured to check for “option 60.” If the string “docsis” matches, the response from the DHCP server includes DHCP options—such as TFTP, SiAddr, and the name of the configuration file—required for the cable modem to initialize properly. You can also assign the DHCP client/device to a specific subnet based on the relay agent client class.
Follow the steps below to create a DHCP client class in the NS1 Connect portal:
Navigate to DHCP > Client Class.
Click the + button in the upper-right corner to initiate the Create Client Class modal.
Enter a name for the client class. Note that you cannot change the name after creating the client class.
Under Add Test, enter an expression that specifies the test conditions in order for a client to be considered a member of this client class.
For more information on creating expressions for DHCP class matching, refer to the related Kea documentation.
In the screenshot example above, the vendor identifier is provided by DHCP option 60. The example test checks if the first four characters of the vendor identifier match "MSFT."
Optionally, under Settings, complete the following form fields:
Next Server: IP address of the TFTP server where the configuration is stored
Boot File Name: file name where the configuration is stored
Server Host Name: host name of the TFTP server where the configuration is stored
Click Save client class. The client class is added to the list. Note that when you select the client class, the test details appear on the right.
Follow the steps below to add DHCP options to a client class in the NS1 Connect portal:
Navigate to DHCP > Client Class, select a client class from the list, and click the menu (three-dots) icon to the right. Then select Add DHCP Options from the list.
In the Add DHCP Options modal, use the search bar to start typing the name of the DHCP option you want to add to this client class. You have the option to filter by the type of option space via the corresponding checkboxes.
Once the option appears, select it from the list. Depending on the selected option, additional sub-options may appear. Add, remove, and edit as desired.
After you select one or more options, consider the following regarding the Always Send checkbox for each option:
If enabled, the DHCP server will always send this option in a response
If not enabled, the DHCP server will only send this option when requested by a client
Click Save DHCP options to save changes, and then click X to exit the modal.
Follow the steps below to apply a DHCP client class to a scope group in the NS1 Connect portal:
Navigate to DHCP > Management to view a list of existing scope groups.
Click the menu (three-dots) icon next to the desired scope group and click Apply Client Class.
In the Apply Client Class modal, use the drop-down menu to select one or more client classes from the list.
Click Save client class. Now, the scope group will match clients to the selected client classes.