Two different IP addresses leased out to the same device
davec at columbia.edu
Fri Sep 11 01:35:39 UTC 2009
On Sep 9, 2009, at 11:45 AM, Simon Hobson wrote:
> Frank has hinted at this, I'll expand and explain.
> As far as the server is concerned, they are different clients as
> required by the RFC.
> One lease has a UID (aka Client-ID) which therefore forms the
> primary key in the database - the other has no UID and so the server
> falls back to using the MAC address.
> This is a longstanding issue when a machine boots with multiple DHCP
> clients - and it's mostly down to Microsoft that the problem exists.
> The RFC doesn't specify what should be in the Client-ID, and
> Microsoft decided that putting the MAC address in there made sense.
> This isn't wrong, just different to everyone else who default to not
> supplying a Client-ID at all.
> It first started popping up when people were multi-booting into
> Windows and other OS's like Linux. Then PXE came along and added to
> it. There have been patches to fudge the request packets (either
> remove the Client-ID or add it).
> A proposed feature that I believe never made it was to allow the
> administrator to configure the database key - it currently defaults
> to "pick-first(client-id, hardware)". If changed to just plain
> "hardware" then Client-ID would be ignored.
What is the expected behavior on lease renewal if a client is
initially issued a lease keyed on UID/Client-ID, but then the client's
hardware address is added to a class that is denied access to the pool
from which the original lease was issued? I would hope the "deny
members of" configuration would take precedence even though it's based
on hardware address instead of UID, but I believe I'm seeing behavior
that suggests otherwise. Note this is on an older 3.0.x release, so
if this is a bug known to be fixed in a later version that would
definitely prompt me to upgrade sooner.
More information about the dhcp-users