Creating a "Catch-All" Configuration

[Scott Coleman]

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/9dd84813/attachment.html>