In diesem Dokument werden verschiedene Methoden zur Fehlerbehebung in Mesh-Umgebungen der Serie 9800 beschrieben.
Cisco empfiehlt, dass Sie sowohl über Kenntnisse des Wireless Controllers als auch über Kenntnisse der Mesh-Bereitstellung verfügen.
Gilt für: Diese Probleme sind für Seehafen und Bergbauumgebung aufgetreten.
* Catalyst Wireless LAN Controller 9800-L/9800-CL/9800-40
* Outdoor Mesh-Bereitstellungen (RAP-MAP)
* Dual-Band-WLANs (2,4 GHz/5 GHz)
* Umgebungen mit:
* Langstrecken-Mesh-Verbindungen
* Hochfrequenzrauschen / Industriegebiete (Häfen, Terminals, Yards)
Mesh/AP-Symptome
* Kein Client- oder Upstream-Verkehr
* Ping schlägt fehl, bis AP neu gestartet wird.
* Klappt gelegentlich.
* MAP wechselt unerwartet zu einem anderen RAP/MAP.
* Der Mesh-AP trennt sich vom WLC und erfordert einen manuellen Neustart.
* Der Client befindet sich auf unbestimmte Zeit im Authentifizierungsstatus.
* Der Client durchläuft APs, bleibt aber nicht authentifiziert.
* Client stellt erst eine Verbindung her, nachdem:
* Erzwingung des Entfernens aus dem WLC- oder AP-Neustart
* Häufige Client-Verluste bei 2,4 GHz
| Kategorie |
Typische Probleme |
| RF/Design |
Kanalüberdeckung, große Kanalbreite, Antennenversatz |
| Netzsteuerung |
Instabilität bei übergeordneter Auswahl, schwacher Backhaul-SNR |
| Konfiguration |
Gemischte Datenraten, mehrere BGNs, statische Stromversorgung |
| Software |
wncd Prozess-Stalls, veralteter Client-Status |
| Skalierung/Auslastung |
Übermäßige Authentifizierungsanrufe, EAPOL-Timer stimmen nicht überein |
Root-AP (RAP)
Vermeiden
2.4 GHz)
Verpflichtend: 12 Mbit/s
Deaktivieren: 6, 9 Mbit/s
Sonstige: Unterstützt
5 GHz)
Verpflichtend: 12 Mbit/s
Deaktivieren: 6, 9 Mbit/s
Sonstige: Unterstützt
Auswirkungen:
Vermeidung aggressiver DCA-Änderungen in den Produktionszeiten
In vernetzten Bereichen:
Dieses Verhalten tritt nur gelegentlich auf, ist bei Bedarf schwer nachzuvollziehen und gehört nicht zum normalen Authentifizierungsablauf.
1. Instabilität durch Mesh-Backhaul
Auswirkungen:
2. Roaming während der Authentifizierung
Auswirkungen:
3. Niedrige Datenübertragungsraten auf Client-Dienstfunk (2,4 GHz)
Auswirkungen:
4. Mesh-Backhaul und Client-Datenverkehr, der dieselben RF-Einschränkungen nutzt
Auswirkungen:
Das Problem gilt als behoben, wenn bei einer Mesh-Bereitstellung alle genannten Bedingungen gleichzeitig erfüllt werden:
Client-Verhaltensindikatoren
WLC-Anzeigen
Command:
Übersicht über Wireless-Clients anzeigen
Indikatoren:
Aktivieren Sie diesen Befehl, wenn der Client länger als 10 Minuten verbunden ist:
show wireless client mac <Client-mac>
Mesh-spezifische Indikatoren
Befehle:
Übergeordnetes Element für AP-Mesh anzeigen
Maschendraht anzeigen
Indikatoren:
Protokolle müssen gesammelt werden, während sich der Client im Authentifizierungsstatus befindet.
Protokolle, die nach einem Neustart oder nach dem Löschen des Clients gesammelt werden, sind für die Ursache nicht hilfreich.
1. Controller-Baseline-Protokolle
Technologie-Wireless anzeigen
show clock
Zweck:
2. Client-Status-Validierungsprotokolle
Übersicht über Wireless-Clients anzeigen
Übersicht über Wireless-Clients anzeigen | Authentifizierung einschließen
show wireless client mac <Client-mac>
3. Interne WNCD-Protokolle (kritisch)
Ausführliche Ablaufverfolgung aktivieren:
set plattform software trace wncd chassis active r0 all verbotsed
Protokolle sammeln (letzte 30 Minuten):
show logging process wncd internal last 30 minutes
Client-spezifische gefilterte Protokolle:
show logging process wncd start last 30 minutes filter mac <client-mac> to-file bootflash:wncd_client.log
4. Radio Active (RA)-Verfolgung - pro Client
Über GUI:
5. Mesh-Backhaul-Validierungsprotokolle
Maschendraht anzeigen
Übergeordnetes Element für AP-Mesh anzeigen
ap Mesh Statistiken anzeigen
6. Optional (falls verfügbar) - Authentifizierungsserver-Protokolle
Intermittierender und unvorhersehbarer Verlust der Mesh-Backhaul-Konnektivität über mehrere IW9167-MAPs, was zu AP-Disjoins, Mesh-Authentifizierungsfehlern, nicht erreichbaren APs und Blackholing des Client-Datenverkehrs führt. Die Wiederherstellung erforderte häufig einen AP-Neustart oder WLC-Eingriff.
Fehlermeldungen/Anzeigen
FEHLER bei MeshSecurity: Zeitgeber abgelaufen
CRIT-MeshSicherheit: Fehler bei der Authentifizierung der Mesh-Sicherheit mit dem übergeordneten Element.
CRIT-MeshAwppAdj: Als übergeordnetes Element entfernen
mlme_ext_vap_down: VAP (Mon1) ist ausgefallen
ieee80211_ucfg_mesh_add_client(): Knoten nicht gefunden
DTLS - Warnungen schließen
CAPWAP-Heartbeat-Timeout
1. Mesh-Kontrollebene ist fehlerfrei
Die genannten Befehle können normal angezeigt werden und können nicht allein zur Validierung der Datenverkehrsweiterleitung verwendet werden:
show ap summary
Drahtlose Mesh-AP-Baumstruktur anzeigen
show capwap client rcb
Mit diesen Befehlen wird nur der Status der Kontrollebene bestätigt.
Identifizieren von Mesh-Datenebenenfehlern
MAP: Mesh-Status anzeigen
Dies ist der primäre Indikator für den Zustand der Mesh-Weiterleitung.
Fehlerfreie Ausgabe
MAC übergeordneter AP: 24:D7:9C:04:79:B1
Status der vermaschten Verbindung: UP
Weiterleitungsstatus: AKTIVIERT
Datenverkehr-Blackholing-Ausgabe
MAC übergeordneter AP: 24:D7:9C:04:79:B1
Status der vermaschten Verbindung: UP
Weiterleitungsstatus: DEAKTIVIERT
Dolmetschen:
Mesh-Adjacency ist vorhanden, aber der Access Point leitet den Datenverkehr nicht weiter.
2. MAP: Mesh-Verlauf anzeigen
Wiederholte übergeordnete Übergänge ohne AP-Neuladen weisen auf einen instabilen Weiterleitungsstatus hin:
CRIT-MeshAwppAdj: Als übergeordnetes Element entfernen
CRIT-MeshAwppAdj: Als übergeordnetes Element festlegen
CRIT-MeshAwppAdj: Als übergeordnetes Element entfernen
Durch dieses Muster befindet sich der Access Point häufig in einem nicht weiterleitenden Zustand.
3. MAP Syslog Symptome
Häufige Syslog-Meldungen, die bei Blackholing des Datenverkehrs beobachtet wurden:
ieee80211_ucfg_mesh_add_client(): Knoten nicht gefunden
CLSM: Schlüsselprogrammierung aufgrund von Nulltaste überspringen
Diese weisen darauf hin, dass der Mesh-Sicherheitskontext unvollständig ist und die Weiterleitung von verschlüsseltem Datenverkehr verhindert.
4. WLC-Mesh-Pfad "ap name <AP>" anzeigen
Dieser Befehl bestätigt die Ansicht des Datenpfads durch den Controller.
Gesund
Pfadstatus: Aktiv
Datenpfad: Abschließen
Blackholing von Datenverkehr
Pfadstatus: Aktiv
Datenpfad: Unvollständig
Auslegung:
Der Mesh-Pfad ist vorhanden, die Datenweiterleitung ist jedoch nicht eingerichtet.
5. ARP-bezogene Indikatoren
Bei Bereitstellungen, bei denen sich die VLAN-SVI auf dem WLC befindet:
Dieses Verhalten bestätigt einen Fehler bei der Weiterleitung auf Datenebene und keine RF- oder CAPWAP-Instabilität.
Phase 0 - Obligatorische Vorbereitung (vor der Veröffentlichung)
WICHTIG: Die nach dem Neustart gesammelten Protokolle sind für die Mesh-RCA nicht ausreichend.
Permanente Fehlersuche auf RAP und MAP aktivieren
Auf RAP
Anschlusslänge 0
Debuggen von Mesh-Ereignissen
debug mesh adjacency child
debug mesh adjacency packet
debug mesh adjacency channel
Debugging Mesh Security
Debug-Mesh-Weiterleitungspaket
debuggen capwap-Clientereignisse
debug capwap client error
Terminalmonitor
Auf KARTE
Anschlusslänge 0
Debuggen von Mesh-Ereignissen
debug mesh adjacency parent
debug mesh adjacency packet
debug mesh adjacency channel
Debugging Mesh Security
debuggen capwap-Clientereignisse
debug capwap client error
Terminalmonitor
Lassen Sie Debug aktiviert, bis sich das Problem reproduziert.
Phase 1 - Protokollerfassung während der Ausgabe (KRITISCH)
Starten Sie APs NICHT NEU, BEVOR Sie PROTOKOLLE SAMMELN
Protokolle von betroffenem MAP (sofort bei Auftreten des Problems)
show mesh status
Mesh-Historie älteste anzeigen
Mesh-Verlauf anzeigen
Flash-Syslogs anzeigen
Weitere Syslog-Informationen <Datum>
Protokolle von RAP (vorheriges und neues übergeordnetes Element)
Mesh-Historie älteste anzeigen
show mesh status
Protokolle von WLC (zur Fehlerzeit)
Drahtlose Mesh-AP-Baumstruktur anzeigen
Wireless Mesh-Nachbarn anzeigen
show ap name <AP-NAME> Mesh-Pfad
show ap name <AP-NAME> allgemeine Konfiguration
Show tech-support wireless
Optional (hoher Wert):
show logging process wncd start last 2 days level verbos
Client- und Datenverkehrskorrelation (empfohlen)
Durchgängige Ping-Befehle während des Fehlerfensters ausführen:
ping -t <Gateway-IP>
Phase 2 - Validierung von HF und Konfiguration (nach der Erfassung)
RF-Validierung (WLC)
show ap dot11 5ghz zusammenfassung
show ap dot11 24ghz zusammenfassung
show ap name <AP> config dot11 5 GHz
show ap name <AP> config dot11 24ghz
ARP-/Weiterleitungs-Validierung (bei Blackholing von Datenverkehr)
Bei auf WLC gehosteter SVI:
Löschen des ARP-Caches
Wenn der Datenverkehr wiederhergestellt wird → trägt die ARP-Verarbeitung dazu bei.
Phase 3 - Stabilisierungsmaßnahmen (validiert)
Mesh-Topologiesteuerung
RF-Optimierung
Alle genannten Probleme treten bei der Mesh-Bereitstellung nur gelegentlich auf und sind schwer zu beheben. Daher kann die Bereitstellung von Quick Script zur Protokollerfassung die Lösung schneller beschleunigen.
Im Folgenden finden Sie ein EEM-Beispielskript, das auf dem WLC für Probleme bei der Client-Authentifizierung ausgeführt werden kann:
Vollständiges EEM-Skript (Anwendung über WLC CLI)
::cisco::eem::event_register_timer watchdog zeit 900 maxrun 240
Namespace-Import::cisco::eem::*
Namespace-Import ::cisco::lib::
# ----------------------------
# Prozess: WLC-Zeitzeichenfolge in Sekunden konvertieren
# Unterstützt: "X Tage Xh:Xm:Xs", "Xh:Xm:Xs", "Xm:Xs", "Xs"
# ----------------------------
proc time_to_seconds {time_str} {
Gesamtsumme festlegen 0
if {[regexp {([0-9]+)\s+days?\s+([0-9]+)\s+h:([0-9]+)\s+m:([0-9]+)\s+s} $time_str -> d h m s}} {
set total [expr {$d*86400 + $h*3600 + $m*60 + $s}]
} elseif {[regexp {([0-9]+)\s+h:([0-9]+)\s+m:([0-9]+)\s+s} $time_str -> h m s]} {
set total [expr {$h*3600 + $m*60 + $s}]
} elseif {[regexp {([0-9]+)\s+m:([0-9]+)\s+s} $time_str -> m s]} {
set total [expr {$m*60 + $s}]
} elseif {[regexp {([0-9]+)\s+s} $time_str -> s]} {
Gesamtbetrag $s
}
Rückerstattung $total
}
# ----------------------------
# Prozess: Protokollieren der gesamten Protokollsammlungsinstanzen (max. 2)
# ----------------------------
proc get_log_count {} {
if {[file exist /bootflash/auth_log_count.txt]} {
set fd [open /bootflash/auth_log_count.txt r]
set count [read $fd]
Geschlossen $fd
Rückgabe von $count
} else {
Rücklauf 0
}
}
proc set_log_count {count} {
set fd [open /bootflash/auth_log_count.txt w]
spart $fd $count
Geschlossen $fd
}
# ----------------------------
# EEM-Hauptausführung
# ----------------------------
if {[catch {cli_open} result]} {
Ausgang 1
}
array set cli $result
set fd $cli(fd)
cli_exec $fd "enable"
cli_exec $fd "Terminallänge 0"
cli_exec $fd "Klemmenbreite 0"
# Aktuelle Protokollsammlung abrufen
set log_count [get_log_count]
max_log_instance2 festlegen
# Alle Clients im Authentifizierungsstatus abrufen
set summary [cli_exec $fd] "Zusammenfassung des Wireless-Clients anzeigen | Authentifizierung einschließen"]
set lines [split $summary "\n"]
foreach line $lines
# Übereinstimmung mit MAC-Format xxxx.xxxx.xxxx
if {[regexp {([0-9a-fA-F]{4}\.[0-9a-fA-F]{4}\.[0-9a-fA-F]{4})} $line -> mac]} {
set detail [cli_exec $fd "show wireless client mac-address $mac detail"]
# Zeitzeichenfolge "Connected For" extrahieren
if {[regexp {Connected For[:space:]]*:[:space:]]*(.+)} $detail -> conn_time]} {
Sekunden einstellen [time_to_seconds $conn_time]
# Prüfen, ob er >15 Minuten (900 Sekunden) stecken geblieben ist
if {$seconds > 900} {
action_syslog msg "EEM: Client $mac bei der Authentifizierung für $conn_time (>$seconds seconds) festgehalten"
# Protokolle nur bei maximaler Instanzgrenze sammeln
if {$log_count < $max_log_instance} {
action_syslog msg "EEM: WLC- + Client-Protokolle werden gesammelt (Instanz [expr {$log_count + 1}]/$max_log_instance)"
set log_file "/bootflash/auth_stuck_eem.log"
set fd_log [open $log_file a]
Anzahl Protokolle pro Client
setzt $fd_log "\n=== [Uhrenformat [Uhrzeitsekunden]] | Client $mac | $conn_time ==="
setzt $fd_log "\n— Client Detail —"
setzt $fd_log $detail
setzt $fd_log "\n— Client-Zusammenfassung —"
put $fd_log [cli_exec $fd] "show wireless client summary | $mac einfügen"]
Anzahl WLC-weite Protokolle
put $fd_log "\n— WLC WNCD Logs (30m) —"
put $fd_log [cli_exec $fd "show logging process wncd start last 30 minutes"]
setzt $fd_log "\n— WLC Show Tech Wireless —"
put $fd_log [cli_exec $fd "show tech wireless"]
$fd_log schließen
set log_count [expr {$log_count + 1}]
set_log_count $log_count
} else {
action_syslog msg "EEM: Die maximale Anzahl an Protokollinstanzen ($max_log_instance) wurde erreicht. Protokollsammlung wird übersprungen."
}
# Immer festsitzenden Client deaktivieren
cli_exec $fd "MAC-Adresse des Wireless-Clients $mac deauthentifizieren"
action_syslog msg "EEM: Deauthentifizierter Client $mac"
}
}
}
}
cli_close $fd
Beenden 0
—
#### Hauptfunktionen des Skripts
1. **15-Minuten-Intervall**: Watchdog-Zeitgeber auf 900 Sekunden (15 Minuten) eingestellt, wie angefordert
2. **Schwellenwert**: Nur bei Clients, die > 15 Minuten (900 Sekunden) hängen geblieben sind
3. **Protokolllimit**: Erfasst WLC + Client-Protokolle für **max. 2 Instanzen** und überspringt anschließend die Protokollerfassung (deauthentifiziert noch Clients)
4. **WLC-Protokollsammlung**: Umfasst:
- Kundenspezifische Details/Zusammenfassung
- WNCD-Prozessprotokolle (30-Minuten-Fenster)
- Vollständige "Show tech wireless"
5. **Permanenter Zähler**: Nachverfolgung von Protokollinstanzen über "/bootflash/auth_log_count.txt" in EEM-Skriptausführungen
Bereitstellung und Überprüfung
1. Wendet das Skript auf WLC an:
WLC#-Konfigurationsterminal
WLC(config)# Ereignismanager-Applet AuthStuckHandler
WLC(config-applet)# Ereignis-Timer Überwachungszeit 900
WLC(config-applet)# action 1 cli-Befehl "sh bootflash:auth_stuck_eem.tcl"
WLC(config-applet)# Ende
(Oder fügen Sie das vollständige TCL-Skript direkt in die WLC EEM-Konfiguration ein.)
2. EEM-Registrierung überprüfen:
WLC# Show Event Manager-Richtlinie registriert
3. Sammelprotokolle abrufen:
WLC# copy bootflash:auth_stuck_eem.log ftp:
WLC# copy bootflash:auth_log_count.txt ftp:
4. Setzen Sie den Protokollzähler zurück, um die Erfassung erneut zu aktivieren (falls erforderlich):
WLC# delete bootflash:auth_log_count.txt
In diesem Dokument werden validierte TAC-Methoden und Fallstudien zusammengeführt, um die dringendsten Probleme mit Mesh-Wi-Fi beim Catalyst 9800 zu lösen: instabiles Backhaul, Clients bleiben im Authentifizierungszustand und der Datenverkehr wird nicht übertragen.
Ein wichtiger Punkt ist, dass 90 % der gemeldeten Netzausfälle nicht isolierte Hardware- oder Client-Fehler sind, sondern Symptome eines nicht übereinstimmenden Status auf Kontroll- und Datenebene, einer instabilen Mesh-Topologie oder eines suboptimalen HF-Designs.
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
23-Jun-2026
|
Erstveröffentlichung |