Skip to content

PATTERN Cited by 1 source

Wildcard config match for vendor string drift

Intent

When a configuration target is identified by a vendor-specific string that varies across OEMs even when the underlying configuration target is identical, match against a wildcard (regex-style) pattern that captures only the configuration- identifying facts, ignoring the vendor-noise (model identifiers, MAC addresses, branding).

Stop-gap workaround for vendor string mismatch; pair with a string-standardisation roadmap so the wildcard can eventually retire.

Context

Across a multi-OEM fleet, the same logical network boot interface (e.g. HTTPS IPv4 on physical port 1) appears with different vendor-specific strings:

UEFI: HTTPS IPv4 Ethernet Network Adapter XXX-XXX-Y for OCP 3.0 P1
UEFI: HTTPS IPv4 Network Adapter - 50:00:E6:8F:4F:32 P1

(Source: Cloudflare 2026-06-01.)

Exact-string configuration logic breaks. Per-vendor branches proliferate. NIC swaps during repair invalidate exact strings. Fleet-wide configuration deployment becomes impractical.

Mechanism

"In order to work around this issue, we had to implement an additional feature to the CfHIIConfig_App tool, allowing it to set the config without having the full string:

.*HTTP.*IPv4.*P1

The config would then be matched against the accepted config strings and would select the correct boot order."

Three structural pieces:

  1. Identify the configuration-identifying tokens. What facts uniquely identify the target? For network boot, this is protocol (HTTP/HTTPS), transfer type (PXE/iPXE/ native HTTPS), IP family (IPv4/IPv6), and physical port number (P1, P2, etc.).
  2. Construct a wildcard pattern that requires those tokens in order. .*HTTP.*IPv4.*P1 matches both example strings above by anchoring on the configuration-identifying facts (HTTP, IPv4, P1) and tolerating any vendor noise between them.
  3. Validate that exactly one interface matches per port + protocol + family. If two interfaces match, the wildcard is too loose; tighten until uniqueness holds across the fleet.

The durable companion: string standardisation

Cloudflare explicitly frames the wildcard as a stop-gap, with the durable fix being vendor-side standardisation of the strings:

"We are currently working with our UEFI vendors to standardize the network interface strings to only make use of the relevant information (e.g. protocol, transfer type, port number, and physical slot index) and drop the product details like the MAC address. The product details, if needed, can be read from the embedded vital product detail information of the network interface card. That way we eliminate both configuration drift and the use of wildcards."

The endpoint state: configuration-identifying facts in the boot-interface string, asset-identifying facts (MAC, model, branding) read on demand from the NIC's Vital Product Data (VPD) when needed. Wildcards retire because exact match works.

Why wildcards-as-stop-gap is the right shape

  • Unblocks immediate fleet automation — Cloudflare shipped sub-minute subsequent-boot reductions without waiting for vendor standardisation.
  • Compatible with any future-state where standardisation succeeds — once the strings are clean, the wildcard collapses to an exact match without behaviour change.
  • Pushes for the right durable fix — building the wildcard surfaces exactly which fields are noise vs signal, vocabulary that informs the standardisation conversation.
  • Doesn't fork the fleet — single wildcard config rolls out everywhere; no per-OEM branches.

When to use

  • Multi-OEM fleet where configuration targets are identified by vendor-specific strings.
  • Configuration substrate exposes the strings only (no alternate identifier path like a stable enum or VPD-keyed lookup).
  • The configuration-identifying tokens are present in all vendor strings in a discoverable order.
  • A standardisation roadmap exists or can be opened with vendors.

When not to use

  • A stable, vendor-neutral identifier already exists (use it).
  • Multiple targets per port (the wildcard might match more than intended); start with the standardisation conversation rather than the wildcard.
  • Standardisation effort is not feasible (vendor coordination cost too high) — accept per-vendor branching as the durable fix instead.

Risks

  • Loose match accidentally selects wrong interface — when two interfaces both contain the wildcard tokens. Always validate per-fleet that the wildcard has exactly one match per (port, protocol, family) tuple.
  • Vendor adds a new string format that doesn't match — e.g. drops P1 in favour of Port-1. Wildcards are not futureproof; pair with monitoring on config-application failures.
  • Cargo-culting — engineers adding wildcards to other fleet config without thinking through the wildcard's span. Document the standardisation roadmap so the wildcard's "stop-gap" status is explicit.
Last updated · 542 distilled / 1,571 read