---
title: "Subnet Selectors and Client Classes in Kea DHCP"
slug: "subnet-selection-and-client-classes"
description: "Client class statements selectively block access to certain subnets."
tags: ["kea dhcp"]
updated: 2023-01-12T08:39:06Z
published: 2023-01-12T08:39:06Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Subnet Selection and Client Classes

#### How can you use a client class to select a subnet in a shared network?

Configuration of client classes does not _select_ subnets by itself. Instead, client classes can be used to selectively block access to certain subnets. When you have different client classes specified for two subnets, it DOES NOT instruct the server to pick one subnet for one client class and another one for a different client class. It is interpreted by the server as "this subnet can ONLY be used by DHCP clients belonging to this class, and that other subnet can ONLY be used by DHCP clients belonging to that class."

When the Kea server gets a DHCP packet it first selects a subnet. This selection is NOT based on client classification; it is based on what we call subnet selectors. The most typical subnet selector for the case of relayed traffic is the relay IP address. The following configuration structure:

```json
"relay": {
    "ip-addresses": [ "192.0.2.1", "192.0.2.2" ]
}
```

can be added to a subnet or a shared network configuration. If you add this to a shared network, it is the equivalent of adding this selector to all subnets within the shared network.

When the server gets a DHCP packet, it iterates over the configured subnets and picks the FIRST ONE which matches. In this case, it is matching the `giaddr` to the list of  relay addresses in the statement above. When it finds a match, it then checks whether this particular client can use this subnet per client classification. If not, it goes to the next subnet, and so on.

For example: for the unrestricted client it will use giaddr of `192.0.2.2` to select subnets. The restricted subnet will be found first, but the server will not use it because it is guarded by the restricted class. So it will then check the next subnet and will compare `giaddr` with the list of IP addresses and will find the match. Because the client class for this second subnet is matching the client classification made for the packet, it will remain in this subnet.

If you don't provide any subnet selectors, the Kea server uses the `giaddr` in the received packet and matches it with the prefixes of configured subnets. For example, suppose there are two subnets configured: `198.51.100.0/22` and
`192.0.2.0/24`. The restricted client's packet is received via relay `198.51.100.2`, which matches the first subnet prefix, so this subnet is selected for the client. Since the client classification guard also allows this subnet to be used by this client, everything is fine.

When the unrestricted client sends the packet via relay agent `192.0.2.2`, the server again tries to find a suitable subnet by subnet prefix matching. The one that matches is the restricted subnet, but the server eliminates this subnet because the client classification guard doesn't permit using this subnet. The second subnet is not selected for the client because the relay agent `192.0.2.2` does not match the subnet prefix `192.168.30.0/24`. There are no more subnets, so the server gives up and does not provision this client.