> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://helpdesk.ggcircuit.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

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

# 🧩 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.
```