Network+ — Solução de Problemas: 44 questões

Step 1: Coleta de informações — Logs do servidor RADIUS indicando falhas TLS e erros de certificado direcionam imediatamente para problemas de certificados/PKI entre o AP/autenticador e o servidor RADIUS. Após uma atualização de firmware, componentes de TLS/SSL podem exigir novos parâmetros, rejeitar certificados fracos ou detectarem que o certificado expirou.

Step 2: Isolamento — Verifique a validade do certificado no servidor RADIUS (datas de validade), se a cadeia de certificados ainda é confiável pelo dispositivo que inicia a conexão (APs ou controladora), e se as configurações de confiança/CA foram preservadas durante a atualização. Também é útil capturar logs de EAP e TLS para confirmar falha em Handshake TLS em vez de falhas de credenciais do usuário.

Step 3: Remediação — Se o certificado expirou, renove-o com uma nova assinatura válida e distribua os certificados CA confiáveis aos APs/controladora; se a atualização mudou as configurações de verificação, ajuste a configuração para aceitar a cadeia correta ou atualize o certificado para os requisitos de segurança. Teste com um cliente pilotado para confirmar sucesso da autenticação. Trap: Uma suposição comum é culpar imediatamente a configuração do SSID ou interferência física; no entanto, logs que claramente mostram erros de TLS e certificado apontam para problemas de PKI/autenticação e não para problemas de nível de rádio. Por que cada alternativa falha: - Chave WEP obsoleta configurada nos APs: WEP é um mecanismo de criptografia de camada de enlace e não envolve RADIUS/TLS. Falhas TLS indicam problema no processo de autenticação 802.1X, não na criptografia WEP. Além disso, WEP não é compatível com EAP/TLS em ambientes corporativos modernos. - SSID incorreto configurado nos clientes: Um SSID incorreto resultaria em clientes não conseguindo sequer associar ao AP ou escolhendo outro perfil, e não geraria erros TLS no RADIUS, já que sem associação não haveria tentativa de EAP/TLS. - Interferência de 2,4 GHz causando perda de pacotes EAPOL: Interferência pode causar retransmissões ou tempo limite, mas não produz mensagens específicas de erro de certificado/TLS no servidor RADIUS. Logs de TLS indicam fracasso na verificação de certificado durante o handshake, não simples perda de pacotes.

Step 1: Coleta de informações — Quando os hosts relatam 'gateway unreachable', o primeiro passo é confirmar endereços IP, máscara e gateway em um host afetado e checar a tabela ARP e MAC do switch. Se os endereços IP e a interface do roteador estiverem corretos, verificar se o MAC do gateway aparece na tabela ARP do host ou na tabela MAC do switch permite determinar se existe conectividade de camada 2.

Step 2: Isolamento — Se o roteador responde e está na VLAN correta mas o host não vê o MAC do gateway, inspecione as configurações de VLAN nas portas do switch. Em muitos cenários de campus, uma porta pode ter sido movida ou configurada na VLAN errada (por exemplo, porta do host em VLAN 20 enquanto o gateway da rede está em VLAN 10). Um mismatch de VLAN resulta exatamente no sintoma descrito: o host tem IP correto para aquela sub-rede, mas o tráfego de camada 2 não é entregue ao gateway, gerando mensagens de 'gateway unreachable'.

Step 3: Implementação e verificação — Corrigir a VLAN na porta do switch para a VLAN correta ou ajustar a configuração de trunking, e então verificar ARP, ping local para o gateway e logs para confirmar resolução do problema. Depois de corrigir, documente a causa raiz e aplique controles (naming, templates, verificação) para reduzir regressões. Trap: Uma armadilha comum é atribuir a culpa imediatamente ao roteador ou à máscara IP. Embora máscaras erradas ou roteador down possam produzir problemas, se o roteador estiver operacional e os IPs parecerem corretos, a causa frequente em ambientes de escritório é a configuração incorreta de VLAN nas portas do switch. Por que cada alternativa falha: - Lista de controle de acesso no roteador bloqueando ICMP: Um ACL que bloqueia ICMP impediria respostas de ping mas não faria o gateway completamente inacessível na camada 2; além disso, outros protocolos poderiam ainda funcionar e o roteador continuaria visível na ARP. O log 'gateway unreachable' normalmente indica ausência de camada 2/3, não apenas ICMP bloqueado. - Servidor DNS com resolução incorreta: Problemas de DNS afetam nomeação e resolução de nomes, não causam mensagens de 'gateway unreachable' porque comunicação com o gateway usa endereços IP diretamente. - Gateway configurado com máscara de sub-rede incorreta: Uma máscara errada no gateway poderia causar roteamento incorreto, mas frequentemente produziria sintomas diferentes — hosts podem ainda ver o MAC do gateway na ARP na mesma VLAN. A verificação inicial do gateway e da interface do roteador mostrou que a interface está funcionando, apontando para um problema de camada 2 (VLAN) em vez da máscara do gateway.

Step 1: Inspecionar a configuração do switch e VLAN — começar verificando a VLAN atribuída à porta do switch onde a impressora está conectada e compará‑la com a VLAN do usuário. Ferramentas como 'show interface switchport' em switches gerenciáveis mostram a VLAN administrativa e o estado da porta.

Step 2: Entender domínios de broadcast — portas atribuídas a VLANs distintas pertencem a domínios lógicos separados; tráfego L2 (como ARP, NetBIOS, ou impressão raw sobre L2) não atravessa vazios VLAN sem um gateway/roteamento entre VLANs. Mesmo que a porta esteja 'up' fisicamente, se estiver na VLAN errada, a comunicação direta falhará.

Step 3: Remediar: corrigir a atribuição de VLAN na porta do switch para corresponder à VLAN dos usuários que precisam acessar a impressora; se a intenção for segmentação de segurança, então garantir um roteador/MLS com regras e ACLs apropriadas para permitir somente o tráfego necessário entre as VLANs. Trap: Um erro comum é supor que 'porta up = conectividade plena'. A porta pode estar fisicamente conectada (cabo e link OK), mas lógica e administrativamente associada a outra VLAN, o que impede comunicação entre dispositivos que você espera que conversem diretamente. Por que cada opção errada falha: - Problema de duplex: um mismatch de duplex causaria alta taxa de retransmissões ou throughput reduzido, e problemas intermitentes; não explicaria o fato de o usuário conseguir pingar o gateway e outros servidores na mesma VLAN enquanto falha somente com a impressora, nem porque a porta está configurada em VLAN diferente. - STP bloqueou a porta: STP normalmente coloca portas em estado de bloqueio só quando há um loop detectado; a porta mostraria status não‑forwarding (por exemplo, blocked) em vez de 'up' e operando. A descrição indica que a porta está 'up', então STP bloqueando não é consistente com os fatos. - ACL no roteador: ACLs entre VLANs poderiam bloquear tráfego, mas o usuário pode pingar o gateway e outros servidores na mesma VLAN, o que sugere que não há bloqueio generalizado no roteador. Além disso, o diagnóstico revelou que a porta da impressora está na VLAN errada — uma explicação mais direta e local do problema. Mesmo se ACLs existirem, primeiro corrija a VLAN errada antes de revisar regras de roteamento. Resumo: verifique sempre a VLAN atribuída nas portas do switch ao diagnosticar inacessibilidade de recursos locais; portas 'up' não garantem pertença lógica correta ao VLAN pretendido.

Step 1: Entender o comportamento do BPDU Guard — BPDU Guard é aplicado em portas consideradas 'edge' (PortFast), que presumem conectar-se a dispositivos finais. Se uma porta PortFast recebe um BPDU, BPDU Guard a desativa (err-disabled) para proteger a topologia STP de loops causados por dispositivos de switching conectados inadvertidamente.

Step 2: Diagnosticar e agir rapidamente — Verifique a porta err-disabled, identifique o dispositivo conectado (comandos show interface status, show mac address-table, ou inspeção física), e determine se é um switch/ponte que não deveria estar ali (p.ex., um switch de usuário, ponto de acesso mal configurado como switch, ou um cabo ligando dois switches erroneamente). Para restauração imediata, depois de verificar que o dispositivo conectado não criará loop, reabilite a porta (clear err-disable interface gi1/0/12 ou re-enable) e, se apropriado, corrigir a configuração do dispositivo conectado ou remover o cabo. Se o dispositivo for legítimo (ex.: um telefone com switch integrado), ajuste a configuração para permitir BPDUs naquele caso (desabilitar PortFast onde não adequado ou usar BPDU Filter com cautela).

Step 3: Prevenir recorrência — Eduque a equipe e aplique políticas físicas/virtuais que evitem conectar switches de usuário em portas edge; padronize configuração de portas (usar PortFast somente em portas que realmente conectam hosts finais), mantenha documentação de portas e habilite monitoramento e alertas para eventos err-disabled. Em ambientes onde APs ou telefones com switch integrado são comuns, planeje exceções controladas ou use features como BPDU filtering com risco conhecido e documentação. Trap: Uma armadilha comum é supor que BPDU Guard sempre indica ataque malicioso; na verdade frequentemente é resultado de um cabo conectado erroneamente a outro switch ou de dispositivos com funcionalidade de bridge (p.ex., telefones com switch integrado) em portas configuradas como edge. Why each wrong answer fails: - A porta é trunk e houve mismatch de VLANs; reconfigurar como access para a VLAN correta: Porta trunk com mismatch de VLAN provoca problemas de tráfego e VLAN tagging, mas não dispara especificamente BPDU Guard. BPDU Guard reage ao recebimento de BPDUs em portas configuradas como PortFast/edge; mismatch de VLAN não causa a porta ser err-disabled por BPDU Guard. - STP Root foi alterado causando flapping; forçar o root no switch core: Mudanças no root bridge podem gerar reconvergência e flapping, mas não levam a mensagens de BPDU Guard e não colocam portas individuais em err-disabled por recepção de BPDU. Forçar root é uma ação de alto impacto e não trata a causa indicada pelos logs. - Problema de duplex/velocidade na porta causando erros; ajustar parâmetros manuais de speed/duplex: Erros de duplex/velocidade normalmente aparecem como colisões, CRCs, ou lentidão na transmissão e não disparam a proteção BPDU Guard. O log específico sobre BPDU Guard aponta para STP/BPDU recebido numa porta edge. Conclusão: O log indica que uma porta com PortFast recebeu BPDUs e foi desativada por BPDU Guard; a correção imediata é verificar o dispositivo conectado, isolar/remover se for indevido e então reabilitar a porta; medidas preventivas incluem revisar design e configurar PortFast apenas em portas finais e documentar exceções.

Step 1: Identificar sintomas e coletar dados — Em uma implantação empresarial com SSID único e vários APs, desconexões intermitentes e baixa taxa de transferência localizadas no mesmo andar tipicamente apontam para problemas de RF. Primeiro, olhe os gráficos de uso de canal, use um analisador de espectro ou a ferramenta de survey do controlador e registre RSSI, taxa de retransmissão e número de clientes por AP.

Step 2: Diagnosticar causas potenciais — Se vários APs estiverem transmitindo no mesmo canal ou em canais sobrepostos (especialmente em 2,4 GHz), o desempenho se degrada por colisões e concorrência por airtime; clientes re-associam frequentemente ou experimentam altos índices de retransmissões.

Step 3: Aplicar a correção e validar — Replaneje canais (usar largura de banda adequada e canais não sobrepostos), balanceie potência de transmissão e, se disponível, habilite seleção automática de canal coordenada pelo controlador. Teste com clients reais e monitore métricas para confirmar resolução. Trap: A armadilha comum é culpar imediatamente o DHCP ou o switch quando os sintomas são tipicamente RF — problemas de Wi‑Fi na camada 1 são freqüentes e às vezes sutis. Why each wrong answer fails: Exaustão do escopo DHCP — Isto causaria falha na obtenção de endereço IP (clientes sem conectividade), não desconexões intermitentes nem baixa performance enquanto conectados; além disso, o sintoma estaria presente nas associações iniciais, não apenas em throughput degradado. Falha no injetor PoE — Se o PoE estivesse falhando, o AP provavelmente perderia energia completamente ou reiniciaria, causando downtime completo e não um padrão de degradação por clientes no mesmo andar; logs do switch mostrariam quedas de energia se fosse o caso. Firmware desatualizado — Firmware pode causar problemas, mas é menos provável que introduza degradação localizada imediatamente após adicionar um AP; além disso, os controladores normalmente reportam incompatibilidades de firmware e o problema ocorreria em todo o equipamento com aquela versão, não apenas onde há sobreposição de canal. Em resumo, coletar evidências RF (survey), ajustar canais e potências e validar com métricas resolves a causa mais provável: co‑canal/interferência.

Step 1: Recolher dados e sintomas — em um cenário empresarial com vários APs no mesmo andar e muitos clientes, é comum ver sintomas de degradação quando os APs estão usando canais adjacentes ou exatamente os mesmos canais de forma próxima. Use ferramentas de análise de espectro (scanner Wi‑Fi ou analisador RF) para mapear quais canais os APs e redes vizinhas estão ocupando. Verifique taxas de retransmissão, contagem de colisões, nível de sinal (RSSI) e índices de erro (CRC).

Step 2: Diagnosticar a interferência — se o espectro mostrar vários APs em canais sobrepostos (por exemplo em 2, 6 e 11, mas com APs muito próximos gerando sobreposição) ou muitas redes vizinhas, isso causa co‑canal e interferência por sobreposição. Mesmo que os APs tenham o mesmo SSID, clientes trocam entre APs com base em métricas de sinal; se os canais estão em conflito, o meio fica saturado e as retransmissões aumentam, levando a sessões intermitentes.

Step 3: Remediar — planejar um esquema de canais adequado (no caso de 2,4 GHz utilizar os canais não sobrepostos; em 5 GHz aproveitar mais canais e banda larga), ajustar potências, redistribuir APs para reduzir sobreposição, habilitar execução de rádio com equilíbrio de carga/rogue detection e, se possível, migrar clientes para 5 GHz. Implementar controle de transmissão e ajustar thresholds de roaming melhora estabilidade. Trap: Uma armadilha comum é assumir que 'SSID igual e roaming habilitado' é suficiente; mesmo com SSID único, se os canais e potência não forem planejados, o desempenho colapsa. Outro erro é confiar apenas em relatórios dos APs — usar análise de espectro é crucial. Por que cada opção errada falha: - Modo de economia de energia do cliente: embora possa afetar eficiência e causar atrasos em clientes móveis, não explica desconexões generalizadas e degradação somente sob alta densidade; power save causa latência percebida, mas não tipicamente tantas quedas simultâneas em muitos clientes. - SSID incorreto em alguns APs: SSIDs diferentes causariam problemas de roaming (clientes não fariam roaming automaticamente), mas a descrição indica um SSID único e o problema aparece com alta densidade; além disso, SSID incorreto não causaria necessariamente aumento de retransmissões na camada física como interferência de canal faz. - Atribuição de VLAN errada nos switches: isso poderia impedir acesso à rede ou recursos em alguns APs, mas normalmente resultaria em falta de conectividade consistente em APs específicos, não em degradação progressiva e quedas quando o número de usuários aumenta. A sintomatologia de piora com alta densidade aponta para problemas de camada física/RF, não apenas VLAN. Resumo: em ambientes densos de AP, a maior causa de instabilidade e quedas intermitentes é interferência/co‑canalização; auditoria de espectro e replanejamento de canais/potência são as ações corretas.

Step 1: Confirmar ausência de rota — O sintoma (ultimo salto responde como destino desconhecido e a rota não está presente na tabela do roteador central) indica que o roteador central não possui um caminho conhecido para a sub-rede da filial. Traceroute mostrando que o tráfego sai da filial e alcança a rede central até certo ponto confirma que o caminho de ida chega ao limite do conhecimento de roteamento do central.

Step 2: Determinar método de correção — Em redes pequenas, configuração de uma rota estática no roteador central para a sub-rede da filial com next-hop apontando para o roteador de borda que conhece essa rede resolve o problema. Em infraestruturas maiores, habilitar ou corrigir a distribuição de rotas via um protocolo de roteamento dinâmico (OSPF/BGP) também seria apropriado.

Step 3: Implementar e testar — Inserir a rota estática (ou corrigir a configuração de roteamento dinâmico), limpar caches ARP/route, e validar com ping/traceroute bidirecional para confirmar que retornos chegam. Trap: muitos técnicos pulam direto para pensar em NAT ou firewall quando veem perda de conectividade intersítios, mas se o problema é que o roteador central não conhece a rede, abrir portas ou alterar NAT não resolverá a ausência de encaminhamento. Por que cada alternativa falha: Adicionar uma rota estática na roteador central apontando para a filial (correta) — esta ação informa ao roteador central qual próximo salto usar para encaminhar pacotes de retorno à filial, restaurando conectividade. Reconfigurar NAT no roteador da filial — NAT altera endereços, e poderia mascarar redes, mas o sintoma de rota ausente no roteador central indica que o problema é antes de qualquer tradução de endereços; além disso, se NAT fosse o problema, normalmente veríamos traduções erradas ou logs de NAT. Abrir portas de firewall entre filial e central — firewalls bloqueam fluxo por portas/protocolos; se o tráfego chegasse à rede central e fosse bloqueado, o roteador central ainda teria a rota de retorno; a falta de rota indica problema de encaminhamento, não de filtragem de aplicação. Sincronizar relógio entre roteadores (NTP) — relógio incorreto pode afetar protocolos (certificados, autenticações) em cenários muito específicos, mas não causará diretamente ausência de rota na tabela do roteador; é um passo operacional bom para logs e troubleshooting, mas não resolve a falta de aprendizado de rota. Em resumo, o diagnóstico segue a lógica do modelo OSI: verificar se o destino é alcançável via roteamento (camada 3) antes de inspecionar NAT e firewall (camada 4/7).

Step 1: Entender o sintoma — o 4-way handshake do RSN (Robust Security Network) é o processo de estabelecimento de chaves entre cliente e AP. Um timeout aqui significa que a troca de mensagens destinadas a estabelecer a chave de sessão falhou, muitas vezes devido a chave pré-compartilhada incorreta, incompatibilidade de segurança, ou perda de pacotes que impedem a conclusão.

Step 2: Verificação imediata e determinística — confirmar que a PSK configurada no controlador/APs é exatamente a mesma que os clientes tentam usar. Erros de digitação, múltiplas versões de PSK distribuídas ou problemas de perfil no MDM são causas comuns.

Step 3: Ações corretivas e prevenção — corrigir PSK ou mover para autenticação baseada em 802.1X, garantir políticas de distribuição segura de credenciais, e monitorar handshake rates. Trap: acreditar que qualquer problema de autenticação Wi‑Fi é causado por interferência ou firmware é um equívoco; interferência pode causar perda de pacotes, mas os logs mostram especificamente um timeout no handshake que normalmente aponta para chaves incompatíveis. Por que cada resposta errada falha: Reduzir a largura de canal (opção 2) pode melhorar alcance/interferência em ambientes congestionados, mas não resolverá um mismatch de PSK ou credenciais; é uma medida de desempenho, não correção de autenticação. Atualizar firmware dos APs (opção 3) pode corrigir bugs que afetam autenticação em alguns casos, mas não é a verificação mais direta e demora mais; além disso, logs apontam timeout de handshake, que é mais frequentemente configuração de credenciais. Alterar o SSID (opção 4) força reconexões, mas não muda a chave ou credenciais; se a PSK estiver errada, a mudança de SSID não resolverá e pode causar confusão adicional. Em síntese, confirme a PSK/credentials primeiro, corrija a configuração e depois investigue interferência, firmware ou incompatibilidades de algoritmos se o problema persistir.

Step 1: Analisar o espectro e sintomas — Baixo throughput e inconsistência em áreas densas de APs apontam para problemas de RF: co-channel interference (CHI) e overlap de canais, especialmente em bandas de 2,4 GHz onde há poucos canais não sobrepostos. Uma varredura de espectro (site survey) e análise dos níveis de RSSI/ SNR e airtime ocupado confirmam se muitos APs estão competindo no mesmo canal.

Step 2: Planejamento de canais e ajuste — Replanejar a atribuição de canais, usar canais não sobrepostos (na 2,4 GHz usar 1/6/11 quando aplicável) e, na 5 GHz, distribuir canais e largura de canal de forma adequada; além disso, ajustar potência de transmissão para reduzir área de cobertura excessiva e evitar co-channel contention, e considerar balanceamento de clientes entre APs.

Step 3: Teste e monitoramento — Após realocar canais e ajustar potência/largura, avaliar melhora de throughput, latência e retransmissões; manter monitoramento contínuo para mudanças por novos dispositivos ou interferência externa. Trap: muitos técnicos aumentam potência de todos os APs crendo que isso melhora desempenho — na prática isso aumenta sobreposição e pressão no airtime. Por que cada alternativa falha: Replanejar canais e reduzir sobreposição de frequência entre APs (correta) — minimizar sobreposição e co-channel interference reduz colisões no domínio sem fio e melhora airtime disponível por cliente, resultando em throughput melhor. Trocar todas as senhas WPA2 por senhas mais longas — segurança das chaves é importante, mas não influencia rendimento ou interferência RF; esta ação não resolverá problemas de capacidade ou interferência. Aumentar a potência de transmissão de todos os APs — aumentar potência aumenta área de cobertura sobreposta, gera mais competição entre APs e frequentemente degrada desempenho; a prática correta é reduzir potência quando há alta densidade e ajustar canais. Alterar o SSID para separar dispositivos por tipo — separar SSIDs pode ajudar em políticas de QoS e segmentação, mas não reduz interferência física no espectro; dispositivos ainda competirão pelo mesmo airtime em um mesmo canal. Portanto, a resposta operacional mais efetiva em um cenário de alta densidade é planejamento e otimização do espectro (canais e potência), além de possíveis medidas de banda e balanceamento de clientes.

Step 1: Correlacionar evidências — o traceroute mostra chegada ao roteador de distribuição e parada ali; isso indica que o roteamento falha neste ponto, não sendo um problema no host inicial nem necessariamente no servidor remoto. A ausência de entrada de rota para o prefixo remoto no roteador de distribuição confirma que ele não sabe como encaminhar para a rede de destino.

Step 2: Determinar causas de falha no encaminhamento — duas causas frequentes em cenário empresarial: (a) rota estática ausente ou rota dinâmicas não propagadas (i.e., o roteador não recebeu a rota via protocolo de roteamento), e (b) ACL (lista de controle de acesso) configurada para bloquear tráfego para aquele prefixo, impedindo o encaminhamento mesmo quando existe rota. Ambas resultam no mesmo efeito observável no traceroute.

Step 3: Proceder com verificações e correções — verificar a tabela de roteamento do roteador de distribuição (show ip route / show route), checar configurações de protocolos de roteamento (BGP/OSPF/OSPF area/redistribution) e adicionar a rota estática necessária ou ajustar o anúncio do protocolo. Rever as ACLs aplicadas às interfaces ingressantes/egressantes para garantir que o tráfego do host ao prefixo remoto não esteja sendo negado; ajustar ou criar exceções conforme política. Trap: É comum presumir que o problema está no servidor remoto (NAT, firewall) sem olhar a tabela de rotas local. Traceroute parando em um roteador costuma indicar falta de rota nesse salto ou filtragem nesse ponto. Por que cada resposta errada falha: - NAT mal configurado na aplicação web do servidor remoto: Má configuração de NAT no servidor só afetaria conexões na borda do site remoto e não explicaria por que o traceroute para exatamente no roteador de distribuição local; além disso, a ausência de rota no roteador explica a parada antes do trânsito remeter ao NAT. - Gateway padrão incorreto no host que inicia a conexão: Se o gateway do host estivesse incorreto, o traceroute não alcançaria o roteador de distribuição; como o traceroute chega até ele e para, o gateway do host está funcionando corretamente. Conclusão: Corrija a tabela de rotas (ou propagação do protocolo de roteamento) e revise quaisquer ACLs aplicadas ao roteador de distribuição para restaurar conectividade com o prefixo remoto.

Step 1: Identificar a causa exata a partir do log — a string "no free leases" é um indicativo direto de que o servidor DHCP não tem endereços disponíveis no pool configurado para atribuição. Isso não é uma falha de serviço temporária nem um problema de transporte de DHCP (relay).

Step 2: Aplicar correção imediata — expandir o escopo DHCP (aumentar o range de endereços atribuíveis ou adicionar escopos adicionais) é a ação que resolve imediatamente a condição de falta de endereços e restabelece a atribuição para novos clientes.

Step 3: Prevenir recorrência — revisar a taxa de alocação, reduzir tempos de lease se apropriado, implementar monitoramento/alertas para uso do pool, e considerar DHCP failover ou escopos adicionais para suportar picos de demanda. Trap: um erro comum é acreditar que reiniciar o servidor DHCP limpa o problema; reiniciar não cria novos endereços no pool, então clientes continuarão sem IP se não houver alocação livre. Por que cada resposta errada falha: Reiniciar o servidor DHCP (opção 2) pode limpar estados voláteis, mas não altera a configuração do pool; se realmente não houver endereços livres, reiniciar simplesmente fará o serviço responder com o mesmo erro. Configurar relay DHCP (opção 3) é necessário quando clientes e servidor DHCP estão em sub-redes diferentes sem encaminhamento de broadcast, mas o log "no free leases" vem do próprio servidor indicando esgotamento do pool; relay não resolverá falta de endereços. Limpar a cache ARP nos switches (opção 4) trata problemas de resolução de camada 2/3 e entradas obsoletas — não impacta a disponibilidade do pool DHCP. Em resumo, expanda o escopo ou renumere/reestruture a alocação de endereços, e implemente monitoramento e políticas de lease adequadas para prevenir nova exaustão.

Step 1: Entender o fluxo de autenticação e handoff em ambientes wireless com 802.1X e VLANs dinâmicas. Quando um cliente se move entre APs, ocorrem processos de disassociation/reauthentication e o controlador/AP precisa reassociar o cliente e aplicar a VLAN correta conforme resposta RADIUS (atributos VLAN). Logs de RADIUS mostram sucesso, portanto a autenticação em si pode não ser a causa primária; o ponto a verificar é o processo de reassociação e timers que coordenam roaming.

Step 2: Verificar timers e comportamento de reassociação no AP/controlador. Analise parâmetros como idle timeout, session timeout, reauth interval, fast roam (802.11r, se em uso), opportunistic key caching (OKC) ou PMK caching, e configurações de roam entre controladores. Verifique também se o AP aplica corretamente os atributos de VLAN retornados pelo RADIUS em cada reassociação; falhas aqui resultam em clientes autenticados sem a VLAN correta, o que causa perda de conectividade. Capturas de tráfego do plano de controle e syslogs dos APs durante roaming ajudam a identificar se há atraso ou falha de reassociação.

Step 3: Corrigir com base na evidência. Ajuste timers para reduzir reautenticação frequente, habilite mecanismos de roaming rápido (802.11r/k/v) se suportados e corrija mapeamentos de VLAN dinâmicos se estiverem inconsistentes. Teste com clientes reais em movimentação. Trap: Achar que RADIUS autenticando com sucesso garante roaming estável; autenticação e aplicação de políticas são etapas separadas e o problema pode ocorrer nas transições entre APs ou no mapeamento de VLANes dinâmicas. Why each wrong answer fails: Opção 1 (Verificar timers de reautenticação e o comportamento de reassociação do AP - CORRETA): aborda diretamente o ponto de falha provável quando o RADIUS autentica com sucesso mas os clientes perdem conectividade durante movimento — a transição (handoff) e aplicação de VLANs dinâmicas. Opção 2 (Substituir o controlador wireless por um novo hardware): substituição de hardware é uma medida drástica sem evidências; custos e risco são altos e logs indicam que a autenticação funciona, então o problema pode ser de configuração ou timers, não necessariamente hardware. Opção 3 (Alterar o SSID para um novo nome e testar): mudar SSID é irrelevante para a estabilidade do handoff e não isola problemas de reassociação, timers ou VLAN dinâmica; causa apenas trabalho administrativo extra. Opção 4 (Desligar o 802.1X e usar WPA2-PSK temporariamente): desabilitar 802.1X altera toda a arquitetura de segurança e VLAN dinâmica; é uma mudança disruptiva que não ajuda a diagnosticar o problema de roaming e remove importantes mecanismos de autenticação. Assim, o primeiro passo adequado é revisar timers e o processo de reassociação nos APs/controlador.