PXE, UEFI and BMC Paths That Survive a Real Fleet

PXE, the Preboot Execution Environment, goes back to a spec Intel wrote in 1997, and it's still around because it doesn't ask much of the hardware. A NIC with a PXE option ROM sends out a DHCP request, gets pointed at a TFTP server, pulls down a bootloader (iPXE or GRUB, usually), and hands off to an installer or a live image. No agent running, no OS pre-installed, no need for the vendor's management stack to actually work right, and if you've ever dealt with a flaky BMC firmware build, you know that last part is not nothing. Here's the catch. PXE assumes a network where everyone on the wire can be trusted, because DHCP has no built-in way to say "only answer PXE requests from this rack." Run a shared VLAN with more than one DHCP-speaking box on it and you'll eventually hit the classic failure: some rogue DHCP server, maybe a bad switch config or somebody's forgotten test machine, answers the request first, and now a server is trying to chainload a bootloader from an IP address nobody recognizes. You fix this with DHCP options 60, 66, and 67 tied to switch port ACLs, plus a provisioning VLAN walled off at layer 2 from everything else. That's operational discipline bolted on top of the protocol. PXE itself gives you none of it for free. Then there's the timing problem once you scale up. TFTP runs over UDP and a lot of the older server implementations are single-threaded, so PXE-booting 200 machines in one rack during a firmware refresh turns into a long, ugly tail as the TFTP server falls behind. Most teams running real fleets end up shifting the actual payload over to HTTP after the initial handshake, which is exactly what iPXE's HTTP boot support is for, keeping TFTP around only for the tiny first-stage loader. I've watched that one change take a provisioning window from four hours down to eleven minutes on a 300-node batch. ## UEFI: the quiet infrastructure everyone assumes and nobody reads UEFI took over from legacy BIOS, and for provisioning purposes what matters isn't the boot menu, it's that HTTP Boot and Secure Boot live natively in the firmware instead of getting bolted on through a separate bootloader. A UEFI build with HTTP Boot turned on can pull an image straight over HTTPS, skipping PXE and TFTP entirely. That kills off a whole category of DHCP-spoofing risk and makes the network setup a lot simpler to reason about. Fleet mix is where it gets messy though. Put Dell, Supermicro, and HPE boxes in the same rack, and even if all three vendors call themselves UEFI compliant, you'll find three different ways of handling boot order persistence, three different approaches to Secure Boot key enrollment, three different logging behaviors when something fails. UEFI is a spec, not a promise that everyone implements it the same way, and vendors read the optional sections of that spec very differently from each other. Try scripting boot-order changes across a mixed fleet with `efibootmgr` and sooner or later you'll hit a vendor firmware that quietly reverts the boot order on the next power cycle. Nothing in any log tells you it happened. You just find out three reboots later when the box comes up into the wrong OS. Secure Boot is worth a closer look here too. It does real work, chaining trust from firmware to bootloader to kernel so nobody can swap in a malicious image mid-provisioning. But managing keys across a mixed-vendor fleet, especially once you're signing your own kernels or running a custom iPXE build with your own certs, turns into its own multi-week project with its own on-call rotation. Skipping it to move faster is a reasonable call for a lot of teams. Just know what you're trading away when you do. ## BMC and Redfish: provisioning without needing the OS to cooperate The Baseboard Management Controller runs on its own processor, entirely outside the host OS, which means it can power-cycle a dead machine, mount a virtual media image, or check chassis temperature even when the host has never booted an OS at all. This is the layer that makes zero-touch provisioning possible at real scale, because you're not waiting on an OS to load or a PXE handshake to land before you get first contact. The BMC is alive the second power hits the chassis. Redfish is what makes that usable instead of painful. Before it, the standard was IPMI, and anyone who spent years writing against IPMI's binary protocol and its pile of vendor-specific OEM extensions knows exactly how much pain Redfish's plain JSON-over-HTTPS interface took off the table. Query power state, mount an ISO as virtual media, set the one-time boot device, trigger a power cycle: all of it through documented REST calls, instead of guessing which vendor's raw `ipmitool` command does what this week. Here's the part that trips people up. "Redfish-compliant" isn't one thing, it's a range. The DMTF certifies conformance, sure, but how much of the schema a vendor actually implements varies a lot. Some expose full sensor telemetry and firmware inventory down to the last detail; others cover the bare minimum needed to pass certification and leave whole chunks of the schema empty or throwing errors. If you're automating against Redfish across a mixed-vendor fleet, write code that checks what's actually supported before you call it, because the exact same API call that works cleanly against one BMC will 404 against another from a different manufacturer, sometimes even a different model line from the same manufacturer. ## Where these three paths actually meet Real fleets don't pick one of these three and call it done. They stack them. BMC and Redfish handle the low-level work of waking a box up and pointing it at a boot source. UEFI HTTP Boot or a PXE-chained iPXE script gets an actual image onto the machine. Then configuration management, whether that's cloud-init, Ignition for CoreOS-style immutable builds, or something built in-house, takes over once the OS is running and handles the last mile: identity, network config, workload assignment. The failure pattern shows up the same way almost every time. A team builds and tests their provisioning pipeline against one vendor's hardware in a lab, everything works, they ship it, and then a second vendor's SKUs land in the fleet six months later. Firmware quirks that never showed up at ten machines turn into a standing ticket queue at a thousand. More automation doesn't fix that. Writing provisioning logic that expects divergence between vendors from day one does, and so does testing against the oldest, ugliest firmware revision sitting in your fleet instead of whatever shipped last quarter, and treating BMC capability discovery as a step you always run rather than something you assume. None of these three protocols is going anywhere, and none of them works alone. Anyone who tells you otherwise hasn't run a mixed-vendor fleet past a few hundred nodes. The fleets that hold up under real load are built by people who read the spec, then go check what the vendor's box actually does against that spec, and build for the gap between the two rather than pretending it doesn't exist.