Una PC, teléfono o AP que nunca obtiene una dirección IP es un problema de cliente a servidor con cuatro capas posibles en el medio, y cada capa tiene su propio comando display dhcp. Este es el orden que encuentra la falla más rápido — además del caso del puerto perimetral STP que bloquea silenciosamente los dispositivos de arranque rápido, y las comprobaciones de DHCP Snooping que aparecen una y otra vez.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Un cliente que no puede obtener una dirección IP es un problema que puede estar en cualquiera de los cuatro dispositivos del camino — identifique la capa antes de leer la configuración.
Una PC, teléfono, cámara o AP que nunca obtiene una dirección por DHCP divide el camino en cuatro dispositivos y tres segmentos de red: el cliente, el switch de acceso al que está conectado, un relé DHCP o dispositivo DHCP Snooping opcional, y el propio servidor DHCP. El ping por sí solo no puede indicar dónde falla realmente el DHCP, porque ICMP y DHCP son tipos de paquete completamente distintos — un enlace que hace ping correctamente puede seguir descartando silenciosamente mensajes DHCP Discover.
A continuación, el árbol de fallas en el que se basa este texto, los comandos display dhcp server / relay / snooping statistics para cada capa, cinco causas raíz que aparecen una y otra vez — incluido un caso de puerto perimetral STP que falla el DHCP específicamente en PC de arranque rápido — y algunas respuestas de preguntas frecuentes extraídas de casos reales de campo.
Las fallas de DHCP se dividen según qué dispositivo de la cadena realmente descarta la conversación — cliente, switch, Snooping/relé, o servidor.
Dos pruebas rápidas ubican el síntoma en este árbol antes que nada: ponga una IP estática en el cliente para confirmar o descartar el DHCP por completo, y — cuando haya un relé involucrado — conecte el cliente directamente al propio segmento del servidor DHCP para aislar el servidor de todo lo que está aguas abajo de él.
Las etiquetas del diagrama se mantienen en inglés para mayor claridad técnica.
Una IP estática en el cliente confirma o descarta el DHCP en segundos. A partir de ahí, los cuatro recuadros en la parte superior del árbol son simplemente una cuestión de qué contadores de display dhcp ... statistics realmente se mueven — solo eso indica qué dispositivo dejar de sospechar.
Cuatro capas, cuatro comandos distintos, y un par de pruebas rápidas que indican qué capa dejar de sospechar.
Si el switch nunca aprende la dirección MAC del cliente en primer lugar, nada aguas abajo importa todavía.
<HUAWEI> display mac-address mac-address 00e0-fc74-32d3
// if this returns nothing, the switch never saw a frame from this client --
// check whether the VLAN exists here and is allowed on the port, then check the next hop
<HUAWEI> display interface GigabitEthernet1/0/1
// Up but error-packet counters climbing -> suspect the cable, not DHCPLa alcanzabilidad por ping no dice nada sobre el DHCP — Discover/Offer/Request/ACK es un tipo de paquete completamente distinto que hay que rastrear por separado.
<HUAWEI> display dhcp snooping statistics
// packet counters per DHCP message type -- confirms whether Discover/Offer/
// Request/ACK actually transited this device, independent of ICMP reachability
<HUAWEI> debugging dhcp snooping error
// error debug for the DHCP Snooping module specifically -- repeat for
// client / relay / server depending on which role this device playsDHCP Snooping se sitúa entre el cliente y el servidor puramente para validar y registrar — una interfaz de confianza faltante bloquea al cliente directamente, no solo el registro de vínculo.
<HUAWEI> display dhcp snooping interface 10GE1/0/1
DHCP snooping running information for interface 10GE1/0/1 :
DHCP snooping : Enable
Trusted interface : No (default)
// no trusted interface configured on the network side -> server replies get dropped
[HUAWEI] interface 10GE1/0/2
[HUAWEI-10GE1/0/2] dhcp snooping trusted
<HUAWEI> display dhcp snooping user-bind all
DHCP Dynamic Bind-table:
IP Address MAC Address VSI/VLAN(O/I/P) Interface Lease
------------------------------------------------------------------
10.1.1.254 00e0-fc74-32d3 100/-- /-- 10GE1/0/1 2026.07.17-16:36
print count: 1 total count: 1
// GIADDR already non-zero because Snooping sits after the first relay hop
[HUAWEI] undo dhcp snooping check dhcp-giaddr enableSi todo lo anterior está limpio y la solicitud definitivamente llega al servidor, lo que queda es el propio pool del servidor y cualquier política de filtrado de paquetes.
<HUAWEI> display ip pool interface Vlanif100
Pool-name : Vlanif100
...
-------------------------------------------------------------------------------
Network section
Start End Total Used Idle(Expired) Conflict Disabled
-------------------------------------------------------------------------------
192.168.4.1 192.168.4.254 254 0 254(0) 0 0
-------------------------------------------------------------------------------
// Idle = 254 here -- if this instead read 0, the pool itself is out of addresses
// shrink the lease on an interface pool so addresses recycle faster:
[HUAWEI-Vlanif100] dhcp server lease day 0 hour 2Una vez que sepa en qué capa está la falla, estas cinco causas explican la mayor parte de lo que realmente falla.
SÍNTOMACiertos modelos de portátiles — el reporte de campo suele ser una marca particular de notebook empresarial — no logran obtener una dirección IP específicamente al arrancar en frío (o en ciertas secuencias de arranque de la tarjeta de red), mientras que otros dispositivos en el mismo switch funcionan bien.
CAUSACuando algunas tarjetas de red se inicializan durante el arranque, hacen parpadear brevemente el enlace antes de estabilizarse. Si el puerto del switch no está configurado como puerto perimetral STP, ese parpadeo se trata como un cambio de topología y desencadena un recálculo STP completo — hasta 30 segundos durante los cuales el puerto no reenvía tráfico en absoluto. El cliente DHCP del cliente solo envía cuatro intentos de Discover en total; si los cuatro caen dentro de esa ventana negra de 30 segundos, el cliente se rinde y reporta una falla de DHCP que no tiene nada que ver con la configuración de DHCP en sí.
SOLUCIÓNConfigure cada puerto de acceso conectado a dispositivos de usuario final como puerto perimetral STP. Un puerto perimetral omite por completo el retraso de escucha/aprendizaje al activarse el enlace, por lo que un parpadeo en el arranque nunca desencadena un recálculo de topología en primer lugar.
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] stp edged-port enableSÍNTOMAUn cliente detrás de un relé DHCP nunca obtiene una dirección, específicamente en topologías donde un switch con DHCP Snooping habilitado se sitúa entre el relé y el servidor en lugar de directamente en el segmento de acceso del cliente.
CAUSACuando el cliente y el servidor están en subredes diferentes, el relé DHCP del primer salto estampa su propia dirección IP en el campo GIADDR de la solicitud antes de reenviarla. Si dhcp snooping check dhcp-giaddr enable está configurado en un dispositivo Snooping situado aguas abajo de ese relé, ve un GIADDR distinto de cero en lo que debería ser una solicitud de primer salto y descarta el paquete como sospechoso.
SOLUCIÓNSin cambiar la topología, deshabilite la comprobación GIADDR en ese dispositivo Snooping. La solución estructuralmente correcta es mover DHCP Snooping al dispositivo de capa de acceso o al propio relé de primer salto, que es donde está diseñado para situarse — Snooping existe para registrar la MAC y el puerto reales del cliente, y esa información solo está disponible en el primer salto.
[HUAWEI] undo dhcp snooping check dhcp-giaddr enableSÍNTOMAEl cliente obtiene con éxito una dirección IP, pero display dhcp snooping user-bind all nunca muestra una entrada para él — la función de seguridad parece simplemente no estar funcionando.
CAUSAQue se cree una entrada de vínculo dinámico depende tanto de la configuración del lado del usuario como del lado de red juntas, no de una sola. Si el puerto del lado del usuario no tiene dhcp snooping enable, o el puerto/VLAN del lado de red no está marcado como interfaz de confianza, el cliente a menudo aún puede obtener una dirección a través del switch — pero Snooping nunca captura la transacción que necesitaba para construir un registro de vínculo.
SOLUCIÓNHabilite dhcp snooping enable en el puerto orientado al cliente y configure dhcp snooping trusted en el puerto orientado a la red (o en todo el VLAN) para que la ruta de respuesta se reconozca como legítima y el par solicitud/respuesta se registre en conjunto.
[HUAWEI] interface 10GE1/0/1
[HUAWEI-10GE1/0/1] dhcp snooping enable
[HUAWEI-10GE1/0/1] quit
[HUAWEI] interface 10GE1/0/2
[HUAWEI-10GE1/0/2] dhcp snooping trustedSÍNTOMADespués de que un switch ha estado funcionando un tiempo, los nuevos clientes conectados a un puerto determinado no pueden obtener una dirección IP y no pueden alcanzar la puerta de enlace en absoluto — mientras que los clientes existentes ya conectados no se ven afectados.
CAUSALa seguridad de puerto con MAC pegajosa convierte cada dirección MAC aprendida dinámicamente en una entrada pegajosa permanente. Una vez alcanzado el número máximo de MAC configurado, el puerto deja de aprender nuevas direcciones por completo y descarta silenciosamente las tramas de cualquier MAC que aún no reconozca — incluido el Discover DHCP de un cliente completamente nuevo, que ni siquiera llega al punto donde el propio DHCP podría responder.
SOLUCIÓNVerifique display mac-address para un puerto atascado en su máximo configurado con cada entrada mostrando type sticky. Si la intención nunca fue bloquear el puerto a un solo dispositivo, eleve port-security enable maximum a un tope razonable para cuántos dispositivos deberían compartir legítimamente ese puerto, o elimine la seguridad de puerto por completo si realmente no se requiere allí.
<HUAWEI> display mac-address
MAC Address VLAN/VSI/BD Learned-From Type Age
-------------------------------------------------------------
0000-0000-0001 100/-/- 10GE1/0/1 sticky 15825
...
0000-0000-0030 100/-/- 10GE1/0/1 sticky 15825
Total items: 30
// port already at its configured maximum of 30 sticky MACs -- a 31st device is refused
[HUAWEI-10GE1/0/1] port-security enable maximum 64SÍNTOMALos clientes en un VLAN o subred en particular no pueden obtener una dirección mientras que todo lo demás en la red no se ve afectado, y tiende a empeorar a lo largo del día en lugar de ser constante.
CAUSALa columna Idle de display ip pool es el número de direcciones genuinamente disponibles para entregar en este momento. Un pool que llega a Idle=0 — por más dispositivos en el segmento de los que el pool fue originalmente dimensionado, o un tiempo de arrendamiento lo bastante largo como para que las entradas obsoletas de dispositivos desconectados aún no hayan caducado — simplemente no tiene nada más que ofrecer, independientemente de si la conversación DHCP en sí funciona correctamente.
SOLUCIÓNReduzca el tiempo de arrendamiento para que las entradas caducadas se reciclen más rápido, divida el VLAN para añadir otro pool de interfaz, o amplíe la máscara de subred del pool si el plan de IP lo permite — aproximadamente en ese orden de cuán disruptivo es cada cambio para la red existente.
<HUAWEI> display ip pool interface Vlanif100
Network section
Start End Total Used Idle(Expired) Conflict Disabled
192.168.4.1 192.168.4.254 254 254 0(0) 0 0
// Idle = 0 -- the pool has nothing left, regardless of DHCP itself being healthy
[HUAWEI-Vlanif100] dhcp server lease day 0 hour 4Sacadas directamente del campo — las que vale la pena tener una respuesta lista.
Dos pruebas antes de tocar cualquier configuración de switch. Primero, ponga una IP estática en el cliente y pruebe la conectividad — si eso también falla, es un problema de alcanzabilidad de Capa 2/3, no DHCP. Segundo, cuando haya un relé involucrado, conecte el cliente directamente al propio segmento del servidor DHCP; si obtiene una dirección allí, el servidor está bien y todo lo que está aguas abajo de él — relé, Snooping, el switch de acceso — es donde hay que mirar.
Este es el patrón del puerto perimetral STP. Algunas tarjetas de red hacen parpadear brevemente el enlace durante su propia secuencia de arranque antes de estabilizarse. En un puerto que no está configurado como puerto perimetral STP, ese parpadeo parece un cambio de topología y desencadena un recálculo completo — hasta 30 segundos sin reenvío. Un cliente DHCP solo reintenta Discover cuatro veces en total, y si los cuatro intentos caen dentro de esa ventana, se rinde. Otros dispositivos que no hacen parpadear su enlace al arrancar nunca desencadenan el problema, por eso parece específico de la marca en lugar de todo el switch.
Una interfaz de confianza basada en VLAN solo se aplica a los paquetes DHCP pertenecientes a esa VLAN específica que pasan por ella; un puerto de confianza basado en interfaz se aplica a cada paquete DHCP que recibe el puerto, independientemente de la VLAN. Use confianza basada en interfaz en un enlace ascendente simple que transporta una o pocas VLAN hacia el servidor, y confianza basada en VLAN cuando el mismo enlace ascendente físico también deba permanecer no confiable para otras VLAN que transporta.
Habilitar DHCP Snooping no inserta automáticamente la Opción 82. La inserción debe configurarse explícitamente — en el VLAN del lado del usuario o en la propia interfaz del lado del usuario — como un paso separado de habilitar Snooping. Verifique display dhcp option82 configuration en el dispositivo de acceso para confirmar que la inserción realmente está activada donde entra el tráfico del cliente, no solo que Snooping esté funcionando en algún lugar del camino.
En el dispositivo de capa de acceso al que el cliente está directamente conectado, o en el relé DHCP de primer salto — nunca más aguas abajo que eso. Todo el propósito de Snooping es registrar la MAC real, la VLAN y el puerto del cliente en una tabla de vínculos, y esa información solo es visible en el primer salto; un dispositivo Snooping situado más adentro de la red solo ve paquetes retransmitidos con la propia dirección del relé sustituida, que es también lo que desencadena el falso positivo de la comprobación GIADDR descrito arriba.
Un ping que funciona solo confirma la alcanzabilidad ICMP; el DHCP es un intercambio de cuatro mensajes completamente distinto (Discover/Offer/Request/ACK) que hay que rastrear en sus propios términos. Verifique display mac-address para confirmar que el switch realmente está aprendiendo al cliente en Capa 2, luego use display dhcp ... statistics en cada salto (snooping, relé, servidor) para ver exactamente dónde el conteo de paquetes específico de DHCP deja de subir — un ping saludable no le dice nada de todo esto.
Esta nota se basa en el modelo de clasificación de fallas DHCP del switch Huawei serie S y sus comandos display dhcp server / relay / snooping statistics, display ip pool, display mac-address y display dhcp snooping, además de los casos de campo detrás de ellos. Si su equipo de acceso o agregación es de otro proveedor, los comandos exactos cambian, pero la lógica por capas subyacente — cliente/puerto de acceso, rastreo de ruta de paquetes, confianza y vínculo de DHCP Snooping, pool y política del servidor — se traslada directamente. No cubre en profundidad los flujos DHCPv6 sin estado/PD específicos, ni el comportamiento de relé DHCP específico de controladores inalámbricos más allá de lo que se aplica igualmente a un switch de acceso cableado.
Cuéntenos en qué capa está atascado — cliente/puerto, Snooping, relé o servidor — junto con la salida de display dhcp ... statistics, y le ayudaremos a interpretarla.