Eventos de radar DFS em Cisco Meraki, HPE Aruba e Ruckus: um checklist de diagnóstico para alterações de canal

Para diagnosticar e resolver eventos de radar DFS em redes WiFi Cisco Meraki, HPE Aruba ou Ruckus a funcionar sob a norma IEEE 802.11h, analise os registos do seu controlador para deteções de radar. Assim que for detetado, o ponto de acesso deve abandonar o canal de 5GHz em 10 segundos e permanecer fora dele durante 30 minutos.

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

A Seleção Dinâmica de Frequência (DFS) permite que o WiFi partilhe partes da banda de 5GHz com radares. A norma IEEE 802.11h define o mecanismo. Os reguladores definem os tempos: a FCC ao abrigo da 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) deteta radar, a sequência é fixa:

1. Deteção. O rádio associa um padrão de impulsos no seu canal de funcionamento a uma assinatura de radar.
2. Anúncio de mudança de canal (CSA). O AP adiciona um elemento CSA aos seus beacons, indicando aos clientes o novo canal e a contagem decrescente para a mudança.
3. Mudança de canal. O rádio deve parar de transmitir nesse canal em 10 segundos.
4. Período de não ocupação. O canal fica interdito durante pelo menos 30 minutos.
5. Verificação de disponibilidade do canal (CAC). Antes de um canal DFS entrar em funcionamento, o rádio escuta durante pelo menos 60 segundos. Nas regiões ETSI, os canais 120, 124 e 128 (5600 - 5650 MHz) são partilhados com radares meteorológicos, e a verificação nesses canais dura 10 minutos.

O que os convidados experienciam depende dos seus dispositivos. Os clientes que respeitam o CSA seguem o AP com uma curta pausa. Os clientes que o ignoram perdem a ligação, efetuam uma nova procura e voltam a associar-se, frequentemente nos 2.4GHz ou num AP vizinho. Se o AP se mover para um canal DFS que não tenha passado na sua verificação, o rádio de 5GHz pode permanecer em silêncio por um minuto ou mais.

O padrão a procurar:

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

O que costuma causar alterações de canais DFS?

Radar genuíno

Os radares meteorológicos na gama de 5600 - 5650 MHz são uma fonte genuína comum na Europa. Nos EUA, o Terminal Doppler Weather Radar (TDWR) nos principais aeroportos utiliza a mesma gama. A linha de vista importa mais do que a distância. APs exteriores, pisos superiores e fachadas envidraçadas detetam radares que os APs do rés-do-chão nunca veem.

A proximidade por si só prevê muito pouco. Muitos radares de vigilância aeroportuária e de navegação marítima funcionam noutras bandas, bem fora dos 5GHz. Um local ao lado de um porto pode nunca registar um único evento de radar. O seu registo de eventos é a prova, não o mapa.

Falsos positivos

Um falso positivo de DFS é uma deteção de radar sem que nenhum radar esteja presente. O rádio interpreta uma descarga de energia como um padrão de impulsos de radar. Os gatilhos típicos incluem:

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

A pista está no isolamento. Um AP regista eventos repetidos em canais variados, enquanto os vizinhos com a mesma visão do céu não registam nenhum.

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

Alterações não relacionadas com radar que parecem iguais

Os planeadores de canais movem rádios por interferência e carga. O Meraki Auto RF, Aruba ARM e AirMatch, e Ruckus ChannelFly e BackgroundScanning alteram canais sem radar. Os reinícios de AP e alterações de energia também desligam clientes. Estas falhas precisam de correções diferentes, por isso confirme o motivo antes de excluir qualquer coisa.

Como determinar se o radar causou a falha?

Siga esta lista de verificação por ordem:

1. Identifique a reclamação. Obtenha a hora ao minuto e a sala, piso ou zona.
2. Extraia eventos de alteração de canal para os APs que servem essa área, uma hora antes e depois.
3. Leia o motivo registado. Um motivo de radar ou DFS confirma a causa. Um motivo de interferência, ruído ou otimização descarta-a.
4. Anote o canal. Eventos agrupados em 120, 124 e 128 apontam para radar meteorológico.
5. Conte os APs afetados. Vários vizinhos juntos sugerem radar real. Um AP isolado sugere um falso positivo.
6. Procure um padrão semanal. Repetições regulares sugerem um radar com um horário ou varrimento fixo.
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 deteção de DFS no seu modelo de AP.

Se gere o Purple Guest WiFi, os volumes de início de sessão por local oferecem-lhe uma verificação cruzada. Uma queda acentuada num local que coincida com um evento de radar confirma o impacto nos convidados.

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

Fabricante	Onde aparecem os eventos de radar	Planeador de canais	Onde restringir canais
Cisco Meraki	Registo de eventos sem fios filtrado por eventos DFS; página de espetro de RF por AP	Auto RF	Lista de canais do perfil de RF, aplicada aos APs afetados
HPE Aruba	Histórico ARM no controlador ou cluster Instant; eventos 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 AP
Ruckus	Eventos e alarmes SmartZone para deteção de radar	ChannelFly ou BackgroundScanning	Definições de rádio para uma zona dedicada ou grupo de AP

Cisco Meraki

O Meraki regista a deteção de radar no registo de eventos como eventos DFS, identificando o AP e o canal. Filtre por tipo de evento e pela janela de reclamação. A página de espetro de RF para cada AP mostra a utilização e interferência, o que separa o radar do congestionamento. Para evitar a recorrência, remova os canais problemáticos do Auto RF num 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 de ARM lista cada alteração de canal com o respetivo motivo, sendo que a deteção de radar aparece como um motivo distinto. O AirMatch cria o plano de canais centralmente, mas uma deteção de radar obriga o AP a mudar de canal imediatamente. Uma alteração não programada a meio da tarde num canal DFS é, por isso, um forte indício. Restrinja os canais no perfil de rádio para um grupo de APs que contenha apenas os APs afetados. Se os convidados forem redirecionados para uma página de login após voltarem a ligar-se, trata-se de uma falha diferente: consulte o HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist.

Ruckus

O SmartZone gera um evento quando um AP deteta radar, identificando o AP e o canal. Verifique os eventos e alarmes para essa janela temporal e, em seguida, compare-os com a atividade do ChannelFly ou BackgroundScanning. Uma alteração de canal DFS no Ruckus sem nenhum evento de radar associado é uma decisão do planeador e não do DFS. Remova os canais problemáticos nas definições de rádio para uma zona dedicada ou grupo de APs.

Nas três plataformas, altere apenas os APs afetados. Uma exclusão a nível de todo o local consome capacidade em APs que nunca detetaram radar.

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

Não por predefinição. Excluir todos os canais DFS numa região ETSI deixa apenas quatro canais de 20 MHz: 36, 40, 44 e 48. As regras da FCC deixam nove, adicionando os canais 149 a 165. Num espaço de alta densidade, quatro canais obrigam os APs a partilhar tempo de antena e abrandam todos os clientes. Deixe os registos decidirem.

O que os seus registos mostram	Causa provável	Recomendação	Canais de 20 MHz restantes (ETSI / FCC)
Eventos em vários APs vizinhos, concentrados nos canais 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 nas proximidades	Excluir DFS apenas nos APs afetados; manter o mesmo nos restantes	4 / 9 nos APs afetados
Eventos repetidos num 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 de largura	Reduzir para 40 ou 20 MHz, manter DFS	19 / 25
Alterações de canal, mas sem entradas de radar	Planeador ou interferência	Corrigir interferência e potência, manter DFS	19 / 25

Cenário prático: um hotel perto de um aeroporto regional

Um hotel de 180 quartos numa região ETSI situado a 3 km de um campo de aviação com um radar meteorológico. Os hóspedes nos pisos superiores virados a oeste reportavam quebras na maioria das tardes. O registo de eventos mostrou 63 eventos de radar numa semana em 11 de 46 APs, todos nos canais 120 a 128. A equipa moveu esses 11 APs para um perfil que excluía os canais meteorológicos e definiu a largura para 40 MHz. Nas quatro semanas seguintes, o hotel registou zero eventos de radar. As reclamações de WiFi na receção caíram de 14 para duas por semana. Os outros 35 APs mantiveram todos os canais DFS. Para saber mais sobre implementações em hotéis, consulte Hotéis.

Cenário prático: uma cadeia de lojas com um AP ruidoso

Uma cadeia de retalho com 120 lojas viu uma loja registar 30 eventos de radar numa quinzena nos canais 52, 100 e 116. Os APs vizinhos na mesma loja não registaram nenhum, o que apontava para um falso positivo. As notas de lançamento do modelo de AP listavam uma correção de deteção DFS, pelo que a equipa 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 deixaram de perder ligações na zona das caixas de pagamento. O parque de equipamentos manteve todos os 19 canais. Consulte Retalho para acesso de convidados em múltiplos locais.

Cenário prático: escritórios municipais junto a um porto

Uma equipa de TI municipal planeava desativar o DFS em escritórios junto a um porto comercial. Trinta dias de registos não mostraram qualquer evento de radar. As alterações de canal resultaram de uma reação do planeador à rede de um inquilino vizinho. A equipa manteve o DFS, reduziu a potência de transmissão e corrigiu o plano de canais. Os relatórios semanais de quebras caíram de nove para um.

Como evitar que os eventos DFS voltem a perturbar os hóspedes?

• Utilize canais de 20 ou 40 MHz em locais densos. Canais mais estreitos reduzem a exposição e adicionam reutilização.
• Exclua canais meteorológicos cirurgicamente 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 lançamento.
• Reveja os eventos DFS mensalmente e crie alertas para qualquer AP que registe mais do que alguns eventos por semana.
• Planeie para 6GHz. A banda de 6GHz não tem requisitos de DFS, pelo que os clientes WiFi 6E e WiFi 7 evitam totalmente as mudanças de canal por radar.
• Separe o RF do acesso de convidados. O Purple funciona como uma sobreposição em nuvem independente de hardware em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O seu controlador gere o plano de canais e o Purple gere o início de sessão de convidados. O Purple processou 440 milhões de inícios de sessão em mais de 80.000 locais ativos em 2024 (dados do Purple).

Perguntas frequentes

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

Sim. O Purple Guest WiFi é uma sobreposição em nuvem independente de hardware que funciona em Cisco Meraki, HPE Aruba e Ruckus, bem como em Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Mantém os seus pontos de acesso, controladores e configuração de RF. O Purple adiciona o início de sessão de convidados, aceitações de escolha consciente e dados primários por cima. Não é necessária qualquer substituição de hardware e as suas definições de DFS permanecem sob o seu controlo.

O Purple alterará as nossas definiçõ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. Estes 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. Esta separação permite-lhe corrigir um problema de DFS no dashboard do seu fabricante sem tocar na experiência de início de sessão do convidado, e alterar as definições de início de sessão sem tocar no RF.

É conforme desativar os canais DFS?

Sim. A norma ETSI EN 301 893 e a FCC Part 15.407 exigem a deteção de radar em qualquer canal DFS que utilize. Nenhuma delas exige que utilize canais DFS. Excluí-los é sempre conforme. O que nunca deve fazer é operar num canal DFS com a deteçã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?

Normalmente 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 a produzir falsos positivos após uma atualização de firmware, ou quando adiciona capacidade de 6GHz. A banda de 6GHz não tem requisitos de DFS, pelo que 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 irá prejudicar o WiFi de convidados num local movimentado?

Sim, se os excluir em todo o local. Numa região ETSI, quatro canais de 20 MHz não conseguem separar dezenas de APs num estádio, centro de conferências ou hotel de grandes dimensões. Os APs acabam por partilhar o tempo de antena e o rendimento diminui para todos os convidados. Exclua canais apenas nos APs que registam radar, e mantenha o DFS em todos os outros locais. Esta abordagem contém o problema sem abdicar 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 norma ETSI EN 301 893, que aplica o DFS aos canais 52 a 64 e 100 a 140. 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 deteção.

Pode um MSP diagnosticar eventos de DFS numa infraestrutura de vários fabricantes?

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