Declaring the subnets in ISC DHCP
  • 25 Sep 2018
  • 3 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Declaring the subnets in ISC DHCP

  • Dark
    Light
  • PDF

Article Summary

It's necessary to declare the subnets in dhcpd.conf for any interfaces on which you want to use DHCP protocols:

  • the subnets on which you are listening for and responding to client requests and leasequeries.
  • the subnets for which you are providing client leases.

The need to declare the subnets on which the server is listening as well as those for which client leases are being provided is sometimes surprising to administrators, but the necessity is because of the way that the ISC DHCP code interfaces with the kernel and networking layers of the host operating system.

Let's step back and look at how DHCP uses its UDP sockets.

1.  Listening for and responding directly to local clients

By default, DHCP will scan for and open sockets on all local interfaces.

DHCP opens two sockets for responding to local clients, a raw socket and a 'normal' socket.

Dynamic Host Configuration Protocol (RFC 2131) requires that DHCP messages from the booting clients are sourced from the all-zeroes address and sent to the all-ones limited broadcast address (0.0.0.0 and 255.255.255.255). These special addresses are used in the initial bootstrapping of a DHCP client, when the client does not yet have an address.

Without coding vast amounts of platform-specific skulduggery, we can't reliably transmit packets of that form via a straight UDP socket; receiving packets of that form is even less reliable (and that's without default local firewall rules trying to helpfully throw out "Martians"). So we use raw sockets, and that means we open a raw socket for every interface declared on the command line, plus a UDP socket overall.

The raw sockets perform only "funny packet" transmission, these all-ones limited broadcasts or unicast-without-arps, and all packet reception. The overall UDP socket ("fallback interface" in internal parlance) has a reader that drops every packet read from it (based on the assumption that all packets read in this way are duplicates of packets read from raw sockets), and is only used to transmit "routable" replies to clients, e.g. clients performing lease renewals.

You can read more about DHCP and raw sockets in these two KB articles:

This is the simple and intuitive case where the subnets you declare are both those on which the server is listening and at the same time those for which client leases are being provided.

2.  Listening for and responding to client requests that are relayed to the server from non-local subnets

In this scenario a DHCP relay local to the clients will be encapsulating and forwarding the client requests to the DHCP server. Even though the server may not be serving leases directly (and have no pools defined using this subnet), you will still need to declare the local subnets in dhcpd.conf so that relayed client requests can be serviced.

You will therefore need to declare both the subnets for which you are serving leases and then in addition those subnets upon which DHCP will listen for and service the relayed client queries.

3.  Listening and responding to leasequery requests

Note: ISC DHCP supports only basic lease query over UDP
ISC DHCP does not support bulk lease query or active lease query. ISC DHCP's leasequery is UDP-only - both bulk lease query and active lease query use a TCP-based implementation.

The UDP socket can be used to transmit to a renewing DHCP client, but it cannot be used to receive leasequeries.

So to receive leasequeries on other interfaces, the interface must be listed on the command line (if interfaces are listed on the command line, otherwise all interfaces are read by default) and ISC DHCP configuration requires that all read interfaces are associated with a subnet declaration.

In the example below, the administrator wants only to listen for leasequeries on this interface - the DHCP service is provided on other interfaces:

subnet 192.168.22.0 netmask 255.255.255.0 {
     not authoritative;
     ignore booting;
     }

To be able to respond to leasequeries, DHCP needs to be configured globally or per subnet
The sample configuration snippet above permits DHCP to receive the leasequery requests. In addition, the server needs to be configured to respond to those queries. This is enabled by adding allow/deny leasequery at the appropriate scope(s).