Solução De Problemas Do Catalyst 9800 Mesh Wifi

Introdução

Este documento descreve diferentes métodos para solucionar problemas de ambientes de 9800 Mesh.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento do Wireless Controller junto com o conhecimento de implantação da malha.

1. Âmbito e aplicabilidade

Aplicável a: Estes problemas por ter ocorrido para o porto marítimo e o ambiente mineiro.

* Controladores LAN sem fio Catalyst 9800-L / 9800-CL / 9800-40

* Implantações de malha externa (RAP-MAP)

* WLANs de banda dupla (2,4 GHz / 5 GHz)

* Ambientes com:

  * Links de malha de longa distância

  * Alto ruído de RF / áreas industriais (portos, terminais, pátios)

2. Sintomas comuns relatados pelo cliente

Sintomas de malha/PA

1. O AP em malha mostra Associado na WLC, mas sem Conexões de Cliente

  * Nenhum tráfego de cliente ou upstream

  * O ping falha até a reinicialização do AP.

2. Link RAP-MAP

  * Flaps intermitentes.

  * MAP roaming para outro RAP/MAP inesperadamente.

  * O AP em malha se desconecta da WLC e exige reinicialização manual.

3. Sintomas de conectividade do cliente

* Cliente preso indefinidamente no estado de Autenticação.

* O cliente faz roaming entre APs, mas permanece não autenticado.

* O cliente se conecta somente após:

  * Forçar remoção da reinicialização da WLC ou do AP

  * Quedas frequentes de clientes em 2,4 GHz

3. Partições de Erros de Causa Raiz de Alta Probabilidade

Categoria	Problemas típicos
RF / Design	Sobreposição de canal, largura de canal ampla, desalinhamento de antena
Controle de malha	Instabilidade da seleção principal, SNR de backhaul fraco
Configuração	Taxas de dados mistas, vários BGNs, energia estática
Software	interrupções de processo de wncd, estado de cliente obsoleto
Escala/Carga	Excesso de chamadas de autenticação, incompatibilidade do temporizador EAPOL

4. Validação Obrigatória do Projeto e da Configuração

4.1 Backhaul em malha (crítico)

AP raiz (RAP)

• Largura do canal: somente 20 MHz
• Canais sem sobreposição em RAPs
• Mesmo nome de grupo de bridge (BGN)
• Atribuição de canal estático
• Linha de visão para MAP

Evitar

• Combinação de 20/40 MHz em RAPs
• Mesmo canal em todas as RAPs
• Vários BGNs na mesma área

4.2 Antena e montagem

• Antena omni de 5 GHz:
• Montado perpendicularmente ao solo
• Rádio dedicado de 5 GHz para backhaul em malha
• Antena direcional preferida para MAPs de longo alcance
• Eliminar obstruções (metal, gruas, contêineres)

5. Práticas Recomendadas de RF e WLAN

5.1 Taxas de dados (altamente recomendado)

2,4 GHz

Obrigatório: 12 Mbps

Desabilitado: 6 a 9 Mbps

Outros: Supported

5 GHz

Obrigatório: 12 Mbps

Desabilitado: 6 a 9 Mbps

Outros: Supported

Impacto:

• Reduz clientes difíceis
• Melhora a estabilidade de roaming e autenticação

5.2 Alimentação e RRM

• Evite a alimentação de TX estática no nível do AP
• Usar RRM Global
• Potência de transmissão mínima:
• 2,4 GHz: ≥ 12 dBm

Evite mudanças agressivas de DCA nas horas de produção

Solução de problemas de conectividade do cliente

Descrição do problema

Em áreas conectadas por malha:

• Clientes associados a MAPs com êxito.
• A autenticação é iniciada, mas nunca é concluída.
• O cliente permanece no estado Authenticating (Autenticação) na WLC.
• O cliente pode fazer roaming entre APs enquanto ainda está autenticando.
• Autenticação bem-sucedida somente após: O cliente é removido manualmente da WLC ou o MAP é reinicializado.

Esse comportamento é intermitente, difícil de ser reproduzido sob demanda e não faz parte do fluxo de autenticação normal.

Sintomas observados

• Show wireless client summary (Mostrar resumo de clientes sem fio) exibe os clientes presos na Autenticação.
• Os clientes geram repetidas tentativas de autenticação.
• Nenhuma falha ou rejeição explícita de autenticação foi vista.
• O cliente permanece preso mesmo após vários eventos de roaming.
• Problema observado principalmente quando os clientes estão conectados via MAPs.
• A frequência de emissão aumenta durante a carga operacional.

Principais fatores que contribuem com as implantações em malha para problemas de conexão do cliente

1. Instabilidade de backhaul de malha

• RSSI/SNR flutuante entre RAP e MAP.
• MAP selecionando novamente o pai durante a autenticação.
• Latência de malha que causa timeout de EAP ou retransmissão.
• MAP temporariamente encaminhando tráfego, mas de forma não consistente

Impacto:

• A máquina de estado de autenticação não foi concluída.
• O cliente permanece preso na autenticação.

2. Roaming Durante a Autenticação

• Os clientes fazem roaming entre MAPs ou entre MAP e RAP.
• O contexto de autenticação não é totalmente transferido.
• O cliente continua em roaming enquanto permanece no estado de Autenticação

Impacto:

• A autenticação é reiniciada repetidamente.
• O cliente nunca atinge o estado de EXECUÇÃO.

3. Baixas Taxas de Dados em Clientes Servindo Rádio (2,4 GHz)

• Obrigatório 6 ou 9 Mbps habilitado.
• Tentativas excessivas e consumo de tempo de transmissão.
• Quadros de autenticação atrasados ou descartados.

Impacto:

• A troca de EAP se torna não confiável na malha.
• A autenticação parece suspensa sem falha explícita.

4. Backhaul em malha e tráfego de cliente compartilhando as mesmas restrições de RF

• Alta utilização em links de malha.
• O tráfego de autenticação do cliente compete com:
• Tráfego de dados
• Controlar tráfego
• Os pacotes de autenticação são pequenos, mas sensíveis ao tempo.

Impacto:

• A autenticação é concluída somente após novas tentativas ou redefinições

Como identificar o problema é atingido (autenticação de malha travada)

O problema é considerado atingido quando todas as condições mencionadas são observadas simultaneamente em uma implantação de malha:

Indicadores de comportamento do cliente

• O cliente permanece no estado Autenticando por mais de 60 a 120 segundos.
• O cliente não faz a transição para o estado EXECUTAR automaticamente.
• O cliente se conecta com êxito somente após:
• Remoção forçada do cliente da WLC
• Reinicialização de AP em malha
• O cliente pode fazer roaming entre MAPs ou RAPs enquanto permanece no estado de Autenticação.

Indicadores de WLC

Comando:

show wireless client summary

Indicadores:

• O MAC do mesmo cliente persistentemente listado em Autenticação.
• A entrada do cliente não expira naturalmente.

Verifique esse comando se o cliente estiver conectado por mais de 10 minutos:

show wireless client mac <client-mac>

Indicadores específicos da malha

Comandos:

show ap mesh parent

show ap mesh link

Indicadores:

• Alteração ou instabilidade principal durante a autenticação do cliente
• Valores de RSSI/SNR flutuantes
• Aumento de novas tentativas ou perda de pacotes no backhaul de malha

Coleta de logs obrigatória (durante a janela de falha)

Os logs devem ser coletados enquanto o cliente está preso no estado de Autenticação.
Os logs coletados após a reinicialização ou a exclusão do cliente não são úteis para a causa raiz.

1. Registros de Linha de Base do Controlador

show tech wireless

show clock

Propósito:

• Capturar o estado geral da WLC
• Correlacionar carimbos de data/hora entre registros

2. Logs de Validação do Estado do Cliente

show wireless client summary

show wireless client summary | incluir Autenticação

show wireless client mac <client-mac>

3. Logs Internos WNCD (Críticos)

Habilitar rastreamento detalhado:

set platform software trace wncd chassis ative r0 all verbose

Coletar logs (últimos 30 minutos):

show logging process wncd internal últimos 30 minutos

Logs filtrados específicos do cliente:

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

4. Rastreamento de Rádio Ativo (RA) - Por Cliente

Da GUI:

• Monitor > Sem fio > Cliente > Solução de problemas
• Adicione o MAC do cliente afetado.
• Inicie o rastreamento de RA.
• Reproduza o problema.

5. Logs de validação de backhaul de malha

show ap mesh link

show ap mesh parent

show ap mesh statistics

6. Opcional (Se Disponível) - Logs Do Servidor De Autenticação

• Registros de autenticação RADIUS para o cliente afetado
• Latência e retransmissões de autenticação

Troubleshooting de Desconexão MAP-RAP

Descrição do problema

Perda intermitente e imprevisível da conectividade de backhaul de malha em vários MAPs IW9167, resultando em desjunções de AP, falhas de autenticação de malha, APs inalcançáveis e blackholing de tráfego de cliente. A recuperação frequentemente exigia a reinicialização do AP ou a intervenção da WLC.

Sintomas

• O MAP se desassocia do RAP pai
• MAP associado, mas não pode passar tráfego
• MAPA inalcançável de WLC, RAP e gateway
• Clientes associados, mas sem acessibilidade upstream
• Interrupções em cascata quando o MAP ou RAP pai circula

Mensagens de erro/indicadores

ERROR-MeshSecurity Timer expirado

CRIT-MeshSecurity Falha da Segurança de Malha ao autenticar com pai

CRIT-MeshAwppAdj Remover como Pai

mlme_ext_vap_down: VAP (mon1) está inoperante

ieee80211_ucfg_mesh_add_client(): Nó não encontrado

Alertas de fechamento DTLS

Tempo limite de pulsação CAPWAP

Como identificar o problema é atingido (RAP-MAP Connection Issue)

1. Plano de controle de malha parece saudável

Os comandos mencionados podem parecer normais e não podem ser usados sozinhos para validar o encaminhamento de tráfego:

show ap summary

show wireless mesh ap tree

show capwap client rcb

Esses comandos confirmam somente o estado do plano de controle.

Identificando a falha do plano de dados da malha

MAP: mostrar status da malha

Este é o principal indicador de integridade do encaminhamento de malha.

Saída íntegra

MAC do AP pai: 24:D7:9C:04:79:B1

Estado do link da malha: PARA CIMA

Estado de encaminhamento: HABILITADO

Saída de buraco negro de tráfego

MAC do AP pai: 24:D7:9C:04:79:B1

Estado do link da malha: PARA CIMA

Estado de encaminhamento: Desabilitado

Interpretação:
A adjacência de malha existe, mas o AP não está encaminhando tráfego.

2. MAPA: mostrar histórico de malha

As transições pai repetidas sem recarregamento de AP indicam estado de encaminhamento instável:

CRIT-MeshAwppAdj Remover como Pai

CRIT-MeshAwppAdj Definir como Pai

CRIT-MeshAwppAdj Remover como Pai

Esse padrão frequentemente deixa o AP em um estado de não encaminhamento.

3. MAP Sintomas de Syslog

Mensagens de syslog comuns observadas durante o blackholing de tráfego:

ieee80211_ucfg_mesh_add_client(): Nó não encontrado

CLSM: Ignorar programação de chave devido a chave nula

Isso indica que o contexto de segurança da malha está incompleto, impedindo o encaminhamento de tráfego criptografado.

4. WLC show ap name <AP> mesh path

Esse comando confirma a visualização do controlador do caminho de dados.

Íntegro

Status do Caminho: Ativo

Caminho de dados: Completo

Blackholing de tráfego

Status do Caminho: Ativo

Caminho de dados: Incompleto

interpretação:
O caminho de malha existe, mas o encaminhamento de dados não está estabelecido.

5. Indicadores relacionados com o ARP

Em implantações onde a VLAN SVI reside na WLC:

• Existem entradas ARP para clientes e AP.
• O tráfego do cliente falha.
• Limpar o ARP restaura a conectividade imediatamente.

Esse comportamento confirma a falha de encaminhamento do plano de dados, não a instabilidade de RF ou CAPWAP.

Coleta de logs obrigatória (durante a janela de falha)

Fase 0 - Preparação obrigatória (antes que o problema ocorra)

IMPORTANTE: os logs coletados após a reinicialização são insuficientes para a RCA de malha.

Habilitar depurações persistentes em RAP e MAP

No 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

monitor de terminal

No 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

monitor de terminal

Deixe as depurações ativadas até que o problema se reproduza.

Fase 1 - Coleta de registros durante o problema (CRÍTICO)

NÃO REINICIALIZE OS APs ANTES DE COLETAR LOGS

 Logs do MAP afetado (imediatamente quando ocorre o problema)

show mesh status

mostrar histórico de malha mais antigo

show mesh history

show flash syslogs

more syslog <date>

Logs do RAP (pai anterior e novo)

mostrar histórico de malha mais antigo

show mesh status

Logs da WLC (no momento da falha)

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

Correlação entre cliente e tráfego (recomendado)

Executar ping contínuo durante a janela de falha:

ping -t <gateway-ip>

Fase 2 - Validação de RF e configuração (pós-captura)

Validação de RF (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

Validação de ARP / Encaminhamento (se ocorrer blackholing de tráfego)

Se o SVI estiver hospedado no WLC:

clear arp-cache

 Se o tráfego restaura → o tratamento ARP é um fator que contribui.

Fase 3 - Ações de estabilização (validadas)

Controles de Topologia de Malha 

• Habilite Bloquear Filho em MAPs quando aplicável.
• Forçar MAPs a se conectarem ao RAP mais próximo.
• Reduza a contagem de saltos da malha.

Otimização de RF 

• Reduza a potência de transmissão RAP.
• Bloqueie os canais de backhaul de 5 GHz.
• Padronize os canais de 2,4 GHz (1/6/11).

Todos os problemas mencionados são muito intermitentes na implantação de malha e difíceis de obter, portanto, implantar um script rápido para capturar os logs pode obter a resolução mais rapidamente.

Este é um exemplo de script EEM que pode ser executado na WLC para problemas de autenticação de cliente:

Script EEM completo (aplicado via WLC CLI)
::cisco::eem::event_register_timer watchdog time 900 maxrun 240
importação de namespace ::cisco::eem::*
importação de namespace ::cisco::lib::*
Nº ----------------------------
# Proc: Converter cadeia de caracteres de tempo do WLC em segundos
# Suporta: "X dias Xh:Xm:Xs", "Xh:Xm:Xs", "Xm:Xs", "Xs"
Nº ----------------------------
proc time_to_seconds {time_str} {
set total 0
se {[regexp {([0-9]+)\s+dias?\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]} {
total definido [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
}
retorno de $total
}
Nº ----------------------------
# Proc: Controlar instâncias de coleta de log total (máx. 2)
Nº ----------------------------
proc get_log_count {} {
se {[o arquivo existe /bootflash/auth_log_count.txt]} {
set fd [open /bootflash/auth_log_count.txt r]
set count [read $fd]
fechar $fd
return $count
}else {
return 0
}
}
proc set_log_count {count} {
set fd [open /bootflash/auth_log_count.txt w]
puts $fd $count
fechar $fd
}
Nº ----------------------------
# Execução do EEM principal
Nº ----------------------------
if {[catch {cli_open} result]} {
exit 1
}
array set cli $result
set fd $cli(fd)
cli_exec $fd "enable"
cli_exec $fd "terminal length 0"
cli_exec $fd "terminal width 0"
Nº Obter contagem atual da coleção de logs
set log_count [get_log_count]
set max_log_instances 2
# Receber todos os clientes no estado Autenticação
set summary [cli_exec $fd "show wireless client summary | incluir autenticação"]
set lines [split $summary "\n"]
foreach line $lines {
# Corresponder 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"]

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

# Verificar se travado >15 minutos (900 segundos)
if {$seconds > 900} {
action_syslog msg "EEM: Cliente $mac preso na autenticação por $conn_time (>$segundos)"

# Coletar logs somente se estiver abaixo do limite máximo de instâncias
if {$log_count < $max_log_instances} {
action_syslog msg "EEM: Coletando logs de WLC + cliente (Instância [expr {$log_count + 1}]/$max_log_instances)"
set log_file "/bootflash/auth_stuck_eem.log"

set fd_log [abrir $log_file a]

Nº de logs por cliente
puts $fd_log "\n=== [formato de clock [segundos de clock]] | Cliente $mac | $conn_time === travado"
puts $fd_log "\n— Client Detail —"
puts $fd_log $detail
puts $fd_log "\n— Resumo do cliente —"
puts $fd_log [cli_exec $fd "show wireless client summary | incluir $mac"]

Nº de logs de WLCs
puts $fd_log "\n— WLC WNCD Logs (30m) —"
puts $fd_log [cli_exec $fd "show logging process wncd start last 30 minutes"]
puts $fd_log "\n— WLC Show Tech Wireless —"
puts $fd_log [cli_exec $fd "show tech wireless"]

fechar $fd_log
set log_count [expr {$log_count + 1}]
set_log_count $log_count
}else {
action_syslog msg "EEM: Máximo de instâncias de log ($max_log_instances) atingido. Ignorando coleta de logs."
}

# Sempre desautenticar cliente preso
cli_exec $fd "cliente sem fio mac-address $mac deauthenticate"
action_syslog msg "EEM: Cliente desautenticado $mac"
}
}
}
}
cli_close $fd
exit 0 (sair 0)
—
#### Principais recursos do script
1. **Intervalo de 15 minutos**: Temporizador watchdog definido como 900 segundos (15 minutos) conforme solicitado
2. **Limite travado**: Apenas acionadores em clientes presos >15 minutos (900 segundos)
3. **Limite de log**: Coleta registros de WLC + por cliente para **máximo de 2 instâncias** e, em seguida, ignora a coleta de logs (ainda desautentica clientes)
4. **Coleta de logs da WLC**: Inclui:
- Detalhe/resumo por cliente
- Logs do processo WNCD (janela de 30 minutos)
- Full `show tech wireless`
5. **Contador persistente**: Controla instâncias de log via `/bootflash/auth_log_count.txt` nas execuções de script do EEM

Implantar e verificar
1. Aplique o script ao WLC:
WLC#configure terminal
WLC(config)# event manager applet AuthStuckHandler
WLC(config-applet)#event timer watchdog time 900
WLC(config-applet)# action 1 comando cli "sh bootflash:auth_stuck_eem.tcl"
WLC(config-applet)#end
(Ou cole o script Tcl completo diretamente na configuração EEM da WLC.)

2. Verifique o registro EEM:
WLC#show event manager policy registered

3. Recuperar logs coletados:
WLC#copy bootflash:auth_stuck_eem.log ftp:
WLC#copy bootflash:auth_log_count.txt ftp:

4. Redefina o contador de log para reativar a coleta (se necessário):
WLC#delete bootflash:auth_log_count.txt

Conclusão

Este documento consolida metodologias validadas do TAC e estudos de caso reais para resolver os problemas mais difundidos do Catalyst 9800 Mesh WiFi: backhaul instável, clientes presos no estado de autenticação e tráfego não sendo transmitido.

Um argumento principal é que 90% das falhas de malha relatadas não são falhas isoladas de hardware ou cliente, mas sintomas de estado incompatível do plano de controle e do plano de dados, topologia de malha instável ou design de RF inadequado.

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	23-Jun-2026	Versão inicial