CONCEPT Cited by 1 source

Network boot interface¶

Definition¶

A network boot interface is a firmware-level mechanism that lets a server boot its operating system over the network instead of from local storage. The two primary instances on modern hardware are the Preboot Execution Environment (PXE) and UEFI HTTPS boot.

Network boot is the primitive that makes large-fleet, centrally-controlled, automated server provisioning possible — "critical for centralized, automated, and scalable control over how machines start up, especially across a globally distributed fleet serving different workloads." The OS image lives on a managed server (web server, cloud, enterprise storage); the hardware fetches it on boot rather than holding a local copy that must be kept in sync.

Two primary instances¶

Interface	Transport	Substrate	Notes
PXE	TFTP (legacy) → HTTP/HTTPS via iPXE	Pre-boot environment chainloads iPXE	Cloudflare's standard path for "various automation reasons"
UEFI HTTPS boot	HTTPS (native)	Motherboard firmware fetches OS directly	Available on some Cloudflare hardware; bypasses iPXE chainloading

Quote from Cloudflare's 2026-06-01 core boot-time post:

"The two primary interfaces are the [Preboot Execution Environment (PXE)] and Unified Extensible Firmware Interface (UEFI) HTTPS boot."

"Some of our hardware supports HTTPS-based UEFI network boot, which enables the computer's motherboard firmware to natively download operating system files securely."

Why fleets typically have multiple interfaces enabled¶

Different platforms in a heterogeneous fleet have different hardware/use-case requirements:

Some support UEFI HTTPS boot natively, offering the cleanest secure path.
Others rely on PXE + iPXE chainloading for HTTPS-capable network boot.
IPv4 vs IPv6 are separately listable interfaces.
Per-port (P1, P2, etc.) — multiple NICs may each surface separate boot interfaces.

The natural fleet posture is to enable multiple variants so heterogeneous platforms all boot, and to let the firmware probe them in order until one succeeds.

The probe-order failure mode¶

Each network boot interface, when unreachable, times out before falling through — "every failed network boot attempt burned roughly five minutes waiting for a timeout response." If the working interface is at the end of the probe order, the server burns one timeout per dead interface before booting. This is the canonical linear-search timeout amplification failure mode.

The fix is to declare the boot interface order upfront per hardware/use-case, eliminating the guessing — patterns/declare-boot-interface-order-upfront.

Composition with iPXE / UEFI / OS¶

Power on
   ↓
Firmware POST + hardware initialisation (UEFI)
   ↓
Pre-boot environment (PXE / iPXE)
   ↓
Network boot interface probing  ← *this stage is where the bug lived*
   ↓                                (or, with declared order, this stage is fast)
Boot loader fetches OS image over HTTP/HTTPS
   ↓
Kernel startup

In Cloudflare's three-stage decomposition, the network-boot- interface probe sits in the middle pre-boot stage — early enough that declaring the order upfront takes effect before the kernel starts.

Seen in¶

2026-06-01 — Cloudflare Gen12 boot-time regression. Canonical wiki disclosure of network-boot-interface probe-order as a fleet-automation hazard. Cloudflare's Gen12 core fleet had four network boot interfaces enabled (IPv4 HTTPS, IPv4 iPXE, IPv6 HTTPS, IPv6 iPXE); a routine firmware update changed which interface succeeded, exposing the linear-search timeout amplification. 4-hour-to-3-minute firmware upgrade time reduction after declaring the order upfront.