Guide de dépannage pour les problèmes d’interopérabilité des clients sans fil avec CUWN
Contenu
Introduction
Ce document décrit en détail les informations qui doivent être collectées initialement pour étudier et résoudre efficacement les problèmes d'interopérabilité sans fil lorsqu'ils surviennent avec la solution Cisco Unified Wireless Network (CUWN). La nécessité d'une telle approche globale devient de plus en plus importante avec l'augmentation constante du nombre et des combinaisons de périphériques clients sans fil et de radios de point d'accès (AP).
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Points d'accès sans fil Cisco
- Contrôleurs LAN sans fil (WLC)
- Périphériques réseau associés
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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. If your network is live, make sure that you understand the potential impact of any command.
Informations générales
Il est courant de constater qu’étant donné les différents périphériques clients qui existent et continuent d’être développés. Divers problèmes peuvent survenir en ce qui concerne l'établissement, la maintenance ou simplement pour tirer le meilleur parti de leur connexion au réseau sans fil et pour prendre en charge l'infrastructure.
Cela peut souvent se traduire par un problème de configuration simple de la part du périphérique client et/ou de l'infrastructure sans fil elle-même. Cependant, dans certains cas, cela peut être attribué à un problème d'interopérabilité concernant un périphérique client et des composants spécifiques qui le prennent en charge (demandeur, adaptateur WLAN, pilote sans fil, etc.), et/ou les points d'accès en question. En tant qu'ingénieurs sans fil, ces problèmes d'interopérabilité représentent une opportunité d'identifier, de dépanner et de résoudre des défis potentiellement complexes.
Des renseignements supplémentaires sur ce qui est décrit dans cet article pourraient être demandés et devraient être recueillis au cas par cas, compte tenu du nombre illimité de variables qui pourraient dicter de telles exigences. Cependant, les informations détaillées ici constituent une ligne directrice générique pour traiter tout problème potentiel d'interopérabilité des clients sans fil.
I. Définition du problème
La première étape pour aborder efficacement tout problème dans l'intention de trouver une solution consiste à définir précisément le problème à l'étude. Pour ce faire, assurez-vous qu'au moins ces questions sont posées et que leurs réponses sont clairement documentées :
- Le problème est-il limité à un modèle spécifique de points d'accès et/ou de type radio (c'est-à-dire 2,4 GHz contre 5 GHz) ?
- Le problème est-il observé uniquement sur des versions spécifiques du logiciel WLC ?
- Le problème concerne-t-il uniquement des versions spécifiques de type(s) client(s) et/ou logiciel (par exemple, version du système d'exploitation, version du pilote WLAN, etc.) ?
- Y a-t-il d'autres périphériques sans fil qui ne rencontrent pas ce problème ? Dans l'affirmative, lesquelles ?
- Le problème est-il reproductible lorsque le client est connecté à une configuration sans fil simplifiée, telle qu'un SSID ouvert, avec une largeur de canal de 20 MHz et 802.11ac désactivé ? (c'est-à-dire le problème se produit-il uniquement en mode 802.11n et en mode 802.11ac ?).
- Si le problème n'est pas reproductible avec un SSID ouvert, à quelle configuration de sécurité minimale le problème est-il détecté ? (PSK ou 802.1X sur le WLAN).
- Quelles étaient les versions précédentes de la configuration de travail et du logiciel ?
II. Configuration WLC Et Journaux Généraux
Run-Config
Sans exception, il est absolument nécessaire de collecter la configuration du WLC du client pour un examen détaillé des fonctionnalités utilisées par le client, de leur configuration spécifique et d'autres détails de ce genre. Pour ce faire, vous devez établir une session Telnet/SSH sur les WLC en question et enregistrer la sortie de ces commandes CLI dans un fichier texte :
config paging disable show run-config
La sortie de configuration en cours est toujours préférée, car elle inclut des informations détaillées concernant les points d'accès joints et les informations RF associées, etc. Bien que dans certains cas et situations, comme lorsque vous travaillez initialement avec un WLC avec un grand nombre de points d'accès joints (c'est-à-dire un WLC 8510 avec plus de 2500 points d'accès). Il peut être préférable de collecter initialement uniquement la configuration du WLC sans de telles informations d'AP pour un examen rapide, car la show run-config complète peut prendre 30 minutes ou plus pour compléter le compte du nombre d'AP. Cependant, il peut être nécessaire de collecter ultérieurement la sortie de la configuration d'exécution complète.
Pour ce faire, vous pouvez éventuellement collecter le résultat de ces commandes CLI dans un fichier texte :
config paging disable show run-config no-ap show wlan apgroups
Fichier de configuration WLC
En plus de la sortie show run-config ou show run-config no-ap, il est également recommandé de collecter une sauvegarde complète de la configuration du WLC. Cela est utile, si un laboratoire recréé doit être effectué par le TAC/HTTS et l'escalade de l'unité binaire, pour essayer de reproduire le problème du client dans un environnement de laboratoire Cisco. Une sauvegarde du WLC peut être collectée via l'interface utilisateur graphique ou l'interface de ligne de commande du WLC en question, avec l'utilisation de TFTP ou FTP pour enregistrer le fichier de configuration sur le serveur TFTP/FTP externe. L'exemple ci-dessous montre l'utilisation de l'interface utilisateur graphique et de l'interface de ligne de commande pour enregistrer une sauvegarde du WLC, avec l'utilisation de TFTP :
IUG
Commandes > Upload File > Configuration > Upload comme illustré dans l'image.
CLI
transfer upload datatype config
transfer upload mode tftp transfer upload serverip <TFTP-Server_IP-address> transfer upload path / transfer upload filename <desired-filename> transfer upload start
Syslogs du WLC
À ce stade, vous voulez également collecter les journaux actuels du WLC pour une révision supplémentaire si nécessaire. Idéalement, vous voulez collecter ces journaux immédiatement après votre test avec un client sans fil où le problème signalé est reproduit. Si le client exporte les journaux WLC vers un serveur syslog externe, vous voulez les récupérer à partir de là. Sinon, vous pouvez enregistrer le msglog et le traplog actuellement stockés localement sur le WLC en enregistrant cette sortie de session CLI dans un autre fichier texte :
config paging disable show msglog show traplog
III. Informations et détails sur le périphérique client
L'étape suivante consiste à recueillir autant d'informations et de détails sur le ou les périphériques client(s) en cours d'utilisation qui rencontrent un problème potentiel d'interopérabilité sans fil. Ces informations devraient comprendre, mais pas nécessairement, les éléments suivants :
- Type de client (tablette, smartphone, ordinateur portable, etc.)
- Marque et modèle des périphériques
- Version du système d'exploitation
- Modèle de carte WLAN
- Version du pilote de carte WLAN
- Supposant utilisé (par ex. Windows Zero Config / Auto Config, Intel PROSet, etc.)
- Sécurité configurée pour l'utilisation par le client sans fil et le WLAN (Open, PSK, EAP-PEAP/MSCHAPv2, etc.)
- Notez tous les paramètres client qui ont été modifiés par rapport aux paramètres par défaut fournis par le fournisseur en question (état de veille, paramètres d'itinérance, U-APSD, etc.).
IV. Topologie du réseau
Pour accélérer davantage les efforts de dépannage et le processus d'analyse de la cause première (RCA), il est toujours recommandé de fournir un schéma de topologie de réseau détaillé et complet. Le schéma de topologie du réseau doit non seulement inclure des détails sur le réseau et l'infrastructure sans fil, mais également fournir un aperçu des périphériques sans fil en question qui fonctionnent au sein du réseau (imprimantes/scanners, quels VLAN clients sont utilisés, etc.) et de leur emplacement respectif.
Un certain nombre d'outils (Microsoft Visio, dessin.io, etc.) et divers styles peuvent être utilisés pour créer un tel diagramme de réseau. L'aspect important est simplement de s'assurer que les informations appropriées sont clairement reflétées dans le diagramme fourni pour examen par toutes les parties et tous les fournisseurs concernés. Exemple de topologie de réseau qui capture des informations de base mais utiles concernant l'infrastructure et les périphériques clients, comme l'illustre l'image.
V. Informations complémentaires et spécifications
Pour garantir que les informations appropriées sont collectées au moment de tout test avec le ou les périphériques clients avec lesquels les utilisateurs finaux rencontrent des problèmes. Il est recommandé de créer de manière préventive une feuille de calcul ou un document similaire pour enregistrer tous les problèmes client et les détails associés observés au moment du test, comme dans cet exemple :
| Adresse MAC : | Nom d’utilisateur | Description du symptôme signalé | symptôme observé par l'utilisateur final | Ping de passerelle par défaut O/N | État du signal Wi-Fi (connecté/tentative de connexion) | Enregistrer ipconfig /all (ou équivalent) |
| xxyy.aabb.0011 | test_user1 | Se déconnecte de manière intermittente du point d'accès. | Perte de la connectivité réseau et de l'association sans fil du point d'accès 3. | n | Tentative de connexion | ifconfig en0 en0 : flags=8863<UP, BROADCAST, SMART, RUNNING, SIMPLEX, MULTICAST> mtu 1500 éther xx:yy:aa:bb:00:11 inet6 fe80::848:cb8f:881a:4cbf%en0 prefixlen 64 secure scopeid 0x4 inet 192.168.10.237 netmask 0xffffff00 broadcast 192.168.10.255 nd6 options=201<PERFORMNUD, DAD> média : sélection automatique état : actif |
L'objectif de cet exercice est d'aider à documenter et à déterminer un modèle commun d'intérêt, ainsi qu'à obtenir une vue d'ensemble précise de la ou des questions à l'étude. Une fois cette feuille de calcul prête à être utilisée pour la collecte de données, vous êtes prêt à commencer vos tests. Voici quelques considérations supplémentaires, mais importantes :
VI. WLC - Commandes Show and Debug
Lorsque des tests sont effectués pour reproduire et résoudre des problèmes potentiels d'interopérabilité des clients sans fil, il est impératif que les débogages et les journaux supplémentaires soient collectés à partir de l'infrastructure sans fil utilisée. Ces deux sections peuvent expliquer en détail les journaux spécifiques et la sortie de débogage initiale qui doivent être collectés du WLC et des AP, respectivement.
Commandes de débogage WLC
config sessions timeout 0
debug client <MAC_address> debug dhcp message enable
En ce qui concerne la nature du problème à résoudre, vous pouvez également ajouter ces débogages WLC au cas par cas :
- debug aaa detail enable - utilisez ceci s'il y a des problèmes liés à l'authentification avec le serveur AAA
- debug aaa events enable - utilisez ceci s'il y a des problèmes liés à l'authentification avec le serveur AAA
- debug aaa all enable - utilisez ceci pour les problèmes d'authentification ; le résultat de ce débogage est verbose, donc utilisez-le uniquement quand vous en avez absolument besoin (par exemple pour les cas de remplacement AAA, etc.)
- debug mobility handoff - utilisation en cas de problèmes d'itinérance entre les WLC
Une fois le problème reproduit avec le client sans fil en question, et tous les renseignements décrits dans les sections antérieures et postérieures sont recueillis et documentés. Pour exécuter ces commandes CLI, vous devez désactiver les débogages sur le WLC.
debug disable-all
Commandes Show du WLC
config paging disable show time show client detail <MAC_address> ping <client_IP-address> <repeat count [1-100]>
Comme indiqué précédemment, assurez-vous d'exécuter les débogages WLC dans une session Telnet/SSH et collectez le résultat pour ces commandes show dans un autre Telnet/SSH vers le WLC. Vous devez faire de même pour collecter les débogages AP et les résultats des commandes show détaillés dans cette section.
VII. AP - Commandes Show and Debug
Points d'accès Cisco IOS légers
Avant de commencer un débogage sur un ou plusieurs points d'accès IOS légers impliqués dans le test, tels que les points d'accès Cisco de modèle précédent, 2600, 2700, 3700 ou 2600. Vous devez d'abord exécuter ces commandes CLI sur le point d'accès, afin d'éviter un délai d'attente au moment d'une session Telnet/SSH/console aux points d'accès en question lors de vos tests clients :
debug capwap console cli config t line vty 0 4 exec-timeout 0 session-timeout 0
Vous pouvez également suivre ces étapes pour utiliser la connexion console et remplacer l'instruction line vty 0 4 par line console 0 à la place, afin de désactiver les délais d'expiration et de session pour une connexion série/console en conséquence.
- console de ligne 0 - à utiliser pour modifier les paramètres de temporisation de session série
- line vty 0 4 - à utiliser pour modifier les paramètres de temporisation de session Telnet/SSH
Commandes show AP
Avant de commencer le test, vous devez d'abord collecter un exemple de ces commandes show sur l'AP. Vous devez collecter le résultat de ces commandes show au moins deux fois pour chaque test impliquant le client sans fil en question ; avant et après le test.
term len 0 show clock show tech show capwap client mn show int do1 dfs show logging more event.log show trace dot11_rst display time format local show trace dot11_rst show trace dot11_bcn display time format local show trace dot11_bcn
Commandes de débogage AP
Une fois que vous avez collecté la sortie initiale des commandes show mentionnées ci-dessus, vous pouvez maintenant activer les débogages sur le même point d'accès dans une session Telnet/SSH séparée comme indiqué. Assurez-vous d'enregistrer la totalité de la sortie dans un fichier texte.
debug dot11 {d0|d1} monitor addr <client_MAC-address>
debug dot11 {d0|d1} trace print clients mgmt keys rxev txev rcv xmt txfail ba
term mon
Légende
| Indicateur | Description |
| d0 | Radio 2,4 GHz (logement 0) |
| d1 | Radio 5 GHz (logement 1) |
| gestion | Traiter les paquets de gestion |
| ba | Informations ACK du bloc de suivi |
| rcv | Suivre les paquets reçus |
| keys | Touches de jeu de suivi |
| rxev | Suivre les événements reçus |
| txev | Suivre les événements de transmission |
| txrad | Suivre la transmission à la radio |
| xmt | Suivre les paquets de transmission |
| txfail | Suivre les échecs de transmission |
| taux | Modifications du taux de suivi |
Pour désactiver les débogages sur le point d'accès une fois le processus de test et de collecte de données terminé, vous pouvez exécuter cette commande CLI sur le point d'accès :
u all
Points d'accès AP-COS
Pour les points d'accès compatibles avec la norme 802.11ac de 2e vague et versions ultérieures, tels que les points d'accès du modèle 1800, 2800 et 3800. Ces nouveaux AP modèles introduisent un système d'exploitation complètement nouveau pour les plates-formes de point d'accès appelées AP-COS. Par conséquent, toutes les commandes utilisées précédemment sur les points d'accès légers Cisco IOS traditionnels, comme indiqué ci-dessus, ne s'appliquent toujours pas. Si vous dépannez un problème d'interopérabilité avec différents périphériques STA clients et AP-COS modèles, ces informations doivent être collectées auprès du ou des points d'accès AP-COS impliqués dans le test équivalent.
Avant de démarrer un débogage sur un ou plusieurs AP de modèle AP-COS impliqués dans le test. Vous devez d'abord exécuter cette commande CLI sur le point d'accès, afin d'éviter un délai d'attente au moment d'une session Telnet/SSH/console aux points d'accès en question lors de vos tests clients :
exec-timeout 0
Commandes show AP-COS
Avant de commencer le test, vous devez d'abord collecter un exemple de ces commandes show sur l'AP. Vous devez collecter le résultat de ces commandes show au moins deux fois pour chaque test impliquant le client sans fil en question ; avant et après le test.
term len 0
show clock show tech
show client statistics <client_MAC-address>
show cont nss status
show cont nss stats
show log
Gamme 1800 | Commandes de débogage AP-COS
Ces débogages sont spécifiques à la série 18xx de points d'accès. Ceci est dû au fait que le(s) chipset(s) utilisé(s) pour la série 1800 des points d'accès diffèrent de ceux trouvés dans les points d'accès de la série 2800/3800, et donc un ensemble différent de débogages sont requis dans ce scénario par comparaison. Les débogages correspondants pour les AP de la gamme 2800/3800 sont traités dans la section suivante.
Une fois que vous avez collecté la sortie initiale des commandes show mentionnées ci-dessus, vous devez maintenant activer les débogages sur le ou les mêmes points d'accès 1800 dans une session Telnet/SSH séparée comme indiqué. Assurez-vous d'enregistrer la totalité de la sortie dans un fichier texte.
debug dot11 client level events addr <client_MAC-address> debug dot11 client level errors addr <client_MAC-address> debug dot11 client level critical addr <client_MAC-address> debug dot11 client level info addr <client_MAC-address> debug dot11 client datapath eapol addr <client_MAC-address> debug dot11 client datapath dhcp addr <client_MAC-address> debug dot11 client datapath arp addr <client_MAC-address>
Dans certains cas, vous devrez peut-être également activer les débogages supplémentaires sur le point d'accès 18xx pour dépanner davantage les problèmes d'interopérabilité des clients. Cependant, ceci ne doit être fait que si/comme demandé par un ingénieur du centre d'assistance technique Cisco pour une demande/demande de service correspondante.
Comme les débogages supplémentaires peuvent non seulement être beaucoup plus verbeux dans leur sortie, mais peuvent également introduire une charge supplémentaire sur l'AP aussi, par conséquent, il faut du temps supplémentaire pour une analyse appropriée. Ce qui, dans certaines conditions, peut perturber le service, si de nombreux périphériques clients tentent de se connecter au même point d'accès sous test ou variables similaires.
Pour désactiver les débogages sur le point d'accès de variante AP-COS - que ce soit sur un AP de la gamme 1800 ou 2800/3800 - une fois le processus de test et de collecte de données terminé, vous pouvez exécuter cette commande CLI sur l'AP :
config ap client-trace stop
Gammes 2800/3800 | Commandes de débogage AP-COS
Une fois que vous avez collecté la sortie initiale des commandes show mentionnées ci-dessus, vous devez maintenant activer les débogages sur les mêmes points d'accès 2800/3800 dans une session Telnet/SSH séparée comme indiqué. Assurez-vous d'enregistrer la totalité de la sortie dans un fichier texte.
config ap client-trace address add <client_MAC-address>
config ap client-trace filter all enable
config ap client-trace output console-log enable
config ap client-trace start
term mon
Pour désactiver les débogages sur les points d'accès de la gamme 1800/2800/3800 une fois le processus de test et de collecte de données terminé, vous pouvez exécuter cette commande CLI sur le point d'accès :
config ap client-trace stop
VIII. Captures de paquets côté client
À partir du périphérique client utilisé s'il s'agit d'un ordinateur portable, d'un MacBook ou d'un ordinateur similaire, vous devez collecter la capture de paquets en mode proche à partir de l'interface sans fil du périphérique client utilisé pour reproduire le problème. Les utilitaires courants tels que Netmon 3.4 (Windows uniquement) ou Wireshark peuvent être téléchargés et utilisés pour collecter cette capture et l'enregistrer dans un fichier *.pcap. Cela dépend de l'appareil, il peut également y avoir des moyens de collecter un tcpdump ou similaire auprès du client en question, de sorte que vous pourriez avoir besoin de consulter le fabricant du périphérique client pour obtenir de l'aide à cet égard.
Voici un exemple de configuration d'une capture Wireshark pour l'interface sans fil sur un MacBook Pro :
Comme pour toute capture de paquets, quel que soit l'utilitaire utilisé pour la collecter, assurez-vous d'enregistrer le fichier au format pcap (i.e. *.pcap, *.pcapng, *.pkt, etc.). Il s'agit non seulement de s'assurer que les ingénieurs de Cisco dans n'importe quel service peuvent consulter facilement les fichiers de capture de paquets, mais également les ingénieurs d'autres fournisseurs et organisations (Intel, Apple, etc.). Cela permet un processus de collaboration et de coopération plus transparent, ce qui facilite encore davantage la collaboration entre Cisco et le ou les fournisseurs de périphériques clients afin de mieux étudier et résoudre les éventuels problèmes d'interopérabilité.
IX. Captures de paquets en direct (OTA)
Afin de résoudre efficacement les problèmes potentiels ou existants d'interopérabilité sans fil, il est essentiel de collecter une capture de paquets OTA de qualité du problème. Cela permet d'analyser en détail la communication sans fil 802.11 réelle entre le client sans fil et les points d'accès en question, en plus de donner une perspective plus détaillée sur les journaux, les débogages, etc. du côté client et de l'infrastructure sans fil. Il s'agit d'une étape essentielle qui doit être accomplie pour chaque test d'un problème potentiel d'interopérabilité sans fil, sans exception.
Cependant, il arrive souvent que le client final ne soit pas correctement équipé ou préparé à collecter des captures de paquets OTA. Il s'agit d'un obstacle courant auquel sont souvent confrontés les ingénieurs sans fil, et ils doivent collaborer avec le client pour le surmonter de différentes manières. Cet article des forums d'assistance Cisco peut servir de point de départ pour guider et éduquer le client en conséquence :
Détection/capture de paquets sans fil 802.11
Il est primordial que la ou les captures de paquets OTA soient collectées au format pcap (i.e. *.pcap, *.pcapng, *.pkt, etc.), et inclut les métadonnées 802.11 (RSSI, canal, débit de données, etc.). Le renifleur OTA doit également être maintenu à proximité immédiate du périphérique client en question à tout moment pendant les essais, afin d'assurer une vision précise du trafic envoyé et reçu à/depuis le périphérique client testé.
La raison en est que les captures de paquets agrégées avec l'utilisation de cet utilitaire sont actuellement enregistrées dans un format de fichier propriétaire, et non dans un format de type pcap qui peut être facilement affiché dans Wireshark ou d'autres utilitaires similaires. Assurez-vous que votre capture de paquets OTA est dans un format de fichier non propriétaire, ce qui permet à toutes les parties et à tous les fournisseurs concernés de consulter facilement tous les fichiers de capture en tout temps et, en fin de compte, d'accélérer les efforts de résolution.
Voici quelques méthodes courantes pour collecter une capture de paquets OTA :
- AirPCAP avec Wireshark
- MacBook Pro
- OmniPeek Professional, OmniPeek Enterprise, etc.
- Assistant distant OmniPeek (ORA)
- Point d'accès Cisco en mode Sniffer
Captures 802.11n
Pour les captures de paquets OTA qui impliquent des clients sans fil 802.11n, il y a actuellement plus de flexibilité et de facilité d'utilisation. Cela est dû à une plus grande variété d'adaptateurs WLAN USB sans fil disponibles qui peuvent être facilement utilisés avec un certain nombre d'outils, tels que OmniPeek et d'autres.
Prenez note de la manière dont les capacités des cartes sans fil spécifiques utilisées pour collecter une capture OTA 802.11n se comparent aux capacités du jeu de composants WLAN réel utilisé par les périphériques clients que vous tentez de dépanner. Par exemple, si le périphérique client rencontre un problème potentiel d'interopérabilité sans fil qui utilise un chipset 802.11n à 2 flux spatiaux (2SS). Ensuite, il est fortement recommandé de s'assurer que la carte sans fil utilisée pour collecter une capture de paquets OTA est également une carte 2SS ou supérieure, avec des spécifications 802.11n ou plus récentes.
Captures OTA 802.11ac
Pour les captures 802.11ac à 3 flux spatiaux (3SS), vous pouvez utiliser les capacités de reniflage natif d'un MacBook Pro 2014 ou ultérieur exécutant Mac OS X 10.10.x ou supérieur. Si vous dépannez un périphérique client 802.11ac à 2 flux spatiaux, vous pouvez également utiliser un MacBook Air pour les captures 802.11ac. Le modèle Air de MacBooks utilise uniquement des chipsets WLAN 2SS au moment de la rédaction de cet article. Vous pouvez consulter l'article ci-dessous sur les forums d'assistance Cisco pour obtenir des instructions sur la collecte de captures de paquets OTA à l'aide de Mac OS X, à l'aide de diverses méthodes :
Dotation sans fil avec l'utilisation de Mac OS X 10.6+
Vous pouvez également utiliser un point d'accès de la gamme 2702/2802/3702/3802 ou un point d'accès similaire en mode renifleur pour collecter une capture de paquets 802.11ac correcte avec 3SS. Vous pouvez également vous reporter à la ressource ci-dessous pour obtenir la liste actuelle des adaptateurs sans fil 802.11ac disponibles. Certaines peuvent être utilisées avec des outils courants tels que OmniPeek et d'autres pour collecter une capture de paquets 802.11ac (chipsets de Ralink, Atheros, etc.) :
https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters
Vous pouvez également utiliser un point d'accès de la gamme 2702/2802/3702/3802 ou un point d'accès similaire en mode renifleur pour collecter une capture de paquets 802.11ac correcte avec 3SS. Pour plus de commodité, des instructions détaillées sur la façon de configurer un point d'accès Cisco en mode renifleur et de collecter une capture de paquets OTA sont disponibles dans l'article ci-dessous des forums d'assistance Cisco :
Point d'accès Cisco en mode Sniffer
Pour le dépannage de scénarios d'itinérance avec un périphérique client sans fil, le défi le plus courant consiste à collecter efficacement une capture de paquets OTA sur plusieurs canaux. Cette méthode de surveillance simultanée de plusieurs canaux 802.11 est obtenue par la collecte de la capture de paquets OTA agrégée. Il est recommandé d'utiliser plusieurs adaptateurs WLAN USB compatibles 802.11ac avec un logiciel d'analyse de réseau compatible afin d'atteindre cet objectif. Parmi les cartes WLAN USB compatibles 802.11ac courantes, citons l'adaptateur Savvius WiFI pour OmniPeek (802.11ac), Netgear A6210, ou tout autre adaptateur similaire.
X. Résumé
Voici un bref résumé des informations à collecter pour résoudre efficacement un problème potentiel d'interopérabilité des clients sans fil avec un CUWN. Cette section est destinée à servir de section de référence rapide, selon les besoins.
I. Définition du problème
- Le problème est-il limité à un modèle spécifique de point d'accès et/ou de type radio (2,4 GHz contre 5 GHz) ?
- Le problème est-il observé uniquement sur des versions spécifiques du logiciel WLC (Wireless LAN Controller) ?
- Le problème concerne-t-il uniquement des versions spécifiques de type(s) client(s) et/ou logiciel (par exemple, version du système d'exploitation, version du pilote WLAN, etc.) ?
- Y a-t-il d'autres périphériques sans fil qui ne rencontrent pas ce problème ? Dans l'affirmative, lesquelles ?
- Le problème est-il reproductible lorsque le client est connecté à un SSID ouvert, à une largeur de canal de 20 MHz et à 802.11ac désactivé ? (c'est-à-dire le problème se produit-il uniquement en mode 11n et en mode 11ac)
- Si le problème n'est pas reproductible avec un SSID ouvert, à quelle configuration de sécurité minimale le problème est-il détecté ? (PSK ou 802.1X sur le WLAN)
- Quelle était la configuration de travail et les versions logicielles précédentes ?
II. Configuration et journaux du WLC
Collectez ceci à partir de l'interface de ligne de commande du ou des WLC(s) en question :
- config paging disable
- show run-config
Vous pouvez également collecter uniquement ces sorties si nécessaire :
- config paging disable
- show run-config no-ap
- show wlan apgroups
Sauvegarde de la configuration du WLC via TFTP, FTP, etc. (IUG: Commandes > Télécharger le fichier > Configuration)
Syslogs du WLC
III. Informations sur le périphérique client
- Type de client (tablette, smartphone, ordinateur portable, etc.)
- Marque et modèle des périphériques
- Version du système d'exploitation
- Modèle de carte WLAN
- Version du pilote de carte WLAN
- Supposant utilisé (par ex. Windows Zero Config / Auto Config, Intel PROSet, etc.)
- Sécurité configurée pour l'utilisation par le client sans fil et le WLAN (Open, PSK, EAP-PEAP/MSCHAPv2, etc.)
IV. Schéma de topologie du réseau
Cela doit inclure une représentation et/ou des détails concernant les périphériques sans fil du réseau (imprimantes/scanners, WLC, etc.)
V. Créer une feuille de calcul pour enregistrer tous les problèmes des clients
Exemple :
| Adresse MAC : | Nom d’utilisateur | Description du symptôme signalé | symptôme observé par l'utilisateur final | Ping de passerelle par défaut O/N | État du signal Wi-Fi (connecté/tentative de connexion) | Enregistrer ipconfig /all (ou équivalent) |
L'objectif de cet exercice est d'aider à identifier un modèle commun et de présenter une image plus précise des enjeux à l'étude.
VI. Commandes Show and Debug sur le WLC
Collectez ces débogages WLC via l'interface de ligne de commande :
- config sessions timeout 0
- debug client <adresse_MAC>
- debug dhcp message enable
Ajoutez les débogages supplémentaires au cas par cas :
- debug aaa detail enable - utilisez ceci s'il y a des problèmes liés à l'authentification avec le serveur AAA
- debug aaa events enable - utilisez ceci s'il y a des problèmes liés à l'authentification avec le serveur AAA
- debug aaa all enable - utilisez ceci pour les problèmes d'authentification ; c'est un verbose, donc utilisez-le uniquement lorsque nécessaire (c'est-à-dire pour les cas de remplacement AAA, etc.)
- debug mobility handoff - utilisation lors de problèmes d'itinérance entre les WLC
Collectez le résultat des commandes show du WLC via l'interface de ligne de commande :
- config paging disable
- show time
- show client detail <mac-address of client> (notez l'état du client sur le WLC)
- Envoyez une requête ping au client à partir du WLC
Une fois le test terminé, utilisez cette commande pour arrêter tous les débogages actuels sur le WLC :
- debug disable-all
VII. Commandes Show and Debug sur le point d'accès
Points d'accès Cisco IOS légers
Cette section décrit en détail les débogages requis pour les points d'accès de modèle 1700/2700/3700 ou précédents.
Pour éviter un délai d'expiration de session AP au moment d'une session Telnet/SSH/console, utilisez les commandes suivantes :
- debug capwap console cli
- config t
- line console 0 - permet de modifier les paramètres de temporisation de session série
- line vty 0 4 - permet de modifier les paramètres de temporisation de session Telnet/SSH
- exec-timeout 0
- session-timeout 0
- durée 0
Avant de commencer le test, collectez un exemple de ces commandes show sur l'AP. Au minimum, collectez deux échantillons de ce résultat, avant et après la fin des tests avec l'utilisation de ces commandes show AP via l'interface de ligne de commande :
- durée 0
- show clock
- show tech
- show capwap client mn
- show int do1 dfs
- show logging
- more event.log
- show trace dot11_rst display time format local
- show trace dot11_rst
- show trace dot11_bcn display time format local
- show trace dot11_bcn
Collectez ces débogages AP via l'interface de ligne de commande :
- debug dot11 { d0 | d1 } monitor addr <adresse_MAC>
- debug dot11 { d0 | d1 } trace print clients mgmt keys rxev txev rcv xmt txfail ba
- term mon
Une fois le test terminé, utilisez cette commande pour désactiver les débogages :
- tous
AP-COS AP
Cette section détaille les débogages requis pour les AP de la gamme 1800/2800/3800.
Pour éviter un délai d'expiration de session AP au moment d'une session Telnet/SSH/console, utilisez les commandes suivantes :
- exec-timeout 0
Avant de commencer le test, collectez un exemple des commandes show ci-dessous sur l'AP. Au minimum, collectez deux échantillons de ce résultat, avant et après la fin des tests avec l'utilisation de ces commandes show AP via l'interface de ligne de commande :
- durée 0
- show clock
- show tech
- show client statistics <adresse_MAC_client>
- show cont nss status
- show cont nss stats
- show log
Pour les points d'accès de la gamme 1800, collectez ces débogages AP via l'interface de ligne de commande :
- debug dot11 client events addr <adresse_MAC_client>
- debug dot11 client level errors addr <adresse_MAC_client>
- debug dot11 client level Critical addr <adresse_MAC_client>
- debug dot11 client level info addr <adresse_MAC_client>
- debug dot11 client datapath eapol addr <adresse_MAC_client>
- debug dot11 client datapath dhcp addr <adresse_MAC_client>
- debug dot11 client datapath arp addr <adresse_MAC_client>
- term mon
Pour les points d'accès de la gamme 2800/3800, collectez ces débogages AP via l'interface de ligne de commande :
- config ap client-trace address add <adresse_MAC_client>
- config ap client-trace filter all enable
- config ap client-trace output console-log enable
- config ap client-trace start
- term mon
Une fois le test terminé, utilisez cette commande pour désactiver les débogages :
- config ap client-trace stop
VIII. Captures côté client
Collectez une capture de paquets Netmon 3.4 (Windows XP ou 7 uniquement) ou Wireshark à partir de la carte WLAN du périphérique client.
IX. Captures OTA
Captures 802.11n
- AirPCAP avec Wireshark
- MacBook Pro
- OmniPeek Professionnel, Entreprise, etc.
- Assistant distant OmniPeek (ORA)
- Point d'accès Cisco en mode Sniffer
Captures 802.11ac
- Pour les captures 3SS 11ac, vous pouvez utiliser un Macbook Pro 2014 ou une version ultérieure exécutant 10.10.x ou une version ultérieure (n'utilisez pas MacBook Air pour les captures 11ac si possible, car il s'agit actuellement d'un périphérique 2SS uniquement).
- Vous pouvez également utiliser un point d'accès Cisco 2702, 3702 ou similaire en mode renifleur.
- Pour les scénarios d'itinérance et avec l'utilisation de logiciels professionnels d'analyse de réseau tels que OmniPeek de Savvius. Il est recommandé d'utiliser plusieurs adaptateurs WLAN USB compatibles 802.11ac, tels que l'adaptateur Savvius WiFI pour OmniPeek (802.11ac), Netgear A6210 ou un appareil similaire.
XI. Annexe A - Conseils et astuces supplémentaires
Fenêtres
Pour collecter des informations supplémentaires concernant la connexion sans fil actuelle et d'autres détails connexes directement à partir d'un ordinateur Windows. Vous pouvez utiliser ces commandes liées à netsh wlan dans la ligne de commande Windows (CMD) :C:\Users\engineer>netsh wlan show ?
These commands are available:
Commands in this context:
show all - Shows complete wireless device and networks information.
show allowexplicitcreds - Shows the allow shared user credentials settings.
show autoconfig - Shows whether the auto configuration logic is enabled or
disabled.
show blockednetworks - Shows the blocked network display settings.
show createalluserprofile - Shows whether everyone is allowed to create all
user profiles.
show drivers - Shows properties of the wireless LAN drivers on the system.
show filters - Shows the allowed and blocked network list.
show hostednetwork - Show hosted network properties and status.
show interfaces - Shows a list of the wireless LAN interfaces on
the system.
show networks - Shows a list of networks visible on the system.
show onlyUseGPProfilesforAllowedNetworks - Shows the only use GP profiles on GP
configured networks setting.
show profiles - Shows a list of profiles configured on the system.
show settings - Shows the global settings of wireless LAN.
show tracing - Shows whether wireless LAN tracing is enabled or disabled.
C:\Users\engineer>netsh wlan show interfaces
There are 3 interfaces on the system:
Name : Wireless Network Connection 8
Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter #5
GUID : 6beec9b0-9929-4bb4-aef8-0809ce01843e
Physical address : c8:d7:19:34:d5:85
State : disconnected
Name : Wireless Network Connection 4
Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter
GUID : 23aa09d4-c828-4184-965f-4e30f27ba359
Physical address : 48:f8:b3:b7:02:6e
State : disconnected
Name : Wireless Network Connection
Description : Intel(R) Centrino(R) Advanced-N 6200 AGN
GUID : 8fa038f8-74e0-4167-98f9-de0943f0096c
Physical address : 58:94:6b:3e:a1:d0
State : connected
SSID : snowstorm
BSSID : 00:3a:9a:e6:28:af
Network type : Infrastructure
Radio type : 802.11n
Authentication : WPA2-Enterprise
Cipher : CCMP
Connection mode : Profile
Channel : 157
Receive rate (Mbps) : 300
Transmit rate (Mbps) : 300
Signal : 80%
Profile : snowstorm
Hosted network status : Not started
C:\Users\engineer>netsh wlan show networks bssid | more
Interface name : Wireless Network Connection
There are 21 networks currently visible.
SSID 1 : snowstorm
Network type : Infrastructure
Authentication : WPA2-Enterprise
Encryption : CCMP
BSSID 1 : 00:3a:9a:e6:28:af
Signal : 99%
Radio type : 802.11n
Channel : 157
Basic rates (Mbps) : 24 39 156
Other rates (Mbps) : 18 19.5 36 48 54
BSSID 2 : 00:3a:9a:e6:28:a0
Signal : 91%
Radio type : 802.11n
Channel : 6
Basic rates (Mbps) : 1 2
Other rates (Mbps) : 5.5 6 9 11 12 18 24 36 48 54
-- More --
macOS (anciennement OS X)
Afin de collecter la sortie équivalente comme la commande ipconfig /all sur un PC Windows, vous pouvez utiliser la commande Linux/Unix commune de ifconfig pour répertorier les informations détaillées pour toutes les interfaces réseau sur un MacBook Apple. Si nécessaire, vous pouvez également spécifier de recevoir la sortie pour seulement l'interface sans fil native pour un MacBook donné (soit en0 ou en1, cela dépend du modèle). Comme cet exemple :
bash-3.2$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 14:10:9f:de:df:f3 inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4 inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255 nd6 options=1<PERFORMNUD> media: autoselect status: active
Afin d'obtenir des informations rapides mais détaillées concernant la connexion sans fil actuelle sur un MacBook. Vous pouvez également sélectionner l'icône WiFi dans le coin supérieur droit du Bureau tout en maintenant enfoncé le bouton option sur votre clavier, comme illustré dans l'image.
Une autre option utile est d'utiliser l'utilitaire caché de ligne de commande appelé aéroport. Il est fortement recommandé de ne l'utiliser qu'avec votre propre MacBook ou un Mac utilisé dans un environnement de laboratoire. Comme certains administrateurs réseau ne souhaitent pas accorder l'accès à cet utilitaire sur un MacBook d'utilisateur final, utilisez le niveau de prudence approprié en conséquence. Pour continuer, entrez ceci dans Terminal sur le MacBook en question :
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
Vous pouvez désormais utiliser facilement l'utilitaire CLI de l'aéroport. Voici un exemple :
bash-3.2$ airport -I
agrCtlRSSI: -61
agrExtRSSI: 0
agrCtlNoise: -90
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 216
maxRate: 300
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2
BSSID: 0:3a:9a:e6:28:af
SSID: snowstorm
MCS: 13
channel: 157,1
Pour faciliter encore plus le processus de collecte d'une capture de paquets OTA à canal unique 802.11 fiable avec l'utilisation des fonctionnalités d'un MacBook Pro ou similaire. Vous pouvez soit tirer parti des fonctionnalités intégrées dans macOS avec l'utilisation de la méthode Wireless Diagnostics > Sniffer ou similaire comme indiqué précédemment, mais vous pouvez également utiliser un utilitaire tiers appelé Airtool (OS X 10.8 et versions ultérieures). L'avantage est une interface simple permettant de collecter rapidement une capture de paquets OTA, qui est enregistrée directement sur le bureau en quelques clics à travers l'interface utilisateur de l'application à partir de la barre de menus supérieure de votre écran.
Pour plus d'informations et de liens de téléchargement pour Airtool, consultez la page suivante :
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
14-May-2016 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)