Eventos de radar DFS no Cisco Meraki, HPE Aruba e Ruckus: um checklist de diagnóstico para mudanças de canal

Para diagnosticar e resolver eventos de radar DFS em redes WiFi Cisco Meraki, HPE Aruba ou Ruckus operando sob o padrão IEEE 802.11h, analise os logs do seu controlador para detecções de radar. Uma vez detectado, o ponto de acesso deve desocupar o canal de 5GHz dentro de 10 segundos e permanecer fora dele por 30 minutos.

Como é um evento de radar DFS na sua rede de 5GHz?

A Seleção Dinâmica de Frequência (DFS) permite que o WiFi compartilhe partes da banda de 5GHz com o radar. O IEEE 802.11h define o mecanismo. Os reguladores definem os tempos: a FCC sob a 47 CFR Part 15.407 nos EUA, e o ETSI EN 301 893 em toda a Europa. Nas regiões ETSI, os canais 52 a 64 e 100 a 140 são canais DFS. As regras da FCC adicionam o canal 144.

Quando um ponto de acesso (AP) detecta radar, a sequência é fixa:

1. Detecção. O rádio associa um padrão de pulso em seu canal de operação a uma assinatura de radar.
2. Anúncio de mudança de canal (CSA). O AP adiciona um elemento CSA aos seus beacons, informando aos clientes o novo canal e a contagem regressiva para a mudança.
3. Mudança de canal. O rádio deve parar de transmitir nesse canal dentro de 10 segundos.
4. Período de não ocupação. O canal fica fora de limites por pelo menos 30 minutos.
5. Verificação de disponibilidade de canal (CAC). Antes que um canal DFS entre em serviço, o rádio escuta por pelo menos 60 segundos. Nas regiões ETSI, os canais 120, 124 e 128 (5600 - 5650 MHz) são compartilhados com radares meteorológicos, e a verificação ali dura 10 minutos.

O que os visitantes experimentam depende de seus dispositivos. Os clientes que respeitam o CSA seguem o AP com uma breve pausa. Os clientes que o ignoram perdem a conexão, reescaneiam e se reassociam, frequentemente em 2.4GHz ou em um AP vizinho. Se o AP se mover para um canal DFS que não passou na sua verificação, o rádio de 5GHz pode permanecer silencioso por um minuto ou mais.

O padrão a ser procurado:

• Todos os clientes em um AP, ou em um grupo de APs vizinhos, caem no mesmo instante.
• O AP retorna em um canal diferente, frequentemente um canal não DFS entre 36 e 48.
• A mudança ocorre fora da sua janela agendada de otimização de canais.
• Os mesmos APs repetem o padrão, às vezes em horários semelhantes do dia.
• A carga de 2.4GHz aumenta enquanto os clientes de 5GHz desaparecem.

O que geralmente causa mudanças de canal DFS?

Radar real

Radares meteorológicos na faixa de 5600 - 5650 MHz são uma fonte real comum na Europa. Nos EUA, o Terminal Doppler Weather Radar (TDWR) em grandes aeroportos utiliza a mesma faixa. A linha de visão importa mais do que a distância. APs externos, andares superiores e fachadas envidraçadas detectam radares que os APs do térreo nunca veem.

A proximidade isolada prediz pouco. Muitos radares de vigilância aeroportuária e de navegação marítima operam em outras bandas, bem fora de 5GHz. Um local ao lado de um porto pode nunca registrar um único evento de radar. O seu log de eventos é a evidência, não o mapa.

Falsos positivos

Um falso positivo de DFS é uma detecção de radar sem a presença de radar. O rádio interpreta uma oscilação de energia como um padrão de pulso de radar. Os gatilhos típicos incluem:

• interferência não WiFi pulsada de links de vídeo sem fio ou equipamentos com defeito;
• transmissões fortes de um AP próximo ou link ponto a ponto em um canal adjacente;
• defeitos de rádio ou firmware, que os fabricantes corrigem em atualizações de software.

O sinal revelador é o isolamento. Um AP registra eventos repetidos em canais variados enquanto os vizinhos com a mesma visão do céu não registram nenhum.

Canais largos aumentam a exposição a detecções reais e falsas. Um canal de 80 MHz abrange quatro subcanais de 20 MHz, e uma detecção em qualquer um deles move o canal inteiro.

Mudanças que não são de radar, mas parecem iguais

Os planejadores de canal movem os rádios por interferência e carga. Meraki Auto RF, Aruba ARM e AirMatch, e Ruckus ChannelFly e BackgroundScanning alteram os canais sem radar. Reinicializações de AP e mudanças de energia também desconectam clientes. Esses problemas precisam de correções diferentes, portanto, confirme o motivo antes de excluir qualquer coisa.

Como você descobre se o radar causou a queda?

Siga esta lista de verificação em ordem:

1. Identifique a reclamação. Obtenha o horário exato com precisão de minutos e a sala, andar ou zona.
2. Extraia eventos de mudança de canal para os APs que atendem a essa área, uma hora antes e depois.
3. Leia o motivo registrado. Um motivo de radar ou DFS confirma a causa. Um motivo de interferência, ruído ou otimização a descarta.
4. Observe o canal. Eventos agrupados nos canais 120, 124 e 128 apontam para radar meteorológico.
5. Conte os APs afetados. Vários vizinhos juntos sugerem radar real. Um único AP sozinho sugere um falso positivo.
6. Procure um padrão semanal. Repetições regulares sugerem um radar com uma programação ou varredura fixa.
7. Verifique a largura do canal. Eventos que aparecem apenas em canais de 80 ou 160 MHz tornam a largura parte do problema.
8. Leia as notas de lançamento do firmware para correções de detecção de DFS no modelo do seu AP.

Se você opera o Purple Guest WiFi, o volume de logins por local oferece uma verificação cruzada. Uma queda acentuada em um site que coincide com um evento de radar confirma o impacto nos visitantes.

Como corrigir eventos de DFS no Meraki, Aruba e Ruckus?

Fabricante	Onde os eventos de radar aparecem	Planejador de canal	Onde você restringe os canais
Cisco Meraki	Registro de eventos sem fio filtrado para eventos DFS; página de espectro de RF por AP	Auto RF	Lista de canais do perfil de RF, aplicada aos APs afetados
HPE Aruba	Histórico do ARM na controladora ou cluster Instant; eventos do AirMatch no AOS 8 e Aruba Central	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	Lista de canais permitidos no perfil de rádio para um grupo de APs
Ruckus	Eventos e alarmes do SmartZone para detecção de radar	ChannelFly ou BackgroundScanning	Configurações de rádio para uma zona dedicada ou grupo de APs

Cisco Meraki

Meraki registra a detecção de radar no log de eventos como eventos DFS, nomeando o AP e o canal. Filtre por tipo de evento e pela janela da ocorrência. A página de espectro de RF para cada AP mostra a utilização e a interferência, separando o radar do congestionamento. Para evitar a recorrência, remova os canais problemáticos do Auto RF em um perfil de RF. Aplique esse perfil apenas aos APs afetados. A própria documentação de DFS da Meraki cobre os passos exatos.

HPE Aruba

O histórico do ARM lista cada mudança de canal com seu motivo, e a detecção de radar aparece como um motivo distinto. O AirMatch cria o plano de canais centralmente, mas uma detecção de radar força o AP a se mover imediatamente. Uma mudança não agendada no meio da tarde em um canal DFS é, portanto, um forte indício. Restrinja os canais no perfil de rádio para um grupo de APs contendo apenas os APs afetados. Se os visitantes forem enviados de volta para uma página de login após a reconexão, esse é um problema separado: consulte o HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist.

Ruckus

O SmartZone gera um evento quando um AP detecta radar, nomeando o AP e o canal. Verifique eventos e alarmes para o período e compare-os com a atividade do ChannelFly ou BackgroundScanning. Uma mudança de canal DFS da Ruckus sem um evento de radar por trás é uma decisão do planejador, não DFS. Remova os canais problemáticos nas configurações de rádio para uma zona dedicada ou grupo de APs.

Em todas as três plataformas, altere apenas os APs afetados. Uma exclusão em todo o site reduz a capacidade em APs que nunca detectaram radar.

Você deve desativar os canais DFS perto de um aeroporto, porto ou radar meteorológico?

Não por padrão. Excluir todos os canais DFS em uma região ETSI deixa apenas quatro canais de 20 MHz: 36, 40, 44 e 48. As regras da FCC deixam nove, adicionando os canais de 149 a 165. Em um local de alta densidade, quatro canais forçam os APs a compartilhar o tempo de transmissão e lentificam todos os clientes. Deixe os logs decidirem.

O que seus logs mostram	Causa provável	Recomendação	Canais de 20 MHz restantes (ETSI / FCC)
Eventos em vários APs vizinhos, concentrados em 120-128	Radar meteorológico	Excluir 120, 124 e 128 nos APs afetados	16 / 22
Eventos na maioria dos canais DFS em muitos APs, diariamente	Radar forte próximo	Excluir DFS apenas nos APs afetados; manter nos outros	4 / 9 nos APs afetados
Eventos repetidos em um AP, canais variados	Falso positivo	Atualizar firmware, testar ou substituir o rádio, manter DFS	19 / 25
Eventos apenas em canais de 80 ou 160 MHz	Exposição por largura	Reduzir para 40 ou 20 MHz, manter DFS	19 / 25
Mudanças de canal mas sem entradas de radar	Planejador ou interferência	Corrigir interferência e potência, manter DFS	19 / 25

Cenário prático: um hotel próximo a um aeroporto regional

Um hotel de 180 quartos em uma região ETSI estava situado a 3 km de um aeródromo com radar meteorológico. Os hóspedes nos andares superiores voltados para o oeste relataram quedas na maioria das tardes. O registro de eventos mostrou 63 eventos de radar em uma semana em 11 dos 46 APs, todos nos canais 120 a 128. A equipe moveu esses 11 APs para um perfil que excluía os canais meteorológicos e definiu a largura em 40 MHz. Nas quatro semanas seguintes, o hotel registrou zero eventos de radar. As reclamações de WiFi na recepção caíram de 14 para duas por semana. Os outros 35 APs mantiveram todos os canais DFS. Para saber mais sobre implantações em hotéis, consulte Hotéis.

Cenário prático: uma rede de varejo com um AP ruidoso

Uma rede de varejo de 120 lojas viu uma loja registrar 30 eventos de radar em duas semanas nos canais 52, 100 e 116. Os APs vizinhos na mesma loja não registraram nenhum, o que apontava para um falso positivo. As notas de versão do modelo do AP listavam uma correção de detecção de DFS, então a equipe atualizou o firmware. Os eventos continuaram e o AP foi substituído sob garantia. Os eventos de radar na loja caíram para zero e os clientes pararam de perder a conexão na área dos caixas. A propriedade manteve todos os 19 canais. Consulte Varejo para acesso de visitantes em vários locais.

Cenário prático: escritórios municipais ao lado de um porto

Uma equipe de TI municipal planejava desativar o DFS em escritórios próximos a um porto comercial. Trinta dias de registros não mostraram nenhum evento de radar. As alterações de canal vieram de uma reação do planejador à rede de um inquilino vizinho. A equipe manteve o DFS, reduziu a potência de transmissão e corrigiu o plano de canais. Os relatórios semanais de quedas caíram de nove para um.

Como evitar que eventos DFS interrompam seus hóspedes novamente?

• Use canais de 20 ou 40 MHz em locais densos. Canais mais estreitos reduzem a exposição e adicionam reutilização.
• Exclua canais meteorológicos de forma cirúrgica onde os eventos se concentram de 120 a 128, apenas nos APs afetados.
• Mantenha o firmware atualizado e leia as correções de DFS em cada nota de versão.
• Revise os eventos DFS mensalmente e alerte sobre qualquer AP que registre mais do que alguns eventos por semana.
• Planeje para 6GHz. A banda de 6GHz não exige DFS, de modo que clientes WiFi 6E e WiFi 7 evitam totalmente as mudanças causadas por radares.
• Separe o RF do acesso de visitantes. O Purple funciona como um overlay de nuvem agnóstico de hardware sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Sua controladora gerencia o plano de canais e o Purple gerencia o login de visitantes. O Purple realizou 440 milhões de logins em mais de 80.000 locais ativos em 2024 (dados do Purple).

Perguntas frequentes

O Purple Guest WiFi funciona em nossos pontos de acesso existentes Meraki, Aruba ou Ruckus?

Sim. O Purple Guest WiFi é um overlay de nuvem agnóstico de hardware que roda sobre Cisco Meraki, HPE Aruba e Ruckus, além de Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você mantém seus pontos de acesso, controladoras e configuração de RF. O Purple adiciona o login de visitantes, opções de consentimento consciente e dados primários por cima. Nenhuma substituição total é necessária e suas configurações de DFS permanecem sob seu controle.

O Purple alterará nossas configurações de DFS ou de canais?

Não. O Purple não define canais de rádio, largura de canal ou potência de transmissão. Essas configurações permanecem no Meraki Auto RF, Aruba ARM ou AirMatch, e Ruckus ChannelFly ou BackgroundScanning. O Purple lida com a autenticação de convidados e a captura de dados acima da camada de rádio. Essa separação permite que você corrija um problema de DFS no painel do seu fabricante sem afetar a experiência de login do convidado, e altere as configurações de login sem mexer em RF.

É compatível desativar os canais DFS?

Sim. As normas ETSI EN 301 893 e FCC Part 15.407 exigem detecção de radar em qualquer canal DFS que você utilizar. Nenhuma delas exige que você use canais DFS. Excluí-los é sempre compatível com as normas. O que você nunca deve fazer é operar em um canal DFS com a detecção desativada. O custo real da exclusão é a capacidade: nas regiões ETSI, a remoção de todos os canais DFS deixa quatro canais de 20 MHz em vez de 19.

Precisamos de novos pontos de acesso para evitar problemas de DFS?

Geralmente não. A maioria dos problemas de DFS é corrigida com configuração: excluindo canais meteorológicos nos APs afetados, estreitando a largura do canal ou atualizando o firmware. A substituição faz sentido quando um rádio continua produzindo falsos positivos após uma atualização de firmware, ou quando você adiciona capacidade de 6GHz. A banda de 6GHz não tem exigência de DFS, portanto, os pontos de acesso WiFi 6E e WiFi 7 eliminam as mudanças de radar para os clientes que os suportam.

A exclusão de canais DFS prejudicará o WiFi de convidados em um local movimentado?

Sim, se você os excluir em todo o local. Em uma região ETSI, quatro canais de 20 MHz não conseguem separar dezenas de APs em um estádio, centro de conferências ou grande hotel. Os APs acabam compartilhando o tempo de transmissão e a taxa de transferência cai para todos os convidados. Exclua os canais apenas nos APs que registram radar e mantenha o DFS em todos os outros lugares. Essa abordagem limita o problema sem abrir mão da capacidade.

As regras de DFS diferem entre o Reino Unido, a Europa e os EUA?

Sim. O Reino Unido e a UE seguem a ETSI EN 301 893, que aplica DFS aos canais 52 a 64 e 100 a 140. Ela também exige uma verificação de disponibilidade de 10 minutos nos canais meteorológicos 120, 124 e 128. Os EUA seguem a FCC Part 15.407, que adiciona o canal 144 e deixa nove canais não-DFS. Ambos exigem pelo menos 30 minutos de não ocupação após uma detecção.

Um MSP pode diagnosticar eventos de DFS em um parque de diferentes fabricantes?

Sim, mas os eventos de radar ficam nas próprias ferramentas de cada fabricante: o registro de eventos Meraki, o histórico Aruba ARM ou eventos AirMatch, e os eventos e alarmes SmartZone. Um MSP deve padronizar a lista de verificação em vez da ferramenta, e registrar a hora, o canal, a contagem de APs e o motivo de cada incidente. O Purple oferece uma única plataforma para acesso de convidados em todos esses fabricantes, enquanto o diagnóstico de RF permanece em cada controladora.