Problem:
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 203.0.113.51 for client xx:xx:xx:xx:xx:xx is duplicate on VLAN001
Sep 21 22:22:31 dhcpd: [ID 702911 local5.error] uid lease 203.0.113.206 for client xx:xx:xx:xx:xx:xx is duplicate on VLAN002
Sep 21 22:34:42 dhcpd: [ID 702911 local5.error] uid lease 203.0.113.42 for client xx:xx:xx:xx:xx:xx is duplicate on VLAN001
Sep 21 22:13:08 dhcpd: [ID 702911 local5.error] uid lease 203.0.113.20 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.)
Solution:
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.
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.