As 10 principais causas de timeouts de DHCP em redes sem fios de alta densidade

Bem-vindo à Série de Briefing Técnico da Purple. Sou o seu anfitrião e hoje vamos mergulhar num dos problemas mais frustrantes - e sinceramente, mais mal diagnosticados - nas redes sem fios empresariais: os timeouts de DHCP em redes de alta densidade. Se gere o 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 círculo rotativo de "a obter endereço IP", este episódio é para si. Vamos cobrir as dez principais causas, como diagnosticar cada uma e o que deve fazer em relação a isso agora mesmo. Primeiro, vamos enquadrar o cenário. O DHCP - o 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 aperto de mão 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 numa mesa de registo de conferência, ou dez mil adeptos a abrir simultaneamente a aplicação do estádio, o DHCP torna-se um estrangulamento crítico. E quando falha, os utilizadores não conseguem aceder à internet. Ponto final. Vamos então analisar as dez causas. Número um: esgotamento do pool de IPs. Esta é a causa mais comum e é totalmente evitável. O seu scope de DHCP - a gama de endereços IP que o seu servidor está autorizado a atribuir - tem um tamanho finito. Uma sub-rede slash-24 fornece-lhe 254 endereços utilizáveis. Parece suficiente até considerar que os dispositivos móveis muitas vezes mantêm os leases mesmo após a desconexão, que os dispositivos IoT proliferam no seu espaço e que o seu scope foi dimensionado para uma ocupação normal, não para um evento esgotado. A solução é simples: dimensione corretamente os seus scopes. Para ambientes de alta densidade, utilize sub-redes slash-22 ou slash-21. Isso fornece-lhe mais de mil endereços por VLAN. Monitorize a utilização e configure alertas para os oitenta por cento de capacidade - nunca deixe atingir os noventa. Número dois: tempos de lease excessivos. Este é o assassino silencioso. Se o seu tempo de lease de DHCP estiver definido para vinte e quatro horas - o que é a predefinição em muitos sistemas - e estiver a gerir 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 rotação - hotéis, retalho, eventos - defina o seu tempo de lease para trinta a sessenta minutos. Para redes corporativas de funcionários onde os dispositivos permanecem ligados todo o dia, oito a doze horas é o adequado. Nunca utilize o lease predefinido de vinte e quatro horas numa rede de convidados. Número três: má configuração do agente DHCP relay. Em qualquer implementação empresarial com múltiplas VLANs, o seu servidor DHCP está quase de certeza numa sub-rede diferente dos seus clientes de rede sem fios. O agente DHCP relay - normalmente configurado no seu switch Layer 3 ou router - é responsável por encaminhar as transmissões de DHCP dos clientes para o servidor. Se o relay estiver mal configurado - endereço helper incorreto, interface incorreta ou o relay 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 funcionamento. Número quatro: interferência de tempestade de difusão (broadcast storm). As mensagens de deteção DHCP são transmissões de Layer 2. Numa rede plana de grande dimensão, com centenas de pontos de acesso todos na mesma VLAN, uma tempestade de difusão - 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, deve também ativar a supressão de difusão nos seus controladores de rede sem fios. A maioria das plataformas empresariais - Cisco, Aruba, Juniper Mist - suporta funcionalidades de proxy DHCP ou filtragem de difusão que convertem as transmissões DHCP em unicast, reduzindo significativamente a sobrecarga. Número cinco: ponto único de falha - sem redundância de 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 pós-falha (failover) de DHCP - seja o modo de failover de DHCP do Windows Server ou um dispositivo 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, mas ainda assim precisa de compreender os modos de falha. Número seis: servidores DHCP não autorizados (rogue DHCP). Este caso pode ser particularmente insidioso. Um servidor rogue DHCP é qualquer dispositivo não autorizado na sua rede que esteja a responder a mensagens de deteção DHCP. Pode ser um hotspot pessoal que alguém ligou, uma máquina virtual mal configurada ou, no pior dos cenários, um ataque deliberado. Os servidores rogue DHCP distribuem endereços IP incorretos, informações de gateway erradas ou servidores DNS que apontam para infraestruturas maliciosas. O resultado varia entre os utilizadores ficarem sem conectividade ou serem alvo de 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-a. Não é opcional numa implementação profissional. Número sete: firewall e ACL a bloquear as portas UDP sessenta e sete e sessenta e oito. O DHCP opera na porta UDP sessenta e sete para tráfego servidor para cliente e na porta sessenta e oito para cliente para servidor. Se tiver listas de controlo de acesso ou regras de firewall que estejam 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ítica. Verifique sempre se as portas UDP sessenta e sete e sessenta e oito estã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, a deteção de DHCP nunca chega à camada de distribuição. Da mesma forma, se o âmbito do DHCP for definido para a sub-rede errada, ou se o âmbito não estiver ativo, 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, através do comutador de acesso, através do comutador de distribuição, até à interface do servidor DHCP. Uma única etiqueta de VLAN em falta em qualquer ponto dessa cadeia causará uma falha total. Número nove: erros de firmware do ponto de acesso. Isto é menos comum, mas vale a pena referir, particularmente em implementações de grande escala onde está a executar um ambiente de firmware misto. Existem casos documentados - incluindo um erro bem divulgado da UniFi U7 no início de 2026 - em que o firmware do ponto de acesso deixava cair intermitentemente o terceiro pacote do protocolo de handshake do DHCP: o DHCPREQUEST. O cliente envia a deteção, recebe uma oferta, envia o pedido - e o AP deixa-o cair. O cliente nunca recebe uma confirmação. A correção é simples: mantenha o firmware do seu AP atualizado e, quando estiver a resolver falhas intermitentes de DHCP que não se enquadram em nenhum 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 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 tempo limite esgotado. O padrão 802.1X IEEE 802.11r - transição rápida de BSS - foi concebido para acelerar o roaming, mas tem problemas de compatibilidade conhecidos com alguns dispositivos clientes. A solução mais fiável para o roaming de Camada 3 é utilizar a criação de túneis de cliente do seu controlador sem fios ou as funcionalidades de AP âncora, 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 as suas gamas de IP imediatamente. Obtenha um relatório de utilização de DHCP e analise a ocupação de pico. Se alguma gama estiver a atingir oitenta por cento de utilização durante o funcionamento normal, precisa de a expandir antes do seu próximo evento de grande tráfego. Use uma barra-22 ou superior para redes de convidados. Segundo, defina os tempos de atribuição (lease times) de forma adequada para cada segmento de rede. WiFi de convidados: trinta a sessenta minutos. WiFi de colaboradores: 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 (rogue). Quarto, implemente a redundância de DHCP (failover). Se estiver em Windows Server, configure a funcionalidade de failover integrada. Se estiver numa plataforma gerida na nuvem, perceba de onde o DHCP está a ser fornecido e o que acontece quando esse componente falha. Quinto, ative a supressão de broadcast no seu controlador wireless. Converta os broadcasts DHCP em unicast sempre que suportado. Isto reduz significativamente o overhead em ambientes densos. Sexto, documente o mapeamento de VLAN para a gama DHCP. Cada VLAN deve ter uma gama documentada, uma configuração de 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, as perguntas rápidas. Pergunta: Como sei se o meu pool de DHCP está esgotado? Resposta: Execute o comando "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 do 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 e confirmação (request-acknowledge). Pergunta: Devo usar IPs estáticos em vez de DHCP para ambientes de alta densidade? Resposta: Não. A gestão de IPs estáticos à escala é operacionalmente impossível de gerir. A resposta correta é um DHCP bem estruturado com o dimensionamento de gama, tempos de atribuição e redundância adequados. Pergunta: O DHCP snooping afeta o desempenho? Resposta: De forma insignificante. Nos switches geridos modernos, o DHCP snooping opera em hardware e não tem impacto mensurável no débito (throughput). Em resumo: os tempos limite (timeouts) de DHCP em redes wireless de alta densidade são quase sempre causados por uma de dez causas raiz - esgotamento do pool, tempos de atribuição excessivos, má configuração de relay, tempestades de broadcast, falta de redundância, servidores não autorizados, bloqueios de firewall, más configurações de VLAN, bugs de firmware ou problemas de roaming. Cada uma tem um caminho de diagnóstico claro e uma resolução clara. Nenhuma delas exige atualizações de hardware dispendiosas. Exigem uma configuração correta, monitorização adequada e documentação detalhada. Se está a gerir uma plataforma de WiFi de convidados como a Purple, tem a vantagem adicional de 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 janelas de tempo. Essa telemetria é inestimável para a análise de causa raiz. Os seus próximos passos: audite as suas gamas de DHCP hoje mesmo, implemente o 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 ouvir a Purple Technical Briefing Series. Para mais guias, referências de arquitetura e melhores práticas de implementação, visite purple.ai.