DHCP (Dynamic Host Configuration Protocol) es la base automática para la asignación de IP, gateway y DNS. Cuando las reservas DHCP no se aplican, los leases «se quedan colgados» o los clientes de repente usan direcciones incorrectas, a menudo se producen averías generalizadas: VoIP pierde el registro, las impresoras dejan de encontrarse, los clientes VPN terminan en servidores DNS incorrectos. Este Runbook resume causas prácticas, secuencias de comprobación y estrategias de contingencia para que proceda de manera estructurada en entornos mixtos Windows-, Linux- y appliance.
Lo que realmente importa en DHCP
Comprenda brevemente la mecánica práctica: el intercambio DHCP se realiza clásicamente como DORA (Discover, Offer, Request, Ack). Determinante para las reservas es la identidad del cliente: en muchos casos no es la dirección MAC, sino el DHCP Client Identifier (Option 61). Los leases tienen tiempos de renovación T1/T2; si la renovación falla, parece un fallo repentino.
Reservas DHCP: práctica y diagnóstico
Recomendaciones concretas para reservas en producción: cree la reserva sobre la identidad que el cliente realmente envía. Muchos sistemas operativos y dispositivos modernos usan, en lugar de la MAC de hardware, un Client Identifier (Option 61), UUIDs o IDs específicas del vendor; las capas de virtualización también pueden cambiar las MAC durante operaciones de clonación. Documente cada reserva en su IPAM (gestión de direcciones IP) y presente un registro de cambios: quién creó la reserva, cuándo y para qué dispositivo objetivo.
Síntomas frecuentes y sus causas probables
La reserva es ignorada
A menudo se debe a identidad incorrecta (Client Identifier vs. MAC), reserva en el scope/VLAN equivocado, o un segundo servidor DHCP ofrece otra oferta. Virtualización, NIC‑Teaming o funciones de privacidad pueden cambiar identidades. Comprobación rápida: una captura de paquetes muestra qué campos envía el cliente.
Leases problemáticos tras cambio de red (WLAN, VPN, Dock)
Las causas son: lease antiguo en la caché del cliente, opciones DHCP diferentes por red, falta de configuración del relay o problemas con sufijos DNS a través de VPN. Problemas de MTU o de enrutamiento pueden agravar la situación y provocar fragmentación de paquetes.
IP duplicada (conflicto de direcciones)
Principalmente causado por IPs estáticas en el pool dinámico, reservas olvidadas o VMs clonadas. También VRRP/HSRP o datos de IPAM mal mantenidos conducen a conflictos. Compruebe las cachés ARP y las tablas MAC del switch para identificar hosts activos.
Sólo afecta a un VLAN/ubicación
Aquí son sospechosos el relay/IP‑Helper, las ACL, el DHCP Snooping o puertos de acceso/WLAN‑SSID‑VLAN mal configurados. Verifique si GIADDR en el servidor coincide con la subred esperada.
Orden de verificación estructurado (pasos breves y priorizados)
Recorra la cadena: 1) nivel físico/VLAN (gateway, trunks, ACLs), 2) servicio de red (relay/IP‑helper, Option 82, DHCP Snooping), 3) servidores (scopes, reservas, leases, failover), 4) clientes y dispositivos especiales. Este orden evita intervenciones innecesarias en el cliente y reduce el riesgo.
Comprobaciones de red: switches, relay y snooping
Comprobar DHCP Snooping y bindings del switch
DHCP Snooping (una función que bloquea respuestas DHCP no autorizadas) previene servidores rogue, pero requiere definiciones correctas de puertos trusted. Con una configuración incorrecta, servidores legítimos pueden quedar bloqueados. En Cisco IOS/IOS‑XE compruebe los bindings y el estado:
# Cisco IOS Beispiel: Status und Bindings prüfen
show ip dhcp snooping
show ip dhcp snooping binding
show running-config | include ip dhcp snoopingLa tabla de bindings contiene las asignaciones MAC→IP→VLAN; si está vacía, falta conectividad o el switch no ve tráfico DHCP.
Relay (IP Helper) und Option 82
El relay‑agent (IP Helper) establece GIADDR (Gateway IP Address) y puede añadir la Opción 82 (Relay Agent Information). Si el servidor usa la Opción 82, cambia el emparejamiento de reservas y políticas. Compruebe si el servidor procesa o ignora la Opción 82 y, ante problemas, pruebe temporalmente a eliminar la Opción 82.
Serverseitige Diagnose und Konkrete Checks
Windows DHCP Server: Suche nach Identitätsabweichungen
Windows almacena ClientId en la base de datos DHCP. Si los dispositivos usan la Opción 61, la reserva puede no aparecer donde la espera. Cree reservas con los cmdlets Get/Set y compruebe los leases:
# Beispiel: Reservierung anlegen und prüfen (Windows DHCP)
Add-DhcpServerv4Reservation -ScopeId 10.20.30.0 -IPAddress 10.20.30.42 -ClientId "01-11-22-33-44-55" -Description "Konferenzdrucker"
Get-DhcpServerv4Reservation -ScopeId 10.20.30.0 | Where-Object {$_.IPAddress -eq '10.20.30.42'}
# Scope‑Statistiken
Get-DhcpServerv4ScopeStatistics -ScopeId 10.20.30.0Tenga en cuenta que ClientId suele estar en el formato 01+MAC (01 prefijado) o como cadena de texto; utilice exactamente el formato que muestra el servidor.
ISC dhcpd: Reservierung (host) im dhcpd.conf
En ISC dhcpd, el archivo dhcpd.leases es la fuente de la verdad; los cambios en el fichero de configuración deben verificarse sintácticamente y el servicio reiniciarse o recibir una señal HUP:
# Beispielhost‑Reservierung in /etc/dhcp/dhcpd.conf
host printer-konf01 {
hardware ethernet 11:22:33:44:55:66;
fixed-address 10.20.30.42;
option host-name "Konf-Printer01";
}
# Syntaxprüfung
sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf
# Neustart (Debian/Ubuntu)
sudo systemctl RESTart isc-dhcp-serverEn configuraciones HA/Failover, vigile datos de leases inconsistentes entre master/slave y evite intervenciones manuales simultáneas en el archivo de leases.
Packet Capture: Schlüsseldaten erkennen
Una captura es la prueba más fiable: quién envía DHCPOFFER/DHCPACK, qué GIADDR/Option82 está establecida y qué contienen las opciones 61/50/54. Use tcpdump/tshark/Wireshark para análisis precisos.
# tcpdump Beispiel: DHCP Traffic mitschneiden
sudo tcpdump -i eth0 -nn -s 0 -w dhcp.pcap 'udp and (port 67 or port 68)'
# tshark: DHCP Felder extrahieren (Client Identifier, GIADDR, Server Identifier)
tshark -r dhcp.pcap -T fields -e dhcp.option.client_id -e ip.src -e ip.dst -e bootp.giaddr -e bootp.file -E header=y -E separator=,
# Wireshark Displayfilter Beispiele
bootp.option.type == 61 # Client Identifier
bootp.option.type == 82 # Relay Agent Information
bootp.option.type == 54 # DHCP Server IdentifierInterpretación: si aparece la Opción 61 que no corresponde con la MAC esperada, debe reasignar la reserva a ese ClientId o ajustar el lado cliente.
Client‑Seite: gezielte Maßnahmen und Diagnostics
En el cliente, primero compruebe los valores visibles, luego los logs/cache y finalmente acciones de reinicio específicas. En Windows los EventLogs aportan indicios; en Linux los archivos de lease y systemd/journal. Para dispositivos problemáticos se recomienda una prueba controlada en un VLAN de pruebas aislado.
Runbooks prácticos: escenarios típicos y pasos
Escenario A: la reserva no se aplica
- En el cliente afectado, realizar una captura de paquetes (o SPAN desde el puerto de acceso) y comprobar el identificador del cliente.
- En el servidor DHCP, buscar una coincidencia para exactamente ese identificador de cliente.
- Si la reserva en el servidor está vinculada a la MAC, cree una nueva reserva para la ClientId encontrada o modifique el cliente para que use la MAC (p. ej., la configuración del adaptador de red de la VM).
- Solicitar la renovación del cliente (ipconfig/renew o dhclient‑Release/Renew) y comprobar el registro.
Escenario B: muchos clientes reciben APIPA o conservan la IP anterior
- Comprobar la ocupación del scope (Pool‑Exhaustion).
- Verificar a nivel de red si el Discover llega al servidor (captura de paquetes en el relay/gateway).
- Comprobar en el switch el DHCP Snooping por errores; verificar ACLs/firewall para UDP 67/68.
- Reducir temporalmente el tiempo de concesión para pruebas (Atención: aumenta el tráfico DHCP) y monitorizar.
Monitorización, alertas y automatización
Una operación estable necesita métricas: IPs disponibles en el pool, tasa de mensajes de IP duplicada, tiempos de espera en las solicitudes DHCP, y número de Rogue‑DHCPOFFERs por hora. Si dispone de logs centralizados (Syslog, ELK, Splunk), filtre por eventos Bootp/DHCP y defina umbrales.
# Ejemplo ELK/Splunk: Búsqueda de DHCPOFFERs inesperados (pseudo‑consulta)
source="/var/log/messages" OR source="/var/log/syslog" "DHCPOFFER" NOT (src_ip==10.20.30.5 OR src_ip==10.20.30.6)
Automatización concreta: si su API de IPAM está disponible, se pueden crear y auditar reservas mediante flujos de trabajo PR/Change. Para Windows DHCP son apropiados scripts de PowerShell; para ISC dhcpd, los cambios pueden desplegarse desde un repositorio de configuración central mediante CI/CD (con comprobación de sintaxis previa).
Consejos de resolución de problemas específicos para VPN
Las configuraciones VPN requieren atención especial, ya que la MTU del túnel, las estrategias de split‑tunnel y el DNS del túnel afectan la experiencia DHCP. Compruebe siempre ambos extremos (el cliente local y el extremo del túnel) y compare las capturas.
# Prueba de MTU a través del túnel: ping con bandera DF
ping -M do -s 1400 vpn-gateway.example.com
# Comprobar MSS‑Clamping: observar conexiones TCP para ver si la fragmentación causa problemasConsejo: si los servidores VPN usan pools propios, documente sus perfiles de lease y las políticas DNS. En relays site‑to‑site compruebe el enrutamiento asimétrico; un Offer puede regresar por una ruta diferente y ser descartado por el cliente.
Implementación y estrategia de retroceso
Realice los cambios de DHCP de forma planificada: hacer copia de seguridad de la base de datos/archivos DHCP antes de cambiar, aplicar cambios en pasos pequeños por scope, monitorizar la ocupación del scope, y definir criterios claros de rollback (p. ej., aumento notable de eventos de IP duplicada o Pool‑Exhaustion). Proponga pasos de rollback en su ticket de cambio (who, when, how). Buena práctica: trabaje en una ventana de mantenimiento/pruebas e informe previamente a los clientes/equipos afectados.
Conclusión
Los problemas de DHCP se pueden resolver de forma fiable si actúa de manera metódica: primero la ruta (VLAN, Relay, Firewall), luego el lado del servidor (Scope, concesiones, reservas) y, por último, los clientes y dispositivos especiales. Las capturas de paquetes suelen ser la prueba más rápida para problemas de identidad y de relay. Un plan de direccionamiento limpio, reglas de reserva documentadas, perfiles de concesión y medidas activas contra Rogue‑DHCP (DHCP Snooping con definiciones claras de Trust) son las palancas más efectivas para un funcionamiento estable en redes heterogéneas. Mantenga sus procesos auditables y automatice las comprobaciones recurrentes para reducir escaladas.
Reservas DHCP: arquitectura, escalabilidad y aspectos operativos
Además de la mera resolución de fallos, merece la pena revisar la arquitectura y la operación: allí residen muchos riesgos que después derivan en interrupciones recurrentes. Diseñe los servicios DHCP como un componente de infraestructura crítico para la operación, con responsabilidades claras, auditabilidad y validación automática.
Disponibilidad y consistencia
No escale DHCP simplemente copiando la configuración. Los servicios stateful necesitan un repositorio de concesiones consistente. Utilice los mecanismos de failover previstos por el fabricante (Windows DHCP Failover, ISC dhcpd‑Failover‑Protocol) en lugar de copias manuales. Atención al riesgo de split‑brain: si ambos nodos actúan simultáneamente como primarios, se generan concesiones duplicadas y conflictos de direcciones.
Copia de seguridad, recuperación rápida y control de cambios
Una copia rápida de seguridad de los datos de concesiones y de la configuración es obligatoria antes de cualquier cambio. Ejemplo: exportar Windows DHCP, asegurar las concesiones de ISC:
# Windows: DHCP-Konfiguration und Leases exportieren
Export-DhcpServer -ComputerName dhcp01 -File C:backupsdhcp-dump.xml -Leases -Force# ISC dhcpd: Leases sichern und Configuration in Versionskontrolle
sudo cp /var/lib/dhcp/dhcpd.leases /var/backups/dhcpd.leases.$(date +%F)
sudo rsync -a /etc/dhcp/ /var/backups/dhcp-config/Realice los cambios mediante ticket y pipeline CI/CD: comprobación de sintaxis, despliegue canario en un Scope y health‑checks automatizados minimizan el riesgo de indisponibilidad.
Integración con IPAM y automatización
Conecte DHCP con su IPAM a través de APIs, pero tenga en cuenta las condiciones de carrera: dos sistemas no deben liberar simultáneamente la misma dirección. Las opciones de diseño son: IPAM como Single Source of Truth con modelo push hacia el servidor DHCP, o DHCP como fuente primaria con reconciliación periódica. Implemente acciones idempotentes y resolución de conflictos (por ejemplo, bloqueo de API o actualizaciones transaccionales).
Supervisión, alertas y métricas
Operationalice métricas: IPs disponibles por Scope, Offer→Ack‑Ratio, número de Rogue‑Offers, número de Duplicate‑IP‑Events, errores de renovación de concesiones (errores T1/T2). Defina umbrales claros, p. ej. alerta cuando las IPs disponibles < 10% o Duplicate‑IP‑Events > 5 en 15 minutos.
Seguridad e integración de red
Los segmentos donde corre DHCP deberían estar en el Management‑VLAN o en un Control‑Plane estrictamente controlado. Proteja los agentes Relay y los Trust‑Ports en DHCP Snooping y documente el uso de Option‑82. Para los auditores, mantenga registros de auditoría: quién creó las reservas, cuándo y con qué ClientIdentifier.
Regla práctica: pruebe cada cambio de configuración primero en un Scope aislado, automatice las validaciones y defina criterios simples de rollback (p. ej. caída de tasas de ACK o aumento de mensajes de conflicto). De ese modo DHCP sigue siendo una base fiable para sus redes heterogéneas.
Para este tema también son importantes el arrendamiento DHCP y la resolución de problemas DHCP. El artículo contextualiza estos aspectos de forma comprensible y muestra en qué hay que centrarse en la práctica diaria.