Diskless PCs Fail to PXE Boot After a Meraki/Cisco Switch Firmware Upgrade (STP Edge-Port / PortFast Fix)

Diskless client PCs stop PXE booting fleet-wide because the switch's access ports no longer forward traffic immediately on link-up. The fix is to mark those ports as edge ports (PortFast / BPDU Guard).

Summary

After a managed switch is upgraded, factory-reset, or replaced, diskless client PCs may stop PXE booting all at once. The switch's access ports stop forwarding traffic for ~30–60 seconds after each link-up (normal Spanning Tree convergence), and iPXE's DHCP times out inside that window.

Symptoms

• All — or most — client PCs fail to boot from the network at the same time, often right after a switch firmware upgrade or replacement.
• iPXE loads on the client, then loops:
• • Configuring (net0 <mac>)…… No configuration methods succeeded (https://ipxe.org/040ee119)
  • DHCP failed, retrying in N seconds before next attempt.
• A PC boots if you start it into a local OS first, then restart into PXE (the link stays up across a warm restart).
• The same PC booted through a basic/unmanaged switch works immediately.
• The ggRock server, boot files, and iSCSI targets all test healthy.

Root cause

Diskless boot needs the network the instant the PC powers on. On a managed switch, an access port that is not designated as an edge port runs through Spanning Tree's listening/learning states before it begins forwarding — roughly 30 seconds (RSTP) to 50 seconds (legacy STP) of dropped traffic after every link-up.

• The PC's firmware PXE ROM uses long, patient DHCP retries (~3 / 8 / 16 / 32s backoff) and usually outlasts the delay, so it eventually gets an address and downloads iPXE.
• iPXE then takes over, re-initializes the NIC (bouncing the link and restarting convergence), and runs its own DHCP with a much shorter timeout. It gives up before the port forwards → No configuration methods succeeded (error 040ee119) → no boot.

This is why the failure looks intermittent, and why "boot to Windows first" works: a warm restart keeps the link up, so the port never re-converges.

Common trigger: a switch firmware change

A frequent cause is a managed switch losing an edge-port default after a firmware change. For example, a Meraki overlay running on a Catalyst treated access ports as edge by default (forward unless a BPDU is seen). After an upgrade to native IOS-XE, the switch follows standard behavior — no port is an edge port unless it is explicitly configured. Same hardware and cabling, but the default flips from "forward fast" to "converge first," and every cold client boot starts failing.

How to diagnose

1. Check the client screen

The iPXE No configuration methods succeeded (040ee119) / DHCP failed, retrying loop is the signature.

2. Confirm the server and back-end are healthy

This rules out everything except the network path. From any machine on the LAN:

curl "http://<ggrock-ip>/boot/script?mac=<client-mac>&ip=<client-ip>"

A valid #!ipxe … script in response means proxyDHCP, TFTP, the boot-script API, and iSCSI registration are all fine — the problem is upstream, in the network path.

3. Capture the boot on the server

Scope the capture to one client by MAC. The failure is cold-specific, so start the capture, then cold-boot the PC:

tcpdump -ni <nic> -w boot.pcap ether host <client-mac>

Signature: the client sends DHCP DISCOVERs (vendor class PXEClient) that go unanswered for ~30–60 seconds, then DHCP suddenly completes and the boot file transfers in milliseconds. A clean, fast data plane after a long initial delay points to a port-forwarding/convergence problem — not bandwidth, packet loss, or the server.

4. Isolation test

Connect the clients through a basic unmanaged switch. If they boot immediately, the managed switch is confirmed as the cause.

Resolution

Designate the client access ports as edge ports so they forward the instant link comes up.

Meraki dashboard (cloud-managed Catalyst / MS)

1. Go to Switch → Ports and select all client access ports (use a port profile or multi-select).
2. Set STP guard = BPDU Guard. This marks the port as an edge port (the PortFast equivalent) and shuts it down only if it unexpectedly receives a BPDU.
3. Save and apply.

Cisco IOS-XE (CLI equivalent)

interface range <client-access-ports>
 spanning-tree portfast
 spanning-tree bpduguard enable

Verification

Cold-boot several PCs across different ports (full power-off → on, not a warm restart). Each should pull its boot image and reach the OS with no iPXE DHCP loop.

Important notes

• Add edge-port / BPDU Guard configuration to the standard diskless-deployment checklist for any managed switch.
• Keep the ggRock server port and all uplinks out of scope — they have been forwarding since the last reboot and must not have BPDU Guard.

Related terms

PXE boot failure, diskless not booting, iPXE "No configuration methods succeeded", error 040ee119, DHCP failed retrying, Spanning Tree convergence, STP / RSTP, PortFast, edge port, BPDU Guard, Meraki-managed Catalyst (C9300X), IOS-XE upgrade, Realtek RTL8126 5GbE autonegotiation, ggRock, ggLeap.

Updated on: 24/06/2026