Validation du débit sans fil 802.11ax et test de validation

Introduction

Ce document décrit la façon de tester le débit sans fil d'un point d'accès en se concentrant sur la norme 802.11ax et le débit attendu.

Conditions préalables

Exigences

Ce document suppose une configuration déjà fonctionnelle avec des points d'accès 802.11ax / Wi-Fi 6 offrant déjà une connectivité client

Composants utilisés

Les informations contenues dans ce document sont axées sur la technologie et les vitesses 802.11ax/Wi-Fi 6.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Comprendre

Le Wi-Fi 6 peut fonctionner sur plusieurs bandes : 2,4 GHz, 5 GHz et même la bande 6 GHz selon la certification Wi-Fi 6E.

Le 802.11ac est apparu en deux vagues. La seconde vague a apporté le support de canal 160Mhz, avec MU-MIMO et un maximum théorique de 8 flux spatiaux.

Ces nombres ne sont que les nombres théoriques de la norme, les différences s'appliquent en fonction de la feuille de données AP spécifique.

La norme 802.11ax n'est pas directement définie dans les débits de données, mais est plutôt une combinaison de 12 schémas de codage de modulation (MCS 0 à MCS 11), une largeur de canal allant de 20 MHz (1 canal) à 160 MHz (8 canaux), un certain nombre de flux spatiaux (généralement de 1 à 2, il y a eu 3 produits de flux spatiaux, mais ils sont de moins en moins visibles).

L'intervalle de garde (IG) court, moyen ou long ajoute également environ 10% de modification à ce dernier.

Voici un tableau pour évaluer un débit en Mbits/s en connaissant tous ces facteurs :

Un tableau plus complet est disponible à l'adresse : https://mcsindex.com/

Remarque : le débit de données n'est PAS égal au débit réalisable attendu. Ceci est lié à la nature de la norme 802.11 qui a beaucoup de surcharge administrative (trames de gestion, conflits, collisions, accusés de réception, etc.) et cela peut dépendre de la liaison SNR, RSSI et d'autres facteurs importants.

C'est une règle de base :

Débit attendu = Débit de données x 0,65

Prenez un exemple de la vie réelle. Un point d'accès Cisco 9120 avec un smartphone moderne compatible Wi-Fi 6 et capable de 2 flux spatiaux. Si nous sommes dans un environnement à haute densité où des canaux de 20 Mhz sont utilisés, le débit de données maximal utilisé est compris entre 240 et 280 Mbits/s selon l'intervalle de garde. Cela signifie que, dans un environnement propre et dans des conditions de test, un client peut transférer des données entre 160 et 200 Mbits/s (soit 65 à 70 % de l'efficacité du protocole). Ceci n'est valable que lors d'un transfert important ou d'un test de vitesse où le protocole est optimisé pour un débit de données maximal. Lorsque vous utilisez d’autres applications, le débit diminue car la latence joue également un rôle dans les protocoles qui exécutent une requête ping-pong de paquets et attendent des accusés de réception avant de poursuivre.

Notez également que le sans fil est un environnement partagé, ce qui signifie que la quantité de clients connectés au point d'accès partage le débit effectif entre eux. Si un client effectuant un test de vitesse peut atteindre entre 160 et 200 Mbits/s, cela signifie que deux clients effectuant un test de vitesse en même temps voient chaque 80 à 100 Mbits/s. Si quatre clients effectuent un test de vitesse en même temps, ils voient 40 à 50 Mbits/s chacun, etc.

En plus de cela, plus de clients signifie plus de contention et inévitablement plus de collision. L'efficacité de la cellule de couverture diminue considérablement à mesure que le nombre de clients augmente. Il est donc irréaliste de définir un type de SLA pour le débit dans des endroits où vous ne contrôlez pas la quantité de clients connectés ou ce qu'ils font sur le réseau en termes d'activité.

Mesurer

En règle générale, deux scénarios sont possibles lorsque vous effectuez un test de débit :

• Les points d'accès sont dans la commutation locale Flexconnect

• Les points d'accès sont en mode local ou en commutation centrale Flexconnect

Prenez ces scénarios un par un :

(Schéma 1)

Dans le cas du schéma 1, nous supposons que les AP sont en mode local de commutation centrale Flexconnect.

Cela signifie que tout le trafic client est encapsulé dans le tunnel CAPWAP et se termine sur le WLC.

(Schéma 2)

La ligne rouge du schéma 2 indique le flux de trafic du client sans fil.

Le serveur iPerf doit être aussi proche que possible du point de terminaison du trafic, idéalement branché sur le même commutateur que le WLC lui-même et utiliser le même VLAN.

Dans le cas de la commutation locale Flexconnect, le trafic client est terminé sur le point d'accès lui-même, et considérant que le serveur iPerf doit être configuré aussi près du point de terminaison du trafic client sans fil, branchez le serveur iPerf sur le même commutateur et le même VLAN où le point d'accès est branché.

Dans notre cas, il s'agit du commutateur d'accès (schéma 3).

(Schéma 3)

Les tests iPerf peuvent être divisés en deux catégories : en amont et en aval.

Étant donné que le serveur iPerf écoute et que le client iPerf génère le trafic, lorsque le serveur iPerf est du côté filaire, ceci est considéré comme un test en amont.

Le client sans fil utilise l'application iPerf pour transférer le trafic sur le réseau.

Le test en aval est l'inverse, ce qui signifie que le serveur iPerf est défini sur le client sans fil lui-même et que le client iPerf est du côté filaire, poussant le trafic vers le client sans fil. Dans ce scénario, ceci est considéré comme en aval.

Le test doit être effectué à l’aide des protocoles TCP et UDP. Vous pouvez utiliser ces commandes pour effectuer les tests suivants :

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

 

Exemple de résultats 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 :

Lors de l’utilisation du protocole UDP, il est important de s’assurer qu’il n’y a pas ou peu de perte de paquets. Il est possible de voir des nombres de débits très élevés, mais si vous avez une perte de paquets de 50 %, vous n'avez pas réellement transféré cette quantité de données.

Parfois, iPerf se comporte mal et ne donne pas la bande passante moyenne à la fin du test UDP.

Il est toujours possible de résumer la bande passante pour chaque seconde, puis de la diviser par nombre de secondes :

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

Remarque : les résultats iPerf devraient être légèrement meilleurs sur la commutation locale Flexconnect par rapport au scénario de commutation centrale.
Ceci est dû au fait que le trafic client est encapsulé dans CAPWAP, ce qui ajoute plus de surcharge au trafic et en général le WLC agit comme un goulot d'étranglement car il est le point d'agrégation pour tout le trafic des clients sans fil.
En outre, le test iPerf UDP devrait donner de meilleurs résultats dans un environnement propre, car il s'agit de la méthode de transfert la plus efficace lorsque la connexion est fiable. Cependant, TCP peut gagner en cas de fragmentation importante (lorsque TCP Adjust MSS est utilisé) ou de connexion non fiable

.

Vérifier et valider

Afin de vérifier à quel débit de données le client est connecté, émettez ces commandes dans CLI 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

Vous pouvez voir que ce client particulier est connecté à ces débits :

Débit actuel..................................... m10 ss2

Ce qui signifie que le client utilise l'index MCS 10 (m10) sur 2 flux spatiaux (ss2)

À partir de la commande « show wireless client mac <MAC> det », il n’est pas possible de voir si le client est connecté sur une liaison de canal 20/40/80 MHz.

Ceci peut être fait directement sur le point d'accès :

Exemple 9164 :

#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 dernière option pour vérifier le débit connecté est les captures OTA. Dans les informations radio du paquet de données, vous pouvez trouver les informations nécessaires :

 Cette capture OTA a été effectuée avec un client macbook 11ac.

Dépannage

Si vous n'obtenez pas les résultats escomptés pendant le test, il existe plusieurs façons de résoudre le problème et de collecter les informations nécessaires avant d'ouvrir un dossier TAC.

Les problèmes de débit peuvent être causés par les éléments suivants :

-Client

- AP

- Chemin filaire (problèmes liés à la commutation)

- WLC

Dépannage client

• La première étape consiste à mettre à jour les pilotes des périphériques clients sans fil vers la dernière version
• La deuxième étape consiste à effectuer le test iPerf avec des clients disposant d'un adaptateur sans fil différent pour voir si vous obtenez les mêmes résultats

Dépannage AP

Il peut y avoir des scénarios où le point d'accès abandonne le trafic, ou certaines trames ou d'autres comportements inappropriés.

Afin d'obtenir plus d'informations à ce sujet, il y a besoin de captures OTA (Over The Air) + session span sur le port de commutation AP (span doit être fait sur le commutateur où le point d'accès est connecté)

Les captures OTA et SPAN doivent être effectuées pendant le test, en utilisant le SSID ouvert afin de pouvoir voir le trafic passé au point d'accès et le trafic AP passe vers le client et vice versa.

Il existe plusieurs bogues connus pour ce comportement :

CSCvg07438 : AP3800 : Débit faible dû aux pertes de paquets dans le point d'accès dans les paquets fragmentés et non fragmentés

CSCva58429 : point d'accès Cisco 1532i : faible débit (commutation locale FlexConnect + EoGRE)

Dépannage des chemins câblés

Il peut y avoir des problèmes sur le commutateur lui-même, vous devez vérifier la quantité de chutes sur les interfaces et si celles-ci augmentent pendant les tests.

Essayez d'utiliser un autre port sur le commutateur pour connecter le point d'accès ou le WLC.

Une autre option consiste à brancher un client sur le même commutateur (auquel le point de terminaison client [AP/WLC] est connecté) et à le placer sur le même VLAN, puis à exécuter les tests câblés à câblés sur le même VLAN pour voir s'il y a des problèmes dans le chemin câblé.

Dépannage du WLC

Il se peut que le WLC abandonne le trafic (quand les AP sont en mode local) du client.

Vous pouvez mettre le point d'accès en mode Flexconnect et le WLAN en commutation locale, puis exécuter les tests.

Si vous voyez qu'il y a des différences significatives dans le débit en mode local (commutation centrale) par rapport à la commutation locale Flexconnect et qu'il n'y a aucun problème sur le commutateur connecté au WLC, alors très probablement le WLC abandonne le trafic.

Pour résoudre ce problème, appliquez le plan d'action :

- Captures SPAN sur le port de commutation WLC (doit être effectué sur le commutateur)

- Captures SPAN sur le port AP

- Captures OTA du client

En effectuant ce dépannage et en fournissant les résultats au TAC, cela accélère la procédure de dépannage.