Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
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.
Note: Le public visé par ce document est composé d'ingénieurs réseau sans fil expérimentés et d'administrateurs qui connaissent déjà l'utilisation, la configuration et le dépannage de ces sujets.
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.
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 :
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
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 :
Commandes > Upload File > Configuration > Upload comme illustré dans l'image.
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
À 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
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 :
Note: Toute information ou note supplémentaire concernant le ou les périphériques clients, jusqu'à laquelle figurent des captures d'écran de sa ou de ses configurations WLAN, etc., doit également être incluse si nécessaire.
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.
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 :
Note: Tous les débogages et les captures de paquets collectés doivent être synchronisés sur le même serveur NTP pour faciliter la corrélation avec les journaux, et doivent être pris en même temps pour tout test donné.
Note: Fournir un horodatage précis du moment où le problème est observé et du moment où le problème semble se rétablir (le cas échéant).
Note: Collectez toujours les débogages filtrés par adresse MAC client sur l'AP et le WLC.
Remarque : n'exécutez pas les commandes show et debug sur l'AP dans la même session Telnet/SSH/console, elles doivent être exécutées séparément dans une session différente en conséquence.
Remarque : les débogages AP sont préférables sur Telnet/SSH plutôt que sur Console, car la console est généralement trop lente pour être efficace.
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.
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 :
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
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.
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.
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
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
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
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
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
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
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
À 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é.
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é.
Note: Si le ou les tests en question impliquent un scénario d’itinérance de périphérique client, selon lequel plus d’un canal 802.11 doit être surveillé dans une capture de paquets agrégée. Il n'est donc pas recommandé d'utiliser AirMagnet WiFi Analyzer à partir de Fluke Networks.
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 :
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.
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.
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.
Collectez ceci à partir de l'interface de ligne de commande du ou des WLC(s) en question :
Vous pouvez également collecter uniquement ces sorties si nécessaire :
Sauvegarde de la configuration du WLC via TFTP, FTP, etc. (IUG: Commandes > Télécharger le fichier > Configuration)
Syslogs du WLC
Note: Tous les paramètres du client ont été modifiés par rapport aux paramètres par défaut fournis par le fournisseur en question. (par exemple, état de veille, paramètres d'itinérance, U-APSD, etc.)
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.)
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.
Collectez ces débogages WLC via l'interface de ligne de commande :
Ajoutez les débogages supplémentaires au cas par cas :
Collectez le résultat des commandes show du WLC via l'interface de ligne de commande :
Une fois le test terminé, utilisez cette commande pour arrêter tous les débogages actuels sur le WLC :
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 :
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 :
Collectez ces débogages AP via l'interface de ligne de commande :
Une fois le test terminé, utilisez cette commande pour désactiver les débogages :
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 :
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 :
Pour les points d'accès de la gamme 1800, collectez ces débogages AP via l'interface de ligne de commande :
Pour les points d'accès de la gamme 2800/3800, collectez ces débogages AP via l'interface de ligne de commande :
Une fois le test terminé, utilisez cette commande pour désactiver les débogages :
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.
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 --
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 :
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
14-May-2016 |
Première publication |