Validar el rendimiento de Wi-Fi: guía de pruebas y supervisión

Introducción

Este documento describe cómo monitorear y resolver problemas de rendimiento en redes Wi-Fi grandes.

Contexto

En las redes Wi-Fi, no hay muchos tipos de usuarios finales que perciban problemas.

Los problemas notificados pueden oscilar entre:

• clientes que no puedan conectarse;
• clientes que se desconectan repentinamente o;
• la velocidad percibida de la aplicación en el dispositivo del usuario no es satisfactoria.

Detrás de estos síntomas simples puede haber cientos de tipos de problemas, la mayoría ni siquiera involucran las redes Wi-Fi reales como problemas de DNS, problemas de conexión a Internet, etc.

Los servidores de gestión como Cisco Catalyst Center ayudan al administrador a solucionar problemas específicos y este artículo no trata en detalle los numerosos tipos de problemas diarios que se pueden ver y solucionar fácilmente a través de Catalyst Center. En su lugar, este documento se centra en la información más vaga de los usuarios finales sobre la lentitud de la red.

¿Cómo probar eso? ¿Cómo se valida el rendimiento real en toda la red? ¿Cómo se pueden clasificar los problemas relacionados con la velocidad en elementos procesables para mejorar la experiencia general del usuario final?

Estas son todas las preguntas que este documento intenta responder.

Definición del rendimiento máximo esperado

La primera pregunta en cada red es: ¿cuál es la velocidad máxima que podría alcanzarse de manera potencial y realista?

Dado que las redes Wi-Fi son un medio compartido, la velocidad que se experimenta depende directamente del número de clientes y dispositivos que utilizan la red Wi-Fi al mismo tiempo en el mismo canal. Por lo tanto, esta cuestión de la velocidad máxima real que se puede alcanzar directamente implica tener un único dispositivo cliente y un único punto de acceso en un lugar aislado y tranquilo donde nadie está utilizando el mismo canal Wi-Fi. En estas condiciones, los factores para determinar la velocidad máxima se reducen a:

• El protocolo Wi-Fi utilizado (Wi-Fi 5, Wi-Fi 6, ...)
• Las capacidades de hardware del cliente y del punto de acceso (número de antenas, número de transmisiones espaciales, conexión Ethernet del punto de acceso, etc.)
• La configuración (ancho de canal, ...)

Conocer estos factores le permite tener una estimación de cuál es el rendimiento máximo en la vida real que podría esperar alcanzar en condiciones de laboratorio.

Para hacerse una idea rápida, debe comprobar a qué velocidad de datos se conectan los informes de sus clientes al punto de acceso. Esta velocidad de datos no es el rendimiento real que puede demostrar en sus pruebas. Esto se debe a que Wi-Fi es un medio semidúplex que tiene cierta sobrecarga de gestión (las tramas deben reconocerse, las balizas deben transmitirse) y también silencios cortos entre las tramas para una mejor recepción y decodificación. Esto significa que, cuando se envían datos, se envían a la velocidad de datos documentada, pero no siempre se envían datos. Las tramas de administración y control se envían a una velocidad de datos mucho más baja para garantizar la recepción. Se calcula que puede plantearse alcanzar del 65 al 70% de la velocidad de datos utilizada en una prueba de rendimiento real. Por ejemplo, si el cliente informa de que está conectado y envía datos a 866 Mbps, las pruebas reales deben notificar una velocidad de transferencia de alrededor de 600 Mbps.

Si conoce los parámetros de configuración en uso, así como las capacidades de hardware de los dispositivos involucrados, también puede averiguar qué velocidad de datos máxima (y, por lo tanto, el rendimiento, mediante el cálculo del porcentaje documentado en esta sección) debe ser alcanzable.

Si hay una discordancia entre la velocidad de datos informada y la que esperaba lograr, puede iniciar el proceso de solución de problemas mediante la configuración y verificar los diversos parámetros para entender dónde está la brecha.

Un ejemplo: si tiene un punto de acceso modelo C9120 que emite a 20 MHz de ancho de canal en la banda de 5 GHz y un típico cliente Wi-Fi 6 de 2 flujos espaciales, puede calcular que, en un entorno de radiofrecuencia (radiofrecuencia) perfectamente limpio, con un solo cliente podría esperar alcanzar de 160 a 200 Mbps en una sola transferencia de archivos.

Para obtener más información sobre las pruebas y la validación del rendimiento, visite https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html.

Establecer la experiencia básica

Es importante saber qué se puede esperar en su emplazamiento en circunstancias típicas. A menudo, un técnico visita el sitio vacío antes de la implementación, realiza pruebas de velocidad y documenta los números esperados.

Luego entran los empleados o los clientes, el sitio se pone ocupado y la experiencia real difiere mucho.

Una vez que se pone en marcha una implementación, es una buena idea enviar técnicos para que midan la experiencia real en cada área y tomen nota del aspecto que tendrá la red en un día normal.

Esto incluye la cantidad media de clientes por radio cuando la red funciona a un nivel satisfactorio, así como el rendimiento medio obtenido con una prueba de velocidad.

Buscar desviaciones de la experiencia

Al utilizar la red, resulta sencillo supervisar las alertas o dispositivos importantes que se desactivan repentinamente. Este documento se centra en la parte difícil: cómo detectar una red inalámbrica que aún funciona pero que proporciona una experiencia de usuario final deficiente.

Encontrar pruebas de un problema (pruebas pasivas)

Usted mismo ha probado su red, sabe que funciona correctamente y está supervisando sus sistemas de gestión y paneles. Nada se informa como abajo: usted puede dar un paso atrás y relajarse. ¿O puedes?

Si espera los ecos de los usuarios finales que se quejan de la mala experiencia, lo más probable es que llegue demasiado tarde. Cuando los usuarios finales se quejan, el problema ha estado sucediendo durante mucho tiempo y solo se oye de los pocos usuarios que fueron lo suficientemente vocales para que usted lo escuche.

Innumerables usuarios ya se han sentido frustrados, no le han dicho nada ni a usted ni a su equipo de soporte técnico, pero han dado una mala reputación a su red.

Entonces, la pregunta es: ¿cómo se pueden detectar los casos de mala experiencia tan pronto como ocurren?

1. Panel de garantía del cliente en Cisco Catalyst Center

En el panel de control de Cisco Catalyst Center Assurance, dispone de un gráfico general del estado de sus clientes.

Siempre hay algunos clientes que no pueden conectarse porque alguien ingresó la clave incorrecta, o el dispositivo está sentado en el borde mismo de su cobertura, así que no espere llegar al 100% de los clientes sanos, pero esté familiarizado con lo que es un buen porcentaje de clientes sanos para su entorno.

Estar en el rango de los 90 es normalmente una buena noticia.

Con una mirada muy rápida se puede ver lo que está sucediendo a los clientes que no son saludables:

• ¿Están lejos del AP (puntos de acceso)?
• ¿Es un problema de autenticación?

Puede ver fácilmente en este gráfico la proporción de cada categoría.

En el mismo rango de ideas, puede desplazarse hasta la parte inferior de esa página y filtrar para mostrar los dispositivos cliente que se informa que tienen un estado de salud deficiente. A continuación, puede intentar detectar si hay algún patrón:

• Potencialmente, todos están conectados en la banda de 2,4 Ghz (lo que se sabe que en muchos casos proporciona una experiencia más pobre);
• Potencialmente, todos ellos se reportan con una potencia de señal baja;
• Potencialmente todos están en la misma área físicamente.

2. El panel de garantía de la red y el dispositivo 360 en Cisco Catalyst Center

Una métrica especialmente adecuada para detectar un área potencial específica de problemas es ir a la página Network Assurance (Garantía de red) de Cisco Catalyst Center. Tiene un widget que muestra los puntos de acceso principales por número de clientes:

Si el punto de acceso superior de la red tiene 40 clientes conectados, está satisfecho. Esto implica que todos los otros AP (puntos de acceso) tienen un número de clientes inferior.

Por otro lado, si encuentra que los AP superiores tienen un número inusualmente alto de clientes, puede hacer una conjetura que la experiencia del cliente allí es particularmente pobre (a menos que la mayoría de los clientes duerman y no estén activos en la red).

A continuación, puede pasar a una investigación "por AP" en la que se amplía la información de los principales AP específicos incluidos en este widget para comprender su estado actual.

Otro método para ver el recuento de clientes es ir a los mapas de la página Jerarquía de red de su Catalyst Center. Una vez en la página de la vista de planta, haga clic en "Ver opciones" y en la sección Puntos de acceso, cambie la visualización a "Asociar. Clientes" para mostrar el recuento de clientes por AP:

La ventaja de la técnica del mapa es que usted puede localizar donde está el AP con el conteo alto del cliente y evaluar si el conteo alto podría ser justificado (puede haber una buena razón para que una muchedumbre se reúna en ese lugar en ese momento dado).

También puede echar un vistazo a los AP vecinos: si comparten parte de la carga, las cosas están bien. Si un AP está teniendo un conteo anormalmente alto de clientes mientras que los AP vecinos no tienen ningún cliente en absoluto, la situación se vuelve más sospechosa.

Podría haber un problema con los AP vecinos (si su conteo de clientes es cero) o el diseño de RF puede hacer que el AP problemático atraiga a todos los clientes en comparación con sus vecinos (por ejemplo, debido a una potencia TX mucho más alta y/o diferentes antenas).

El mapa le da una buena visión general de los clientes asociados en cada AP

Una vez que haya identificado los AP potencialmente problemáticos donde el conteo de clientes es extremadamente alto, puede buscar ese nombre de AP y abrir la página del dispositivo 360.

El gráfico de la salud le da una visión general si la salud para ese AP es mala ahora o si ha sido constantemente mala en el último día o más.

En la misma página, tiene una lista de problemas relacionados con ese AP. En este caso, está claro que ambas radios están experimentando una alta utilización.

El visor de eventos puede darle una idea si ha habido eventos específicos relacionados con ese AP.

Un ejemplo podría ser un algoritmo RRM configurado para ejecutarse con demasiada frecuencia y causar cambios de canales con frecuencia que impactan a los clientes conectados, o una radio que se reinicia constantemente debido a varios problemas o interferencias.

Al final de la página del dispositivo 360, puede establecer la vista en "RF", seleccionar la radio específica y tiene información interesante que le permite evaluar el origen del problema.

Tener muchos clientes no es necesariamente un problema: todo depende de lo activos que sean.

A veces, incluso con unos pocos clientes, el AP podría tener sus manos ocupadas y ofrecer una experiencia pobre. El indicador real es la utilización del canal.

Cuando la utilización del canal se acerca al 100% (incluso a partir del 70%), los clientes comienzan a competir con fuerza por un acceso medio, una latencia de experiencia y colisiones.

Los gráficos le permiten comparar la utilización total del canal y esta parte de responsabilidad del AP en él.

Por ejemplo, si la utilización del canal es del 80%, esto significa que el 80% del tiempo hay "alguien" transmitiendo a través del canal. Si el AP muestra una utilización de Rx del 40% y una utilización de Tx del 40%, usted sabe que solamente este AP es responsable de mantener el canal ocupado (es decir, ningún otro AP está transmitiendo) y está bien equilibrado entre recibido y transmitido. Si la utilización combinada de Rx y Tx de AP está lejos de la utilización del canal, esto implica que otro AP (no autorizado o administrado) está usando el mismo canal y causando interferencia del mismo canal.

Esta captura de pantalla muestra un AP donde el canal está extremadamente ocupado (91%):

El gráfico muestra que solo el 7% de esta utilización se debe a otros AP y fuentes no WiFi y que el AP está ocupado transmitiendo durante el 82% del tiempo y recibiendo durante solo el 2%.

El número de clientes y el rendimiento total indicarían que es probable que uno o más clientes estén descargando archivos de gran tamaño.

El gráfico de interferencias le permite determinar si el canal se mantiene ocupado por transmisiones Wi-Fi o interferencias reales (no Wi-Fi):

Como conclusión, y como regla general, debe cuidar de los AP con el conteo de clientes más alto y la utilización de canales más alta. Entonces debe evaluar si esta carga está justificada o no y si causa una mala experiencia para los usuarios finales en esa área.

3. Análisis de IA

El análisis de IA le proporciona una supervisión más inteligente. La supervisión ya no se basa en umbrales fijos, sino que se adapta al uso previsto.

El mapa de calor de la red le da una evolución del conteo de clientes, para detectar los AP con el conteo de clientes más alto durante la semana. También puede detectar fácilmente los AP que no conectan constantemente a ningún cliente: el problema opuesto también es un problema.

Podría haber un problema físico con estos AP (problema de montaje, problema con las antenas, etc.) o un problema de software si la radio está congelada (y si un reinicio de ese AP lo soluciona).

La página Trends and Insights le brinda una lista de AP que regularmente muestran un alto uso del canal o actividad del cliente para que pueda verificar fácilmente si coincide con sus áreas más concurridas o si hay algo anormal en ellas:

Pruebas activas de la infraestructura

Cuando los usuarios informan de una experiencia deficiente en un área específica, desea probarla de forma activa para confirmar sus comentarios. Es importante comprender que las pruebas típicas varían mucho con respecto al tráfico real de los clientes.

Los usuarios suelen intentar utilizar su aplicación favorita y están contentos si funciona. Rara vez transfieren archivos grandes. Su aplicación favorita podría tener diferentes comportamientos:

• Vídeo a demanda: puede consumir cualquier cantidad de ancho de banda (depende de si el vídeo es de 720p o 4K, por ejemplo).
  • Es muy tolerante a la fluctuación, ya que almacena previamente unos segundos o minutos de vídeo. El patrón parece una transferencia de archivos de gran tamaño durante un breve período y, a continuación, se silencia mientras el vídeo se reproduce desde el búfer hasta la siguiente carga previa.
• Llamada de voz: consume una cantidad insignificante de ancho de banda, pero es extremadamente sensible a la latencia y a la fluctuación.
  • Esto puede utilizar potencialmente el etiquetado de QoS (calidad de servicio) y, por lo tanto, enfrentarse a una experiencia diferente (priorizada) del tráfico de mejor esfuerzo.
• Datos: una aplicación de redes sociales descarga datos por ráfagas.
  • La cantidad varía en función del contenido y de la rapidez con la que se desplaza el usuario.

Una aplicación de prueba de rendimiento típica maximiza el protocolo para lograr la mayor velocidad de transferencia posible: intenta reservar el medio y enviar tantas tramas de datos concatenadas como sea posible. Esto no representa el mismo tipo de uso que las aplicaciones de la vida real (aparte de las transferencias de archivos) que están muy saturadas por naturaleza.

La prueba de aplicaciones de la vida real imita los comportamientos de los usuarios, pero hace que sea imposible obtener métricas y números reales para comparar. Solo se tiene una sensación subjetiva si la red es fluida o no.

Para las pruebas de rendimiento, muchos sitios web son populares y ofrecen una imagen decente de la experiencia del usuario final, ya que prueban todo el ancho de banda entre el cliente e Internet. Sin embargo, si desea validar la red inalámbrica por separado de la conexión a Internet y de los problemas de routing y firewall, se recomienda utilizar una herramienta de prueba de rendimiento dedicada como Iperf: https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047.

Esta herramienta permite realizar pruebas específicas entre un cliente y un servidor que se coloca en la red. Esto le permite mover el servidor a lugares específicos de la red y probar el rendimiento en secciones de red cada vez más largas para validar cada sección. Comience colocando el servidor Iperf en el mismo switch que el AP donde se encuentra su cliente inalámbrico en caso de conmutación local o inalámbrico habilitado para entramado o en el mismo switch que el WLC (controlador de LAN inalámbrica) (y en la VLAN del cliente si es posible) en caso de conmutación central.

Si está utilizando un WLC de anclaje, debe colocar el servidor Iperf en el mismo switch que el WLC de anclaje ya que es donde se termina el tráfico. A veces puede ser interesante crear una WLAN no anclada (LAN inalámbrica) para ver si los resultados de rendimiento potencialmente decepcionantes son causados por el propio anclaje frente a una WLAN no anclada.

En realidad no tiene sentido utilizar varios clientes para realizar pruebas de rendimiento al mismo tiempo. Durante las pruebas de rendimiento, se espera que este único cliente utilice la totalidad del tiempo de transmisión del canal disponible. Por lo tanto, si dos clientes realizan una prueba de rendimiento al mismo tiempo, cada uno verá un resultado dividido al menos por la mitad. Si se utilizan más clientes, las colisiones comienzan a ocurrir en números y los resultados ya no son representativos.

Existen varias herramientas de ^terceros para automatizar las pruebas de red. Tenga en cuenta que, mientras se prueba el rendimiento en un área, se utiliza de forma eficaz todo el tiempo de transmisión durante toda la prueba y, por tanto, no es buena idea probar la red con demasiada frecuencia, ya que es perjudicial para otros clientes.

Solución de problemas de rendimiento

Cuando se identifica un problema de rendimiento, hay varias cosas que se pueden considerar para aislar el problema:

• Aislar si, antes de iniciar la prueba, el entorno de RF ya está ocupado. Cuanto mayor sea la utilización del canal (fuera de la prueba), menor será el resultado de la prueba de rendimiento. Si se identifica un problema de utilización del canal, verifique si otros AP están presentes en la misma área en el mismo canal y reconsidere su diseño de RF. Reducir el ancho de los canales, eliminar los accesos no deseados y utilizar antenas diferentes con una cobertura más centrada son buenas opciones. Agregar más AP no es siempre la mejor idea.
• Obtenga una captura de la prueba de rendimiento y vea si hay muchos reintentos de datos en una capa 802.11 (en porcentaje de todas las tramas de datos). Un alto número de reintentos significa que el entorno de RF es potencialmente el problema. Compruebe también qué velocidades de datos se utilizan, qué protocolo potencialmente no es óptimo o el número de flujos espaciales que se están utilizando. Una transferencia de datos grande es muy característica en una captura por aire, se ven docenas de tramas de datos con el mismo origen y destino y con un tiempo delta excesivamente pequeño entre sí seguido de un bloque ACK. Si la transferencia se caracteriza por un ACK regular después de cada trama de datos, o una gran cantidad de petición de envío/despejada de envío, el bajo rendimiento se puede explicar fácilmente.
• Verifique si el problema de rendimiento ocurre con todos los tipos de seguridad en la WLAN. A veces, una incompatibilidad de seguridad específica entre el cliente y el AP puede conducir a un rendimiento pobre.