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

[David Sotnick]

Anyone? Mr. Hankins?

Surely someone must have some insight here...

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 138.72.199.0 netmask 255.255.255.128 {
>   option routers 138.72.199.126;
>   option broadcast-address 138.72.199.127;
>   option subnet-mask 255.255.255.128;
>
>   # Dynamic DHCP pool for new hosts not yet in DHCP
>   pool {
>     allow unknown-clients;
>     ddns-updates off;
>     range 138.72.199.1 138.72.199.63;
>     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 138.72.199.64 138.72.199.124;
>     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 138.72.129.254: 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
>
>