Score:0

Two DHCP, One PXE

in flag

I am trying to figure how to build a specific topology in our servers, but mostly I want help on theoretical level.

I understand that you can have 2 DHCP servers on a same network as long as they have different address range. However there is no deterministic way to find which server replies first.

What I would like to know is what happens if you put PXE in the game. So let's say that in a network there is a DHCP server (A) that is not PXE-enabled, and thus responds to the initial DHCPDISCOVER, with a standard DHCPOFFER with no PXE specific parameters. The second DHCP server (B) is PXE-enabled, so it responds to the initial DHCPDISCOVER with a DHCPOFFER containing PXE parameters.

What will happen, if server (A) responds first?

  1. Will the host just drop the second DHCPOFFER and not PXE boot?
  2. Will the host accept the DHCPOFFER from server (A) and follow PXE instructions from server (B)?
  3. Will the host reject the DHCPOFFER from server (A) and accept the DHCPOFFER of server (B)?
  4. Something else?
Score:4
za flag

DHCP could not be "pxe-enabled". Network booting is not a DHCP duty. The only role DHCP takes in this is to present a client an information about boot file server address and boot application file name. That's all.

A boot server does not have to live on the same machine where DHCP server exists. It can be anywhere within IP reach. PXE uses TFTP protocol to download a boot application, so if corresponding information exists in the DHCP server reply, it will try to use it to download specified file and run it.

So, in your case just set up both DHCP servers to point to the same TFTP server, which can coexist with one of these DHCP servers or it can live on some third machine, and it will work.

Score:0
za flag
Pat

Having 2 active DHCP servers targeting he same sub-network w/o MAC filters leads to uncertainty and that's not a good idea. If you need high availability/redundancy just use a high availability DHCP server supporting redundancy.

DHCP servers are "pxe-enabled" when you configure them for offering the PXE parameters:

  1. TFTP server IP
  2. NBP (Network Boot Program) path and name

Answering your question regarding a PXE client receiving 2 offers one with PXE data and one without, well, the client should take the one providing PXE info but I have seen faulty firmware not doing this and throwing a PXE error. The rest of options you mention are undefined by the PXE standard.

When you have a sub-network that already has DHCP infrastructure, you do not want or you are not allowed to change its configuration, and you want to add PXE services the most common approach is to add a proxyDHCP. A proxyDHCP only provides the PXE info to booting PXE clients and remains silent to booting non-PXE clients. Then the booting PXE client receives 2 DHCP offers one from the DHCP server providing IP and corresponding DHCP options and one from the proxyDHCP providing PXE data and it is able to boot. proxyDHCP is part of the PXE standard and is today widely supported by PXE firmware.

Despite the PXE data provided by DHCP the PXE standard also requires setting up the corresponding TFTP server used for transferring the initial booting components. Also additional server services are needed like HTTP, CIFS, NFS offering transfer services for the bulk of components being net transferred right after the PXE stage finishes.

e.g. when PXE booting a Linux Live distro the NBP (grub or pxelinux) is initially transferred usually displaying a boot menu, later the kernel and initrd are also TFTP transferred and booted. Next he booting kernel performs a second DHCPDISCOVERY as a regular DHCP client (no PXE) gets its IP and next HTTP or CIFS or NFS transfers the corresponding squashfs file and the live distro is booted.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.