Subnet Selection and Client Classes
  • 12 Jan 2023
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Subnet Selection and Client Classes

  • Dark
    Light
  • PDF

Article Summary

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:

"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.