The network client boot stack sends a DHCPDISCOVER as a broadcast. Any machine can be listening on UDP 67 (bootps) for this. The real DHCP server responds with the DHCPOFFER containing the IP address the client should use. Around the same time, the PXE server responds with its own DHCPOFFER that does not issue an address, but does contain the values for the requested DHCP options.
The client basically keeps broadcasting DHCPDISCOVER until it gets both, then it does the unicast DHCPREQUEST and wait for unicast DHCPACK with the normal DHCP server.
Now, that said, I've only ever seen this work with commercial PXE servers like Microsoft RIS. To my knowledge, ISC DHCPD is unable to send a DHCPOFFER with options but no address. But my knowledge is at least a decade out of date.
At home I just set the options on the main DHCP server like every other hobbyist does, but this isn't true PXE, this is just plain old DHCP+TFTP remote boot.
Let's say you do have such a server that sends DHCPOFFER with the options and no IP address. If it's on its own machine, then it can listen on port 67, same as the real DHCP server on another machine. But, if it's on the same machine as the DHCP server, it has to listen on port 4011. In this case the client behaves a little differently. For this to work, the DHCP server must send as part of the DHCPOFFER an unsolicited option 60 to indicate that the client should go ahead and accept the IP then send a second unicast DHCPDISCOVER to port 4011 and await a DHCPOFFER from that port. Option 60 is only needed, and can only be used, if the independent PXE server is running on the same host as the DHCP server.
So there's basically 3 scenarios:
* Hobbyist: just configure the booting options on the real DHCP server
* Real PXE, separate machine: Both real DHCP and PXE listen for broadcast DHCPDISCOVER and respond with complementary DHCPOFFER. Real DHCP server has no knowledge whatsoever about booting.
* Real PXE, same machine: Real DHCP server responds with unsolicited option 60 no matter what. This is the extend of its knowledge of booting. Separate PXE server runs on port 4011 instead of 67, and everything is unicast.
There may finally be hobbyist projects that support this model, but when I last did this stuff, there were not. Learning how RIS worked was a revelation for me, and it really made me wonder why the hobbyist community of the time seemed hellbent on not doing PXE correctly, which annoyingly requires control over the options set by the real DHCP server, and often makes it impossible to do fun stuff like use different boot files for different clients.
https://en.wikipedia.org/wiki/Preboot_Execution_Environment
The network client boot stack sends a DHCPDISCOVER as a broadcast. Any machine can be listening on UDP 67 (bootps) for this. The real DHCP server responds with the DHCPOFFER containing the IP address the client should use. Around the same time, the PXE server responds with its own DHCPOFFER that does not issue an address, but does contain the values for the requested DHCP options.
The client basically keeps broadcasting DHCPDISCOVER until it gets both, then it does the unicast DHCPREQUEST and wait for unicast DHCPACK with the normal DHCP server.
Now, that said, I've only ever seen this work with commercial PXE servers like Microsoft RIS. To my knowledge, ISC DHCPD is unable to send a DHCPOFFER with options but no address. But my knowledge is at least a decade out of date.
At home I just set the options on the main DHCP server like every other hobbyist does, but this isn't true PXE, this is just plain old DHCP+TFTP remote boot.
Let's say you do have such a server that sends DHCPOFFER with the options and no IP address. If it's on its own machine, then it can listen on port 67, same as the real DHCP server on another machine. But, if it's on the same machine as the DHCP server, it has to listen on port 4011. In this case the client behaves a little differently. For this to work, the DHCP server must send as part of the DHCPOFFER an unsolicited option 60 to indicate that the client should go ahead and accept the IP then send a second unicast DHCPDISCOVER to port 4011 and await a DHCPOFFER from that port. Option 60 is only needed, and can only be used, if the independent PXE server is running on the same host as the DHCP server.
So there's basically 3 scenarios: * Hobbyist: just configure the booting options on the real DHCP server * Real PXE, separate machine: Both real DHCP and PXE listen for broadcast DHCPDISCOVER and respond with complementary DHCPOFFER. Real DHCP server has no knowledge whatsoever about booting. * Real PXE, same machine: Real DHCP server responds with unsolicited option 60 no matter what. This is the extend of its knowledge of booting. Separate PXE server runs on port 4011 instead of 67, and everything is unicast.
There may finally be hobbyist projects that support this model, but when I last did this stuff, there were not. Learning how RIS worked was a revelation for me, and it really made me wonder why the hobbyist community of the time seemed hellbent on not doing PXE correctly, which annoyingly requires control over the options set by the real DHCP server, and often makes it impossible to do fun stuff like use different boot files for different clients.