Eventos de radar DFS en Cisco Meraki, HPE Aruba y Ruckus: una lista de verificación 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 para detectar radares. 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 ETSI, los canales del 52 al 64 y del 100 al 140 son canales DFS. Las normas de la FCC añaden el canal 144.

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

1. Detección. La radio asocia 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 balizas (beacons), indicando a los clientes el nuevo canal y la cuenta atrás para el traslado.
3. Cambio de canal. La 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, la radio escucha durante al menos 60 segundos. En las regiones ETSI, los canales 120, 124 y 128 (5600 - 5650 MHz) se comparten con el radar meteorológico, y la verificación allí dura 10 minutos.

Lo que experimentan los 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 reasocian, a menudo en 2.4GHz o en un AP vecino. Si el AP se traslada a un canal DFS que no ha superado su verificación, la radio de 5GHz puede permanecer en silencio durante un minuto o más.

El patrón a buscar:

• Todos los clientes en un AP, o en un grupo de AP vecinos, se desconectan al mismo tiempo.
• El AP regresa en un canal diferente, a menudo un canal no DFS entre el 36 y el 48.
• El cambio se produce 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 de golpe 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 importa 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 poco. Muchos radares de vigilancia aeroportuaria y de navegación marítima operan en otras bandas, muy alejadas de los 5GHz. Un espacio al lado de un puerto puede no registrar nunca un solo evento de radar. Su registro de eventos es la prueba, no el mapa.

Falsos positivos

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

• interferencias de fuentes que no son de WiFi pulsadas provenientes de enlaces de vídeo inalámbricos o equipos defectuosos;
• transmisiones fuertes de un AP cercano o 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 está en el aislamiento. Un AP registra eventos repetidos en varios canales mientras que los vecinos con la misma perspectiva del entorno 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 todo el canal.

Cambios ajenos al radar que se comportan igual

Los planificadores de canales mueven las radios debido a la interferencia y la 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. Estos fallos requieren soluciones diferentes, así que confirme el motivo antes de descartar nada.

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

Siga esta lista de comprobación en orden:

1. Localice la queja. Obtenga la hora exacta al minuto y la sala, planta o zona.
2. Extraiga los eventos de cambio de canal de los AP que dan servicio a esa zona, una hora antes y una hora 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 juntos sugieren 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. Compruebe el ancho de canal. Los eventos que solo aparecen en canales de 80 o 160 MHz indican que el ancho de canal es parte del problema.
8. Lea las notas de la versión del firmware para ver las correcciones de detección de DFS en su modelo de AP.

Si utiliza Purple Guest WiFi, los volúmenes de inicio de sesión por ubicación le permiten realizar una doble comprobación. Una caída pronunciada en un sitio que coincide con un evento de radar confirma el impacto en las visitas.

¿Cómo se solucionan los 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 de RF por AP	Auto RF	Lista de canales del perfil de RF, aplicada a los AP afectados
HPE Aruba	Historial de ARM en el controlador o clúster de 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, indicando el AP y el canal. Filtre por tipo de evento y por el intervalo de tiempo de la incidencia. La página de espectro de RF de cada AP muestra la utilización y la interferencia, lo que ayuda a distinguir el radar de la congestión. Para evitar que vuelva a ocurrir, elimine los canales conflictivos de Auto RF en un perfil de RF. Aplique ese perfil solo a los AP afectados. La documentación sobre DFS de Meraki detalla los pasos exactos.

HPE Aruba

El historial de ARM muestra cada cambio de canal junto con su motivo, apareciendo la detección de radar como una causa diferenciada. AirMatch diseña el plan de canales de manera centralizada, pero una detección de radar obliga al AP a cambiar de canal de inmediato. Un cambio imprevisto a media tarde en un canal DFS es, por tanto, un indicio claro. Restrinja los canales en el perfil de radio para un grupo de AP que contenga únicamente los AP afectados. Si se redirige a los usuarios invitados de nuevo a una página de inicio de sesión tras volver a conectarse, se trata de un error diferente: consulte la Guía de resolución de problemas del captive portal de HPE Aruba: lista de comprobación de redireccionamiento, certificados y walled garden.

Ruckus

SmartZone registra un evento cuando un AP detecta radar, indicando el AP y el canal. Revise los eventos y las alarmas en ese intervalo de tiempo y luego compárelos con la actividad de ChannelFly o BackgroundScanning. Un cambio de canal DFS en Ruckus que no tenga detrás un evento de radar es una decisión de planificación, no de DFS. Elimine los canales conflictivos en los ajustes de radio para una zona dedicada o un grupo de AP.

En las tres plataformas, modifique únicamente los AP afectados. Una exclusión que afecte a toda la instalación reduciría la capacidad en aquellos AP que nunca han detectado radar.

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

No de forma predeterminada. Excluir todos los canales DFS en una región ETSI deja solo cuatro canales de 20 MHz: 36, 40, 44 y 48. Las normas FCC dejan nueve, sumando del 149 al 165. En un espacio de alta densidad, disponer de solo cuatro canales obliga a los AP a compartir el tiempo de emisión, lo que ralentiza la conexión de todos los clientes. Deje que los registros decidan.

Lo que muestran los registros	Causa probable	Recomendación	Canales de 20 MHz restantes (ETSI / FCC)
Eventos en varios AP vecinos, concentrados en los canales 120 - 128	Radar meteorológico	Excluir los canales 120, 124 y 128 en los AP afectados	16 / 22
Eventos diarios en la mayoría de los canales DFS en muchos AP	Radar cercano potente	Excluir DFS solo en los AP afectados; mantenerlo activo en los demás	4 / 9 en los AP afectados
Eventos recurrentes en un solo AP, en distintos canales	Falso positivo	Actualizar el firmware, probar o sustituir la radio, mantener DFS	19 / 25
Eventos solo en canales de 80 o 160 MHz	Exposición debida al ancho de canal	Reducir a un ancho de canal de 40 o 20 MHz, mantener DFS	19 / 25
Cambios de canal pero sin registros de radar	Planificador o interferencia	Corregir interferencias y 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 las plantas superiores orientadas al oeste informaban de caídas de conexión 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 del 120 al 128. El equipo trasladó esos 11 AP a un perfil que excluía los canales meteorológicos y fijó un ancho de banda de 40 MHz. Durante las siguientes cuatro semanas, el hotel registró cero eventos de radar. Las quejas sobre el WiFi en la recepción disminuyeron de 14 a dos por semana. Los otros 35 AP conservaron todos los canales DFS. Para más información sobre despliegues en hoteles, consulte Hoteles.

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

Una cadena minorista de 120 tiendas vio cómo una de ellas registraba 30 eventos de radar en quince días en los canales 52, 100 y 116. Los AP vecinos de la misma tienda no registraron ninguno, lo que apuntaba a un falso positivo. Las notas de la versión para ese modelo de AP incluían 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 cayeron a cero y los compradores dejaron de perder las conexiones en la zona de cajas. La propiedad conservó los 19 canales. Consulte Retail para el acceso de invitados en múltiples ubicaciones.

Escenario práctico: oficinas municipales junto a un puerto

Un equipo de TI de un ayuntamiento planeaba desactivar el 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 procedían de la reacción del planificador ante la red de un inquilino vecino. El equipo mantuvo el 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 de DFS vuelvan a molestar a los huéspedes?

• Utilice canales de 20 o 40 MHz en espacios densos. Los canales más estrechos reducen la exposición y facilitan la reutilización.
• Excluya los canales meteorológicos de forma quirúrgica donde se concentren los eventos del 120 al 128, únicamente en los AP afectados.
• Mantenga el firmware actualizado y lea las correcciones de DFS en cada nota de versión.
• Revise los eventos de 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 con 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 gestiona el plan de canales y Purple gestiona el inicio de sesión de invitados. Purple procesó 440 millones de inicios de sesión en más de 80.000 recintos activos en 2024 (datos de Purple).

Preguntas frecuentes

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

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, los consentimientos expresos y los datos de primera mano por encima. No se requiere sustitución de hardware y su configuración de DFS permanece bajo su control.

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

No. Purple no configura los canales de radio, el ancho de banda ni la potencia de transmisión. Esas funciones se gestionan 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. Esta 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 de los invitados, así como cambiar la configuración de inicio de sesión sin modificar la RF.

¿Cumple con la normativa desactivar los canales DFS?

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

¿Necesitamos nuevos puntos de acceso 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 puntos de acceso afectados, reduciendo el ancho del canal o actualizando el firmware. La sustitución tiene sentido cuando una radio sigue produciendo falsos positivos después de una actualización de firmware, o cuando se añade capacidad de 6 GHz. La banda de 6 GHz no tiene requisitos de DFS, por lo que los puntos de acceso WiFi 6E y WiFi 7 eliminan los cambios de radar para los clientes que los soportan.

¿Perjudicará la exclusión de canales DFS al WiFi de invitados en un recinto concurrido?

Sí, si los excluye en todo el recinto. En una región ETSI, cuatro canales de 20 MHz no pueden separar docenas de puntos de acceso en un estadio, centro de conferencias o un gran hotel. Los puntos de acceso acaban compartiendo el tiempo de transmisión y el rendimiento disminuye para todos los invitados. Excluya los canales únicamente en los puntos de acceso que registren radar y mantenga el DFS en todos los demás. Este enfoque acota el problema sin renunciar a la capacidad.

¿Difieren las normas 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 el DFS a los canales del 52 al 64 y del 100 al 140. También exige una comprobación de disponibilidad de 10 minutos en los canales meteorológicos 120, 124 y 128. EE. UU. sigue la norma FCC Parte 15.407, que añade el canal 144 y deja nueve canales que no son DFS. Ambas normativas exigen al menos 30 minutos de no ocupación tras una detección.

¿Puede un MSP diagnosticar eventos DFS en una infraestructura de varios proveedores?

Sí, pero los eventos de radar se registran en las propias herramientas de cada proveedor: el registro de eventos de Meraki, el historial ARM o los eventos AirMatch de Aruba, y los eventos y alarmas de SmartZone. Un MSP debe estandarizar la lista de comprobación en lugar de la herramienta, y registrar la hora, el canal, el número de puntos de acceso 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.