> ## 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).

# Falla el arranque PXE con PXE-E21 (Host remoto cancelado)

# 🧩 El arranque PXE falla con PXE-E21 (Host remoto cancelado)
### Causado por un DHCP Helper no autorizado o un servidor DHCP secundario
## 🔎 Descripción general
Este problema ocurre cuando un servidor ggRock está configurado para **DHCP completo + PXE**, pero otro dispositivo en el mismo segmento de red también responde a solicitudes DHCP.
Error común del cliente:
```
PXE-E21: Remote host cancelled
```
Casi siempre es causado por:
* Un DHCP helper (IP helper-address)
* Un segundo servidor DHCP
* Un respondedor PXE (Acronis, WDS, etc.)
* Un dispositivo de red retransmitiendo DHCP involuntariamente
## 🛠️ Síntomas
* Los clientes PXE reciben una dirección IP pero fallan al arrancar
* Éxito de arranque intermitente
* `DHCPNAK wrong server-ID` aparece en los registros de dnsmasq
* Error PXE-E21 en el cliente
* tcpdump muestra respuestas de múltiples IPs
Captura de ejemplo:
```
tcpdump -ni vmbr0 port 67 or port 68
```
Salida problemática de ejemplo:
```
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
```
En este ejemplo:
* `192.168.50.10` = ggRock (esperado)
* `192.168.50.1` = respondedor inesperado (puerta de enlace o dispositivo ascendente)
Si más de un dispositivo responde, el comportamiento PXE se vuelve impredecible.
## 🧠 Por qué sucede esto
Durante el arranque PXE:
1. El cliente envía DHCPDISCOVER
2. Múltiples dispositivos responden
3. El cliente puede seleccionar un servidor DHCP diferente a ggRock
4. ggRock envía un DHCPNAK (wrong server-ID)
5. El proceso PXE se cancela
6. El cliente muestra PXE-E21
Incluso un DHCP helper puede causar esto si está mal configurado.
PXE es extremadamente sensible a respondedores duplicados.
## ✅ Resolución
### Paso 1 – Verifica múltiples respondedores
En el servidor ggRock:
```
tcpdump -eni vmbr0 'port 67 or port 68'
```
Arranca un cliente y observa:
* ¿Las respuestas provienen de múltiples IPs?
* ¿Cuál es la dirección MAC del respondedor inesperado?
### Paso 2 – Busca DHCP Helpers
En el router ascendente o switch de Capa 3, verifica:
* No hay `ip helper-address` configurado
* No hay DHCP relay habilitado en esa VLAN
* No hay servicios de arranque habilitados
Ejemplo (sintaxis similar a Cisco):
```
interface vlan 50
 no ip helper-address
```
### Paso 3 – Busca respondedores PXE
Verifica que estos estén deshabilitados en cualquier otro sistema:
* Respondedor PXE de Acronis
* Windows Deployment Services (WDS)
* Punto de servicio PXE de SCCM
* Otras plataformas de imaging
Incluso si DHCP está deshabilitado, los respondedores PXE aún pueden interferir.
### Paso 4 – Confirma que solo ggRock responde
Ejecuta:
```
tcpdump -ni vmbr0 port 67 or port 68
```
Deberías ver respuestas solo de:
```
192.168.50.10
```
Si solo ggRock responde, PXE debería funcionar normalmente.
## 🏗️ Estructura de configuración recomendada
Para evitar que `ggrock-linux-configurator` sobrescriba la configuración completa de DHCP:
### 1️⃣ Establece el directorio de configuración de dnsmasq
Verifica:
```
grep CONFIG_DIR /etc/default/dnsmasq
```
Debería mostrar:
```
CONFIG_DIR=/etc/dnsmasq.main.d
```
### 2️⃣ Divide la configuración de DHCP y PXE
**/etc/dnsmasq.main.d/10-dhcp.conf**
Contiene:
* `dhcp-range`
* `dhcp-option`
* `dhcp-authoritative`
Ejemplo:
```
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**
Contiene:
* `enable-tftp`
* `tftp-root`
* `dhcp-boot`
* `dhcp-vendorclass`
* Lógica de encadenamiento de iPXE
No uses ProxyDHCP (`dhcp-range=...,proxy`) cuando ejecutas DHCP completo.
## 🔒 Mejor práctica (recomendado)
Si tu switch lo soporta:
* Habilita DHCP snooping
* Marca solo el puerto de ggRock como confiable
* Bloquea todas las otras respuestas DHCP
Esto evita respondedores DHCP accidentales en el futuro.
## 📌 Ejemplo de causa raíz
En un caso:
* Un DHCP helper aún estaba configurado ascendentemente
* Respondía junto a ggRock
* Los clientes recibían múltiples ofertas DHCP
* Ocurrió PXE-E21
* Eliminar el helper resolvió inmediatamente el problema
## 🧾 Resumen
PXE-E21 durante despliegues de DHCP completo de ggRock casi siempre es causado por:
* Un segundo servidor DHCP
* Un DHCP helper
* Un respondedor PXE
PXE requiere un **único servidor DHCP autoritativo** en el segmento.
Cuando solucionas problemas de DHCP:
```
La captura de paquetes es la fuente de verdad.