Unexpected behavior when moving from 'unknown' to 'known'

David Sotnick sotnickd-dhcp at ddv.com
Sun Aug 12 04:46:26 UTC 2007

Mea culpa.

Turns out that the FreeBSD-6.* port of isc-dhcp3-server-3.0.5.r2 (from the
ports collection) changed the name of the startup script it installs. It
moved from:




Very subtle difference that didn't make it into my script that
auto-generates the dhcpd config file, tests the new config and restarts
the server. I would have noticed the DHCP server not restarting, but since
our script tests the config before putting it into place, it looked (in
the log file) like the server *was* restarting.

I feel like an idiot, but I suppose I have the excuse that I've been
working way too hard the past few weeks. :)


On Tue, 7 Aug 2007, David Sotnick wrote:

> I recently upgraded from dhcp-server 3.0.1r5 to 3.0.5r2, and then to
> 3.0.6. My operating system is FreeBSD 6.2-CURRENT.
> I have cases where users machines will be unknown, that is there is no
> host entry for the host (when it is new out of the box), and then once the
> machine is built-out ("bootstrapped"), a host entry is added to the dhcp
> config file.
> We have a small range of IP addresses we hand out to these uknown-clients,
> and a separate range for the client when it is known to us. Both ranges
> are in the same subnet.
> Under version 3.0.1r5 this was all working fine, but now I'm seeing some
> reproducable and undesired effects.
> Here's the class and subnet definition:
> class "dynamic-hosts" {
>     match hardware;
> }
> # begin:mac-metro-buildout
> subnet netmask {
>   option routers;
>   option broadcast-address;
>   option subnet-mask;
>   # Dynamic DHCP pool for new hosts not yet in DHCP
>   pool {
>     allow unknown-clients;
>     ddns-updates off;
>     range;
>     default-lease-time 3600;
>     max-lease-time 3600;
>   }
>   # Dynamic DHCP pool with ddns-enabled for dynamic hosts:
>   pool {
>     deny unknown-clients;
>     allow members of "dynamic-hosts";
>     ddns-updates on;
>     range;
>     default-lease-time 3600;
>     max-lease-time 3600;
>   }
> }
> # end:mac-metro-buildout
> And here's a sample host entry for one of these hosts, after it's been
> built-out and is now 'known' to us, and in DHCP:
> host macbrenda-en0 {
>   option host-name "macbrenda";
>   ddns-hostname "macbrenda";
>   hardware ethernet 00:17:f2:09:da:8e;
> }
> subclass "dynamic-hosts" 1:00:17:f2:09:da:8e;
> In case you were going to ask, I'm matching against 'hardware' and not
> 'dhcp-client-identifier', in my class statement because I want to match
> against something the user cannot change.
> Now, when the host first connects, it's unknown (the above host entry
> doesn't yet exist in the config), and so it gets assigned an IP from the
> pool for unknown-clients. The client gets a lease from the range in the
> first pool, and the lease gets written to the dhcpd.leases file.
> Now for the interesting part... The client then gets added to the dhcp
> config file, and is now considered 'known', and is part of the subclass
> 'dynamic-hosts'. BUT, (I assume) since there is a lease for the client in
> the dhcpd.leases file, the dhcp-server is responding to DHCP requests from
> the client with "no free leases"
> Aug  6 17:17:23 arbiter dhcpd: DHCPDISCOVER from 00:17:f2:09:da:8e via network 138.72.129/24: no free leases
> So I stop the dhcp-server, remove the two lease/binding entries for the
> host, and start the server again, and now, when the client connects, it
> obtains the lease, as it should, from the pool of known-clients.
> Since I wrote this, I realized I have "deny duplicates;" at the top of my
> config file. I added "allow duplicates;" to the subnet declaration for the
> subnet above, and it seems to have fixed the problem.
> Is this expected behavior?
> Thanks,
> David Sotnick
> --
> Tech. Lead - Unix Infrastructure
> Pixar Animation Studios
> Emeryville, CA

More information about the dhcp-users mailing list