Creating a "Catch-All" Configuration

[Stier, Matthew]

I suspect your problem is the order in which they are listed in the DHCP configuration file.

My dhcpd.conf file is:

Options;
Classes;
Group {
  Options;
  Host {
  }
  Host {
 }
  Subnet{
    Pool {
    }
  }
}



From: dhcp-users-bounces+matthew.stier=us.fujitsu.com at lists.isc.org [mailto:dhcp-users-bounces+matthew.stier=us.fujitsu.com at lists.isc.org] On Behalf Of Scott Coleman
Sent: Wednesday, September 25, 2013 11:50 AM
To: Users of ISC DHCP
Subject: Creating a "Catch-All" Configuration

Hello all,

I manage a small /24 IP network used for the development of several types of embedded systems. These
embedded devices boot off of the network via TFTP, so the DHCP server (isc-dhcpd-4.1.1) supplies each one
with an IP address, a TFTP server address, and a unique boot image filename (multiple developers may be
working on different devices at any given time). My dhcpd.conf looks like this:

#
# DHCP Server Configuration file.
#
authoritative;
ddns-update-style none;
default-lease-time 86400;
max-lease-time 172800;
boot-unknown-clients false;

subnet 172.23.5.0 netmask 255.255.255.0
{
  option routers 172.23.5.254;
  option domain-name-servers 172.23.5.254;
  option interface-mtu 1412;
  next-server 172.23.5.254;
}

host dsu_157
{
  hardware ethernet 00:50:c2:af:3f:a7;
  filename "dsu_157";
  fixed-address 172.23.5.157;
}

host dcu_158
{
  hardware ethernet 00:50:c2:af:3f:f8;
  filename "dcu_158";
  fixed-address 172.23.5.158;
}

.
.
.

There are about 2 dozen separate host entries, one for each of the embedded devices currently in use. This setup has been working fine for a couple of years.

Now I would like to add a "catch all" to the system so that when a new device comes off our production line, someone can just plug it in to the network and receive a dynamically-assigned IP address as well as a "default" image filename which would be used in the event that there is no existing host entry in the dhcpd.conf file which matches the board's MAC address. The wrinkle is there are two different types of these devices - one called a DCU and the other a DSU - and each one requires a different type of software image to boot from.

My first thought was to use the client-id option to tell the DHCP server which type of embedded device is requesting an address. The bootloader in the DCU would send a client-id of "DCU" and the DSUsd would send a client-id of "DSU" so the server could specify a matching boot image filename. To this end, I set up two classes to match these client-ids and corresponding address pools from which to assign IP addresses. Here's what I came up with:

#
# DHCP Server Configuration file.
#
authoritative;
ddns-update-style none;
default-lease-time 86400;
max-lease-time 172800;
boot-unknown-clients false;

class "dcu"
{
  match pick-first-value (option dhcp-client-identifier, hardware);
}

class "dsu"
{
  match pick-first-value (option dhcp-client-identifier, hardware);
}

host unknown-dcu
{
  option dhcp-client-identifier 00:44:43:55;
}

subclass "dcu" 00:44:43:55;

host unknown-dsu
{
  option dhcp-client-identifier 00:44:53:55;
}

subclass "dsu" 00:44:53:55;

subnet 172.23.5.0 netmask 255.255.255.0
{
  pool
  {
    allow members of "dcu";
    deny members of "dsu";
    filename "dcu_default";
    range 172.23.5.16 172.23.5.23;
    deny unknown-clients;
  }
  pool
  {
    allow members of "dsu";
    deny members of "dcu";
    filename "dsu_default";
    range 172.23.5.24 172.23.5.31;
    deny unknown-clients;
  }
  option routers 172.23.5.254;
  option domain-name-servers 172.23.5.254;
  option interface-mtu 1412;
  next-server 172.23.5.254;
}

host dsu_157
{
  hardware ethernet 00:50:c2:af:3f:a7;
  filename "dsu_157";
  fixed-address 172.23.5.157;
}

host dcu_158
{
  hardware ethernet 00:50:c2:af:3f:f8;
  filename "dcu_158";
  fixed-address 172.23.5.158;
}

I then modified the bootloader on the devices (Das U-Boot) to send a client-id. This approach works for the "new" clients (the ones without a fixed-address host entry); they get assigned an address from the appropriate pool and use the "default" image file to boot from. And the existing clients (the ones with the older version of the bootloader which don't include a client-id in their DHCPDISCOVER requests) still get their fixed-addresses as before. The problem is when I update the bootloader on an existing client with a fixed-address host entry, such as dsu_157 in the snippet above. This causes the existing client to also provide a client-id with the DHCPDISCOVER request. In this case, based on what I read in the documentation, I would expect the fixed-address from the host entry to override the dynamic assignment, but that's not what
happens; the client instead gets a dynamic address from the pool and the default boot image name; the host entry with the fixed-address seems to be ignored. This is the exact opposite of the behavior that I am looking for.

What am I missing here? Is there a better way to accomplish my overall goal?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130925/d8570f5f/attachment-0001.html>