Validar teste de validação e rendimento sem fio 802.11ax

Introdução

Este documento descreve a forma de testar a taxa de transferência sem fio de um access point com foco em 802.11ax e qual taxa de transferência esperar.

Pré-requisitos

Requisitos

Este documento pressupõe uma configuração já em funcionamento com access points (APs) 802.11ax / Wi-Fi 6, fornecendo conectividade de cliente já

Componentes Utilizados

As informações neste documento estão focadas na tecnologia 802.11ax/Wi-Fi 6 e suas velocidades.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Entender

O Wi-Fi 6 pode operar em várias bandas: 2,4 Ghz, 5 Ghz e até mesmo na banda 6 Ghz, de acordo com a certificação Wi-Fi 6E.

802.11ac veio em duas ondas. A segunda onda trouxe o suporte de canal de 160 MHz, junto com MU-MIMO e um máximo teórico de 8 fluxos espaciais.

Esses números são apenas os números teóricos do padrão, as diferenças se aplicam dependendo da folha de dados específica do AP.

802.11ax não é diretamente definido em velocidades de taxas de dados, mas é uma combinação de 12 esquema de codificação de modulação (MCS 0 a MCS 11), uma largura de canal que varia de 20mhz (1 canal) a 160Mhz (8 canais), um número de fluxos espaciais (tipicamente 1 a 2, houve alguns 3 produtos de fluxos espaciais, mas eles são vistos cada vez menos).

O Intervalo de Guarda (GI) curto, médio ou longo também adiciona cerca de 10% de modificação a isso.

Esta é uma tabela para avaliar uma taxa de dados em Mbps quando conhecer todos esses fatores:

Uma tabela mais completa pode ser encontrada em: https://mcsindex.com/

Observação: a taxa de dados NÃO é igual ao throughput alcançável esperado. Isso está relacionado à natureza do padrão 802.11, que tem muita sobrecarga administrativa (quadros de gerenciamento, contenção, colisão, confirmações,...) e pode depender do link SNR, RSSI e outros fatores significativos.

É uma regra prática:

Throughput esperado = Taxa de dados x 0,65

Tome um exemplo real. Um AP Cisco 9120 com um smartphone moderno com capacidade Wi-Fi 6, capaz de 2 fluxos espaciais. Se estivermos em um ambiente de alta densidade onde canais de 20 Mhz são usados, a taxa de dados máxima usada é entre 240 e 280 Mbps, dependendo do intervalo de guarda. Isso significa que, em um ambiente limpo e condições de teste, poderíamos ter um cliente transferindo dados entre 160 e 200 Mbps possivelmente (65 a 70% de eficiência do protocolo). Isso só é válido quando se faz uma transferência grande real ou um teste de velocidade em que o protocolo é otimizado para throughput máximo de dados. Ao usar outros aplicativos, o throughput cai à medida que a latência também desempenha um papel nos protocolos que fazem um ping-pong de pacotes e esperam por confirmações antes de prosseguir.

Observe também que o ambiente sem fio é compartilhado, isso significa que a quantidade de clientes conectados ao AP está compartilhando o throughput efetivo entre si. Se um cliente que estiver fazendo um teste de velocidade puder alcançar entre 160 e 200 MBps, isso significa que dois clientes que estiverem fazendo um teste de velocidade ao mesmo tempo verão cada um de 80 a 100 Mbps. Se quatro clientes fizerem um teste de velocidade ao mesmo tempo, eles verão de 40 a 50 Mbps cada e assim por diante...

Além disso, mais clientes significam mais contenção e, inevitavelmente, mais colisão. A eficiência da célula de cobertura diminui drasticamente à medida que o número de clientes aumenta. Portanto, é irrealista definir qualquer tipo de SLA para produtividade em locais onde você não controla a quantidade de clientes conectados ou o que eles estão fazendo na rede em termos de atividade.

Medir

De modo geral, podemos ter dois cenários quando você faz um teste de throughput:

• Os APs estão na comutação local Flexconnect

• Os APs estão no modo local ou no switching central Flexconnect

Siga esses cenários um por um:

(Diagrama 1)

No caso do Diagrama 1, supomos que os APs estão no modo local de switching central Flexconnect.

Isso significa que todo o tráfego do cliente é encapsulado no túnel CAPWAP e encerrado na WLC.

(Diagrama 2)

A linha vermelha no diagrama 2 mostra o fluxo de tráfego do cliente sem fio.

O servidor iPerf deve estar o mais próximo possível do ponto de terminação de tráfego, idealmente conectado ao mesmo switch que a própria WLC e usar a mesma VLAN.

No caso do switching local do Flexconnect, o tráfego do cliente é terminado no próprio AP e, considerando que o servidor iPerf deve ser configurado o mais próximo possível do ponto de término do tráfego do cliente sem fio, conecte o servidor iPerf ao mesmo switch e à mesma VLAN onde o AP está conectado.

No nosso caso, trata-se de um switch de acesso (Figura 3).

(Diagrama 3)

Os testes de iPerf podem ser subdivididos em duas categorias: upstream e downstream.

Considerando que o servidor iPerf está escutando e que o cliente iPerf está gerando o tráfego, quando o servidor iPerf está no lado com fio, isso é considerado um teste de upstream.

O cliente sem fio está usando a aplicação iPerf para enviar o tráfego para a rede.

O teste de downstream é vice-versa, significando que o servidor iPerf está definido no próprio cliente sem fio e o cliente iPerf está no lado com fio enviando o tráfego para o cliente sem fio, nesse cenário, isso é considerado downstream.

O teste deve ser feito usando TCP e UDP. Você pode usar estes comandos para executar os testes:

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

 

Exemplo de saídas de iPerf3:

TCP iPerf3:

 
[ 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:

Ao usar o UDP, é importante certificar-se de que não haja pouca perda de pacotes. É possível ver números de throughput muito altos, mas se você tiver 50% de perda de pacotes, não transferiu realmente essa quantidade de dados.

Às vezes, o iPerf não se comporta corretamente e não fornece a largura de banda média no final do teste de UDP.

Ainda é possível somar a Largura de Banda para cada segundo e dividi-la pelo 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

Observação: espera-se que os resultados de iPerf sejam um pouco melhores no switching local do Flexconnect em comparação com o cenário de switching central.
Isso é causado pelo fato de que o tráfego do cliente é encapsulado no CAPWAP, o que adiciona mais sobrecarga ao tráfego e, em geral, o WLC age como um gargalo, pois é o ponto de agregação para todo o tráfego de clientes sem fio.
Além disso, espera-se que o teste UDP iPerf dê melhores resultados em um ambiente limpo, pois é o método de transferência mais eficiente quando a conexão é confiável. O TCP, no entanto, pode vencer em caso de fragmentação pesada (quando o TCP Adjust MSS é usado) ou conexão não confiável

.

Verificar e validar

Para verificar em que taxa de dados o cliente está conectado, execute estes comandos na CLI da WLC:

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

Você pode ver que este cliente específico está conectado a estas taxas:

Taxa de corrente..................................... m10 ss2

O que significa que o cliente está usando o índice MCS 10 (m10) em 2 fluxos espaciais (ss2)

A partir do comando "show wireless client mac <MAC> det", não é possível ver se o cliente está conectado em uma combinação de canais de 20/40/80 MHz.

Isso pode ser feito diretamente no AP:

9164 exemplo:

#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      \<>

A última opção para verificar a taxa conectada são as capturas OTA. Nas informações de rádio do pacote de dados, você pode encontrar as informações necessárias:

 Esta captura OTA foi feita com um cliente de macbook 11ac.

Troubleshooting

Caso você não esteja obtendo os resultados esperados durante o teste, há várias maneiras de solucionar o problema e coletar as informações necessárias antes de abrir um caso de TAC.

Os problemas de throughput podem ser causados por:

-Cliente

-AP

- Caminho com fio (problemas relacionados a switching)

- WLC

Solução de problemas do cliente

• A primeira etapa será atualizar os drivers nos dispositivos clientes sem fio para a versão mais recente
• A segunda etapa será fazer o teste de iPerf com clientes que têm um adaptador sem fio diferente para ver se você obtém os mesmos resultados

Troubleshooting de AP

Pode haver situações em que o AP esteja descartando tráfego, determinados quadros ou com comportamento incorreto.

Para obter mais informações sobre isso, são necessárias capturas Over The Air (OTA) + sessão de span na porta do switch do AP (span deve ser feito no switch onde o AP está conectado)

As capturas OTA e SPAN devem ser feitas durante o teste, usando o SSID aberto para poder ver o tráfego passado para o AP e o AP de tráfego está passando para o cliente e vice-versa.

Há vários bugs conhecidos para esse comportamento:

CSCvg07438 : AP3800: baixo throughput devido a quedas de pacotes no AP em pacotes fragmentados e não fragmentados

CSCva58429: AP Cisco 1532i: baixo rendimento (switching local FlexConnect + EoGRE)

Solução de problemas de caminho com fio

Pode haver alguns problemas no próprio switch, você precisa verificar a quantidade de quedas nas interfaces e se elas aumentam durante os testes.

Tente usar outra porta no switch para conectar o AP ou a WLC.

Outra opção é conectar um cliente ao mesmo switch (ao qual o ponto de terminação do cliente [AP/WLC] está conectado) e colocá-lo na mesma VLAN e, em seguida, executar os testes com fio na mesma VLAN para ver se há algum problema no caminho com fio.

Troubleshooting de WLC

Pode ser que a WLC esteja descartando o tráfego (quando os APs estão no modo local) do cliente.

Você pode colocar o AP no modo Flexconnect e a WLAN na comutação local, depois executar os testes.

Se você observar que há diferenças significativas no throughput no modo local (switching central) em comparação com o switching local do Flexconnect e não há nenhum problema no switch conectado ao WLC, provavelmente o WLC está descartando o tráfego.

Para solucionar esse problema, aplique o plano de ação:

- Capturas de SPAN na porta do switch da WLC (deve ser feito no switch)

- Capturas de SPAN na porta do AP

- Capturas OTA do cliente

Ao executar essa solução de problemas e fornecer os resultados ao TAC, isso acelera o processo de solução de problemas.