Solución de problemas de Catalyst 9800 Mesh Wifi

Introducción

Este documento describe diferentes métodos para resolver problemas de entornos de malla 9800.

Prerequisites

Requirements

Cisco recomienda que tenga conocimientos sobre el controlador inalámbrico y sobre la implementación de malla.

1. Ámbito y aplicabilidad

Se aplica a: Estos problemas de han ocurrido para el puerto marítimo y el entorno minero.

* Controladores de LAN inalámbrica Catalyst 9800-L / 9800-CL / 9800-40

* Implementaciones de malla en exteriores (RAP-MAP)

* WLAN de doble banda (2,4 GHz / 5 GHz)

* Entornos con:

  * Enlaces de malla de larga distancia

  * Alto ruido de RF / zonas industriales (puertos, terminales, yardas)

2. Síntomas Comunes Notificados Por El Cliente

Síntomas de malla/PA

1. El AP de la malla muestra unido en el WLC pero no conecta al cliente

  * Sin tráfico ascendente o de cliente

  * El ping falla hasta que se reinicia el AP.

2. Enlace RAP-MAP

  * Flaps intermitentemente.

  * MAP se traslada a otro RAP/MAP inesperadamente.

  * El AP de malla se desconecta del WLC y requiere el reinicio manual.

3. Síntomas de conectividad del cliente

* Cliente atascado en el estado de autenticación indefinidamente.

* El cliente se traslada a través de los AP pero permanece sin autenticar.

* El cliente se conecta solo después de:

  * Forzar la eliminación del reinicio del WLC o AP

  * El cliente cae con frecuencia a 2,4 GHz

3. Cubos de causa raíz de alta probabilidad

Categoría	Problemas típicos
RF/Diseño	Solapamiento de canales, ancho de canal amplio, falta de alineación de la antena
Control de malla	Inestabilidad en la selección de padre, SNR de red de retorno débil
Configuración	Velocidades de datos mixtas, varios BGN, alimentación estática
Software	paradas de procesos wncd, estado de cliente obsoleto
Escalabilidad/Carga	Exceso de llamadas de autenticación, discordancia de temporizador EAPOL

4. Validación obligatoria de diseño y configuración

4.1 Red de retorno de malla (crítica)

AP raíz (RAP)

• Ancho de canal: sólo 20 MHz
• Canales no superpuestos entre RAP
• Mismo nombre de grupo de puentes (BGN)
• Asignación de canal estática
• Línea de visión a MAP

Evitar

• Mezcla de 20/40 MHz en RAP
• Mismo canal en todos los RAP
• Varios BGN en la misma área

4.2 Antena y montaje

• Antena omni de 5 GHz:
• Montaje perpendicular al suelo
• Radio dedicada de 5 GHz para red de retorno de malla
• Antena direccional preferida para MAP de largo alcance
• Eliminar obstrucciones (metal, grúas, contenedores)

5. Prácticas recomendadas de RF y WLAN

5.1 Velocidades de transferencia de datos (muy recomendado)

2,4 GHz

Obligatoria: 12 Mbps

Desactivar: 6, 9 Mbps

Otros: Supported

5 GHz

Obligatoria: 12 Mbps

Desactivar: 6, 9 Mbps

Otros: Supported

Impacto:

• Reduce los clientes persistentes
• Mejora la estabilidad de roaming y autenticación

5.2 Alimentación y RRM

• Evite la energía TX estática a nivel de AP
• Utilizar RRM Global
• Potencia de transmisión mínima:
• 2,4 GHz: ≥ 12 dBm

Evitar cambios agresivos de DCA en las horas de producción

Solución de problemas de conectividad del cliente

Descripción de problemas

En zonas conectadas en malla:

• Los clientes se asocian correctamente a los MAP.
• La autenticación se inicia pero nunca se completa.
• El cliente permanece en el estado de autenticación en el WLC.
• El cliente puede desplazarse entre los AP mientras se autentica.
• La autenticación se realiza correctamente sólo después de: El cliente se quita manualmente del WLC, o el MAP se reinicia.

Este comportamiento es intermitente, difícil de reproducir a petición y no forma parte del flujo de autenticación normal.

Síntomas observados

• Show wireless client summary muestra a los clientes atascados en la autenticación.
• Los clientes generan intentos de autenticación repetidos.
• No se ha detectado ningún error o rechazo de autenticación explícita.
• El cliente permanece atascado incluso después de varios eventos de itinerancia.
• Problema observado principalmente cuando los clientes están conectados a través de MAP.
• La frecuencia de emisión aumenta durante la carga operativa.

Factores clave que contribuyen a las implementaciones de malla para el problema de conexión de clientes

1. Inestabilidad de red de retorno de malla

• RSSI/SNR fluctuante entre RAP y MAP.
• MAP volviendo a seleccionar el padre durante la autenticación.
• Latencia de malla que causa tiempo de espera o retransmisión de EAP.
• MAP reenvía tráfico temporalmente pero no de forma coherente

Impacto:

• La máquina de estado de autenticación no se completa.
• El cliente permanece atascado en la autenticación.

2. Itinerancia durante la autenticación

• Los clientes se desplazan entre MAP o entre MAP y RAP.
• El contexto de autenticación no se transfiere completamente.
• El cliente continúa la itinerancia mientras permanece en estado de autenticación

Impacto:

• La autenticación se reinicia repetidamente.
• El cliente nunca alcanza el estado RUN.

3. Baja velocidad de datos en la radio de servicio al cliente (2,4 GHz)

• Obligatorio de 6 o 9 Mbps activado.
• Reintentos excesivos y consumo de tiempo de transmisión.
• Tramas de autenticación retrasadas o eliminadas.

Impacto:

• El intercambio EAP se vuelve poco confiable sobre la malla.
• La autenticación aparece bloqueada sin error explícito.

4. Red de retorno de malla y tráfico de clientes que comparten las mismas restricciones de RF

• Alta utilización en enlaces de malla.
• El tráfico de autenticación del cliente compite con:
• Tráfico de datos
• Control del tráfico
• Los paquetes de autenticación son pequeños pero sensibles al tiempo.

Impacto:

• La autenticación se completa sólo después de reintentos o restablecimientos

Cómo identificar si el problema es exitoso (autenticación de malla bloqueada)

El problema se considera afectado cuando todas las condiciones mencionadas se observan simultáneamente en un despliegue de malla:

Indicadores de comportamiento del cliente

• El cliente permanece en estado de autenticación durante más de 60-120 segundos.
• El cliente no realiza la transición al estado RUN automáticamente.
• El cliente se conecta correctamente sólo después de:
• Remoción forzada del cliente del WLC
• Reinicio de Mesh AP
• El cliente puede desplazarse entre los MAP o RAP mientras permanece en el estado de autenticación.

Indicadores WLC

Comando:

show wireless client summary

Indicadores:

• El mismo MAC de cliente enumerado persistentemente en Autenticación.
• La entrada del cliente no caduca de forma natural.

Verifique este comando si el cliente está conectado durante más de 10 minutos:

show wireless client mac <client-mac>

Indicadores específicos de la malla

Comandos:

show ap mesh parent

show ap mesh link

Indicadores:

• Cambio o inestabilidad del padre durante la autenticación del cliente
• Valores RSSI/SNR fluctuantes
• Mayor número de reintentos o pérdida de paquetes en la red de retorno de malla

Recopilación de registros obligatoria (durante la ventana Fallo)

Los registros deben recopilarse mientras el cliente está detenido en el estado de autenticación.
Los registros recopilados después del reinicio o la eliminación del cliente no son útiles para la causa raíz.

1. Registros de referencia del controlador

show tech wireless

show clock

Propósito:

• Capturar el estado general del WLC
• Correlacionar marcas de tiempo entre registros

2. Registros de validación de estado de cliente

show wireless client summary

show wireless client summary | include Autenticación

show wireless client mac <client-mac>

3. Registros internos de WNCD (críticos)

Habilitar seguimiento detallado:

set platform software trace wncd chassis active r0 all verbose

Recopilar registros (últimos 30 minutos):

show logging process wncd internal last 30 minutes

Registros filtrados específicos del cliente:

show logging process wncd start last 30 minutes filter mac <client-mac> to-file bootflash:wncd_client.log

4. Seguimiento de radio activo (RA): por cliente

Desde la GUI:

• Supervisar > Inalámbrico > Cliente > Resolución de problemas
• Agregue el MAC del cliente afectado.
• Inicie el seguimiento de RA.
• Reproduzca el problema.

5. Registros de validación de red de retorno

show ap mesh link

show ap mesh parent

show ap mesh statistics

6. Opcional (Si Está Disponible): Registros Del Servidor De Autenticación

• Registros de autenticación RADIUS para el cliente afectado
• Latencia de autenticación y retransmisiones

Resolución de problemas de desconexión MAP-RAP

Descripción de problemas

Pérdida intermitente e impredecible de conectividad de red de retorno de malla a través de múltiples MAP IW9167, que resulta en desconexiones de AP, fallas de autenticación de malla, AP inalcanzables y bloqueo del tráfico del cliente. La recuperación requería a menudo el reinicio del AP o la intervención del WLC.

Síntomas

• MAP se desasocia del RAP principal
• MAP asociado pero no puede pasar el tráfico
• MAP inalcanzable desde WLC, RAP y gateway
• Clientes asociados pero sin disponibilidad ascendente
• Interrupciones en cascada cuando el MAP o RAP principal se desplaza

Mensajes de error/indicadores

ERROR-MeshSecurity: Temporizador caducado

Seguridad de malla CRIT: La seguridad de malla no se pudo autenticar con el elemento primario

CRIT-MeshAwppAdj: Eliminar como principal

mlme_ext_vap_down: VAP (mon1) está inactivo

ieee80211_ucfg_mesh_add_client(): Nodo no encontrado

alertas de cierre de DTLS

CAPWAP heartbeat timeout

Cómo identificar el problema que se encuentra (problema de conexión RAP-MAP)

1. Plano de control de malla parece saludable

Los comandos mencionados pueden parecer normales y no se pueden utilizar solos para validar el reenvío de tráfico:

show ap summary

show wireless mesh ap tree

show capwap client rcb

Estos comandos sólo confirman el estado del plano de control.

Identificación de falla de plano de datos de malla

MAP: show mesh status

Este es el indicador principal de salud de reenvío de malla.

Salida saludable

MAC de AP principal: 24:D7:9C:04:79:B1

Estado de link de malla: EN FUNCIONAMIENTO

Estado de reenvío: HABILITADO

Salida de Blackholing de tráfico

MAC de AP principal: 24:D7:9C:04:79:B1

Estado de link de malla: EN FUNCIONAMIENTO

Estado de reenvío: INHABILITADO

Interpretación:
La adyacencia de malla existe, pero el AP no está reenviando el tráfico.

2. MAP: mostrar historial de malla

Las transiciones padre repetidas sin recarga de AP indican un estado de reenvío inestable:

CRIT-MeshAwppAdj: Eliminar como principal

CRIT-MeshAwppAdj: Establecer como principal

CRIT-MeshAwppAdj: Eliminar como principal

Este patrón a menudo deja al AP en un estado de no reenvío.

3. Síntomas del registro del MAPA

Mensajes de syslog comunes observados durante la retención de tráfico:

ieee80211_ucfg_mesh_add_client(): Nodo no encontrado

CLSM: Omitir programación de claves debido a clave nula

Esto indica que el contexto de seguridad de malla está incompleto, lo que impide el reenvío de tráfico cifrado.

4. WLC show ap name <AP> mesh path

Este comando confirma la vista del controlador de la ruta de datos.

Sano

Estado de ruta: Activo

Ruta de datos: Completo

Blackholing de tráfico

Estado de ruta: Activo

Ruta de datos: Incompleto

interpretación:
La ruta de la malla existe, pero no se ha establecido el reenvío de datos.

5. Indicadores relacionados con ARP

En las implementaciones donde la VLAN SVI reside en el WLC:

• Existen entradas ARP para clientes y AP.
• El tráfico del cliente falla.
• Despejar ARP restaura la conectividad inmediatamente.

Este comportamiento confirma la falla de reenvío del plano de datos, no la inestabilidad de RF o CAPWAP.

Recopilación de registros obligatoria (durante la ventana Fallo)

Fase 0: Preparación Obligatoria (Antes De Que Se Produzca El Problema)

IMPORTANTE: Los registros recopilados después del reinicio son insuficientes para la malla RCA.

Habilitar depuraciones persistentes en RAP y MAP

En RAP

terminal length 0

debug mesh events

debug mesh adjacency child

debug mesh adjacency packet

debug mesh adjacency channel

debug mesh security

debug mesh forwarding packet

debug capwap client events

debug capwap client error

terminal monitor

En el MAPA

terminal length 0

debug mesh events

debug mesh adjacency parent

debug mesh adjacency packet

debug mesh adjacency channel

debug mesh security

debug capwap client events

debug capwap client error

terminal monitor

Deje los debugs habilitados hasta que se reproduzca el problema.

Fase 1: Recopilación de registros durante el envío (CRÍTICO)

NO REINICIE los AP ANTES DE RECOPILAR LOS REGISTROS

 Registros del MAP afectado (inmediatamente cuando se produce un problema)

show mesh status

show mesh history older

show mesh history

show flash syslogs

more syslog <date>

Registros de RAP (principal anterior y nuevo)

show mesh history older

show mesh status

Registros del WLC (en tiempo de falla)

show wireless mesh ap tree

show wireless mesh neighbor

show ap name <AP-NAME> mesh path

show ap name <AP-NAME> config general

show tech-support wireless

Opcional (valor alto):

show logging process wncd start last 2 days level verbose

Correlación de clientes y tráfico (recomendado)

Ejecute ping continuo durante la ventana de falla:

ping -t <gateway-ip>

Fase 2: RF y validación de la configuración (posterior a la captura)

Validación de radiofrecuencia (WLC)

show ap dot11 5ghz summary

show ap dot11 24ghz summary

show ap name <AP> config dot11 5ghz

show ap name <AP> config dot11 24ghz

ARP / Validación de reenvío (si la negritud del tráfico)

Si SVI está alojado en WLC:

clear arp-cache

 Si el tráfico restaura →, el manejo ARP es un factor que contribuye.

Fase 3 - Acciones de estabilización (validadas)

Controles de topología de malla 

• Active Bloquear hijo en los MAP donde corresponda.
• Fuerza a los MAP a conectarse al RAP más cercano.
• Reduzca el conteo de saltos de malla.

Optimización de RF 

• Reduzca la potencia de transmisión RAP.
• Bloquee los canales de red de retorno de 5 GHz.
• Estandarice los canales de 2,4 GHz (1/6/11).

Todos los problemas mencionados son muy intermitentes en la implementación de malla y difíciles de conseguir, por lo tanto, la implementación de un script rápido para capturar los registros puede obtener la resolución más rápido.

Aquí está una secuencia de comandos EEM de ejemplo que se puede ejecutar en el WLC para el problema de autenticación del cliente:

Script EEM completo (aplicar mediante WLC CLI)
::cisco::eem::event_register_timer watchdog time 900 maxrun 240
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
#----------------------------
# Proc: Convertir cadena de tiempo WLC a segundos
# Admite: "X días Xh:Xm:Xs", "Xh:Xm:Xs", "Xm:Xs", "Xs"
#----------------------------
proc time_to_seconds {time_str} {
set total 0
if {[regexp {([0-9]+)\s+días?\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]} {
set total $s
}
return $total
}
#----------------------------
# Proc: Seguimiento del total de instancias de recopilación de registros (máx. 2)
#----------------------------
proc get_log_count {} {
if {[file exists /bootflash/auth_log_count.txt]} {
set fd [open /bootflash/auth_log_count.txt r]
set count [read $fd]
close $fd
return $count
} else {
return 0
}
}
proc set_log_count {count} {
set fd [open /bootflash/auth_log_count.txt w]
pone $fd $count
close $fd
}
#----------------------------
# Ejecución principal de EEM
#----------------------------
if {[catch {cli_open} result]} {
salida 1
}
array set cli $result
set fd $cli(fd)
cli_exec $fd "enable"
cli_exec $fd "terminal length 0"
cli_exec $fd "ancho de terminal 0"
# Obtener recuento de recopilación de registros actual
set log_count [get_log_count]
set max_log_instance 2
# Extraer todos los clientes en estado de autenticación
set summary [cli_exec $fd "show wireless client summary | include Autenticando"]
set lines [split $summary "\n"]
foreach line $lines {
# Coincidir con el formato MAC 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"]

# Extraer la cadena de tiempo "Conectado para"
if {[regexp {Connected For[:space:]]*:[[:space:]]*(.+)} $detail -> conn_time]} {
set seconds [time_to_seconds $conn_time]

# Comprobar si está atascado >15 minutos (900 segundos)
if {$seconds > 900} {
action_syslog msg "EEM: Cliente $mac bloqueado en autenticación para $conn_time (>$seconds)"

# Recopilar registros solo si están por debajo del límite máximo de instancias
if {$log_count < $max_log_instance} {
action_syslog msg "EEM: Recopilación de registros de WLC + cliente (Instancia [expr {$log_count + 1}]/$max_log_instance)"
set log_file "/bootflash/auth_stuck_eem.log"

set fd_log [open $log_file a]

# Registros por cliente
puts $fd_log "\n=== [clock format [clock seconds]] | Cliente $mac | Bloqueado $conn_time ==="
pone $fd_log "\n— Client Detail —"
pone $fd_log $detail
pone $fd_log "\n— Client Summary —"
puts $fd_log [cli_exec $fd "show wireless client summary | include $mac"]

# Registros de todo el WLC
puts $fd_log "\n— WLC WNCD Logs (30m) —"
puts $fd_log [cli_exec $fd "show logging process wncd start last 30 minutes"]
pone $fd_log "\n— WLC Show Tech Wireless —"
pone $fd_log [cli_exec $fd "show tech wireless"]

close $fd_log
set log_count [expr {$log_count + 1}]
set_log_count $log_count
} else {
action_syslog msg "EEM: Se alcanzó el número máximo de instancias de registro ($max_log_instance). Omitiendo recopilación de registros."
}

# Desautenticar siempre el cliente atascado
cli_exec $fd "wireless client mac-address $mac deauthenticate"
action_syslog msg "EEM: Cliente desautenticado $mac"
}
}
}
}
cli_close $fd
exit 0
—
#### Características clave del script
1. **intervalo de 15 minutos**: Temporizador de vigilancia establecido en 900 segundos (15 minutos) según lo solicitado
2. **Umbral bloqueado**: Solo disparadores en clientes atascados >15 minutos (900 segundos)
3. **Límite de registro**: Recopila registros WLC + por cliente para **máx. 2 instancias totales** y, a continuación, omite la recopilación de registros (sigue desautenticando clientes)
4. **Recopilación de registros WLC**: Incluye:
- Resumen/detalle por cliente
- Registros de proceso WNCD (ventana de 30 minutos)
- "show tech wireless" completo
5. **Contador persistente**: Realiza un seguimiento de las instancias de registro mediante `/bootflash/auth_log_count.txt` en las ejecuciones de scripts EEM

Implementación y verificación
1. Aplique la secuencia de comandos al WLC:
WLC# configure terminal
WLC(config)# event manager applet AuthStuckHandler
WLC(config-applet)# event timer watchdog time 900
WLC(config-applet)# action 1 cli command "sh bootflash:auth_stuck_eem.tcl"
WLC(config-applet)# end
(O pegue la secuencia de comandos Tcl completa directamente en la configuración WLC EEM.)

2. Compruebe el registro de EEM:
WLC# show event manager policy registered

3. Recuperar registros recopilados:
WLC# copy bootflash:auth_stuck_eem.log ftp:
WLC# copy bootflash:auth_log_count.txt ftp:

4. Restablezca el contador de registros para volver a habilitar la recopilación (si es necesario):
WLC# delete bootflash:auth_log_count.txt

Conclusión

Este documento consolida metodologías validadas del TAC y casos prácticos reales para resolver los problemas más generalizados de Catalyst 9800 Mesh WiFi: red de retorno inestable, clientes atascados en el estado de autenticación y tráfico que no se transmite.

Una conclusión fundamental es que el 90% de los fallos de malla notificados no son fallos aislados de hardware o cliente, sino síntomas de un plano de control y un plano de datos no coincidentes, una topología de malla inestable o un diseño de RF subóptimo.

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
1.0	23-Jun-2026	Versión inicial