Knowledge Base ISC Main Website Ask a Question/Contact ISC
What causes dhcpd to log uid lease for client xx:xx:xx:xx:xx:xx is duplicate ?
Author: Cathy Almond Reference Number: AA-00687 Views: 6126 Created: 2012-05-22 22:06 Last Updated: 2015-03-18 11:47 0 Rating/ Voters


Similar errors to those below may be logged regularly by dhcpd servers operating in a failover pair configuration:

Sep 21 22:16:24 dhcpd: [ID 702911 local5.error] uid lease for client xx:xx:xx:xx:xx:xx is duplicate on VLAN001
Sep 21 22:22:31 dhcpd: [ID 702911 local5.error] uid lease for client xx:xx:xx:xx:xx:xx is duplicate on VLAN002
Sep 21 22:34:42 dhcpd: [ID 702911 local5.error] uid lease for client
xx:xx:xx:xx:xx:xx is duplicate on VLAN001
Sep 21 22:13:08 dhcpd: [ID 702911 local5.error] uid lease for client
xx:xx:xx:xx:xx:xx is duplicate on VLAN001

(Note that xx:xx:xx:xx:xx:xx will be the client MAC address in actual logfile messages)


These logged errors can safely be ignored. 

In some situations, a client receives two DHCPOFFER packets - one from each server in the failover pair.  If that happens, the client should accept only one offer, but the log messages indicate that the servers(s) saw this happening and logged the event.

Known Cause

One known situation where this can happen is documented in ISC bug ticket RT #26108.  This is not a defect in the DHCP server code.  In the scenario under consideration in ticket #26108, some clients may send DHCPDISCOVER or DHCPREQUEST packets with the seconds elapsed field coded as little endian, thus confusing the DHCP servers in a failover pair who are expecting this to be big endian.  The incorrectly coded secs field may cause one server to incorrectly deduce that the other is not responding, and thus send a DHCPOFFER that it wouldn't normally.  We've released a code workaround (available in 4.1-ESV-R8, 4.2.5 and newer) that may be helpful to some users:

Add a configure option, enable-secs-byteorder, to deal with clients that do the byte ordering on the secs field incorrectly.  This field should be in network byte order but some clients get it wrong.  When this option is enabled the server will examine he secs field and if it looks wrong (high byte non zero and low byte zero) swap the bytes.  The default is disabled.  This option is only useful when doing load balancing within failover.
[ISC-Bugs #26108]

Aside from any issues due to clients who don't set seconds elapsed field, or who are using a different endian setting, typically this behavior would only be observed where there is a high latency between the client and servers or where there are packet losses in the network causing the client to re-send the original packet with the secs field incremented.

© 2001-2016 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Custom Fields
  • Bug tracking system reference: 26108
  • There is no feedback for this article
Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu