Problembehebung bei Problemen mit der Interoperabilität des Wireless-Clients mit CUWN

Einleitung

In diesem Dokument werden Interoperabilitätsprobleme im Zusammenhang mit der Cisco Unified Wireless Network (CUWN)-Lösung beschrieben. 

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Wireless APs
• Wireless LAN Controller (WLC)
• Zugehörige Netzwerkgeräte

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hinweis: Die Zielgruppe für dieses Dokument sind erfahrene Wireless-Netzwerktechniker und Administratoren, die bereits mit der Verwendung, Konfiguration und Fehlerbehebung dieser Themen vertraut sind.

Hintergrundinformationen

Es kann üblich sein, zu finden, dass angesichts der verschiedenen Client-Geräte, die sowohl existieren und weiter entwickelt werden. Es kann eine Vielzahl von Problemen auftreten, wenn es darum geht, die Verbindung zum Wireless-Netzwerk herzustellen, zu warten oder einfach nur das Beste aus ihnen herauszuholen und die Infrastruktur zu unterstützen.

Dies kann häufig auf ein einfaches Konfigurationsproblem seitens des Client-Geräts und/oder der Wireless-Infrastruktur selbst zurückzuführen sein. In einigen Fällen kann dies jedoch auf ein Interoperabilitätsproblem in Bezug auf ein bestimmtes Client-Gerät und dessen unterstützende Komponenten (Supplicant, WLAN-Adapter, Wireless-Treiber,...) und/oder die betreffenden APs zurückgeführt werden. Als Wireless-Techniker bieten solche Interoperabilitätsprobleme eine Möglichkeit, potenziell komplexe Herausforderungen zu identifizieren, zu beheben und zu lösen.

In diesem Dokument wird detailliert beschrieben, welche Informationen zunächst erfasst werden müssen, um solche Probleme hinsichtlich der Wireless-Interoperabilität, die bei der Unified Wireless Network (CUWN)-Lösung von Cisco auftreten, effektiv zu untersuchen und zu beheben. Die Notwendigkeit eines solchen umfassenden Ansatzes wird mit der stetig wachsenden Zahl und Kombination von Wireless-Client-Geräten und Access Point-Funkgeräten immer wichtiger. Zusätzliche Informationen zu den in diesem Artikel beschriebenen Aspekten können von Fall zu Fall angefordert und gesammelt werden, da eine unbegrenzte Anzahl von Variablen diese Anforderungen bestimmen kann. Die hier aufgeführten Informationen stellen jedoch einen allgemeinen Leitfaden für die Behandlung potenzieller Probleme im Zusammenhang mit der Interoperabilität von Wireless-Clients dar.

I. Problemdefinition

Der erste Schritt, jedes Problem mit der Absicht, gelöst zu werden, effektiv anzugehen, besteht darin, das vorliegende Problem genau zu definieren. Zu diesem Zweck ist sicherzustellen, dass mindestens diese Fragen gestellt und ihre Antworten klar dokumentiert werden:

• Ist das Problem auf ein bestimmtes AP- und/oder Funkmodell (2,4 GHz gegenüber 5 GHz) beschränkt?
• Wird das Problem nur bei bestimmten Versionen der WLC-Software festgestellt?
• Tritt das Problem nur bei bestimmten Versionen von Clienttyp(en) und/oder Software auf (Betriebssystemversion, WLAN-Treiberversion,...)
• Gibt es andere Wireless-Geräte, bei denen dieses Problem nicht auftritt? Wenn ja, welche?
• Ist das Problem reproduzierbar, wenn der Client mit einer vereinfachten Wireless-Konfiguration wie einer offenen SSID mit einer Kanalbreite von 20 MHz verbunden und 802.11ac deaktiviert ist? (Tritt das Problem also nur im 802.11n-Modus und nicht nur im 802.11ac-Modus auf?)
• Wenn das Problem bei einer offenen SSID nicht reproduzierbar ist, welche Mindestsicherheitskonfiguration ist für das Problem erforderlich? (PSK oder 802.1X im WLAN).
• Wie lauteten die vorherigen zweifelsfrei funktionierenden Konfigurations- und Softwareversionen?

II. WLC-Konfiguration und allgemeine Protokolle

Ausführungskonfiguration

Ausnahmslos ist es unbedingt erforderlich, die WLC-Konfiguration zu erfassen, um eine detaillierte Überprüfung der vom Kunden verwendeten Funktionen, ihrer spezifischen Konfiguration und anderer solcher Details zu erhalten. Dazu müssen Sie eine Telnet/SSH-Sitzung mit den entsprechenden WLCs einrichten und die Ausgabe dieser CLI-Befehle in einer Textdatei speichern:

config paging disable

show run-config

Die vollständige Ausgabe von run-config wird immer bevorzugt, da sie detaillierte Informationen zu den verbundenen APs und den zugehörigen RF-Informationen enthält. Allerdings in einigen Fällen und Situationen, z. B. wenn Sie zu Beginn mit einem WLC mit einer großen Anzahl verbundener APs arbeiten (8510 WLC mit mehr als 2500 APs). Es könnte vorgezogen werden, zunächst nur die Konfiguration des WLC ohne solche AP-Informationen zu erfassen, um sie schnell zu überprüfen, da die vollständige Anzeige der Ausführungskonfiguration 30 Minuten oder länger dauern kann, bis die angegebene Anzahl von APs abgeschlossen ist. Es kann jedoch weiterhin erforderlich sein, die Ausgabe für die vollständige Run-Konfiguration zu einem späteren Zeitpunkt zu erfassen.

Dazu können Sie optional die Ausgabe dieser CLI-Befehle in eine Textdatei sammeln:

config paging disable

show run-config no-ap

show wlan apgroups

WLC-Konfigurationsdatei

Zusätzlich zur Ausgabe von show run-config oder show run-config no-ap wird auch empfohlen, ein vollständiges Backup der WLC-Konfiguration zu erstellen. Dies ist hilfreich, wenn ein Labor-Remix über TAC/HTTS und BU Eskalation durchgeführt werden muss, um das Problem in einer Cisco Laborumgebung zu reproduzieren. Ein Backup des WLC kann über die GUI oder die CLI des jeweiligen WLC gesammelt werden, wobei die Konfigurationsdatei über TFTP oder FTP auf dem externen TFTP/FTP-Server gespeichert wird. Dieses Beispiel zeigt die Verwendung der Benutzeroberfläche und der CLI zum Speichern eines Backups des WLC unter Verwendung von TFTP:

GUI

Befehle > Datei hochladen > Konfiguration > Hochladen wie im Bild dargestellt.

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 vom WLC

Zu diesem Zeitpunkt möchten Sie bei Bedarf auch die aktuellen Protokolle vom WLC sammeln, um sie noch einmal überprüfen zu können. Im Idealfall sollten diese Protokolle unmittelbar nach dem Test mit einem Wireless-Client gesammelt werden, wodurch das gemeldete Problem reproduziert wird. Wenn der Kunde die WLC-Protokolle an einen externen Syslog-Server exportiert, möchten Sie sie von dort abrufen. Andernfalls können Sie das msglog und das Traplog, die derzeit lokal auf dem WLC gespeichert sind, speichern, indem Sie diese CLI-Sitzungsausgabe in einer anderen Textdatei speichern:

config paging disable

show msglog

show traplog

III. Details und Informationen zu Clientgeräten

Der nächste Schritt besteht darin, so viele Informationen und Details zu den verwendeten Client-Geräten zu sammeln, bei denen ein potenzielles Problem mit der Wireless-Interoperabilität auftritt. Diese Informationen müssen Folgendes umfassen, sind jedoch nicht unbedingt darauf beschränkt:

• Client-Typ (Tablet, Smartphone, Notebook, ...)
• Gerätehersteller und -modell
• Betriebssystemversion
• WLAN-Adaptermodell
• Treiberversion des WLAN-Adapters
• Verwendete Komponente (Windows Zero Config/Auto Config, Intel PROSet, ...)
• Für die Verwendung durch den Wireless-Client und das WLAN konfigurierte Sicherheit (offen, PSK, EAP-PEAP/MSCHAPv2,...)
• Beachten Sie alle Client-Parameter, die von den vom jeweiligen Anbieter bereitgestellten Standardeinstellungen abweichen (Ruhezustand, Roaming-Parameter, U-APSD,...).

Hinweis: Zusätzliche Informationen oder Hinweise zu den Client-Geräten, einschließlich Screenshots der WLAN-bezogenen Konfiguration usw. müssen bei Bedarf ebenfalls bereitgestellt werden.

IV. Netzwerktopologie

Um die Fehlerbehebung und den Prozess der Ursachenanalyse (Root Cause Analysis, RCA) weiter zu beschleunigen, wird stets empfohlen, ein detailliertes und detailliertes Netzwerktopologiediagramm bereitzustellen. Das Netzwerktopologiediagramm muss nicht nur Details über das Netzwerk und die Wireless-Infrastruktur enthalten, sondern auch einen Einblick in die betreffenden Wireless-Geräte geben, die innerhalb des Netzwerks betrieben werden ( Drucker/Scanner, welche Client-VLAN(s) genutzt werden,...) und deren Position(en) zueinander.

Eine Reihe von Tools (Microsoft Visio, draw.io,...) und eine Vielzahl von Stilen können verwendet werden, um ein solches Netzwerkdiagramm zu erstellen. Wichtig ist dabei lediglich, sicherzustellen, dass die richtigen Informationen in dem Diagramm, das von allen Beteiligten und Anbietern zur Prüfung bereitgestellt wird, klar und deutlich wiedergegeben werden. Eine Beispiel-Netzwerktopologie, die grundlegende, aber nützliche Informationen sowohl zur Infrastruktur als auch zu den Client-Geräten erfasst, wie im Bild gezeigt.

V. Verfolgen Sie zusätzliche Details und Details.

Um sicherzustellen, dass bei jedem Test mit den Client-Geräten, bei denen Endbenutzer Probleme haben, die entsprechenden Informationen gesammelt werden. Es wird empfohlen, präventiv eine Tabelle oder Ähnliches zu erstellen, um alle Client-Probleme und die zugehörigen Details aufzuzeichnen, die zum Zeitpunkt des Tests beobachtet wurden, wie in diesem Beispiel:

MAC-Adresse	Benutzername	Beschreibung des gemeldeten Symptoms	Zeitpunkt, zu dem der Endbenutzer das Symptom beobachtet hat	Ping für Standardgateway J/N	WiFi-Signalstatus (Verbunden/Verbindungsversuch)	ipconfig /all (oder gleichwertig) aufzeichnen
xxyy.aabb.0011	Test_Benutzer1	Unterbrechungsfreie Verbindung zum Access Point	Netzwerkverbindung und Wireless-Verbindung vom AP3 unterbrochen.	N	Verbindungsversuch	ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500     Ether xx:yy:aa:bb:00:11     inet6 fe80::848:cb8f:881a:4cbf%en0 prefixlen 64 gesicherter Bereich 0x4     inet 192.168.10.237 netmask 0xffffff00 broadcast 192.168.10.255     nd6 options=201<LEISTUNG,DAD>     Medien: automatische Auswahl     Status: aktiv

Ziel dieser Übung ist es, ein gemeinsames Muster zu dokumentieren und zu ermitteln sowie ein genaues Bild der aktuellen Probleme zu erhalten. Sobald diese Tabelle für die Datenerfassung vorbereitet wurde, können Sie mit den Tests beginnen. Weitere, jedoch wichtige Überlegungen:

Hinweis: Alle gesammelten Debug- und Paketerfassungen müssen mit demselben NTP-Server synchronisiert werden, um die Korrelation mit den Protokollen zu vereinfachen. Sie müssen für jeden Test gleichzeitig durchgeführt werden.

Hinweis: Geben Sie einen genauen Zeitstempel an, wann das Problem festgestellt wurde und wann es sich zu erholen scheint (falls zutreffend).

Hinweis: Sammeln Sie auf dem AP und dem WLC stets die nach der MAC-Adresse des Clients gefilterten Debugging-Meldungen.

Hinweis: Führen Sie auf dem Access Point innerhalb derselben Telnet-/SSH-/Konsolensitzung keine Befehle zum Anzeigen und Debuggen aus. Diese werden entsprechend separat in einer anderen Sitzung ausgeführt.

Hinweis: AP-Fehlerbehebungen werden bevorzugt bei Telnet/SSH und nicht bei der Konsole durchgeführt, da die Konsole in der Regel zu langsam ist, um effektiv zu sein.

VI. WLC - Befehle anzeigen und debuggen

Bei der Durchführung von Tests zur Reproduktion und Fehlerbehebung potenzieller Probleme mit der Interoperabilität von Wireless-Clients müssen in der verwendeten Wireless-Infrastruktur unbedingt Fehlerbehebungen und zusätzliche Protokolle erfasst werden. In diesen beiden Abschnitten werden die spezifischen Protokolle und die anfängliche Debugausgabe, die vom WLC bzw. den APs erfasst werden, ausführlich erläutert.

WLC-Debug-Befehle

config sessions timeout 0
debug client <MAC_address>
debug dhcp message enable

In Bezug auf die Art des vorliegenden Problems können Sie diese WLC-Debugs auch von Fall zu Fall hinzufügen:

• debug aaa detail enable - Verwenden Sie diese Option, wenn Probleme mit der Authentifizierung beim AAA-Server auftreten.
• debug aaa events enable - Verwenden Sie diese Option, wenn Probleme mit der Authentifizierung beim AAA-Server auftreten.
• debug aaa all enable - Verwenden Sie diesen Parameter für Authentifizierungsprobleme. Die Ausgabe für diesen Debugger ist ausführlich, verwenden Sie ihn daher nur, wenn dies unbedingt erforderlich ist (bei AAA-Überschreibungsfällen...)
• debug mobility handoff - bei Roaming-Problemen zwischen WLCs verwenden

Sobald das Problem mit dem betreffenden Wireless-Client reproduziert wurde und alle in den vorherigen und folgenden Abschnitten beschriebenen Informationen gesammelt und dokumentiert wurden. Um diese CLI-Befehle auszuführen, müssen Sie die Debugging-Funktionen auf dem WLC deaktivieren.

debug disable-all

WLC Befehle anzeigen

config paging disable

show time

show client detail <MAC_address>

ping <client_IP-address> <repeat count [1-100]>

Stellen Sie wie bereits erwähnt sicher, dass die WLC-Debugging-Vorgänge in einer Telnet/SSH-Sitzung ausgeführt und die Ausgabe für diese Show-Befehle in einer anderen Telnet/SSH-Sitzung des WLC gesammelt wird. Sie müssen das Gleiche tun, um die AP-Debugs zu sammeln und die Ausgabe der Befehle anzuzeigen, die in diesem Abschnitt detailliert beschrieben sind.

VII. AP - Befehle anzeigen und debuggen

Leichte Cisco IOS® Access Points

Bevor Sie mit der Fehlerbehebung für die im Test verwendeten Lightweight Cisco IOS® APs (z. B. Access Points der Serien 2600, 2700, 3700 oder ältere Modelle von Cisco) beginnen, Sie müssen diese CLI-Befehle zunächst auf dem Access Point ausführen, um eine Zeitüberschreitung bei einer Telnet-/SSH-/Konsolensitzung mit den betreffenden Access Points zu vermeiden, wenn der Client Folgendes testet:

debug capwap console cli

config t

line vty 0 4

exec-timeout 0

session-timeout 0

Sie können diese Schritte auch ausführen, um die Konsolenverbindung zu verwenden und stattdessen die Anweisung line vty 0 4 durch line console 0 zu ersetzen, um die exec- und Session-Timeouts für eine serielle/Konsolenverbindung entsprechend zu deaktivieren.

• line console 0 - dient zum Ändern der Timeout-Parameter für serielle Sitzungen
• line vty 0 4 - zum Ändern der Timeout-Parameter für Telnet-/SSH-Sitzungen

AP Befehle anzeigen

Bevor Sie mit dem Test beginnen, müssen Sie zunächst ein Beispiel dieser Befehle zum Anzeigen des Access Points sammeln. Sammeln Sie die Ausgabe dieser show-Befehle mindestens zweimal für jeden Test, an dem der betreffende Wireless-Client beteiligt ist, sowohl vor als auch nach Abschluss des Tests.

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 

AP-Debug-Befehle

Nachdem Sie die erste Ausgabe der zuvor genannten show-Befehle gesammelt haben, können Sie die Debug-Vorgänge nun wie dargestellt auf demselben Access Point in einer separaten Telnet/SSH-Sitzung aktivieren. Stellen Sie sicher, dass die gesamte Ausgabe in einer Textdatei gespeichert wird.

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

Flag	Beschreibung
d0	2,4-GHz-Funkmodul (Steckplatz 0)
D1	5-GHz-Funkmodul (Steckplatz 1)
Verwaltung	Trace-Verwaltungspakete
Ba	Trace-Block ACK-Informationen
Empf	Trace empfangener Pakete
Tasten	Trace-Set-Schlüssel
rxev	Trace empfangene Ereignisse
TXEV	Übertragene Ereignisse verfolgen
Txrad	Trace wird an Funk übertragen
xmt	Trace überträgt Pakete
txfail	Fehler bei Trace-Übertragung
Tarife	Änderungen der Trace-Rate

Wenn Sie die Fehlersuche am Access Point deaktivieren möchten, nachdem der Test- und Datensammlungsprozess abgeschlossen ist, können Sie den folgenden CLI-Befehl am Access Point ausführen:

u all

AP-COS Access Points

Für 802.11ac Wave 2-fähige Access Points und neuere Versionen, z. B. Access Points der Modelle 1800, 2800 und 3800. Diese neueren Access Point-Modelle führen ein völlig neues Betriebssystem für die Access Point-Plattformen ein, das als AP-COS bezeichnet wird. Daher gelten nach wie vor nicht alle Befehle, die zuvor für die herkömmlichen Lightweight Cisco IOS® Access Points verwendet wurden. Wenn bei der Fehlerbehebung ein Interoperabilitätsproblem mit verschiedenen Client-STA-Geräten und AP-COS-Modell-APs auftritt, müssen diese Informationen von den AP-COS-Access Points gesammelt werden, die an dem entsprechenden Test beteiligt sind.

Vor dem Starten von Debugs auf AP-COS-Modell-APs, die an dem Test beteiligt sind. Sie müssen zuerst diesen CLI-Befehl auf dem Access Point ausführen, um ein Timeout zum Zeitpunkt einer Telnet-/SSH-/Konsolensitzung mit den betreffenden Access Points zu vermeiden, wenn der Client Folgendes testet:

exec-timeout 0

AP-COS Befehle anzeigen

Bevor Sie mit dem Test beginnen, müssen Sie zunächst ein Beispiel dieser Befehle zum Anzeigen des Access Points sammeln. Sammeln Sie die Ausgabe dieser show-Befehle mindestens zweimal für jeden Test, an dem der betreffende Wireless-Client beteiligt ist, sowohl vor als auch nach Abschluss des Tests.

term len 0

show clock

show tech

show client statistics <client_MAC-address>

show cont nss status

show cont nss stats

show log

Serie 1800 | AP-COS-Debugbefehle

Diese Fehlerbehebungen sind spezifisch für die Access Points der Serie 18xx. Dies ist darauf zurückzuführen, dass sich die für die Access Points der Serie 1800 verwendeten Chipsätze von denen der Access Points der Serien 2800/3800 unterscheiden. In diesem Szenario ist daher ein anderer Satz an Debugging-Vorgängen erforderlich. Die entsprechenden Fehlerbehebungsmaßnahmen für die Access Points der Serien 2800/3800 werden im nächsten Abschnitt behandelt.

Nachdem Sie die erste Ausgabe der zuvor genannten show-Befehle gesammelt haben, müssen Sie nun die Debug-Vorgänge auf denselben 1800 Access Points in einer separaten Telnet/SSH-Sitzung wie dargestellt aktivieren. Stellen Sie sicher, dass die gesamte Ausgabe in einer Textdatei gespeichert wird.

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>

In einigen Fällen müssen Sie möglicherweise auch die zusätzlichen Debugging-Funktionen auf dem 18xx AP aktivieren, um weitere Probleme mit der Client-Interoperabilität zu beheben. Dies sollte jedoch nur dann erfolgen, wenn/wie von einem Cisco TAC-Techniker für eine entsprechende Serviceanfrage/einen entsprechenden Fall angefordert.

Da zusätzliche Debugs nicht nur viel ausführlicher ausgegeben werden können, sondern auch eine zusätzliche Last für den Access Point verursachen können, benötigt es zusätzliche Zeit für die ordnungsgemäße Analyse. Dies kann unter bestimmten Bedingungen den Dienst möglicherweise unterbrechen, wenn viele Client-Geräte versuchen, unter Test oder ähnlichen Variablen eine Verbindung mit demselben Access Point herzustellen.

Um die Fehlersuche auf dem Access Point mit der Variante AP-COS zu deaktivieren (auf einem Access Point der Serien 1800 oder 2800/3800), können Sie nach Abschluss des Test- und Datensammlungsprozesses den folgenden CLI-Befehl auf dem Access Point ausführen:

config ap client-trace stop 

Serie 2800/3800 | AP-COS-Debugbefehle

Nachdem Sie die anfängliche Ausgabe der oben genannten show-Befehle gesammelt haben, müssen Sie nun die Debug-Vorgänge auf denselben 2800/3800 Access Points wie dargestellt in einer separaten Telnet/SSH-Sitzung aktivieren. Stellen Sie sicher, dass die gesamte Ausgabe in einer Textdatei gespeichert wird.

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

Um die Fehlersuche auf dem Access Point der Serien 1800/2800/3800 zu deaktivieren, nachdem der Test- und Datensammlungsprozess abgeschlossen ist, können Sie den folgenden CLI-Befehl auf dem Access Point ausführen:

config ap client-trace stop

VIII. Clientseitige Paketerfassung

Wenn es sich bei dem verwendeten Client-Gerät um einen Notebook-PC, ein MacBook oder Ähnliches handelt, müssen Sie die Paketerfassung im Promiscuous-Modus von der Wireless-Schnittstelle des Client-Geräts sammeln, mit dem das Problem reproduziert wurde. Allgemeine Dienstprogramme wie Netmon 3.4 (nur Windows) oder Wireshark können einfach heruntergeladen und verwendet werden, um diese Erfassung zu sammeln und sie in einer *.pcap-Datei zu speichern. Es hängt von dem Gerät ab, es kann auch Mittel geben, um einen tcpdump oder Ähnliches von dem betreffenden Client zu sammeln, so können Sie sich mit dem Hersteller des Client-Geräts für Unterstützung in dieser Hinsicht beraten müssen.

Hier ist ein Beispiel, um eine Wireshark-Aufzeichnung für die Wireless-Schnittstelle auf einem MacBook Pro zu konfigurieren:

Wie bei jeder Paketerfassung, unabhängig davon, welches Dienstprogramm verwendet wird, um sie zu sammeln, stellen Sie sicher, dass die Datei in einem pcap-Dateiformat (*.pcap, *.pcapng, *.pkt,...). So soll sichergestellt werden, dass nicht nur Cisco Techniker in allen Abteilungen die Paketerfassungsdateien mit Leichtigkeit anzeigen können, sondern auch Techniker von anderen Anbietern und Organisationen (Intel, Apple usw.). Dies ermöglicht einen nahtloseren Kooperations- und Kooperationsprozess, der die Zusammenarbeit zwischen Cisco und dem/den Clientgerätehersteller(n) bei der Untersuchung und Behebung potenzieller Interoperabilitätsprobleme weiter vereinfacht.

IX. Over-the-Air (OTA)-Paketerfassung

Um potenzielle oder bestehende Probleme mit der Wireless-Interoperabilität effizient beheben zu können, ist es wichtig, eine qualitativ hochwertige OTA-Paketerfassung des Problems zu erfassen. Dies ermöglicht die detaillierte Analyse der tatsächlichen 802.11-Wireless-Kommunikation zwischen den betreffenden Wireless-Client- und Access Point-Funkmodulen und gibt darüber hinaus eine weitere Perspektive für die Client-Seite und die Protokolle und Fehlerbehebungen der Wireless-Infrastruktur. Dies ist ein wichtiger Schritt, der ausnahmslos für jeden Test eines potenziellen Problems mit der Wireless-Interoperabilität durchgeführt werden muss.

Häufig ist der Endkunde jedoch nicht angemessen ausgestattet oder bereit, OTA-Paketerfassungen zu sammeln. Wireless-Techniker stehen häufig vor einem solchen Hindernis und müssen mit dem Kunden zusammenarbeiten, um dieses Problem auf verschiedene Weise zu lösen. Dieser Artikel aus den Cisco Support-Foren kann als guter Ausgangspunkt dienen, um den Kunden entsprechend zu führen und zu schulen:

802.11 Wireless-Sniffing/Paketerfassung

Es ist von größter Wichtigkeit, dass die OTA-Paketerfassung(en) in einem pcap-Dateiformat (*.pcap, *.pcapng, *.pkt,...) erfasst wird und 802.11-Metadaten (RSSI, Kanal, Datenrate,...) umfasst. Der OTA-Sniffer muss außerdem während der Tests stets in unmittelbarer Nähe des betreffenden Client-Geräts aufbewahrt werden, um eine genaue Übersicht über den an das bzw. von dem getesteten Client-Gerät gesendeten und empfangenen Datenverkehr zu erhalten.

Hinweis: Wenn die fraglichen Tests ein Client-Geräte-Roaming-Szenario beinhalten, bei dem mehr als ein 802.11-Kanal in einer aggregierten Paketerfassung überwacht werden muss. Dann ist es derzeit nicht empfehlenswert, AirMagnet WiFi Analyzer von Fluke Networks zu verwenden.

Der Grund dafür ist die Tatsache, dass aggregierte Paketerfassungen unter Verwendung dieses Dienstprogramms derzeit in einem proprietären Dateiformat gespeichert werden und nicht in einem pcap-Format, das in Wireshark oder anderen ähnlichen Dienstprogrammen problemlos angezeigt werden kann. Stellen Sie sicher, dass Ihre OTA-Paketerfassung in einem nicht proprietären Dateiformat vorliegt. Auf diese Weise wird sichergestellt, dass alle beteiligten Parteien und Anbieter jederzeit problemlos sämtliche Erfassungsdateien überprüfen können und letztendlich die Problembehebung beschleunigt wird.

Es folgen einige gängige Methoden zum Sammeln einer OTA-Paketerfassung:

• AirPCAP mit Wireshark
• MacBook Pro
• OmniPeek Professional, OmniPeek Enterprise,...
• OmniPeek Remote Assistant (ORA)
• Cisco AP im Sniffer-Modus

802.11n-Erfassungen

Für OTA-Paketerfassungen, die 802.11n-Wireless-Clients umfassen, gibt es derzeit mehr Flexibilität und Benutzerfreundlichkeit. Dies ist auf eine größere Vielfalt von verfügbaren Wireless USB WLAN-Adaptern zurückzuführen, die problemlos mit einer Reihe von Tools wie OmniPeek und anderen verwendet werden können.

Beachten Sie, dass die Funktionen der spezifischen Wireless-Adapter, die für die Erfassung einer 802.11n-OTA verwendet werden, mit denen des tatsächlichen WLAN-Chipsatzes verglichen werden, der von den Client-Geräten verwendet wird, für die Sie eine Fehlerbehebung durchführen möchten. Beispiel: Das Client-Gerät weist ein potenzielles Problem mit der Wireless-Interoperabilität auf, bei der ein 802.11n-Chipsatz mit zwei räumlichen Streams (2SS) verwendet wird. In diesem Fall wird dringend empfohlen, sicherzustellen, dass der Wireless-Adapter, der für die Erfassung von OTA-Paketen verwendet wird, auch ein 2SS- oder besserer Adapter mit 802.11n- oder neueren Spezifikationen ist.

802.11ac OTA-Erfassungen

Für 3 802.11ac-Aufnahmen mit räumlichem Datenstrom (3SS) können Sie die nativen Sniffing-Funktionen eines 2014-Modells MacBook Pro oder höher mit Mac OS X 10.10.x oder höher verwenden. Wenn Sie ein 802.11ac-Client-Gerät mit zwei Signalströmen zur Fehlerbehebung verwenden, können Sie auch ein MacBook Air für 802.11ac-Aufnahmen verwenden. Das Air-Modell von MacBooks verwendet 2SS nur WLAN-Chipsätze derzeit zum Zeitpunkt dieser Veröffentlichung. Anweisungen zum Sammeln von OTA-Paketerfassungen unter Verwendung von Mac OS X finden Sie im folgenden Artikel in den Cisco Support-Foren. Hierbei stehen verschiedene Methoden zur Verfügung:

Wireless-Sniffing mit Mac OS X 10.6+

Sie können auch einen Access Point der Serien 2702/2802/3702/3802 oder einen ähnlichen Access Point im Sniffer-Modus verwenden, um eine ordnungsgemäße 802.11ac-Paketerfassung mit 3SS zu erfassen. Eine aktuelle Liste der verfügbaren 802.11ac Wireless-Adapter finden Sie in der aufgeführten Ressource. Einige davon können potenziell mit gängigen Tools wie OmniPeek und anderen verwendet werden, um eine 802.11ac-Paketerfassung zu erfassen (Chipsätze von Ralink, Atheros, ...):

https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters

Sie können auch einen Access Point der Serien 2702/2802/3702/3802 oder einen ähnlichen Access Point im Sniffer-Modus verwenden, um eine ordnungsgemäße 802.11ac-Paketerfassung mit 3SS zu erfassen. Schrittweise Anleitungen zur Konfiguration eines Cisco AP im Sniffer-Modus und zum Erfassen von OTA-Paketen finden Sie im folgenden Artikel in den Cisco Support-Foren:

Cisco AP im Sniffer-Modus

Bei der Fehlerbehebung von Roaming-Szenarien mit einem Wireless-Client-Gerät besteht die allgemeine Herausforderung darin, eine OTA-Paketerfassung über mehrere Kanäle effektiv zu erfassen. Diese Methode zur gleichzeitigen Überwachung mehrerer 802.11-Kanäle wird durch die Erfassung aggregierter OTA-Pakete erreicht. Es wird empfohlen, mehrere, kompatible 802.11ac-fähige USB-WLAN-Adapter mit einer kompatiblen Netzwerkanalysesoftware zu verwenden, um dieses Ziel zu erreichen. Zu den gängigen 802.11ac-fähigen USB-WLAN-Adaptern gehören der Savvius WiFI-Adapter für OmniPeek (802.11ac), Netgear A6210 oder Ähnliches.

X. Zusammenfassung

Im Folgenden finden Sie eine kurze Zusammenfassung der Informationen, die erfasst werden müssen, um ein potenzielles Problem der Interoperabilität von Wireless-Clients mit einem CUWN effektiv zu beheben. Dieser Abschnitt soll bei Bedarf als Kurzreferenz dienen.

I. Problemdefinition

• Ist das Problem auf ein bestimmtes Access Point- und/oder Funkmodell (2,4 GHz gegenüber 5 GHz) beschränkt?
• Wird das Problem nur bei bestimmten Versionen der Wireless LAN Controller (WLC)-Software festgestellt?
• Tritt das Problem nur bei bestimmten Versionen von Clienttyp(en) und/oder Software auf (Betriebssystemversion, WLAN-Treiberversion,...)
• Gibt es andere Wireless-Geräte, bei denen dieses Problem nicht auftritt? Wenn ja, welche?
• Ist das Problem reproduzierbar, wenn der Client mit einer offenen SSID verbunden ist, eine Kanalbreite von 20 MHz aufweist und 802.11ac deaktiviert ist? (Tritt das Problem nur im 11n-Modus und im 11ac-Modus auf?)
• Wenn das Problem bei einer offenen SSID nicht reproduzierbar ist, welche Mindestsicherheitskonfiguration ist für das Problem erforderlich? (PSK oder 802.1X im WLAN)
• Wie lauteten die vorherigen zweifelsfrei funktionierenden Konfigurations- und Softwareversionen?

II. WLC-Konfiguration und Protokolle

Wählen Sie dies aus der CLI der entsprechenden WLC:

• Konfiguration Paging deaktivieren
• show run-config

Alternativ können Sie auch nur diese Ausgaben nach Bedarf sammeln:

• Konfiguration Paging deaktivieren
• show run-config no-ap
• WLAN-Gruppen anzeigen

Sicherung der WLC-Konfiguration über TFTP, FTP,...(GUI: Befehle > Datei hochladen > Konfiguration)

Syslogs vom WLC

III. Informationen zu Client-Geräten

• Client-Typ (Tablet, Smartphone, Notebook, ...)
• Gerätehersteller und -modell
• Betriebssystemversion
• WLAN-Adaptermodell
• Treiberversion des WLAN-Adapters
• Verwendete Komponente (Windows Zero Config/Auto Config, Intel PROSet, ...)
• Für die Verwendung durch den Wireless-Client und das WLAN konfigurierte Sicherheit (offen, PSK, EAP-PEAP/MSCHAPv2,...)

Hinweis: Client-Parameter, die sich gegenüber den vom jeweiligen Anbieter bereitgestellten Standardeinstellungen geändert haben. (Ruhezustand, Roaming-Parameter, U-APSD,...)

IV. Diagramm der Netzwerktopologie

Dies beinhaltet eine Darstellung und/oder Details bezüglich der drahtlosen Geräte im Netzwerk (Drucker/Scanner, WLCs,...)

V. Erstellen Sie eine Tabelle, um alle Client-Probleme aufzuzeichnen.

Beispiel:

MAC-Adresse	Benutzername	Beschreibung des gemeldeten Symptoms	Zeitpunkt, zu dem der Endbenutzer das Symptom beobachtet hat	Ping für Standardgateway J/N	WiFi-Signalstatus (Verbunden/Verbindungsversuch)	ipconfig /all (oder gleichwertig) aufzeichnen

Ziel dieser Übung ist es, ein gemeinsames Muster zu identifizieren und ein genaueres Bild der aktuellen Probleme zu vermitteln.

VI. Befehle auf dem WLC anzeigen und debuggen

Erfassen Sie die folgenden WLC-Fehlerbehebungen über die CLI:

• Konfigurationssitzungs-Timeout 0
• debug client <MAC_Adresse>
• debug dhcp message enable

Fügen Sie die zusätzlichen Fehlerbehebungen auf Einzelfallbasis hinzu:

• debug aaa detail enable - Verwenden Sie diese Option, wenn Probleme mit der Authentifizierung beim AAA-Server auftreten.
• debug aaa events enable - Verwenden Sie diese Option, wenn Authentifizierungsprobleme mit dem AAA-Server auftreten
• debug aaa all enable - Verwenden Sie diese Einstellung für Authentifizierungsprobleme. Verwenden Sie sie daher nur bei Bedarf (bei AAA-Überschreibungsfällen und Ähnlichem).
• debug mobility handoff - Verwendung bei Roaming-Problemen zwischen WLCs

Erfassen Sie die Ausgabe für die WLC-Befehle show über die CLI:

• Konfiguration Paging deaktivieren
• show time
• show client detail <MAC-Adresse des Clients> (beachten Sie den Client-Status auf dem WLC)
• Pingen des Clients vom WLC

Wenn der Test abgeschlossen ist, beenden Sie mit diesem Befehl alle aktuellen Debugging-Vorgänge auf dem WLC:

• debug disable-all

VII. Befehle auf dem Access Point anzeigen und debuggen

Leichte Cisco IOS® APs

In diesem Abschnitt werden die für die Access Points der Serien 1700/2700/3700 oder frühere Modelle erforderlichen Fehlerbehebungen beschrieben.

Verwenden Sie die folgenden Befehle, um ein Zeitlimit für AP-Sitzungen während einer Telnet-/SSH-/Konsolensitzung zu vermeiden:

• debug capwap console cli
• config t
• line console 0 — zur Änderung der Timeout-Parameter für serielle Sitzungen
• line vty 0 4 — zum Ändern der Timeout-Parameter für Telnet-/SSH-Sitzungen
• exec-timeout 0
• Sitzungs-Timeout 0
• term len 0

Bevor Sie mit dem Test beginnen, sammeln Sie ein Beispiel dieser Befehle zum Anzeigen des Access Points. Erfassen Sie mindestens zwei Beispiele für diese Ausgabe, und zwar sowohl vor als auch nach Abschluss der Tests mithilfe der folgenden AP-show-Befehle über die CLI:

• term len 0
• Uhr anzeigen
• Showtech
• show capwap client mn
• show int do1 dfs
• show logging
• mehr event.log
• show trace dot11_rst Anzeigezeitformat lokal
• show trace dot11_rst
• show trace dot11_bcn Anzeigezeitformat lokal
• trace dot11_bcn anzeigen

Sammeln Sie diese AP-Debug-Meldungen über die CLI:

• debug dot11 { d0 | d1 } Monitoradresse <MAC_Adresse>
• debug dot11 { d0 | d1 } trace print clients mgmt keys rxev txev rcv xmt txfail ba
• Laufzeit

Wenn der Test abgeschlossen ist, können Sie die Fehlersuche mit dem folgenden Befehl deaktivieren:

• u all

AP-COS-APs

In diesem Abschnitt werden die für die Access Points der Serien 1800/2800/3800 erforderlichen Debugging-Aufgaben beschrieben.

Verwenden Sie die folgenden Befehle, um ein Zeitlimit für AP-Sitzungen während einer Telnet-/SSH-/Konsolensitzung zu vermeiden:

• exec-timeout 0

Bevor Sie mit dem Test beginnen, sammeln Sie ein Beispiel der Befehle zum Anzeigen des Access Points. Erfassen Sie mindestens zwei Beispiele für diese Ausgabe, und zwar sowohl vor als auch nach Abschluss der Tests mithilfe der folgenden AP-show-Befehle über die CLI:

• term len 0
• Uhr anzeigen
• Showtech
• Client-Statistiken anzeigen <client_MAC-address>
• NSS-Status anzeigen
• NSS-Statistiken anzeigen
• show log

Erfassen Sie für Access Points der Serie 1800 die folgenden AP-Fehlerbehebungen über die CLI:

• debug dot11, Ereignisadresse auf Clientebene <client_MAC-address>
• debug dot11 client level errors addr <client_MAC-address>
• debug dot11 client level critical addr <client_MAC-address>
• debug dot11 Info-Adresse auf Client-Ebene <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>
• Laufzeit

Erfassen Sie für Access Points der Serien 2800/3800 die folgenden AP-Fehlerbehebungen über die CLI:

• config ap client-trace address add <client_MAC-Adresse>
• config ap client-trace filter all enable
• config ap client-trace output console-log enable
• config ap client-trace start
• Laufzeit

Wenn der Test abgeschlossen ist, können Sie die Fehlersuche mit dem folgenden Befehl deaktivieren:

• config ap client-trace stop

VIII. Kundenseitige Aufnahmen

Sammeln Sie entweder eine Promiscuous Netmon 3.4 (nur Windows XP oder 7)- oder Wireshark-Paketerfassung vom WLAN-Adapter des Client-Geräts.

IX. OTA-Erfassungen

802.11n-Erfassungen

• AirPCAP mit Wireshark
• MacBook Pro
• OmniPeek Professional, Enterprise, ...
• OmniPeek Remote Assistant (ORA)
• Cisco AP im Sniffer-Modus

802.11ac-Erfassungen

• Für 11ac 3SS-Aufnahmen können Sie ein 2014 Macbook Pro oder höher mit 10.10.x oder höher verwenden (verwenden Sie nicht MacBook Air für 11ac-Aufnahmen, wenn möglich, da es derzeit nur ein 2SS-Gerät ist).
• Sie können auch einen 2702, 3702 oder einen ähnlichen Cisco AP im Sniffer-Modus verwenden.
• Für Roaming-Szenarien und unter Verwendung professioneller Netzwerkanalysesoftware wie OmniPeek von Savvius. Es wird empfohlen, mehrere kompatible 802.11ac-fähige USB-WLAN-Adapter zu verwenden, z. B. den Savvius WiFI-Adapter für OmniPeek (802.11ac), Netgear A6210 oder Ähnliches.

XI. Anhang A - Zusätzliche Tipps und Tricks

Windows

Um einige zusätzliche Informationen in Bezug auf die aktuelle Wireless-Verbindung und andere verwandte Details direkt von einem Windows-PC zu sammeln. Sie können die folgenden netsh wlan-bezogenen Befehle in der Windows-Befehlszeile (CMD) verwenden:

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 (ehemals OS X)

Um die entsprechende Ausgabe als ipconfig /all-Befehl auf einem Windows-PC zu sammeln, können Sie stattdessen den gemeinsamen Linux/Unix-Befehl von ifconfig verwenden, um detaillierte Informationen zu allen Netzwerkschnittstellen auf einem Apple MacBook aufzulisten. Bei Bedarf können Sie auch festlegen, dass die Ausgabe nur für die native Wireless-Schnittstelle für ein bestimmtes MacBook (entweder en0 oder en1, es hängt vom Modell) zu empfangen. Beispiel:

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

Um einige schnelle, aber detaillierte Informationen über die aktuelle Wireless-Verbindung auf einem MacBook zu erhalten. Sie können auch das WiFi-Symbol in der oberen rechten Ecke des Desktops auswählen, während Sie gleichzeitig die Optionsschaltfläche auf Ihrer Tastatur gedrückt halten, wie im Bild gezeigt.

Eine weitere nützliche Option ist die Verwendung des versteckten Befehlszeilen-Dienstprogramms airport. Es wird dringend empfohlen, dieses nur mit Ihrem eigenen MacBook oder einem in einer Laborumgebung verwendeten MacBook zu verwenden. Da einige Netzwerkadministratoren möglicherweise keinen Zugriff auf dieses Dienstprogramm auf dem MacBook eines Endbenutzers gewähren möchten, sollten Sie entsprechend vorsichtig sein. Um fortzufahren, geben Sie dies in Terminal auf dem MacBook in Frage:

sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport 

Jetzt können Sie das CLI-Dienstprogramm des Flughafens ganz einfach aufrufen. Ein Beispiel hierfür ist:

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

Um den Prozess weiter zu vereinfachen, um eine zuverlässige, einzelne 802.11-Kanal-OTA-Paketerfassung unter Verwendung der Funktionen eines MacBook Pro oder dergleichen zu sammeln. Sie können entweder die integrierten Funktionen in macOS mit der Wireless Diagnostics > Sniffer-Methode oder ähnlich wie zuvor beschrieben nutzen, aber optional können Sie auch ein Dienstprogramm eines Drittanbieters namens Airtool (OS X 10.8 und höher) verwenden. Der Vorteil ist eine einfache Schnittstelle, um schnell eine OTA-Paketerfassung zu sammeln, die direkt auf dem Desktop mit nur wenigen Klicks über die App-UI direkt von der oberen Menüleiste auf Ihrem Bildschirm gespeichert wird.

 Weitere Informationen und Download-Links zu Airtool finden Sie unter folgender URL:

https://www.adriangranados.com/apps/airtool