Um PC, telefone ou AP que nunca obtém um endereço IP é um problema de cliente a servidor com quatro camadas possíveis no meio, e cada camada tem seu próprio comando display dhcp. Esta é a ordem que encontra a falha mais rápido — além do caso da porta de borda STP que bloqueia silenciosamente dispositivos de inicialização rápida, e as verificações de DHCP Snooping que aparecem repetidamente.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Um cliente que não consegue obter um endereço IP é um problema que pode estar em qualquer um dos quatro dispositivos do caminho — identifique a camada antes de ler a configuração.
Um PC, telefone, câmera ou AP que nunca obtém um endereço via DHCP divide o caminho em quatro dispositivos e três segmentos de rede: o cliente, o switch de acesso ao qual está conectado, um relay DHCP ou dispositivo DHCP Snooping opcional, e o próprio servidor DHCP. O ping sozinho não consegue dizer onde o DHCP realmente está falhando, porque ICMP e DHCP são tipos de pacote completamente diferentes — um link que faz ping bem ainda pode estar descartando silenciosamente mensagens DHCP Discover.
A seguir está a árvore de falhas na qual isto se baseia, os comandos display dhcp server / relay / snooping statistics para cada camada, cinco causas-raiz que aparecem repetidamente — incluindo um caso de porta de borda STP que falha o DHCP especificamente em PCs de inicialização rápida — e algumas respostas de perguntas frequentes tiradas de casos reais de campo.
As falhas de DHCP se dividem conforme qual dispositivo da cadeia realmente descarta a conversa — cliente, switch, Snooping/relay, ou servidor.
Dois testes rápidos posicionam o sintoma nesta árvore antes de qualquer outra coisa: coloque um IP estático no cliente para confirmar ou descartar o DHCP por completo, e — quando um relay estiver envolvido — conecte o cliente diretamente ao próprio segmento do servidor DHCP para isolar o servidor de tudo que está a jusante dele.
Os rótulos do diagrama são mantidos em inglês para maior clareza técnica.
Um IP estático no cliente confirma ou descarta o DHCP em segundos. A partir daí, as quatro caixas no topo da árvore são puramente uma questão de quais contadores de display dhcp ... statistics realmente se movem — só isso já diz qual dispositivo parar de suspeitar.
Quatro camadas, quatro comandos diferentes, e alguns testes rápidos que dizem qual camada parar de suspeitar.
Se o switch nunca aprender o endereço MAC do cliente em primeiro lugar, nada a jusante importa ainda.
<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 DHCPA alcançabilidade por ping não diz nada sobre o DHCP — Discover/Offer/Request/ACK é um tipo de pacote completamente diferente que precisa ser rastreado separadamente.
<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 playsO DHCP Snooping fica entre o cliente e o servidor puramente para validar e registrar — uma interface confiável ausente bloqueia o cliente diretamente, não apenas o 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 enableSe tudo a montante estiver limpo e a solicitação definitivamente chegar ao servidor, o que resta é o próprio pool do servidor e qualquer política de filtragem de pacotes.
<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 2Depois que você souber em qual camada está a falha, essas cinco causas explicam a maior parte do que realmente está errado.
SINTOMACertos modelos de notebook — o relato de campo costuma ser uma marca específica de notebook corporativo — falham em obter um endereço IP especificamente ao ligar a frio (ou em certas sequências de inicialização da placa de rede), enquanto outros dispositivos no mesmo switch funcionam bem.
CAUSAQuando algumas placas de rede inicializam durante o boot, elas piscam brevemente o link antes de estabilizar. Se a porta do switch não estiver configurada como porta de borda STP, essa piscada é tratada como uma mudança de topologia e dispara um recálculo STP completo — até 30 segundos durante os quais a porta não encaminha nenhum tráfego. O cliente DHCP do cliente envia apenas quatro tentativas de Discover no total; se todas as quatro caírem dentro dessa janela escura de 30 segundos, o cliente desiste e relata uma falha de DHCP que não tem nada a ver com a configuração de DHCP em si.
CORREÇÃOConfigure cada porta de acesso conectada a dispositivos de usuário final como porta de borda STP. Uma porta de borda pula completamente o atraso de escuta/aprendizado ao ativar o link, então uma piscada no momento da inicialização nunca dispara um recálculo de topologia.
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] stp edged-port enableSINTOMAUm cliente atrás de um relay DHCP nunca obtém um endereço, especificamente em topologias onde um switch com DHCP Snooping habilitado fica entre o relay e o servidor em vez de diretamente no segmento de acesso do cliente.
CAUSAQuando o cliente e o servidor estão em sub-redes diferentes, o relay DHCP do primeiro salto grava seu próprio endereço IP no campo GIADDR da solicitação antes de encaminhá-la. Se dhcp snooping check dhcp-giaddr enable estiver configurado em um dispositivo Snooping posicionado a jusante desse relay, ele vê um GIADDR diferente de zero no que deveria ser uma solicitação de primeiro salto e descarta o pacote como suspeito.
CORREÇÃOSem mudar a topologia, desabilite a verificação GIADDR nesse dispositivo Snooping. A correção estruturalmente correta é mover o DHCP Snooping para o dispositivo da camada de acesso ou para o próprio relay de primeiro salto, que é onde ele foi projetado para ficar — o Snooping existe para registrar o MAC real e a porta do cliente, e essa informação só está disponível no primeiro salto.
[HUAWEI] undo dhcp snooping check dhcp-giaddr enableSINTOMAO cliente obtém um endereço IP com sucesso, mas display dhcp snooping user-bind all nunca mostra uma entrada para ele — o recurso de segurança parece simplesmente não estar funcionando.
CAUSASe uma entrada de vínculo dinâmico é criada depende tanto da configuração do lado do usuário quanto do lado da rede juntas, não de apenas uma delas. Se a porta do lado do usuário não tiver dhcp snooping enable, ou a porta/VLAN do lado da rede não estiver marcada como interface confiável, o cliente muitas vezes ainda consegue obter um endereço através do switch — mas o Snooping nunca captura a transação de que precisava para construir um registro de vínculo.
CORREÇÃOHabilite dhcp snooping enable na porta voltada para o cliente e configure dhcp snooping trusted na porta voltada para a rede (ou na VLAN como um todo) para que o caminho de resposta seja reconhecido como legítimo e o par solicitação/resposta seja registrado junto.
[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 trustedSINTOMADepois que um switch está funcionando por um tempo, novos clientes conectados a uma determinada porta não conseguem obter um endereço IP e não conseguem alcançar o gateway de forma alguma — enquanto os clientes existentes já conectados não são afetados.
CAUSAA segurança de porta com MAC sticky converte cada endereço MAC aprendido dinamicamente em uma entrada sticky permanente. Uma vez atingido o número máximo de MAC configurado, a porta para completamente de aprender novos endereços e descarta silenciosamente quadros de qualquer MAC que ainda não reconheça — incluindo o Discover DHCP de um cliente totalmente novo, que nem sequer chega ao ponto em que o próprio DHCP poderia responder.
CORREÇÃOVerifique display mac-address para uma porta travada no seu máximo configurado com cada entrada mostrando type sticky. Se a intenção nunca foi travar a porta em um único dispositivo, aumente port-security enable maximum para um teto razoável para quantos dispositivos devem legitimamente compartilhar essa porta, ou remova a segurança de porta completamente se ela não for realmente necessária ali.
<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 64SINTOMAClientes em um VLAN ou sub-rede específico não conseguem obter um endereço enquanto tudo o mais na rede não é afetado, e tende a piorar ao longo do dia em vez de ser constante.
CAUSAA coluna Idle de display ip pool é o número de endereços genuinamente disponíveis para distribuir agora. Um pool que chega a Idle=0 — por haver mais dispositivos no segmento do que o pool foi originalmente dimensionado, ou um tempo de lease longo o suficiente para que entradas obsoletas de dispositivos desconectados ainda não tenham expirado — simplesmente não tem mais nada a oferecer, independentemente de a conversa DHCP em si estar funcionando corretamente.
CORREÇÃOReduza o tempo de lease para que entradas expiradas reciclem mais rápido, divida a VLAN para adicionar outro pool de interface, ou amplie a máscara de sub-rede do pool se o plano de IP permitir — mais ou menos nessa ordem de quão disruptiva cada mudança é para a rede 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 4Tiradas direto do campo — as que vale a pena ter uma resposta pronta.
Dois testes antes de mexer em qualquer configuração de switch. Primeiro, coloque um IP estático no cliente e teste a conectividade — se isso também falhar, é um problema de alcançabilidade de Camada 2/3, não DHCP. Segundo, quando um relay estiver envolvido, conecte o cliente diretamente ao próprio segmento do servidor DHCP; se obtiver um endereço lá, o servidor está bem e tudo a jusante dele — relay, Snooping, o switch de acesso — é onde procurar.
Este é o padrão da porta de borda STP. Algumas placas de rede piscam brevemente o link durante sua própria sequência de boot antes de estabilizar. Em uma porta que não está configurada como porta de borda STP, essa piscada parece uma mudança de topologia e dispara um recálculo completo — até 30 segundos sem encaminhamento. Um cliente DHCP só tenta novamente o Discover quatro vezes no total, e se todas as quatro tentativas caírem dentro dessa janela, ele desiste. Outros dispositivos que não piscam o link ao ligar nunca disparam o problema, por isso parece específico da marca em vez de todo o switch.
Uma interface confiável baseada em VLAN só se aplica a pacotes DHCP pertencentes àquela VLAN específica que passam por ela; uma porta confiável baseada em interface se aplica a todo pacote DHCP que a porta recebe, independentemente da VLAN. Use confiança baseada em interface em um uplink simples que carrega uma ou poucas VLANs em direção ao servidor, e confiança baseada em VLAN quando o mesmo uplink físico também precisa permanecer não confiável para outras VLANs que ele carrega.
Habilitar o DHCP Snooping não insere automaticamente a Opção 82. A inserção deve ser configurada explicitamente — na VLAN do lado do usuário ou na própria interface do lado do usuário — como uma etapa separada de habilitar o Snooping. Verifique display dhcp option82 configuration no dispositivo de acesso para confirmar que a inserção está realmente ativada onde o tráfego do cliente entra, não apenas que o Snooping está rodando em algum lugar do caminho.
No dispositivo da camada de acesso ao qual o cliente está diretamente conectado, ou no relay DHCP de primeiro salto — nunca mais a jusante do que isso. Todo o propósito do Snooping é registrar o MAC real, a VLAN e a porta do cliente em uma tabela de vínculo, e essa informação só é visível no primeiro salto; um dispositivo Snooping situado mais fundo na rede só vê pacotes retransmitidos com o próprio endereço do relay substituído, o que também é o que dispara o falso positivo da verificação GIADDR descrito acima.
Um ping funcionando só confirma a alcançabilidade ICMP; o DHCP é uma troca de quatro mensagens completamente diferente (Discover/Offer/Request/ACK) que precisa ser rastreada em seus próprios termos. Verifique display mac-address para confirmar que o switch realmente está aprendendo o cliente na Camada 2, depois use display dhcp ... statistics em cada salto (snooping, relay, servidor) para ver exatamente onde a contagem de pacotes específica do DHCP para de subir — um ping saudável não diz nada sobre nada disso.
Esta nota se baseia no modelo de classificação de falhas de DHCP do switch Huawei série S e seus comandos display dhcp server / relay / snooping statistics, display ip pool, display mac-address e display dhcp snooping, além dos casos de campo por trás deles. Se seu equipamento de acesso ou agregação for de outro fornecedor, os comandos exatos mudam, mas a lógica em camadas subjacente — cliente/porta de acesso, rastreamento de caminho de pacotes, confiança e vínculo de DHCP Snooping, pool e política do servidor — se aplica diretamente. Não cobre em profundidade os fluxos DHCPv6 sem estado/PD específicos, nem o comportamento de relay DHCP específico de controladores sem fio além do que se aplica igualmente a um switch de acesso cabeado.
Conte-nos em qual camada está travado — cliente/porta, Snooping, relay ou servidor — junto com a saída de display dhcp ... statistics, e ajudaremos você a interpretar.