Eventos de radar DFS en Cisco Meraki, HPE Aruba y Ruckus: una lista de diagnóstico para cambios de canal

Para diagnosticar y resolver eventos de radar DFS en redes WiFi de Cisco Meraki, HPE Aruba o Ruckus que operan bajo el estándar IEEE 802.11h, analice los registros de su controlador en busca de detecciones de radar. Una vez detectado, el punto de acceso debe abandonar el canal de 5GHz en un plazo de 10 segundos y permanecer fuera de él durante 30 minutos.

¿Cómo se ve un evento de radar DFS en su red de 5GHz?

La Selección Dinámica de Frecuencia (DFS) permite que el WiFi comparta partes de la banda de 5GHz con el radar. El estándar IEEE 802.11h define este mecanismo. Los organismos reguladores establecen los tiempos: la FCC bajo la norma 47 CFR Parte 15.407 en los EE. UU., y el ETSI EN 301 893 en toda Europa. En las regiones bajo la normativa ETSI, los canales del 52 al 64 y del 100 al 140 son canales DFS. Las reglas de la FCC añaden el canal 144.

Cuando un punto de acceso (AP) detecta un radar, la secuencia es fija:

1. Detección. El radio compara un patrón de pulsos en su canal de operación con una firma de radar.
2. Anuncio de cambio de canal (CSA). El AP añade un elemento CSA a sus beacons, indicando a los clientes el nuevo canal y la cuenta regresiva para la transición.
3. Cambio de canal. El radio debe dejar de transmitir en ese canal en un plazo de 10 segundos.
4. Periodo de no ocupación. El canal queda fuera de servicio durante al menos 30 minutos.
5. Verificación de disponibilidad de canal (CAC). Antes de que un canal DFS entre en servicio, el radio escucha durante al menos 60 segundos. En las regiones bajo la normativa ETSI, los canales 120, 124 y 128 (5600 - 5650 MHz) se comparten con radares meteorológicos, y la verificación allí dura 10 minutos.

Lo que experimentan los usuarios invitados depende de sus dispositivos. Los clientes que respetan el CSA siguen al AP con una breve pausa. Los clientes que lo ignoran pierden la conexión, vuelven a escanear y se asocian de nuevo, a menudo en 2.4GHz o en un AP vecino. Si el AP se mueve a un canal DFS que no ha superado su verificación, el radio de 5GHz puede permanecer en silencio durante un minuto o más.

El patrón a buscar es el siguiente:

• Todos los clientes de un AP, o de un grupo de AP vecinos, se desconectan al mismo tiempo.
• El AP regresa en un canal diferente, a menudo un canal que no es DFS entre el 36 y el 48.
• El cambio ocurre fuera de su ventana programada de optimización de canales.
• Los mismos AP repiten el patrón, a veces a horas similares del día.
• La carga en 2.4GHz aumenta drásticamente mientras los clientes de 5GHz desaparecen.

¿Qué suele causar los cambios de canal DFS?

Radar real

Los radares meteorológicos en el rango de 5600 - 5650 MHz son una fuente real común en Europa. En los EE. UU., el Radar Meteorológico Doppler de Terminal (TDWR) en los principales aeropuertos utiliza el mismo rango. La línea de visión influye más que la distancia. Los AP de exterior, los pisos superiores y las fachadas acristaladas detectan radares que los AP de la planta baja nunca ven.

La proximidad por sí sola predice muy poco. Muchos radares de vigilancia aeroportuaria y de navegación marítima operan en otras bandas, muy alejadas de los 5GHz. Un establecimiento junto a un puerto podría no registrar jamás un solo evento de radar. Su registro de eventos es la evidencia real, no el mapa.

Falsos positivos

Un falso positivo de DFS es una detección de radar sin que haya ningún radar presente. El radio interpreta una ráfaga de energía como un patrón de pulsos de radar. Los desencadenantes típicos incluyen:

• interferencia pulsada ajena a WiFi procedente de enlaces de video inalámbricos o equipos defectuosos;
• transmisiones potentes de un AP cercano o de un enlace punto a punto en un canal adyacente;
• defectos de radio o firmware, que los fabricantes corrigen en las actualizaciones de software.

La clave es el aislamiento. Un AP registra eventos repetidos en varios canales mientras que los vecinos con la misma visual del cielo no registran ninguno.

Los canales anchos aumentan la exposición a detecciones tanto reales como falsas. Un canal de 80 MHz abarca cuatro subcanales de 20 MHz, y una detección en cualquiera de ellos desplaza a todo el canal.

Cambios ajenos al radar que se ven iguales

Los planificadores de canales mueven los radios por interferencia y carga. Meraki Auto RF, Aruba ARM y AirMatch, y Ruckus ChannelFly y BackgroundScanning cambian de canal sin que intervenga el radar. Los reinicios de los AP y los cambios de potencia también desconectan a los clientes. Estas fallas requieren soluciones diferentes, así que confirme el motivo antes de excluir cualquier opción.

¿Cómo determinar si el radar causó la interrupción?

Siga esta lista de verificación en orden:

1. Identifique la queja. Obtenga la hora exacta al minuto y el aula, piso o zona.
2. Extraiga los eventos de cambio de canal de los AP que dan servicio a esa área, una hora antes y una después.
3. Lea el motivo registrado. Un motivo de radar o DFS confirma la causa. Un motivo de interferencia, ruido u optimización la descarta.
4. Anote el canal. Los eventos agrupados en los canales 120, 124 y 128 apuntan a radares meteorológicos.
5. Cuente los AP afectados. Varios vecinos afectados juntos sugieren la presencia de un radar real. Un solo AP aislado sugiere un falso positivo.
6. Busque un patrón semanal. Las repeticiones regulares sugieren un radar con un horario o barrido fijo.
7. Verifique el ancho de canal. Los eventos que solo aparecen en canales de 80 o 160 MHz hacen que el ancho sea parte del problema.
8. Lea las notas de la versión de firmware para buscar correcciones de detección DFS en su modelo de AP.

Si utiliza Purple Guest WiFi, los volúmenes de inicio de sesión por sucursal le permiten realizar una verificación cruzada. Una caída abrupta en un sitio que coincide con un evento de radar confirma el impacto en los invitados.

¿Cómo solucionar eventos DFS en Meraki, Aruba y Ruckus?

Fabricante	Dónde aparecen los eventos de radar	Planificador de canales	Dónde se restringen los canales
Cisco Meraki	Registro de eventos inalámbricos filtrado por eventos DFS; página de espectro RF por AP	Auto RF	Lista de canales del perfil RF, aplicada a los AP afectados
HPE Aruba	Historial de ARM en el controlador o clúster Instant; eventos de AirMatch en AOS 8 y Aruba Central	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	Lista de canales permitidos en el perfil de radio para un grupo de AP
Ruckus	Eventos y alarmas de SmartZone para detección de radar	ChannelFly o BackgroundScanning	Configuración de radio para una zona dedicada o grupo de AP

Cisco Meraki

Meraki registra la detección de radar en el registro de eventos como eventos DFS, nombrando el AP y el canal. Filtre por tipo de evento y el intervalo del reporte. La página del espectro de RF para cada AP muestra la utilización y la interferencia, lo que separa el radar de la congestión. Para evitar que vuelva a ocurrir, elimine los canales con problemas de Auto RF en un perfil de RF. Aplique ese perfil solo a los APs afectados. La propia documentación de DFS de Meraki cubre los pasos exactos.

HPE Aruba

El historial de ARM enumera cada cambio de canal con su motivo, y la detección de radar aparece como un motivo específico. AirMatch crea el plan de canales de forma centralizada, pero una detección de radar obliga al AP a moverse de inmediato. Por lo tanto, un cambio no programado a media tarde en un canal DFS es una pista importante. Restrinja los canales en el perfil de radio para un grupo de AP que contenga solo los APs afectados. Si se envía a los usuarios invitados de vuelta a una página de inicio de sesión después de reconectarse, se trata de una falla independiente: consulte la Guía de solución de problemas del captive portal de HPE Aruba: lista de verificación de redireccionamiento, certificado y walled garden.

Ruckus

SmartZone genera un evento cuando un AP detecta radar, nombrando el AP y el canal. Revise los eventos y las alarmas de ese intervalo, luego compárelos con la actividad de ChannelFly o BackgroundScanning. Un cambio de canal DFS en Ruckus sin un evento de radar detrás es una decisión del planificador, no de DFS. Elimine los canales con problemas en la configuración de radio para una zona dedicada o un grupo de AP.

En las tres plataformas, cambie únicamente los APs afectados. Una exclusión en todo el sitio reduce la capacidad en los APs que nunca detectaron radar.

¿Se deben desactivar los canales DFS cerca de un aeropuerto, puerto o radar meteorológico?

No por defecto. Excluir todos los canales DFS en una región ETSI deja cuatro canales de 20 MHz: 36, 40, 44 y 48. Las reglas de la FCC dejan nueve, agregando del 149 al 165. En un lugar de alta densidad, cuatro canales obligan a los APs a compartir el tiempo de aire y ralentizan a todos los clientes. Deje que los registros decidan.

Lo que muestran sus registros	Causa probable	Recomendación	Canales de 20 MHz restantes (ETSI / FCC)
Eventos en varios APs vecinos, agrupados en 120-128	Radar meteorológico	Excluir 120, 124 y 128 en los APs afectados	16 / 22
Eventos en la mayoría de los canales DFS en muchos APs, todos los días	Radar cercano fuerte	Excluir DFS solo en los APs afectados; mantenerlo en otros lugares	4 / 9 en los APs afectados
Eventos repetidos en un AP, canales variados	Falso positivo	Actualizar firmware, probar o reemplazar la radio, mantener DFS	19 / 25
Eventos solo en canales de 80 o 160 MHz	Exposición por ancho de banda	Bajar a 40 o 20 MHz, mantener DFS	19 / 25
Cambios de canal pero sin entradas de radar	Planificador o interferencia	Corregir la interferencia y la potencia, mantener DFS	19 / 25

Caso práctico: un hotel cerca de un aeropuerto regional

Un hotel de 180 habitaciones en una región ETSI situado a 3 km de un aeródromo con un radar meteorológico. Los huéspedes de los pisos superiores orientados al oeste informaron caídas de señal la mayoría de las tardes. El registro de eventos mostró 63 eventos de radar en una semana en 11 de los 46 AP, todos en los canales 120 al 128. El equipo movió esos 11 AP a un perfil que excluía los canales meteorológicos y configuró un ancho de banda de 40 MHz. Durante las siguientes cuatro semanas, el hotel registró cero eventos de radar. Las quejas de WiFi en la recepción disminuyeron de 14 a dos por semana. Los otros 35 AP conservaron todos los canales DFS. Para obtener más información sobre implementaciones en hoteles, consulte Hotels.

Escenario práctico: una cadena minorista con un AP ruidoso

Una cadena minorista de 120 tiendas vio cómo una de sus tiendas registraba 30 eventos de radar en una quincena en los canales 52, 100 y 116. Los AP vecinos en la misma tienda no registraron ninguno, lo que apuntaba a un falso positivo. Las notas de la versión para ese modelo de AP enumeraban una corrección de detección DFS, por lo que el equipo actualizó el firmware. Los eventos continuaron y el AP fue reemplazado bajo garantía. Los eventos de radar en la tienda disminuyeron a cero y los compradores dejaron de perder conexiones en el área de cajas. El complejo conservó los 19 canales. Consulte Retail para obtener información sobre el acceso de invitados en múltiples sitios.

Escenario práctico: oficinas municipales al lado de un puerto

Un equipo de TI municipal planeaba desactivar DFS en unas oficinas situadas junto a un puerto comercial. Treinta días de registros no mostraron ningún evento de radar. Los cambios de canal provenían de la reacción del planificador ante la red de un inquilino vecino. El equipo mantuvo DFS, redujo la potencia de transmisión y corrigió el plan de canales. Los informes semanales de caídas disminuyeron de nueve a uno.

¿Cómo evitar que los eventos DFS vuelvan a interrumpir a los huéspedes?

• Utilice canales de 20 o 40 MHz en lugares concurridos. Los canales más estrechos reducen la exposición y permiten una mayor reutilización.
• Excluya los canales meteorológicos de forma quirúrgica donde los eventos se concentren del 120 al 128, únicamente en los AP afectados.
• Mantenga el firmware actualizado y lea las correcciones de DFS en cada nota de la versión.
• Revise los eventos DFS mensualmente y configure alertas para cualquier AP que registre más de unos pocos a la semana.
• Planifique para 6GHz. La banda de 6GHz no requiere DFS, por lo que los clientes de WiFi 6E y WiFi 7 evitan por completo los cambios por radar.
• Separe la RF del acceso de invitados. Purple funciona como una capa en la nube independiente del hardware sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Su controlador administra el plan de canales y Purple administra el inicio de sesión de invitados. Purple procesó 440 millones de inicios de sesión en más de 80,000 establecimientos activos en 2024 (datos de Purple).

Preguntas frecuentes

¿Funciona Purple Guest WiFi en nuestros puntos de acceso Meraki, Aruba o Ruckus existentes?

Sí. Purple Guest WiFi es una capa en la nube independiente del hardware que se ejecuta en Cisco Meraki, HPE Aruba y Ruckus, además de Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Usted conserva sus puntos de acceso, controladores y configuración de RF. Purple añade el inicio de sesión de invitados, el consentimiento explícito y consciente, y los datos de primera fuente de forma complementaria. No es necesario realizar un reemplazo completo y sus ajustes de DFS siguen bajo su control.

¿Modificará Purple nuestra configuración de DFS o de canales?

No. Purple no configura los canales de radio, el ancho de banda del canal ni la potencia de transmisión. Esos parámetros permanecen en Meraki Auto RF, Aruba ARM o AirMatch, y Ruckus ChannelFly o BackgroundScanning. Purple gestiona la autenticación de invitados y la captura de datos por encima de la capa de radio. Esa separación le permite solucionar un problema de DFS en el panel de control de su proveedor sin alterar la experiencia de inicio de sesión del invitado, y cambiar la configuración de inicio de sesión sin modificar la RF.

¿Cumple con las normas desactivar los canales DFS?

Sí. Las normas ETSI EN 301 893 y FCC Parte 15.407 requieren la detección de radar en cualquier canal DFS que utilice. Ninguna de las dos le obliga a utilizar canales DFS. Excluirlos siempre cumple con la normativa. Lo que nunca debe hacer es operar en un canal DFS con la detección desactivada. El costo real de la exclusión es la capacidad: en las regiones ETSI, eliminar todos los canales DFS deja cuatro canales de 20 MHz en lugar de 19.

¿Necesitamos puntos de acceso nuevos para evitar problemas de DFS?

Normalmente no. La mayoría de los problemas de DFS se solucionan con la configuración: excluyendo los canales meteorológicos en los AP afectados, reduciendo el ancho de canal o actualizando el firmware. El reemplazo tiene sentido cuando una radio sigue produciendo falsos positivos después de una actualización de firmware, o cuando se añade capacidad de 6GHz. La banda de 6GHz no tiene requisitos de DFS, por lo que los puntos de acceso WiFi 6E y WiFi 7 eliminan los cambios por radar para los clientes que los admiten.

¿Excluir los canales DFS afectará al WiFi de invitados en un recinto concurrido?

Sí, si los excluye en todo el sitio. En una región ETSI, cuatro canales de 20 MHz no pueden separar decenas de AP en un estadio, centro de conferencias o un gran hotel. Los AP terminan compartiendo el tiempo de transmisión y el rendimiento disminuye para cada invitado. Excluya los canales únicamente en los AP que registren radar, y mantenga el DFS en todos los demás lugares. Este enfoque contiene el problema sin sacrificar la capacidad.

¿Difieren las reglas de DFS entre el Reino Unido, Europa y los EE. UU.?

Sí. El Reino Unido y la UE siguen la norma ETSI EN 301 893, que aplica DFS a los canales 52 a 64 y 100 a 140. También requiere una comprobación de disponibilidad de 10 minutos en los canales meteorológicos 120, 124 y 128. Los EE. UU. siguen la norma FCC Parte 15.407, que añade el canal 144 y deja nueve canales que no son DFS. Ambos requieren al menos 30 minutos de no ocupación después de una detección.

¿Puede un MSP diagnosticar eventos de DFS en una infraestructura de múltiples proveedores?

Sí, pero los eventos de radar residen en las herramientas propias de cada proveedor: el registro de eventos de Meraki, el historial de Aruba ARM o eventos de AirMatch, y los eventos y alarmas de SmartZone. Un MSP debe estandarizar la lista de verificación en lugar de la herramienta, y registrar la hora, el canal, el número de AP y el motivo de cada incidente. Purple le ofrece una única plataforma para el acceso de invitados en todos esos proveedores, mientras que el diagnóstico de RF se mantiene en cada controlador.