Skip to content

PATTERN Cited by 1 source

Declare boot interface order upfront

Intent

Eliminate guesswork in the network boot interface probe stage by declaring the correct interface upfront in the pre-boot PXE stage for each hardware + use-case combination, so the firmware never falls through the timeout gauntlet.

Context

Modern servers commonly have multiple network boot interfaces enabled (IPv4 HTTPS, IPv4 PXE, IPv6 HTTPS, IPv6 PXE — perhaps across multiple physical ports). The firmware probes them in order; each unreachable interface burns a multi-minute timeout before falling through. If the actually-working interface is not at position 1 — or, worse, if a firmware update changes which interface succeeds — every boot pays the linear-search cost.

Cloudflare's Gen12 core fleet (~2,000 units) experienced this in May/June 2026: a routine firmware update pushed boot times from minutes to ~4 hours per upgrade because each upgrade chains multiple sequential reboots, and each boot wastes ~20 minutes probing dead interfaces.

Mechanism

"By restructuring the automation sequence to declare the network boot interface order early on in the pre-boot PXE stage for each hardware/use-case, we were able to cut the total time by about an hour, since the boot process no longer needed to spend 20 minutes probing for each firmware upgrade."

"The fix was to eliminate the guesswork entirely — declare the correct boot interface upfront so the system never wastes time on interfaces that will never respond."

(Source: Cloudflare 2026-06-01)

Three structural pieces:

  1. Per-(hardware × use-case) declaration. The right boot interface differs by platform — some hardware speaks UEFI HTTPS natively, some chainloads through iPXE, some prefer IPv4 vs IPv6. The declaration must be parameterised by platform identity so the right config goes to the right server.
  2. Apply early in pre-boot PXE stage. Before the firmware starts probing interfaces. Otherwise the probe still fires first and the declaration takes effect only on subsequent boots.
  3. Mediate via iPXE — Cloudflare's CfHIIConfig_App tool, signed and run via imgexec from iPXE scripts, writes the UEFI variables that encode the declared boot order.

Composition with state validation

This pattern requires a companion: any declaration that gets written can be wiped by a subsequent firmware upgrade (concepts/firmware-config-persistence-loss). The complete fleet-safe pattern is declare + validate + reapply:

Operational outcomes (Cloudflare 2026-06-01)

Metric Before After
Firmware-upgrade automation nearly 4 hours 3 minutes
Subsequent single boot ~20 minutes < 1 minute

The first boot may take slightly longer (because of the validation + reapply + reboot loop), traded for sub-minute subsequent boots that compound across the fleet over time.

Constraints encountered (and addressed)

Cloudflare's 2026-06-01 post documents three obstacles that fleet operators should anticipate:

  1. Legacy hardware support — "Boot ordering is not supported on older UEFI versions." The pattern needs a fall-back path for un-orderable hardware.
  2. Persistence loss across firmware upgrades — concepts/firmware-config-persistence-loss. Pair with patterns/state-validation-with-auto-reapply-and-reboot.
  3. OEM lockout / lazy-loaded structures — the Force Priority Httpv4 Httpv6 Pxev4 Pxev6 immutable token plus the lazy-loaded EFI_IFR_REF3 required new BIOS firmware from the vendor and a debug session to unblock.
  4. Vendor string drift — pair with patterns/wildcard-config-match-for-vendor-string-drift so a single declaration matches both UEFI: HTTPS IPv4 Ethernet Network Adapter ... P1 and UEFI: HTTPS IPv4 Network Adapter - <MAC> P1.

When to use

  • Fleet of bare-metal or pre-allocated hardware with a known boot-interface preference per platform / SKU.
  • Boot-time on the critical path (firmware upgrades, scale-out, DR rebuild).
  • Fleet automation already exists at the iPXE / pre-boot layer and can run signed configuration tooling.

When not to use

  • Single-server administration where humans will drive the BIOS GUI directly.
  • Heterogeneous hardware where the per-platform mapping is more expensive to maintain than the per-boot timeout cost.
  • Hardware too old to support boot-order declarations at all (per Cloudflare's "Boot ordering is not supported on older UEFI versions" caveat).

Risks

  • Config drift across firmware upgrades — surface via state validation (see companion pattern).
  • Wrong declaration for some platforms — needs a roll-out discipline (canary platforms, observability on first-boot duration after declaration changes).
  • Vendor lockout — discovery only happens when a real fleet hits it; budget for vendor coordination time when rolling this out.
Last updated · 542 distilled / 1,571 read