2 IP addresses when PXE booting, ping check doesn't spot same MAC address

Stephen Borrill dhcp-users at borrill.org.uk
Tue Oct 21 10:32:52 UTC 2014

I'm using a diskless system to boot Windows (Citrix Provisioning
Services). This does a BIOS PXE boot, loads a bootstrap file from TFTP
which connects to a virtual hard disk and then continues with the
Windows boot as though it were a local disk. This means that the IP
address acquired from the BIOS is inherited by Windows and remains in
use. The interface within Windows is still set up to use DHCP and so it
goes through its usual DHCP phase.

It is common to end up with 2 IP addresses on the network when doing
this. Initially the problem was that the BIOS does not send a UID with
the request, but Windows does, so that dhcpd was treating them as two
separate leases. I upgraded to v4.3.0 and used "ignore-client-uids true"
to stop this. However, this then triggered another problem. At the time
that Windows requests its IP address, the IP address from the PXE phase
is still active as it cannot be released by the client. Therefore, the
dhcpd ping check triggers, the original IP address is abandoned and a
new IP address is picked:

10:44:32 dhcpd: DHCPDISCOVER from 36:06:41:1a:62:59 (pcmaster)
10:44:33 dhcpd: DHCPOFFER on to 36:06:41:1a:62:59
10:44:35 dhcpd: DHCPREQUEST for ( from 36:06:41:1a:62:59
10:44:35 dhcpd: DHCPACK on to 36:06:41:1a:62:59
10:47:18 dhcpd: DHCPDISCOVER from 36:06:41:1a:62:59
10:47:18 dhcpd: Abandoning IP address pinged before offer
10:47:20 dhcpd: DHCPDISCOVER from 36:06:41:1a:62:59
10:47:21 dhcpd: DHCPOFFER on to 36:06:41:1a:62:59 (pcmaster)
10:47:21 dhcpd: DHCPREQUEST for ( from
36:06:41:1a:62:59 (pcmaster)
10:47:21 dhcpd: DHCPACK on to 36:06:41:1a:62:59 (pcmaster)

(slightly edited to remove extraneous information such as date, hostname
and interface name)

To test this theory, setting "ping-check false" allows the machine to
keep its single initial address.

It seems to me that there should be an option to only abandon an IP
address after a ping check if the MAC address that responds does not
match the requester. Any other suggestions?


More information about the dhcp-users mailing list