🧩 PXE Boot Fails with PXE-E21 (Remote Host Cancelled)

Caused by Rogue DHCP Helper or Secondary DHCP Server

🔎 Overview

This issue occurs when a ggRock server is configured for full DHCP + PXE, but another device on the same network segment is also responding to DHCP requests.

Common client error:

PXE-E21: Remote host cancelled

This is almost always caused by:

• A DHCP helper (IP helper-address)
• A second DHCP server
• A PXE responder (Acronis, WDS, etc.)
• A network device relaying DHCP unintentionally

🛠️ Symptoms

• PXE clients receive an IP address but fail to boot
• Intermittent boot success
• DHCPNAK wrong server-ID appears in dnsmasq logs
• PXE-E21 error on client
• tcpdump shows replies from multiple IPs

Example capture:

tcpdump -ni vmbr0 port 67 or port 68

Example problematic output:

192.168.50.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply
192.168.50.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply

In this example:

• 192.168.50.10 = ggRock (expected)
• 192.168.50.1 = unexpected responder (gateway or upstream device)

If more than one device replies, PXE behavior becomes unpredictable.

🧠 Why This Happens

During PXE boot:

1. Client sends DHCPDISCOVER
2. Multiple devices respond
3. Client may select a different DHCP server than ggRock
4. ggRock sends a DHCPNAK (wrong server-ID)
5. PXE process aborts
6. Client displays PXE-E21

Even a DHCP helper can cause this if misconfigured.

PXE is extremely sensitive to duplicate responders.

✅ Resolution

Step 1 – Verify Multiple Responders

On the ggRock server:

tcpdump -eni vmbr0 'port 67 or port 68'

Boot a client and observe:

• Are replies coming from multiple IPs?
• What MAC address is the unexpected responder?

Step 2 – Check for DHCP Helpers

On the upstream router or Layer 3 switch, verify:

• No ip helper-address configured
• No DHCP relay enabled on that VLAN
• No boot services enabled

Example (Cisco-like syntax):

interface vlan 50
 no ip helper-address

Step 3 – Check for PXE Responders

Verify these are disabled on any other systems:

• Acronis PXE responder
• Windows Deployment Services (WDS)
• SCCM PXE service point
• Other imaging platforms

Even if DHCP is disabled, PXE responders can still interfere.

Step 4 – Confirm Only ggRock Responds

Run:

tcpdump -ni vmbr0 port 67 or port 68

You should see replies only from:

192.168.50.10

If only ggRock responds, PXE should function normally.

🏗️ Recommended Configuration Structure

To prevent ggrock-linux-configurator from overwriting full DHCP configuration:

1️⃣ Set dnsmasq Config Directory

Verify:

grep CONFIG_DIR /etc/default/dnsmasq

Should show:

CONFIG_DIR=/etc/dnsmasq.main.d

2️⃣ Split DHCP and PXE Configuration

/etc/dnsmasq.main.d/10-dhcp.conf

Contains:

• dhcp-range
• dhcp-option
• dhcp-authoritative

Example:

dhcp-range=192.168.50.20,192.168.50.100,255.255.255.0,12h
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,8.8.8.8,8.8.4.4
dhcp-authoritative

/etc/dnsmasq.main.d/20-pxe.conf

Contains:

• enable-tftp
• tftp-root
• dhcp-boot
• dhcp-vendorclass
• iPXE chainloading logic

Do not use ProxyDHCP (dhcp-range=...,proxy) when running full DHCP.

🔒 Best Practice (Recommended)

If your switch supports it:

• Enable DHCP snooping
• Mark only the ggRock port as trusted
• Block all other DHCP replies

This prevents accidental DHCP responders in the future.

📌 Root Cause Example

In one case:

• A PXE helper was still configured upstream
• It responded alongside ggRock
• Clients received multiple DHCP offers
• PXE-E21 occurred
• Removing the helper immediately resolved the issue

🧾 Summary

PXE-E21 during ggRock full DHCP deployments is almost always caused by:

• A second DHCP server
• A DHCP helper
• A PXE responder

PXE requires a single authoritative DHCP server on the segment.

When troubleshooting DHCP:

Packet capture is the source of truth.

Updated on: 26/02/2026