Validar las pruebas de validación y rendimiento inalámbrico de 802.11ax

Introducción

Este documento describe la manera de probar el rendimiento inalámbrico de un punto de acceso centrado en 802.11ax y qué rendimiento se puede esperar.

Prerequisites

Requirements

En este documento se presupone que ya hay una configuración en funcionamiento con puntos de acceso (AP) 802.11ax / Wi-Fi 6 que ya proporciona conectividad al cliente

Componentes Utilizados

La información de este documento se centra en la tecnología y las velocidades 802.11ax/Wi-Fi 6.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Comprender

Wi-Fi 6 puede funcionar en varias bandas: 2,4 Ghz, 5 Ghz e incluso en la banda de 6 Ghz, según la certificación Wi-Fi 6E.

802.11ac se produjo en dos fases. La segunda oleada incluyó el soporte de canal de 160 Mhz, junto con MU-MIMO y un máximo teórico de 8 flujos espaciales.

Estos números son solo los números teóricos del estándar, las diferencias se aplican dependiendo de la hoja de datos AP específica.

802.11ax no está definido directamente en velocidades de velocidad de datos, sino que es una combinación del esquema de codificación de modulación de 12 (MCS 0 a MCS 11), un ancho de canal que va desde 20 mhz (1 canal) a 160 Mhz (8 canales), un número de flujos espaciales (normalmente de 1 a 2, ha habido unos 3 productos de flujos espaciales, pero se ven cada vez menos).

El intervalo de protección (GI) corto, medio o largo también añade una modificación del 10%.

Esta es una tabla para evaluar una velocidad de datos en Mbps cuando se conocen todos esos factores :

Puede encontrar una tabla más completa en: https://mcsindex.com/

Nota: La velocidad de datos NO es igual al rendimiento esperado alcanzable. Esto está relacionado con la naturaleza del estándar 802.11, que tiene una gran cantidad de sobrecarga administrativa (tramas de gestión, contención, colisión, reconocimientos,...) y puede depender del SNR de enlace, RSSI y otros factores significativos.

Es una regla general:

Rendimiento esperado = Velocidad de datos x 0,65

Tomemos un ejemplo real. Un Cisco 9120 AP con un moderno smartphone compatible con Wi-Fi 6 que puede admitir 2 flujos espaciales. Si estamos en un entorno de alta densidad donde se utilizan canales de 20 Mhz, la velocidad máxima de datos utilizada es de entre 240 y 280 Mbps, dependiendo del intervalo de protección. Esto significa que, en un entorno limpio y en condiciones de prueba, podríamos tener un cliente que transfiriera datos entre 160 y 200 Mbps, posiblemente (entre el 65 y el 70% de la eficacia del protocolo). Esto solo es válido cuando se realiza una prueba de transferencia o velocidad real grande donde el protocolo está optimizado para el rendimiento máximo de datos. Cuando se utilizan otras aplicaciones, el rendimiento disminuye, ya que la latencia también desempeña un papel en los protocolos que realizan un ping-pong de paquetes y esperan las confirmaciones antes de avanzar.

Tenga en cuenta también que la red inalámbrica es un entorno compartido, esto significa que la cantidad de clientes conectados al AP están compartiendo el rendimiento efectivo entre sí. Si un cliente que realiza una prueba de velocidad puede alcanzar entre 160 y 200 MBps, esto significa que dos clientes que realizan una prueba de velocidad al mismo tiempo ven cada 80 a 100 Mbps. Si cuatro clientes realizan una prueba de velocidad al mismo tiempo, verán de 40 a 50 Mbps cada uno, etc.

Además de eso, más clientes significan más contención e inevitablemente más colisión. La eficacia de la celda de cobertura disminuye drásticamente a medida que aumenta el número de clientes. Por lo tanto, no es realista establecer ningún tipo de SLA para el rendimiento en lugares donde no se controla la cantidad de clientes conectados o lo que están haciendo en la red en términos de actividad.

Medida

En términos generales, podemos tener dos escenarios cuando se realiza una prueba de rendimiento:

• Los AP están en el switching local Flexconnect

• Los AP están en modo local o conmutación central Flexconnect

Tomen esos escenarios uno por uno:

(Diagrama 1)

En el caso del Diagrama 1, suponemos que los AP están en el modo local de conmutación central Flexconnect.

Esto significa que todo el tráfico del cliente se encapsula en el túnel CAPWAP y termina en el WLC.

(Diagrama 2)

La línea roja del diagrama 2 muestra el flujo de tráfico del cliente inalámbrico.

El servidor iPerf debe estar lo más cerca posible del punto de terminación del tráfico, idealmente conectado en el mismo switch que el propio WLC y utilizar la misma VLAN.

En el caso de la conmutación local Flexconnect, el tráfico del cliente se termina en el AP mismo, y considerando que el servidor iPerf debe configurarse lo más cerca posible del punto de terminación del tráfico del cliente inalámbrico, conecte el servidor iPerf al mismo switch y a la misma VLAN donde está conectado el AP.

En nuestro caso se trata del switch de acceso (Diagrama 3).

(Diagrama 3)

Las pruebas iPerf se pueden subdividir en dos categorías: ascendente y descendente.

Teniendo en cuenta que el servidor iPerf está escuchando y que el cliente iPerf está generando el tráfico, cuando el servidor iPerf está en el lado cableado, esto se considera una prueba ascendente.

El cliente inalámbrico utiliza la aplicación iPerf para dirigir el tráfico a la red.

La prueba de flujo descendente es viceversa, lo que significa que el servidor iPerf está configurado en el propio cliente inalámbrico y que el cliente iPerf está en el lado cableado que envía el tráfico al cliente inalámbrico; en este escenario, esto se considera flujo descendente.

La prueba se debe realizar mediante TCP y UDP. Puede utilizar estos comandos para realizar las pruebas:

iperf3 -s  <- this command starts iPerf server

iperf3 -c SERVER_ADDRESS -u -b700M <- this command initiates UDP iPerf test with bandwidth of 700 Mbps

iperf3 -c SERVER_ADDRESS <- this command initiates a simple TCP iPerf test

iperf3 -c SERVER_ADDRESS  -w WINDOW_SIZE  -P NUM_OF_PARALLEL_TCP_STREAMS <- this commands initiates a more complex  TCP iPerf test where you can adjust the window size as well the number of parallel TCP streams. 
Please not that in this case you should consider the sum of all the streams as the result

 

Ejemplo de salidas iPerf3:

Rendimiento de TCP 3:

 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec   188 MBytes   157 Mbits/sec                  receiver
 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.05  sec   304 MBytes   254 Mbits/sec                  receiver

   With 10 parallel TCP streams:
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec  88.6 MBytes  73.9 Mbits/sec                  receiver
[  7]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  7]   0.00-10.06  sec  79.2 MBytes  66.0 Mbits/sec                  receiver
[  9]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  9]   0.00-10.06  sec  33.6 MBytes  28.0 Mbits/sec                  receiver
[ 11]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 11]   0.00-10.06  sec  48.7 MBytes  40.6 Mbits/sec                  receiver
[ 13]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 13]   0.00-10.06  sec  77.0 MBytes  64.2 Mbits/sec                  receiver
[ 15]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 15]   0.00-10.06  sec  61.8 MBytes  51.5 Mbits/sec                  receiver
[ 17]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 17]   0.00-10.06  sec  46.1 MBytes  38.4 Mbits/sec                  receiver
[ 19]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 19]   0.00-10.06  sec  43.9 MBytes  36.6 Mbits/sec                  receiver
[ 21]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 21]   0.00-10.06  sec  33.3 MBytes  27.8 Mbits/sec                  receiver
[ 23]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 23]   0.00-10.06  sec  88.8 MBytes  74.0 Mbits/sec                  receiver
[SUM]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[SUM]   0.00-10.06  sec   601 MBytes   501 Mbits/sec                  receiver
 

UDP iPerf3:

Al utilizar UDP, es importante asegurarse de que no haya una pérdida mínima de paquetes. Es posible ver cifras de rendimiento muy altas, pero si tiene una pérdida de paquetes del 50%, en realidad no transfirió esa cantidad de datos.

A veces, iPerf se comporta mal y no proporciona el ancho de banda promedio al final de la prueba UDP.

Todavía es posible resumir el ancho de banda para cada segundo y luego dividirlo por número de segundos:

Accepted connection from 192.168.240.38, port 49264
[  5] local 192.168.240.43 port 5201 connected to 192.168.240.38 port 51711
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  53.3 MBytes   447 Mbits/sec  0.113 ms  32/6840 (0.47%)  
[  5]   1.00-2.00   sec  63.5 MBytes   533 Mbits/sec  0.129 ms  29/8161 (0.36%)  
[  5]   2.00-3.00   sec  69.8 MBytes   586 Mbits/sec  0.067 ms  30/8968 (0.33%)  
[  5]   3.00-4.00   sec  68.7 MBytes   577 Mbits/sec  0.071 ms  29/8827 (0.33%)  
[  5]   4.00-5.00   sec  68.0 MBytes   571 Mbits/sec  0.086 ms  55/8736 (0.63%)  
[  5]   5.00-6.00   sec  68.6 MBytes   576 Mbits/sec  0.076 ms  70/8854 (0.79%)  
[  5]   6.00-7.00   sec  66.8 MBytes   561 Mbits/sec  0.073 ms  34/8587 (0.4%)  
[  5]   7.00-8.00   sec  67.1 MBytes   563 Mbits/sec  0.105 ms  44/8634 (0.51%)  
[  5]   8.00-9.00   sec  66.7 MBytes   559 Mbits/sec  0.183 ms  144/8603 (1.7%)  
[  5]   9.00-10.00  sec  64.1 MBytes   536 Mbits/sec  0.472 ms  314/8415 (3.7%)  
[  5]  10.00-10.05  sec   488 KBytes  76.0 Mbits/sec  0.655 ms  2/63 (3.2%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec  0.655 ms  783/84688 (0.92%)  
[SUM]  0.0-10.1 sec  224 datagrams received out-of-order

Nota: Se espera que los resultados de iPerf sean ligeramente mejores en el switching local Flexconnect en comparación con el escenario de switching central.
Esto se debe al hecho de que el tráfico del cliente se encapsula en CAPWAP, que agrega más sobrecarga al tráfico y en general el WLC actúa como un cuello de botella ya que es el punto de agregación para todo el tráfico de clientes inalámbricos.
Además, se espera que la prueba UDP iPerf dé mejores resultados en un entorno limpio, ya que es el método de transferencia más eficiente cuando la conexión es confiable. TCP, sin embargo, puede ganar en caso de fragmentación pesada (cuando se utiliza MSS de ajuste de TCP) o de conexión no confiable

.

Verificar y validar

Para verificar a qué velocidad de datos el cliente está conectado, ejecute estos comandos en WLC CLI:

WLC#show wireless client mac e88d.a6b0.3bca det

Client MAC Address : e88d.a6b0.3bca
Client MAC Type : Universally Administered Address
Client DUID: NA
Client IPv4 Address : 192.168.1.44
Client IPv6 Addresses : fe80::7798:a5a:a957:ec89
Client Username: N/A
AP MAC Address : 18f9.354d.9d60
AP Name: 9164-etage
AP slot : 1
Client State : Associated
Policy Profile : Darchispp
Flex Profile : default-flex-profile
Wireless LAN Id: 2
WLAN Profile Name: Darchis6
Wireless LAN Network Name (SSID): Darchis6
BSSID : 18f9.354d.9d6f
Connected For : 103 seconds
Protocol : 802.11ax - 5 GHz
Channel : 52
Client IIF-ID : 0xa0000003
Association Id : 2
Authentication Algorithm : Open System
Idle state timeout : N/A
Session Timeout : 80000 sec (Remaining time: 79899 sec)
Session Warning Time : Timer not running
Input Policy Name  : None
Input Policy State : None
Input Policy Source : None
Output Policy Name  : None
Output Policy State : None
Output Policy Source : None
WMM Support : Enabled
U-APSD Support : Disabled
Fastlane Support : Disabled
Client Active State : Active
Power Save : ON
Current Rate : m10 ss2
Supported Rates : 54.0
AAA QoS Rate Limit Parameters:
  QoS Average Data Rate Upstream             :  (kbps)
  QoS Realtime Average Data Rate Upstream    :  (kbps)
  QoS Burst Data Rate Upstream               :  (kbps)
  QoS Realtime Burst Data Rate Upstream      :  (kbps)
  QoS Average Data Rate Downstream           :  (kbps)
  QoS Realtime Average Data Rate Downstream  :  (kbps)
  QoS Burst Data Rate Downstream             :  (kbps)
  QoS Realtime Burst Data Rate Downstream    :  (kbps)
Mobility:
  Move Count                  : 0
  Mobility Role               : Local
  Mobility Roam Type          : None
  Mobility Complete Timestamp : 02/26/2024 14:35:10 Central
Client Join Time:
  Join Time Of Client : 02/26/2024 14:35:10 Central
Client State Servers : None
Client ACLs : None
Policy Manager State: Run
Last Policy Manager State : IP Learn Complete
Client Entry Create Time : 103 seconds
Policy Type : WPA3
Encryption Cipher : CCMP (AES)
Authentication Key Management : FT-SAE
AAA override passphrase : No
SAE PWE Method : Hash to Element(H2E)
Transition Disable Bitmap : None
User Defined (Private) Network : Disabled
User Defined (Private) Network Drop Unicast : Disabled
Encrypted Traffic Analytics : No
Protected Management Frame - 802.11w : Yes
EAP Type : Not Applicable
VLAN Override after Webauth : No
VLAN : default
Multicast VLAN : 0
VRF Name : N/A
WiFi Direct Capabilities:
  WiFi Direct Capable           : No
Central NAT : DISABLED
Session Manager:
  Point of Attachment : capwap_90000002
  IIF ID             : 0x90000002
  Authorized         : TRUE
  Session timeout    : 80000
  Common Session ID: 00000000000041B8E5D75432
  Acct Session ID  : 0x00000000
  Auth Method Status List
  	Method : FT-SAE
  Local Policies:
  	Service Template : wlan_svc_Darchispp (priority 254)
  		VLAN             : 1
  		Absolute-Timer   : 80000
  Server Policies:
  Resultant Policies:
  		VLAN Name        : default
  		VLAN             : 1
  		Absolute-Timer   : 80000
DNS Snooped IPv4 Addresses : None
DNS Snooped IPv6 Addresses : None
Client Capabilities
  CF Pollable : Not implemented
  CF Poll Request : Not implemented
  Short Preamble : Not implemented
  PBCC : Not implemented
  Channel Agility : Not implemented
  Listen Interval : 0
Fast BSS Transition Details :
  Reassociation Timeout : 20
11v BSS Transition : Implemented
11v DMS Capable : No
QoS Map Capable : No
FlexConnect Data Switching : Local
FlexConnect Dhcp Status : Local
FlexConnect Authentication : Local
Client Statistics:
  Number of Bytes Received from Client : 64189
  Number of Bytes Sent to Client : 85831
  Number of Packets Received from Client : 808
  Number of Packets Sent to Client : 244
  Number of Data Retries : 66
  Number of RTS Retries : 0
  Number of Tx Total Dropped Packets : 0
  Number of Duplicate Received Packets : 0
  Number of Decrypt Failed Packets : 0
  Number of Mic Failured Packets : 0
  Number of Mic Missing Packets : 0
  Number of Policy Errors : 0
  Radio Signal Strength Indicator : -41 dBm
  Signal to Noise Ratio : 52 dB
Fabric status : Disabled
Radio Measurement Enabled Capabilities
  Capabilities: None
Client Scan Report Time : Timer not running
Client Scan Reports
Assisted Roaming Neighbor List
Nearby AP Statistics:
EoGRE : Pending Classification
Device Classification Information:
  Device Type      : Un-Classified Device
  Device Name      : Unknown Device
  Protocol Map     : 0x000001  (OUI)
Max Client Protocol Capability:
WiFi to Cellular Steering : Not implemented
Cellular Capability : N/A
Advanced Scheduling Requests Details:
  Apple Specific Requests(ASR) Capabilities/Statistics:
    Regular ASR support: DISABLED

Puede ver que este cliente en particular está conectado a estas velocidades:

Velocidad actual..................................... m10 ss2

Lo que significa que el cliente está utilizando el índice MCS 10 (m10) en 2 flujos espaciales (ss2)

Desde el comando "show wireless client mac <MAC> det", no es posible ver si el cliente está conectado en la vinculación de canales de 20/40/80 MHz.

Esto se puede hacer directamente en el AP:

9164 ejemplo:

#show controllers dot11Radio 2 client E8:8D:A6:B0:3B:CA
              mac radio vap aid state       encr  Maxrate Assoc   Cap is_wgb_wired      wgb_mac_addr
E8:8D:A6:B0:3B:CA     2   0  33   FWD AES_CCM128 MCS112SS HE-6E HE-6E        false 00:00:00:00:00:00
Configured rates for client E8:8D:A6:B0:3B:CA
Legacy Rates(Mbps): 6 9 12 18 24 36 48 54
HE Rates: 1SS:M0-11 2SS:M0-11
HT:yes     VHT:no     HE:yes     40MHz:no     80MHz:yes     80+80MHz:no     160MHz:yes
11w:yes     MFP:no     11h:no     session_timeout: 79950     encrypt_policy: 4
_wmm_enabled:yes     qos_capable:yes     WME(11e):no     WMM_MIXED_MODE:no
short_preamble:no     short_slot_time:no     short_hdr:no     SM_dyn:no
short_GI_20M:no     short_GI_40M:no     short_GI_80M:no     LDPC:no     AMSDU:yes     AMSDU_long:no
su_mimo_capable:no     mu_mimo_capable:no     is_wgb_wired:no     is_wgb:no
HE_DL-MIMO:yes     HE_UL-MIMO:yes     HE_DL-OFDMA:yes     HE_UL-OFDMA:yes     HE_TWT_CAPABLE:no

Additional info for client E8:8D:A6:B0:3B:CA
RSSI: -52
SNR: 41
PS  : Legacy (Sleeping)
Tx Rate: 1297100 Kbps
Rx Rate: 1921600 Kbps
VHT_TXMAP: 0
CCX Ver: 0
Rx Key-Index Errs: 0

Statistics for client E8:8D:A6:B0:3B:CA
              mac   intf TxData TxMgmt TxUC TxBytes TxFail TxDcrd TxCumRetries RxData RxMgmt RxBytes RxErr                      TxRt(Mbps) RxRt(Mbps) idle_counter stats_ago expirat
ion
E8:8D:A6:B0:3B:CA apr2v0    391      4  391  129127      0      0           97    559      4   74055     0 HE-160,2SS,MCS6,GI0.8 ,BF(1297)         12          295  8.674000      79
950

Per TID packet statistics for client E8:8D:A6:B0:3B:CA
Priority Rx Pkts Tx Pkts Rx(last 5 s) Tx (last 5 s)
       0     539     383           84            28
       1       0       0            0             0
       2       0       2            0             0
       3       0       0            0             0
       4       0       0            0             0
       5       0       0            0             0
       6      20       3            5             1
       7       0       3            0             0

 Rate Statistics:
Rate-Index    Rx-Pkts    Tx-Pkts Tx-Retries
         0        176          3          0
         5          0         62          0
         6          4        178         21
         7        250        152         52
         8        100          2         22
         9         51          0          0
        10          1          0          0
        11          0          0          2
webauth done: true
Pre-WebAuth ACLs:
Post-Auth ACLs:
Acl name Quota Bytes left In bytes Out bytes In pkts Out pkts Drops-in Drops-out
iPSK TAG: \<0000000000000000>
              MAC Allow HIT iPSK tag
E8:8D:A6:B0:3B:CA  true   0      \<>

La última opción para verificar la velocidad conectada es capturas OTA. En la información de radio del paquete de datos, puede encontrar la información necesaria:

 Esta captura de OTA se realizó con un cliente de MacBook 11ac.

Troubleshoot

En caso de que no obtenga los resultados esperados durante la prueba, hay varias formas de resolver el problema y recopilar la información necesaria antes de abrir un caso TAC.

Los problemas de rendimiento pueden deberse a lo siguiente:

-Cliente

-AP

- Ruta cableada (problemas relacionados con el switching)

- WLC

Troubleshooting del cliente

• El primer paso consistirá en actualizar los controladores de los dispositivos cliente inalámbricos a la última versión
• El segundo paso consistirá en realizar la prueba de iPerf con clientes que tienen un adaptador inalámbrico diferente para ver si obtiene los mismos resultados

Troubleshooting de AP

Puede haber escenarios cuando el AP está descartando tráfico, o ciertas tramas o se comporta mal de otra manera.

Para obtener más información sobre esto, se necesitan capturas Over The Air (OTA) + sesión span en el puerto de switch AP (el span se debe realizar en el switch donde está conectado el AP)

Las capturas de OTA y SPAN se deben realizar durante la prueba, utilizando SSID abierto para poder ver el tráfico que pasa al AP y el AP de tráfico que pasa hacia el cliente y viceversa.

Existen varios errores conocidos para este comportamiento:

CSCvg07438 : AP3800: Bajo rendimiento debido a caídas de paquetes en AP en paquetes fragmentados y no fragmentados

CSCva58429 : Cisco 1532i AP: bajo rendimiento (switching local FlexConnect + EoGRE)

Troubleshooting de trayecto cableado

Puede haber algunos problemas en el switch en sí, debe verificar la cantidad de caídas en las interfaces y si éstas aumentan durante las pruebas.

Intente utilizar otro puerto en el switch para conectar el AP o el WLC.

Otra opción es conectar un cliente al mismo switch (donde el punto de terminación del cliente [AP/WLC] está conectado) y ponerlo en la misma VLAN, luego ejecutar las pruebas cableadas a cableadas en la misma VLAN para ver si hay algún problema en la trayectoria cableada.

Troubleshooting de WLC

Puede ser que el WLC esté descartando el tráfico (cuando los AP están en el modo local) del cliente.

Puede poner el AP en el modo Flexconnect y el WLAN en el switching local, luego ejecutar las pruebas.

Si usted ve que hay diferencias significativas en el rendimiento en el modo local (conmutación central) comparado con la conmutación local de Flexconnect y no hay ningún problema en el switch conectado al WLC, entonces lo más probable es que el WLC esté descartando el tráfico.

Para solucionar este problema, aplique el plan de acción:

- Capturas SPAN en el puerto de switch WLC (se debe hacer en el switch)

- Capturas SPAN en el puerto AP

- Capturas OTA del cliente

Al realizar esta solución de problemas y proporcionar los resultados al TAC, se acelera el proceso de solución de problemas.