Artículos sobre: ggRock
Este artículo también está disponible en:

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.

Actualizado el: 10/04/2026

¿Este artículo te resultó útil?

Comparte tu opinión

Cancelar

¡Gracias!