As 10 principais causas de tempos limite de DHCP em redes sem fio de alta densidade

Bem-vindo à série de briefings técnicos da Purple. Sou o seu anfitrião e hoje vamos mergulhar em um dos problemas mais frustrantes - e francamente, mais diagnosticados incorretamente - em redes sem fio corporativas: tempos limite de DHCP em redes de alta densidade. Se você gerencia o WiFi em um hotel, centro de conferências, rede de varejo ou estádio, e seus convidados ou funcionários estão enfrentando aquela temida tela de carregamento "obtendo endereço IP", este episódio é para você. Vamos cobrir as dez principais causas raiz, como diagnosticar cada uma e o que você deve fazer a respeito agora mesmo. Vamos contextualizar primeiro. O DHCP - Dynamic Host Configuration Protocol - é o mecanismo pelo qual cada dispositivo conectado à sua rede obtém um endereço IP, uma máscara de sub-rede, um gateway padrão 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 em uma rede pequena é. Mas quando você tem quinhentos dispositivos sobrecarregando uma única VLAN em um balcão de credenciamento de conferência, ou dez mil torcedores abrindo simultaneamente o aplicativo do estádio, o DHCP se torna um gargalo crítico. E quando ele falha, os usuários não conseguem se conectar. Ponto final. Então vamos às dez causas. Número um: esgotamento do pool de IPs. Esta é a causa mais comum e é totalmente evitável. O seu escopo DHCP - a faixa de endereços IP que seu servidor está autorizado a distribuir - tem um tamanho finito. Uma sub-rede barra 24 fornece 254 endereços utilizáveis. Isso parece suficiente até que você considere que os dispositivos móveis geralmente mantêm as concessões mesmo após a desconexão, os dispositivos IoT estão se proliferando pelo seu local e seu escopo foi dimensionado para ocupação normal, não para um evento esgotado. A solução é simples: dimensione corretamente seus escopos. Para ambientes de alta densidade, use sub-redes barra 22 ou barra 21. Isso oferece mais de mil endereços por VLAN. Monitore a utilização e emita alertas em oitenta por cento da capacidade - nunca deixe chegar a noventa. Número de dois: tempos de concessão excessivos. Este é o assassino silencioso. Se o tempo de concessão do seu DHCP estiver definido para vinte e quatro horas - que é o padrão em muitos sistemas - e você gerencia um local onde os convidados entram e saem ao longo do dia, esses endereços IP estão sendo retidos por dispositivos que saíram há horas. Eles não estão disponíveis para novas conexões. Para WiFi de convidados em ambientes de alta rotatividade - hotéis, varejo, eventos - defina seu tempo de concessão de trinta a sessenta minutos. Para redes corporativas de funcionários, onde os dispositivos permanecem conectados o dia todo, de oito a doze horas é apropriado. Nunca use a concessão padrão de vinte e quatro horas em uma rede de convidados. Número três: configuração incorreta do agente de retransmissão DHCP. Em qualquer implantação corporativa com múltiplas VLANs, seu servidor DHCP está quase certamente em uma sub-rede diferente de seus clientes sem fio. O agente de retransmissão DHCP - normalmente configurado em seu switch ou roteador Layer 3 - é responsável por encaminhar as transmissões DHCP dos clientes para o servidor. Se a retransmissão estiver configurada incorretamente - endereço de helper incorreto, interface errada ou a retransmissão simplesmente ausente em uma nova VLAN - os clientes nunca receberão uma resposta para seu DHCPDISCOVER. Esta é uma das causas mais comuns de falhas de DHCP após uma alteração de rede ou uma nova implantação de SSID. Sempre verifique a configuração de retransmissão ao adicionar VLANs e teste com uma captura de pacotes antes de entrar em operação. Número quatro: interferência de tempestade de broadcast. As mensagens de descoberta de DHCP são transmissões Layer 2. Em uma grande rede plana com centenas de pontos de acesso na mesma VLAN, uma tempestade de broadcast - causada por um loop de comutação, uma porta configurada incorretamente ou um dispositivo com mau funcionamento - pode sobrecarregar a rede com tráfego de broadcast a ponto de os pacotes DHCP serem perdidos ou atrasados. O Spanning Tree Protocol deve ser sua primeira linha de defesa, mas em implantações sem fio de alta densidade, você também deve habilitar a supressão de broadcast em seus controladores sem fio. A maioria das plataformas corporativas - Cisco, Aruba, Juniper Mist - oferece suporte a recursos 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 de DHCP. Se o seu servidor DHCP for um único Windows Server ou um único roteador, ele será um ponto único de falha. Quando ele for desativado para aplicação de patches, travar ou perder a conectividade de rede, cada nova tentativa de conexão em sua rede falhará. Em implantações corporativas, você deve executar o failover de DHCP - seja o modo de failover de DHCP do Windows Server ou um appliance DHCP dedicado com redundância ativo-passivo ou ativo-ativo. Para redes gerenciadas na nuvem, muitas plataformas agora oferecem DHCP distribuído, onde o controlador lida com as concessões, mas você ainda precisa entender os modos de falha. Número seis: servidores DHCP não autorizados. Este caso pode ser particularmente insidioso. Um servidor DHCP não autorizado é qualquer dispositivo não autorizado em sua rede que esteja respondendo a mensagens de descoberta DHCP. Pode ser um ponto de acesso pessoal que alguém conectou, uma máquina virtual configurada incorretamente ou, no pior cenário, um ataque deliberado. Servidores DHCP não autorizados distribuem endereços IP incorretos, informações de gateway erradas ou servidores DNS apontando para infraestrutura maliciosa. O resultado varia de usuários sem conectividade a um ataque man-in-the-middle. A mitigação é o rastreamento DHCP (DHCP snooping) - um recurso disponível em praticamente todos os switches gerenciados que permite apenas respostas DHCP de portas confiáveis e designadas. Ative-o. Não é opcional em uma implantação profissional. Número sete: firewall e ACL bloqueando 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 você tiver listas de controle de acesso ou regras de firewall que estejam bloqueando essas portas - talvez como parte de um exercício de reforço de segurança ou uma política mal configurada - o DHCP falhará silenciosamente. Isso é particularmente comum após uma migração de firewall ou uma atualização de política. Sempre verifique se as portas UDP sessenta e sete e sessenta e oito estão explicitamente permitidas entre suas VLANs sem fio e seu servidor DHCP. Use capturas de pacotes na interface do servidor para confirmar se o tráfego está chegando. Número oito: má configuração de VLAN. 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 fio estiver associado a um SSID que mapeia para a VLAN trinta, mas a porta de uplink no access point não estiver transportando a VLAN trinta como uma VLAN marcada, o DHCP discover nunca alcançará a camada de distribuição. Da mesma forma, se o escopo DHCP for definido para a sub-rede errada, ou se o escopo não estiver ativado, os clientes não receberão resposta. Sempre que estiver solucionando problemas de DHCP, verifique a marcação de VLAN de ponta a ponta: do uplink do AP, passando pelo switch de acesso, pelo switch de distribuição, até a interface do servidor DHCP. Uma única tag de VLAN ausente em qualquer ponto dessa cadeia causará uma falha completa. Número nove: bugs de firmware do access point. Isso é menos comum, mas vale a pena destacar, particularmente em implantações de grande escala onde você está executando um ambiente de firmware misto. Houve casos documentados - incluindo um bug UniFi U7 amplamente divulgado no início de 2026 - onde o firmware do access point descartava intermitentemente o terceiro pacote do handshake DHCP: o DHCPREQUEST. O cliente envia o discover, recebe um offer, envia o request - e o AP o descarta. O cliente nunca recebe uma confirmação. A correção é simples: mantenha o firmware do seu AP atualizado e, ao solucionar falhas intermitentes de DHCP que não se encaixam 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 de cliente. Em ambientes de alta densidade, os clientes estão constantemente em roaming entre os access points. Quando um cliente faz roaming de um AP para outro - especialmente se cruzar o limite de uma VLAN ou mudar para uma sub-rede diferente - ele pode precisar obter uma nova concessão de DHCP. Se o evento de roaming não for tratado corretamente, o cliente pode tentar renovar sua concessão existente em uma sub-rede à qual não está mais conectado, resultando em um timeout. O IEEE 802.11r - fast BSS transition - foi projetado para acelerar o roaming, mas apresenta problemas conhecidos de compatibilidade com alguns dispositivos clientes. A solução mais confiável para roaming de Camada 3 é usar o tunelamento de cliente do seu controlador sem fio ou recursos de AP âncora, que garantem que o cliente sempre pareça estar na mesma sub-rede, independentemente de qual AP ele esteja associado. Agora vamos falar sobre a implementação. Se eu estivesse aconselhando um cliente hoje sobre como reforçar sua infraestrutura DHCP para um local de alta densidade, eis o que eu diria. Primeiro, audite seus escopos imediatamente. Obtenha um relatório de utilização do DHCP e verifique a ocupação de pico. Se qualquer escopo estiver atingindo oitenta por cento de utilização durante as operações normais, você precisará expandi-lo antes do próximo evento de alto tráfego. Use slash-22 ou maior para redes de convidados. Segundo, defina os tempos de lease adequadamente 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 cada switch de acesso. Esta é uma tarefa de configuração única que elimina completamente o risco de servidores DHCP não autorizados. Quarto, implante o failover de DHCP. Se você estiver no Windows Server, configure o recurso de failover integrado. Se você estiver em uma plataforma gerenciada na nuvem, entenda de onde o DHCP está sendo servido e o que acontece quando esse componente falha. Quinto, ative a supressão de broadcast no seu controlador sem fio. Converta broadcasts DHCP em unicast onde houver suporte. Isso reduz significativamente a sobrecarga em ambientes densos. Sexto, documente o mapeamento de VLAN para escopo DHCP. Cada VLAN deve ter um escopo documentado, uma configuração de agente de relay e um proprietário definido. Quando algo quebra, essa documentação reduz o seu tempo médio de resolução de horas para minutos. Agora, as perguntas rápidas. Pergunta: Como sei se meu pool de DHCP está esgotado? Resposta: Execute "show ip dhcp pool" em um dispositivo Cisco ou verifique o console de gerenciamento do seu servidor DHCP. Procure por "no free leases" em seu syslog. Configure alertas de monitoramento em oitenta por cento de utilização. Pergunta: Qual é a maneira mais rápida de diagnosticar uma falha de DHCP? Resposta: Captura de pacotes na interface voltada para o cliente. Se você vir DHCPDISCOVER sem nenhuma resposta DHCPOFFER, o problema está entre o cliente e o servidor. Se você vir DHCPOFFER, mas nenhum DHCPACK, o problema está na troca de solicitação-reconhecimento. Pergunta: Devo usar IPs estáticos em vez de DHCP para ambientes de alta densidade? Resposta: Não. O gerenciamento de IP estático em grande escala é operacionalmente inviável. A resposta certa é um DHCP bem estruturado com dimensionamento de escopo, tempos de lease e redundância adequados. Pergunta: O DHCP snooping afeta o desempenho? Resposta: De forma insignificante. Em switches gerenciados modernos, o DHCP snooping opera em hardware e não tem impacto mensurável na taxa de transferência. Para resumir: os timeouts de DHCP em redes sem fio de alta densidade são quase sempre causados por uma de dez causas raiz - esgotamento de pool, tempos de lease excessivos, configuração incorreta de relay, tempestades de broadcast, falta de redundância, servidores não autorizados, bloqueios de firewall, configurações incorretas de VLAN, bugs de firmware ou problemas de roaming. Cada uma tem um caminho de diagnóstico claro e uma remediação clara. Nenhuma delas exige atualizações de hardware caras. Elas exigem configuração adequada, monitoramento adequado e documentação adequada. Se você opera uma plataforma de WiFi para visitantes como o Purple, você tem a vantagem adicional de visibilidade sobre eventos de conexão, fluxos de autenticação e dados de sessão que 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. Seus próximos passos: faça uma auditoria em seus escopos DHCP hoje mesmo, implemente o DHCP snooping se ainda não o fez e configure o monitoramento de utilização com alertas. Não espere pelo próximo evento para descobrir que seu pool está esgotado. Obrigado por ouvir a Série de Informações Técnicas do Purple. Para mais guias, referências de arquitetura e melhores práticas de implantação, visite purple.ai.