Fix UEFI Network Boot IP Address Failure

When booting a client over a network, a UEFI system failing to obtain an IP address prevents the device from loading the Network Bootstrap Program (NBP) and halts deployment. This guide provides actionable troubleshooting steps to identify and resolve network boot IP acquisition failures, covering physical connections, switch configurations, DHCP server settings, and UEFI firmware parameters.

  • Inspect Link Lights: Ensure the network interface card (NIC) and switch port display active link and activity lights during the Preboot Execution Environment (PXE) phase.
  • Test the Cable and Port: Swap the Ethernet cable and connect to a known-working switch port to eliminate physical layer defects.
  • Bypass Docking Stations: If troubleshooting laptops, connect directly to an onboard RJ-45 port or an officially supported, PXE-capable USB-to-Ethernet adapter with MAC address pass-through enabled.

2. Configure UEFI Firmware Settings

  • Enable the UEFI Network Stack: Enter the UEFI setup menu (BIOS) and ensure that Network Stack and IPv4 PXE Support are explicitly enabled.
  • Review Boot Priority: Set the network adapter (UEFI IPv4) as the primary boot device.
  • Toggle Secure Boot: While modern UEFI network boot supports Secure Boot, an unsigned bootloader or misconfigured server certificate can interrupt initialization. Temporarily disable Secure Boot to test if it resolves the issue.
  • Update System Firmware: Outdated UEFI firmware may contain bugs related to the embedded Underscore Network Driver Interface (UNDI). Flash the system to the latest vendor firmware.

3. Adjust Switch Spanning Tree Settings

  • Enable PortFast or Edge Port: Standard Spanning Tree Protocol (STP) takes 30 to 50 seconds to transition a port to the forwarding state. UEFI PXE clients typically timeout after a few seconds of waiting for a DHCP offer. Configure the switch port with STP PortFast (Cisco) or Edge Port to transition the port to forwarding immediately.
  • Verify VLAN Tagging: Ensure the access port is assigned to the correct client VLAN and not set to an isolated or trunked configuration that the bare-metal client cannot negotiate.

4. Check DHCP Scope and Options

  • Examine Scope Exhaustion: Check the DHCP server to ensure the pool has available, unexpired IP addresses in the target subnet.
  • Validate Architecture Handshake (Option 93/Client System Architecture): Unlike legacy BIOS (architecture 0000), 64-bit UEFI clients send Option 93 with value 0007 or 0009. Ensure your DHCP server policies properly interpret these tags and return appropriate responses without dropping requests.
  • Inspect Rogue DHCP Servers: Multiple DHCP servers on the same subnet can race or send malformed configuration parameters. Verify only authorized DHCP servers are responding to broadcast queries.

5. Validate IP Helper / DHCP Relay Configuration

  • Forward Broadcasts Across Subnets: If the client and the DHCP/PXE servers reside on different VLANs, configure an IP Helper Address (or DHCP Relay Agent) on the default gateway switch or router.
  • Direct Relays Properly: Ensure the IP Helper forwards UDP traffic on ports 67 (DHCP) and 4011 (PXE) to both the DHCP server and the PXE server addresses.

6. Perform a Packet Capture

  • Filter DHCP Traffic: Run Wireshark on the DHCP server or set up a switch mirror (SPAN) port targeting the client's switch interface. Filter by bootp or udp.port == 67 || udp.port == 68.
  • Trace the DORA Process:
    • DHCPDISCOVER: Verify if the client’s broadcast reaches the network. If missing, the issue is on the physical link, VLAN, or firmware level.
    • DHCPOFFER: Check whether the server replies with an offer. If missing, verify DHCP scope availability and relay settings.
    • DHCPREQUEST: Ensure the client accepts the offered address.
    • DHCPACK: Confirm the server acknowledges the lease. Missing acknowledgments indicate policy restrictions or MAC filtering rules.