Duplicate lease, different ip.
dpower at fnb.co.za
Wed May 2 09:30:24 UTC 2007
I downloaded "dhcp-3.1.0a3.tar.gz" after configuring and runing "make"
and "make install" without errors or warnings. I then run the command
"service dhcpd restart" and get the following error:
Shutting down DHCP server done
Starting DHCP server Internet Systems Consortium DHCP Server V3.1.0a3
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
Usage: dhcpd [-p <UDP port #>] [-d] [-f]
[-cf config-file] [-lf lease-file]
[-t] [-T] [-s server] [if0 [...ifN]]
If you did not get this software from ftp.isc.org, please
get the latest from ftp.isc.org and install that before
If you did get this software from ftp.isc.org and have not
yet read the README, please read it before requesting help.
If you intend to request help from the dhcp-server at isc.org
mailing list, please read the section on the README about
submitting bug reports and requests for help.
Please do not under any circumstances send requests for
help directly to the authors of this software - please
send them to the appropriate mailing list as described in
the README file.
On Mon, 2007-04-30 at 20:28 +0100, Simon Hobson wrote:
> Bruce Hudson wrote:
> > > I have some strange things happening with my dhcp server.
> >> I am running SLES 10 with isc-dhcpd-V3.0.3
> > The difference between the two leases is that the first request does
> >not include a client identifier and the second does. In theory, the first
> >(without an identifier) should always get one address and the request with
> >an identifier should alway get a second since it is a different client.
> > However, the first time the server see a request with an identifier it
> >will "upgrade" an existing lease for that client address that does not have
> >one by adding it. The process is not reversible so any requests there-after
> >without an idetifier are a different client. There was an ancient message
> >to the list from Ted Lemon that called this "tragically unavoidable".
> > This doesn't really change anything in your case, except for which IP
> >is kept in use. Setting up a host stanza with "deny duplicates" should take
> >care of your problem. It tells the server to discard any existing leases
> >for the specified hardware address, even if the client identifiers do not
> Alternatively, you have two other options :
> 1) Configure your clients so that they all use the same client
> identifier - although that does somewhat negate some of the benefits
> of DHCP.
> 2) There is a patch that 'synthesises' a client-id if none is
> supplied (I think that's how it works). From the archives :
> >Date: Tue, 12 Dec 2006 07:43:57 +0200
> >From: Yedidyah Bar-David <didi at cs.tau.ac.il>
> >To: dhcp-users at isc.org
> >Subject: Re: status update
> >On Mon, Dec 11, 2006 at 04:35:15PM -0500, SCOTT BURGIN wrote:
> > > Hello. Running V3.0.4 server on RHEL.
> > >
> > > We have a remote site using PXE to image workstations.
> > > What we're seeing is the initial PXE boot (with a certain uid) is
> > > causing a lease to be written to the leases file as active.
> > > After the image is laid down and the machine boots the second time, the
> > > machine sends another Discover using a different uid, getting a
> > > different lease.
> > >
> > > I understand this is correct behavior per RFC, but have read that this
> > > is widely acknowledged to be an implementation PIA.
> > > What's fuzzy to me after searching the archives is what everyone agrees
> > > to be options currently to this dilemna for me.
> > > I've heard of patches, but can't seem to find them...other options ?
> I know nothing more about the currency or otherwise of this patch.
> For the future, I understand that the database key will be user
> definable. It will default to "pick first (client-id, hardware)" as
> it is now, but can be changed (primarily to allow the use of relay
> agent circuit ids etc) to just use the hardware address if you so
> I can't remember if this is in 3.1, or just on the to-do list.
Douglas Power <dpower at fnb.co.za>
To read FirstRand Bank's Disclaimer for this email click on the following address or copy into your Internet browser:
If you are unable to access the Disclaimer, send a blank e-mail to
firstrandbankdisclaimer at fnb.co.za and we will send you a copy of the Disclaimer.
More information about the dhcp-users