Valider le débit Wi-Fi : guide de test et de surveillance

Introduction

Ce document décrit comment surveiller et dépanner les problèmes de débit dans les grands réseaux Wi-Fi.

Contexte

Dans les réseaux Wi-Fi, il n'y a pas beaucoup de types de problèmes perçus par les utilisateurs finaux.

Les problèmes signalés peuvent varier entre :

• les clients ne peuvent pas se connecter ;
• les clients qui se déconnectent soudainement ou
• la vitesse perçue de l'application sur le dispositif utilisateur n'est pas satisfaisante.

Derrière ces symptômes simples peuvent se trouver des centaines de types de problèmes, la plupart n'impliquant même pas les réseaux Wi-Fi réels comme les problèmes DNS, les problèmes de connexion Internet, etc.

Les serveurs de gestion tels que Cisco Catalyst Center aident l'administrateur à résoudre des problèmes spécifiques. Cet article ne décrit pas en détail ces nombreux types de problèmes quotidiens qui peuvent être facilement détectés et résolus via Catalyst Center. Au lieu de cela, ce document se concentre sur les commentaires plus vagues des utilisateurs finaux selon lesquels le réseau est lent.

Comment tester ça ? Comment valider le débit réel sur votre réseau ? Comment trier les problèmes liés à la vitesse en éléments exploitables pour améliorer l'expérience globale de l'utilisateur final ?

Ce sont toutes des questions auxquelles ce document tente de répondre.

Définition du débit maximal attendu

La première question de chaque réseau est la suivante : quelle est la vitesse maximale pouvant être atteinte de manière potentielle et réaliste ?

Comme le Wi-Fi est un média partagé, la vitesse ressentie dépend directement du nombre de clients et d'appareils qui utilisent le Wi-Fi au même moment sur le même canal. Par conséquent, cette question de la vitesse maximale réelle qui peut être atteinte implique directement d'avoir un seul périphérique client et un seul point d'accès dans un endroit isolé calme où personne n'utilise le même canal Wi-Fi. Dans ces conditions, les facteurs permettant de déterminer la vitesse maximale se résument à :

• Le protocole Wi-Fi utilisé (Wi-Fi 5, Wi-Fi 6, ...)
• Les capacités matérielles du client et du point d'accès (nombre d'antennes, nombre de flux spatiaux, connexion Ethernet du point d'accès, ...)
• La configuration (largeur de canal, ...)

La connaissance de ces facteurs vous permet d’estimer le débit réel maximal que vous pouvez espérer atteindre dans des conditions de laboratoire.

Pour en avoir une idée rapide, vous devez vérifier à quel débit de données vos rapports client doivent être connectés au point d'accès. Ce débit de données n'est pas le débit réel que vous êtes en mesure de démontrer dans vos tests. En effet, le Wi-Fi est un support bidirectionnel non simultané qui présente une surcharge de gestion (les trames doivent être reconnues, les balises doivent être transmises) et de courts silences entre les trames pour une meilleure réception et un meilleur décodage. Cela signifie que, lorsque des données sont envoyées, elles le sont au débit de données documenté, mais que les données ne sont pas toujours envoyées. Les trames de gestion et de contrôle sont envoyées à un débit de données beaucoup plus faible pour assurer la réception. Une estimation est que vous pouvez envisager d'atteindre 65 à 70 % du débit de données utilisé dans un test de débit réel. Par exemple, si votre client signale qu'il est connecté et qu'il envoie des données à 866 Mbits/s, les tests réels doivent indiquer une vitesse de transfert d'environ 600 Mbits/s.

Si vous connaissez les paramètres de configuration utilisés ainsi que les capacités matérielles des périphériques concernés, vous pouvez également déterminer le débit de données maximal (et donc le débit, en utilisant le calcul de pourcentage décrit dans cette section) qui doit être atteint.

En cas de non-correspondance entre le débit de données signalé et celui que vous espériez atteindre, vous pouvez commencer le processus de dépannage par la configuration et vérifier les différents paramètres pour comprendre où se trouve l'écart.

Un exemple : si vous avez un modèle de point d'accès C9120 diffusant à une largeur de canal de 20 MHz dans la bande de 5 GHz et un client Wi-Fi 6 typique à 2 flux spatiaux, vous pouvez calculer que, dans un environnement RF (radiofréquence) parfaitement propre, avec un seul client, vous pouvez espérer atteindre 160 à 200 Mbits/s en un seul transfert de fichiers.

Pour plus d'informations sur le test et la validation du débit, consultez le site : https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html.

Établir l'expérience de base

Il est important de savoir ce que l'on peut attendre de votre lieu de réunion dans des circonstances typiques. Il arrive souvent qu'un technicien visite le site vide avant le déploiement, exécute des tests de vitesse et documente les nombres attendus.

Ensuite, les employés ou les clients entrent, le site est occupé et l'expérience réelle diffère beaucoup.

Une fois le déploiement en ligne, il est judicieux d'envoyer des techniciens pour mesurer l'expérience réelle dans chaque domaine et prendre note de l'aspect du réseau lors d'une journée normale.

Cela inclut le nombre moyen de clients par radio lorsque le réseau fonctionne à un niveau satisfaisant, ainsi que le débit moyen obtenu avec un test de vitesse.

Recherchez les déviations de l'expérience

Lors de l'exploitation de votre réseau, il est facile de surveiller les alertes majeures ou les périphériques qui tombent soudainement en panne. Ce document se concentre sur la partie difficile : comment repérer un réseau sans fil qui fonctionne toujours mais offre une expérience utilisateur inférieure.

Recherche de preuves d'un problème (test passif)

Vous avez testé votre réseau vous-même ; vous savez qu'il fonctionne correctement et vous surveillez vos systèmes de gestion et vos tableaux de bord. Rien n'est signalé en contrebas, on prend du recul et on se détend. Ou pouvez-vous ?

Si vous attendez les échos des utilisateurs finaux qui se plaignent de la mauvaise expérience, il est probable que vous arriviez trop tard. Lorsque les utilisateurs finaux se plaignent, le problème dure depuis longtemps et vous n'entendez que les quelques utilisateurs qui ont été assez bruyants pour que vous l'entendiez.

D'innombrables utilisateurs ont déjà été frustrés, n'ont rien dit à vous ou à votre centre d'assistance, mais ont donné une mauvaise réputation à votre réseau.

Donc la question est : comment peut-on repérer les occurrences de mauvaise expérience dès qu'elles se produisent ?

1. Le tableau de bord d'assurance client sur Cisco Catalyst Center

Dans le tableau de bord d'assurance de Cisco Catalyst Center, vous disposez d'un graphique global de l'état de santé de vos clients.

Il y a toujours des clients qui ne peuvent pas se connecter parce que quelqu'un a entré la mauvaise clé, ou l'appareil est assis à la limite de votre couverture, alors n'espérez pas atteindre 100% des clients sains mais être familier avec ce qui est un bon pourcentage de clients sains pour votre environnement.

Être dans la gamme des années 90 est généralement une bonne nouvelle.

D'un coup d'oeil très rapide, vous pouvez voir ce qui arrive aux clients qui ne sont pas en bonne santé :

• Sont-ils éloignés du point d'accès (point d'accès) ?
• Est-ce un problème d'authentification ?

Vous pouvez facilement voir sur ce graphique le ratio de chaque catégorie.

Dans la même plage d'idées, vous pouvez faire défiler la page jusqu'en bas et filtrer pour afficher les périphériques clients qui sont signalés comme ayant un mauvais état de santé. Vous pouvez alors essayer de repérer s'il y a un motif :

• Ils sont potentiellement tous connectés sur une bande de 2,4 GHz (ce qui est connu pour donner une expérience plus mauvaise dans de nombreux cas) ;
• Ils sont potentiellement tous signalés à une intensité de signal faible ;
• Ils sont potentiellement tous dans la même zone physiquement.

2. Le tableau de bord d'assurance réseau et le périphérique 360 sur Cisco Catalyst Center

Une mesure particulièrement efficace pour détecter une zone de problèmes potentielle spécifique consiste à accéder à la page Network Assurance de Cisco Catalyst Center. Vous disposez d'un widget montrant les principaux points d'accès par nombre de clients :

Si 40 clients sont connectés au point d'accès supérieur de votre réseau, vous êtes assuré. Cela implique que tous les autres AP (points d'accès) ont un nombre de clients inférieur.

D'un autre côté, si vous trouvez le ou les points d'accès principaux ayant un nombre anormalement élevé de clients, vous pouvez faire une supposition que l'expérience du client là-bas est particulièrement mauvaise (sauf si la plupart des clients sont en sommeil et non actifs sur le réseau).

Vous pouvez ensuite passer à une enquête « par point d'accès » où vous zoomez sur les points d'accès principaux spécifiques signalés dans ce widget pour comprendre leur état actuel.

Une autre méthode d'analyse du nombre de clients consiste à accéder aux cartes de la page Hiérarchie du réseau de votre Catalyst Center. Une fois dans la page de vue d'étage, cliquez sur «Options d'affichage» et dans la section Points d'accès, changez l'affichage en «Assoc. Clients » pour afficher le nombre de clients par point d'accès :

L'avantage de la technique de carte est que vous pouvez repérer où se trouve le point d'accès avec un nombre élevé de clients et évaluer si le nombre élevé pourrait être justifié (il peut y avoir une bonne raison pour qu'une foule se rassemble à cet endroit à ce moment donné).

Vous pouvez aussi jeter un oeil aux AP voisins : s'ils partagent une partie de la charge, les choses sont bonnes. Si un AP a un nombre anormalement élevé de clients alors que les AP voisins n'ont aucun client du tout, la situation devient plus suspecte.

Il peut y avoir un problème avec les points d'accès voisins (si leur nombre de clients est nul) ou la conception RF peut faire en sorte que le point d'accès problématique attire tous les clients par rapport à ses voisins (par exemple en raison d'une puissance TX beaucoup plus élevée et/ou d'antennes différentes).

La carte vous donne une bonne vue d'ensemble des clients associés sur chaque AP

Une fois que vous avez identifié des points d'accès potentiellement problématiques où le nombre de clients est extrêmement élevé, vous pouvez rechercher ce nom de point d'accès et ouvrir la page 360 du périphérique.

Le graphique d'état de santé vous donne une vue d'ensemble si l'état de santé de cet AP est mauvais en ce moment ou s'il a été constamment mauvais au cours de la dernière journée ou plus.

Sur la même page, vous avez une liste de problèmes liés à ce point d'accès. Dans ce cas, il est clair que les deux radios connaissent une utilisation élevée.

L'observateur d'événements peut vous donner une idée s'il y a eu des événements spécifiques liés à ce point d'accès.

Par exemple, un algorithme RRM configuré pour fonctionner trop fréquemment et provoquer des changements fréquents de canaux qui affectent les clients connectés, ou une radio qui se réinitialise constamment en raison de divers problèmes ou interférences.

À la fin de la page du périphérique 360, vous pouvez définir la vue sur « RF », sélectionner la radio spécifique et vous avez des informations intéressantes qui vous permettent d'évaluer la source du problème.

Avoir beaucoup de clients n'est pas nécessairement un problème : tout dépend de leur niveau d'activité.

Parfois, même avec quelques clients, le point d'accès peut avoir les mains occupées et offrir une mauvaise expérience. L'indicateur réel est l'utilisation du canal.

Lorsque l'utilisation des canaux approche les 100 % (même à partir de 70 %), les clients commencent à se battre pour l'accès moyen, la latence et les collisions.

Les graphiques vous permettent de comparer l'utilisation totale du canal et cette partie AP de la responsabilité en elle.

Par exemple, si l'utilisation du canal est de 80 %, cela signifie que 80 % du temps il y a « quelqu'un » qui transmet sur le canal. Si le point d'accès affiche une utilisation Rx de 40 % et une utilisation Tx de 40 %, vous savez que seul ce point d'accès est responsable de maintenir le canal occupé (c'est-à-dire qu'aucun autre point d'accès ne transmet) et qu'il est bien équilibré entre la réception et la transmission. Si l'utilisation combinée des points d'accès Rx et Tx est loin de l'utilisation du canal, cela implique qu'un autre point d'accès (indésirable ou géré) utilise le même canal et provoque des interférences sur le même canal.

Cette capture d'écran représente un point d'accès où le canal est extrêmement occupé (91 %) :

Le graphique montre que seulement 7 % de cette utilisation est due à d'autres points d'accès et sources non Wi-Fi et que le point d'accès est occupé à transmettre pendant 82 % du temps et à recevoir pendant seulement 2 %.

Le nombre de clients et le débit total indiquent qu'un ou plusieurs clients téléchargent probablement des fichiers volumineux.

Le graphique d'interférence vous permet de déterminer si le canal est occupé par des transmissions Wi-Fi ou des interférences réelles (non Wi-Fi) :

En conclusion, et en règle générale, vous devez vous occuper des points d'accès avec le plus grand nombre de clients et l'utilisation de canal la plus élevée. Vous devez ensuite évaluer si cette charge est justifiée ou non et si elle entraîne une mauvaise expérience pour les utilisateurs finaux dans cette zone.

3. Analyses d'IA

L'analytique IA vous offre une surveillance plus intelligente. La surveillance n'est plus basée sur des seuils fixes, mais s'adapte à votre utilisation de base.

L'heatmap du réseau vous donne une évolution du nombre de clients, pour repérer les points d'accès avec le plus grand nombre de clients au cours de la semaine. Vous pouvez également repérer facilement les points d'accès qui n'ont pas de clients connectés en permanence : le problème inverse est également un problème.

Il peut y avoir un problème physique avec ces AP (problème de montage, problème avec les antennes, etc.) ou un problème logiciel si la radio est figée (et si un redémarrage de cet AP le corrige).

La page Trends and Insights vous donne une liste des points d'accès qui affichent régulièrement une utilisation élevée du canal ou une activité client élevée afin que vous puissiez facilement vérifier si cela correspond à vos domaines les plus occupés ou s'il y a quelque chose d'anormal :

Test actif de l'infrastructure

Lorsque les utilisateurs signalent une mauvaise expérience dans un domaine spécifique, vous souhaitez la tester activement pour confirmer leurs commentaires. Il est important de comprendre que les tests typiques diffèrent beaucoup du trafic client réel.

Les utilisateurs essaient généralement d'utiliser leur application préférée et sont heureux si elle fonctionne. Ils transfèrent rarement des fichiers volumineux. Leur application préférée peut avoir différents comportements :

• Vidéo à la demande : cette option peut consommer n'importe quelle quantité de bande passante (cela dépend si la vidéo est de 720 pixels ou de 4 Ko par exemple).
  • Il est très tolérant à la gigue car il met en mémoire tampon quelques secondes ou minutes de vidéo au préalable. Le modèle ressemble à un transfert de fichiers volumineux pendant une courte période, puis se met en silence pendant que la vidéo est lue à partir du tampon jusqu'au prochain préchargement.
• Appel vocal : ce type d'appel consomme une quantité négligeable de bande passante, mais il est extrêmement sensible à la latence et à la gigue.
  • Cela peut potentiellement utiliser le marquage QoS (Quality of Service) et donc faire face à une expérience différente (hiérarchisée) du trafic au mieux.
• Données : une application de médias sociaux télécharge les données par salves.
  • La quantité varie en fonction du contenu et de la vitesse de défilement de l'utilisateur.

Une application de test de débit classique optimise le protocole pour atteindre la vitesse de transfert la plus élevée possible : elle tente de réserver le support et d’envoyer autant de trames de données que possible concaténées. Cela ne représente pas le même type d'utilisation que les applications réelles (autres que les transferts de fichiers), qui sont très chargées par nature.

Le test d'applications réelles imite les comportements des utilisateurs, mais rend impossible l'obtention de mesures et de chiffres réels à comparer. Vous ne ressentez un sentiment subjectif que si le réseau est fluide ou non.

Pour les tests de débit, de nombreux sites Web sont populaires et donnent une image correcte de l'expérience de l'utilisateur final lorsqu'ils testent l'ensemble de la bande passante entre le client et Internet. Toutefois, si vous souhaitez valider votre réseau sans fil indépendamment des problèmes de connexion Internet, de routage et de pare-feu, il est recommandé d'utiliser un outil de test de débit dédié tel que Iperf : https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047.

Cet outil permet des tests spécifiques entre un client et un serveur que vous placez sur votre réseau. Cela vous permet de déplacer le serveur à des emplacements spécifiques du réseau et de tester le débit sur des sections de réseau de plus en plus longues pour valider chaque section. Commencez par placer le serveur Iperf sur le même commutateur que le point d'accès où se trouve votre client sans fil en cas de commutation locale ou de réseau sans fil compatible avec le fabric, ou sur le même commutateur que le WLC (Wireless LAN Controller) (et dans le VLAN client si possible) en cas de commutation centrale.

Si vous utilisez un WLC d'ancrage, vous devez placer le serveur Iperf sur le même commutateur que le WLC d'ancrage que celui où le trafic est terminé. Il peut parfois être intéressant de créer un WLAN non ancré (LAN sans fil) pour voir si les résultats de débit potentiellement décevants sont causés par l'ancrage lui-même par rapport à un WLAN non ancré.

Il n’est pas vraiment judicieux d’utiliser plusieurs clients pour effectuer des tests de débit en même temps. Lors des tests de débit, ce client unique doit utiliser la totalité du temps d’antenne disponible sur le canal. Par conséquent, si deux clients effectuent un test de débit en même temps, ils voient chacun un résultat divisé au moins par deux. Si plus de clients sont utilisés, les collisions commencent à se produire en nombres et les résultats ne sont plus représentatifs.

Il existe plusieurs outils ^tiers pour automatiser le test du réseau. N’oubliez pas que lorsque vous testez le débit dans une zone, vous utilisez efficacement tout le temps d’antenne pendant la durée du test. Il est donc déconseillé de tester le réseau trop souvent, car il perturbe les autres clients.

Dépannage d’un problème de débit

Lorsque vous identifiez un problème de débit, plusieurs éléments peuvent être examinés pour l’isoler :

• Isolez si, avant de commencer le test, l'environnement RF est déjà occupé. Plus l'utilisation du canal est élevée (en dehors du test), plus le résultat du test de débit est faible. Si un problème d'utilisation du canal est identifié, vérifiez si d'autres points d'accès sont présents dans la même zone sur le même canal et reconsidérez votre conception RF. La réduction de la largeur de canal, l'élimination des parasites, l'utilisation de différentes antennes avec une couverture plus ciblée sont toutes de bonnes options. L'ajout de points d'accès n'est pas toujours la meilleure idée.
• Obtenez une capture Over-The-Air du test de débit et voyez s'il y a beaucoup de tentatives de données sur une couche 802.11 (en pourcentage de toutes les trames de données). Un nombre élevé de tentatives signifie que l'environnement RF est potentiellement le problème. Vérifiez également les débits de données utilisés, le protocole potentiellement sous-optimal ou le nombre de flux spatiaux utilisés. Un transfert de données important est très caractéristique dans une capture en direct. Vous voyez des dizaines de trames de données avec la même source et la même destination et avec un temps delta extrêmement petit entre elles suivi d'un ACK de bloc. Si le transfert est caractérisé par un ACK régulier après chaque trame de données, ou un grand nombre de demandes à envoyer/claires à envoyer, le faible débit peut être facilement expliqué.
• Vérifiez si le problème de débit se produit avec tous les types de sécurité sur le WLAN. Parfois, une incompatibilité de sécurité spécifique entre le client et le point d'accès peut entraîner un débit médiocre.