What PXE Actually Is and Why It Matters for Infrastructure
PXE stands for Preboot Execution Environment. It is a standardized way for a computer to boot and load an operating system over a network instead of from a local disk. Think of it as a minimal environment that runs before any OS loads, pulling files from a DHCP server and a TFTP server. It is not a modern innovation. It dates back to the mid-1990s, but it still runs thousands of deployments daily in data centers, labs, and IT departments that do not advertise their reliance on it. Most people learn PXE for one reason: automated OS deployment. You set up a network boot server, point a few machines at it, and watch them install Windows or Linux without touching a keyboard. That is the surface level. The deeper part is performance metrics around the PXE stack itself, because if you are scaling this to hundreds of machines, the difference between a 45-minute deploy window and a three-hour nightmare comes down to tuning DNS, DHCP, TFTP, and the downstream image delivery path. This is where it gets technical and where most guides stop being useful. A PXE deployment rests on several moving parts. Your DHCP server hands out an IP address and tells the client where to find the boot server. The client then reaches out to a TFTP server to pull a boot image. That boot image is usually a small kernel or bootloader that either chains into a full OS installer or hands control to a larger file server over HTTP or NFS. If any of those steps have latency or misconfiguration, the client stalls or fails silently. I have seen this happen because someone changed the subnet mask on one gateway and broke the TFTP route for an entire floor.
The client sends a DHCP discover. The server replies with an IP lease and a next-server option pointing to the TFTP host. The client contacts TFTP and downloads a boot file, often called pxelinux.0, grubnetx64.efi.sfs, or something similar depending on the bootloader stack. Then the boot media loads a configuration file, reads a network config, and starts pulling the actual OS payload. The payload path matters a lot. A lot of tutorials skip this nuance and leave people confused when their client hangs at "Loading boot image." That is usually a TFTP timeout or a DHCP option mismatch, not a problem with the OS image itself. When you are dealing with PXE, the metrics that actually matter are different from what you track for application performance. You care about: I track these by logging DHCP offer timestamps and TFTP packet acknowledgments on the server side. A basic tcpdump or Wireshark capture on the boot server gives you enough signal to diagnose the bottleneck. Most people miss this step and jump straight to replacing hardware, which does not help when the issue is a misconfigured DHCP scope.
Here is a straightforward path that works in most enterprise environments. You need a Linux host acting as the server. Set up DHCP with ISC DHCP server or dnsmasq. Enable the TFTP service. Place your bootloader files in the TFTP root. Configure the bootloader to point at your image source, which can be an HTTP server, an NFS share, or another TFTP endpoint for smaller files. I prefer HTTP for the payload stage because TFTP is slow and has no real concurrency. A single TFTP transfer to fifty clients will turn your server into a traffic jam within minutes. One issue I run into regularly is overlapping DHCP scopes. If your PXE server and your main DHCP server are on the same broadcast domain but configured with conflicting options, clients will get inconsistent replies. Another common mistake is using a relay agent that does not preserve the correct next-server information across subnets. I had a deployment once where the relay stripped the option 66 and option 67 values because of an old firmware bug on the router. The fix was updating the relay firmware and adding a static DHCP reservation for the PXE server. The whole incident took about four hours to isolate, and most of that was spent verifying that the routers were actually passing the required options. When you move past ten or twenty machines, you need to rethink how you deliver the OS payload. The typical approach is to use a multicast deployment for identical builds. Tools like FOG Project, DRBL, or custom iPXE scripts handle multicast well if you size your network properly. Multicast saves bandwidth significantly but introduces a different failure mode: if one client drops the stream, you either resend to everyone or restart the multicast session. I learned this the hard way when a single faulty NIC on a workstation dropped packets and stalled a five-machine deployment for twenty minutes. The workaround was switching to unicast for that batch and fixing or replacing the bad NIC afterward.
Get the Full Details
Standard PXE is limited. It can only boot from TFTP and does not handle HTTPS or complex scripts well. iPXE extends the boot environment significantly. You can boot from HTTP, iSCSI, or even network storage protocols directly. It also supports scripting, which lets you chain multiple boot steps and pass variables based on MAC address or other criteria. I switched most of my workflows to iPXE because it reduced my deployment time from about forty minutes per machine to roughly twelve minutes when using HTTP-based payload delivery. The configuration overhead is higher, but the payoff is real once you get past the initial learning curve. There are a few things that are not obvious until you hit them. One is the maximum TFTP block size. By default, TFTP uses a 512-byte block, which is extremely inefficient for large files. You can negotiate a larger block size, but only if both the client and server support it. Many older PXE implementations do not. Another pitfall is DHCP lease expiration timing. If your lease times are too short during a mass deploy, you will see clients drop their leases mid-transfer. Set your lease time to something reasonable, like twenty-four hours, during deployment windows. A third issue is firewall rules blocking UDP ports. DHCP uses port 67 and 68. TFTP uses port 69. If any intermediate firewall is blocking those, the client will appear to hang indefinitely. Check the firewall logs first. It saves time. PXE is not universal. If your devices do not have a PXE-capable NIC, which is increasingly common on consumer-grade and some embedded hardware, you need an alternative. USB-based deployment, SD card imaging, or cloud-init workflows may be more appropriate. There is also a scenario where PXE becomes impractical: large-scale remote sites with limited bandwidth. In those cases, caching the image locally or using a hybrid approach where you push a base image via USB and then sync configuration over the network is faster and more reliable. I have worked in environments where the WAN link was so constrained that PXE deployments failed consistently, and switching to a staged USB-first model cut the failure rate from about eighteen percent to under two percent.
When a PXE boot fails, start with the simplest checks first. Confirm the client receives a DHCP offer with the correct next-server and boot-file-name options. Use a packet capture on the client or the server side to verify the exchange. If DHCP is working, check TFTP connectivity. A simple tftp command from the server console to itself can confirm the service is responding. Then verify the boot file exists and is readable. After that, check the payload source. If the bootloader reports an error about the config file or kernel path, the issue is likely in the bootloader configuration rather than the network. This sequence covers the vast majority of failures. Skipping it and jumping to reinstalling the OS image is a waste of time. PXE is an old protocol, but it is still relevant. The trick is understanding where the bottlenecks live and measuring the right metrics. Most deployments fail because someone assumed the network was fine without validating the DHCP and TFTP path under load. If you tune those layers and choose the right payload delivery method, you can build a PXE system that handles dozens of concurrent boots without breaking a sweat.
