As 10 Principais Causas de DHCP Timeouts em Redes Sem Fios de Alta Densidade

Bem-vindo à Série de Briefing Técnico da Purple. Eu sou o vosso anfitrião e hoje vamos mergulhar num dos problemas mais frustrantes — e, francamente, mais mal diagnosticados — nas redes sem fios empresariais: os timeouts de DHCP em redes de alta densidade. Se gere WiFi num hotel, num centro de conferências, numa cadeia de retalho ou num estádio, e os seus convidados ou funcionários estão a deparar-se com o temido indicador "a obter endereço IP", este episódio é para si. Vamos abordar as dez principais causas, como diagnosticar cada uma delas e o que deve fazer em relação a isso agora mesmo. Primeiro, vamos contextualizar. O DHCP — Dynamic Host Configuration Protocol — é o mecanismo pelo qual cada dispositivo que se liga à sua rede obtém um endereço IP, uma máscara de sub-rede, um gateway predefinido e informações do servidor DNS. É um handshake de quatro etapas: Discover, Offer, Request, Acknowledge — o que os engenheiros chamam de processo DORA. Parece simples, e numa rede pequena é. Mas quando tem quinhentos dispositivos a sobrecarregar uma única VLAN num balcão de credenciação de uma conferência, ou dez mil adeptos a abrir simultaneamente a aplicação do estádio, o DHCP torna-se num estrangulamento crítico. E quando falha, os utilizadores não conseguem aceder à internet. Ponto final. Vamos então às dez causas. Número um: exaustão do pool de IPs. Esta é a causa mais comum e é totalmente evitável. O seu escopo de DHCP — o intervalo de endereços IP que o seu servidor está autorizado a distribuir — tem um tamanho finito. Uma sub-rede slash-24 fornece-lhe 254 endereços utilizáveis. Isso parece suficiente até considerarmos o facto de os dispositivos móveis frequentemente manterem as concessões (leases) mesmo após a desconexão, os dispositivos IoT estarem a proliferar pelo seu espaço e o seu escopo ter sido dimensionado para uma ocupação normal, e não para um evento com lotação esgotada. A solução é simples: dimensione corretamente os seus escopos. Para ambientes de alta densidade, utilize sub-redes slash-22 ou slash-21. Isso garante-lhe mais de mil endereços por VLAN. Monitorize a utilização e configure alertas para os oitenta por cento de capacidade — nunca permita que atinja os noventa. Número dois: tempos de concessão (lease times) excessivos. Este é o assassino silencioso. Se o seu tempo de concessão DHCP estiver definido para vinte e quatro horas — que é o valor predefinido em muitos sistemas — e gere um espaço onde os convidados entram e saem ao longo do dia, esses endereços IP estão a ser retidos por dispositivos que saíram há horas. Não estão disponíveis para novas ligações. Para o WiFi de convidados em ambientes de elevada rotatividade — hotéis, retalho, eventos — defina o seu tempo de concessão para trinta a sessenta minutos. Para redes de funcionários corporativos onde os dispositivos permanecem ligados o dia todo, o adequado é de oito a doze horas. Nunca utilize a concessão predefinida de vinte e quatro horas numa rede de convidados. Número três: má configuração do agente de relay DHCP. Em qualquer implementação empresarial com múltiplas VLANs, o seu servidor DHCP está quase de certeza numa sub-rede diferente da dos seus clientes sem fios. O agente de relay DHCP — normalmente configurado no seu switch Layer 3 ou router — é responsável por encaminhar as transmissões (broadcasts) DHCP dos clientes para o servidor. Se o relay estiver mal configurado — endereço "helper" errado, interface errada ou se o relay estiver simplesmente em falta numa nova VLAN — os clientes nunca receberão uma resposta ao seu DHCPDISCOVER. Esta é uma das causas mais comuns de falhas de DHCP após uma alteração de rede ou a implementação de um novo SSID. Verifique sempre a configuração do relay ao adicionar VLANs e teste com uma captura de pacotes antes de entrar em produção. Número quatro: interferência por tempestade de broadcast (broadcast storm). As mensagens de descoberta de DHCP são transmissões Layer 2. Numa grande rede plana com centenas de pontos de acesso todos na mesma VLAN, uma tempestade de broadcast — causada por um loop de switching, uma porta mal configurada ou um dispositivo com comportamento anómalo — pode sobrecarregar a rede com tráfego de transmissão ao ponto de os pacotes DHCP se perderem ou atrasarem. O Spanning Tree Protocol deve ser a sua primeira linha de defesa, mas em implementações sem fios de alta densidade, também deve ativar a supressão de broadcast nos seus controladores sem fios. A maioria das plataformas empresariais — Cisco, Aruba, Juniper Mist — suporta funcionalidades de proxy DHCP ou filtragem de broadcast que convertem transmissões DHCP em unicast, reduzindo significativamente a sobrecarga. Número cinco: ponto único de falha — sem redundância DHCP. Se o seu servidor DHCP for um único Windows Server ou um único router, ele representa um ponto único de falha. Quando fica offline para atualizações, falha ou perde a conectividade de rede, todas as novas tentativas de ligação na sua rede irão falhar. Em implementações empresariais, deve utilizar a ativação por falha (failover) de DHCP — seja o modo de failover de DHCP do Windows Server ou um equipamento DHCP dedicado com redundância ativo-passivo ou ativo-ativo. Para redes geridas na nuvem, muitas plataformas oferecem agora DHCP distribuído onde o controlador gere as concessões (leases), mas ainda assim é necessário compreender os modos de falha. Número seis: servidores DHCP não autorizados (rogue). Este caso pode ser particularmente insidioso. Um servidor DHCP rogue é qualquer dispositivo não autorizado na sua rede que esteja a responder a mensagens de descoberta DHCP. Pode ser um hotspot pessoal que alguém ligou, uma máquina virtual mal configurada ou, no pior cenário, um ataque deliberado. Os servidores DHCP rogue distribuem endereços IP incorretos, informações de gateway erradas ou servidores DNS que apontam para infraestruturas maliciosas. O resultado varia entre a total falta de conectividade dos utilizadores até a um ataque "man-in-the-middle". A mitigação é o DHCP snooping — uma funcionalidade disponível em praticamente todos os switches geridos que apenas permite respostas DHCP a partir de portas fidedignas e designadas. Ative-o. Não é opcional numa implementação profissional. Número sete: bloqueio de portas UDP sessenta e sete e sessenta e oito por firewall e ACL. O DHCP funciona na porta UDP sessenta e sete para o tráfego de servidor para cliente e na porta sessenta e oito para o tráfego de cliente para servidor. Se tiver listas de controlo de acesso (ACL) ou regras de firewall a bloquear estas portas — talvez como parte de um exercício de reforço de segurança ou de uma política mal configurada — o DHCP irá falhar silenciosamente. Isto é particularmente comum após uma migração de firewall ou uma atualização de políticas. Verifique sempre se as portas UDP sessenta e sete e sessenta e oito são explicitamente permitidas entre as suas VLANs sem fios e o seu servidor DHCP. Utilize capturas de pacotes na interface do servidor para confirmar que o tráfego está a chegar. Número oito: má configuração de VLAN. As falhas de DHCP são frequentemente o sintoma de um problema de VLAN e não de um problema de DHCP. Se um cliente sem fios estiver associado a um SSID que mapeia para a VLAN trinta, mas a porta de uplink no ponto de acesso não estiver a transportar a VLAN trinta como uma VLAN etiquetada (tagged), o DHCP discover nunca chega à camada de distribuição. Da mesma forma, se o âmbito (scope) do DHCP for definido para a sub-rede errada, ou se o âmbito não estiver ativado, os clientes não obterão resposta. Sempre que estiver a resolver problemas de DHCP, verifique a etiquetagem de VLAN de ponta a ponta: do uplink do AP, passando pelo switch de acesso, pelo switch de distribuição, até à interface do servidor DHCP. Uma única etiqueta de VLAN em falta em qualquer ponto dessa cadeia causará uma falha completa. Número nove: erros de firmware do ponto de acesso. Isto é menos comum, mas vale a pena referir, especialmente em implementações de grande escala onde tem um ambiente de firmware misto. Existem casos documentados — incluindo um erro amplamente divulgado da UniFi U7 no início de 2026 — onde o firmware do ponto de acesso descartava intermitentemente o terceiro pacote do handshake DHCP: o DHCPREQUEST. O cliente envia o discover, recebe um offer, envia o request — e o AP descarta-o. O cliente nunca recebe uma confirmação (acknowledgement). A solução é simples: mantenha o firmware do seu AP atualizado e, quando estiver a resolver problemas de falhas intermitentes de DHCP que não se ajustam a qualquer outro padrão, verifique a versão do firmware e a lista de problemas conhecidos do fabricante. Número dez: problemas de roaming do cliente. Em ambientes de alta densidade, os clientes estão constantemente em roaming entre pontos de acesso. Quando um cliente faz roaming de um AP para outro — particularmente se cruzar um limite de VLAN ou se mover para uma sub-rede diferente — poderá necessitar de obter uma nova concessão (lease) de DHCP. Se o evento de roaming não for gerido corretamente, o cliente poderá tentar renovar a sua concessão existente numa sub-rede à qual já não está ligado, resultando num timeout. O IEEE 802.11r — fast BSS transition — foi concebido para acelerar o roaming, mas tem problemas de compatibilidade conhecidos com alguns dispositivos cliente. A solução mais fiável para o roaming de Camada 3 é utilizar as funcionalidades de encapsulamento de clientes (client tunnelling) ou de AP âncora do seu controlador sem fios, que garantem que o cliente parece estar sempre na mesma sub-rede, independentemente do AP ao qual está associado. Agora vamos falar de implementação. Se estivesse a aconselhar um cliente hoje sobre como reforçar a sua infraestrutura DHCP para um espaço de alta densidade, eis o que lhe diria. Primeiro, audite os seus escopos imediatamente. Obtenha um relatório de utilização de DHCP e analise a ocupação de pico. Se algum escopo estiver a atingir os oitenta por cento de utilização durante as operações normais, precisa de o expandir antes do seu próximo evento de elevado tráfego. Utilize uma barra 22 (slash-22) ou superior para redes de convidados. Segundo, defina os tempos de concessão (lease times) de forma adequada para cada segmento de rede. WiFi de convidados: trinta a sessenta minutos. WiFi de funcionários: oito horas. IoT e infraestrutura: vinte e quatro horas ou reservas estáticas. Terceiro, implemente o DHCP snooping em todos os switches de acesso. Esta é uma tarefa de configuração única que elimina por completo o risco de servidores DHCP não autorizados. Quarto, implemente a redundância (failover) de DHCP. Se estiver no Windows Server, configure a funcionalidade de failover integrada. Se estiver numa plataforma gerida na nuvem, compreenda a partir de onde o DHCP está a ser servido e o que acontece quando esse componente falha. Quinto, ative a supressão de transmissão (broadcast suppression) no seu controlador sem fios. Converta transmissões DHCP em unicast sempre que suportado. Isto reduz significativamente o overhead em ambientes densos. Sexto, documente o seu mapeamento de VLAN para escopo DHCP. Cada VLAN deve ter um escopo documentado, uma configuração de agente de retransmissão (relay agent) e um proprietário atribuído. Quando algo falha, esta documentação reduz o seu tempo médio de resolução de horas para minutos. Agora, passemos às perguntas rápidas. Pergunta: Como posso saber se o meu pool de DHCP está esgotado? Resposta: Execute "show ip dhcp pool" num dispositivo Cisco ou verifique a consola de gestão do seu servidor DHCP. Procure por "no free leases" no seu syslog. Configure alertas de monitorização aos oitenta por cento de utilização. Pergunta: Qual é a forma mais rápida de diagnosticar uma falha de DHCP? Resposta: Captura de pacotes na interface voltada para o cliente. Se vir DHCPDISCOVER sem nenhum DHCPOFFER em resposta, o problema está entre o cliente e o servidor. Se vir DHCPOFFER mas nenhum DHCPACK, o problema está na troca de pedido-confirmação (request-acknowledge). Pergunta: Devo utilizar IPs estáticos em vez de DHCP para ambientes de alta densidade? Resposta: Não. A gestão de IPs estáticos em escala é operacionalmente inviável. A resposta correta é um DHCP bem estruturado, com dimensionamento de escopo, tempos de concessão e redundância adequados. Pergunta: O DHCP snooping afeta o desempenho? Resposta: De forma insignificante. Nos switches geridos modernos, o DHCP snooping opera ao nível do hardware e não tem qualquer impacto mensurável no débito (throughput). Em resumo: os tempos de espera esgotados (timeouts) de DHCP em redes sem fios de alta densidade são quase sempre causados por uma de dez causas de raiz — esgotamento do pool, tempos de concessão excessivos, má configuração do relay, tempestades de difusão (broadcast storms), falta de redundância, servidores não autorizados, bloqueios de firewall, más configurações de VLAN, erros de firmware (bugs) ou problemas de roaming. Cada um tem um caminho de diagnóstico claro e uma remediação clara. Nenhum deles exige atualizações dispendiosas de hardware. Exigem sim uma configuração adequada, uma monitorização correta e a documentação devida. Se utiliza uma plataforma de WiFi de convidados como a Purple, tem a vantagem adicional de ter visibilidade sobre eventos de ligação, fluxos de autenticação e dados de sessão que o podem ajudar a correlacionar falhas de DHCP com dispositivos específicos, SSIDs ou intervalos de tempo. Essa telemetria é inestimável para a análise de causa raiz. Os seus próximos passos: audite os seus escopos DHCP hoje mesmo, implemente DHCP snooping se ainda não o fez e configure a monitorização de utilização com alertas. Não espere pelo próximo evento para descobrir que o seu pool está esgotado. Obrigado por acompanhar a Purple Technical Briefing Series. Para mais guias, referências de arquitetura e boas práticas de implementação, visite purple.ai.