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

[David Sotnick]

Oh, and to clarify-- the request in the log entry below comes from
138.72.129.254, but that subnet is also defined with a range which allows
'members of dynamic-hosts', like so:

subnet 138.72.129.0 netmask 255.255.255.0 {
  option routers 138.72.129.254;
  option broadcast-address 138.72.129.255;
  option subnet-mask 255.255.255.0;

  pool {
    deny unknown-clients;
    allow members of "dynamic-hosts";
    ddns-updates on;
    range 138.72.129.1 138.72.129.240;
    default-lease-time 7200;
    max-lease-time 7200;
  }
}

And yet, still the server is throwing a 'no free leases' message.

I have since done some tcpdumps and analyzed the output in wireshark.
The client is sending exactly the same packet each time, and in one case
when I changed the host {} definition to have the hardware ethernet
address in lower-case (an admin had changed it to all upper case), the
client was suddenly allowed to get a lease from the dynamic-hosts pool.

This all seems very intermittent and unpredictable and is causing me to
worry about our DHCP service even as I sit in the sun at a campsite,
supposedly on vacation...

-David

On Thu, 9 Aug 2007, David Sotnick wrote:

> 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
> >
> >
>
>