Evento muito positivo! Deu para trocar umas impressões com especialistas de renome, brincar um pouco com os novos WLC 3504, e as novas versões de ferramentas de gestão (PI 3.4 e CMX 10.3).
as o ponto alto foi ouvir as palavras sábias do mestre Javier Contreras Albesa. A primeira vez que ouvi foi no CLEUR 2013 e foi mais um daqueles momentos que me apercebi o quanto ainda tinha de aprender sobre wireless e equipamentos Cisco, apesar de na altura já ter o CCNP-Wireless.
Notas tiradas da apresentação:
Garantir que as versões a correr nos equipamentos são as versões aconselhadas pelo TAC:
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html
Praticar uma gestão pro-ativa do bom estado da rede, analisando os seguintes Key Performance Indicators:
Memória - a utilização da memória incrementa regularmente?
CPU - Há alguma tarefa que dispara a utilização do CPU?
Canais de rádio - Há a tendência de alta ocupação dos canais de rádio?
Quais os recursos a analisar?:
- CPU
- Memória
- Timers
- tabelas de ARP
- Clientes
- Queues
- CAPWAP
A utilização da rede é a expectável?
Como é possível controlar o estado da rede?
O Prime Infraestruture é uma excelente ferramenta mas há certos detalhes que lhe "escapam" e por vezes é necessário uma análise mais profunda.
Por onde começar a análise do WLC?
Primeiro, seguir sempre os passos e métodos que falei num post anterior cwap-capitulo 1-processos de troubleshooting . Se o problema persistir e for necessário analisar o WLC com mais detalhe por onde começamos? Pelo Data Plane ou pelo Control Plane?
Control Plane
- Queues
- Per process CPU
- CPU per core
- DHCP stats
-Timers
- ARP switch/kernel
- Memória
- Mbufs
- número de clientes
- número de PMK
Data Plane
- State monitoring
- DP-CP Drops
- Fragmentação
- Pools de pacotes
CONTROL PLANE
Qual o estado do CPU?
(Cisco Controller) >show cpu
Verificar se não há nada de anormal nos valores de Individual CPU Load. Se houver algum valor suspeito verificar os processos.
(Cisco Controller) >show process cpu
Verificar qual o processo que está com o comportamento anormal.
Qual o estado das Queues?
(Cisco Controller) >show queue-info
Verificar se a coluna de "Breached" está toda a zero. Breached significa "quantas vezes a queue ultrapassou 95% de capacidade". Verificar a coluna "inuse" e "maxalowed"
E o que quer dizer cada queue? Qual a sua importância?
Dtlarpqueue: Data transformation layer ARP queue
SNMP-Q: SNMP requests
Debugger/logger-q: Debug and Syslog Messages
SPAM: Messages between AP and WLC
NMSP*: location
Dot1x: all authentication (PSK/dot1x)
APF*: 802.11 client state machine
BCAST*: multicast/broadcast
Verificar o estado das comunicações com o servidor de Radius
Se o Auth Alloc Err e o Acct Alloc Err for diferente de 0 então há problemas no servidor de Radius.Os valores de Auth Alloc deverão ser semelhantes aos de Auth Free , assim como os valores de Acct Alloc deverão ser semelhantes aos de Acct Free.
Qual o estado da memória?
(Cisco Controller) >show memory history
Verificar se os valores de memória disponível não decrementam constantemente. Este comando também identifica há quanto tempo é que o sistema está operacional.
Na secção do comando que analisa a "Pmalloc Pools Information" verificar se chucks-in-pool e chucks-in-use não incrementam a cada dia.
Qual o estado do AP?
(Cisco Controller) >show ap uptime
Há quanto tempo estão em cima e há quanto estão associados ao WLC.
O WLC fez algum reset? Será que guardou o coredump?
(Cisco Controller) >show coredump summary
Verificar quando é que o WLC fez um reset e que nome atribuiu ao ficheiro coredump, a "blackbox" dos WLCs.
Como estão os timers do WLC?
(Cisco Controller) >show system timers summary
Verificar quantos ainda estão livres. Se Alloc Failures for diferente de 0 é porque temos problema...
No caso de WLCs 5520/8540; como estão as fan's?
(Cisco Controller) >show imm chassis fan
Este problema acontecia nas primeiras versões do 5520 mas já há algum tempo que está resolvido. De qualquer maneira, se arrancarem o 5520 e parecer que têm um F16 no bastidor, vejam os RPM das fans
Como estão os clientes?
(Cisco Controller) >show client state summary
Verificar em que estado estão os clientes.
802.1x_req - clientes que não concluíram a negociação de 802.1x. Na grande maioria das vezes acontece por se enganarem nas passwords.
DHCP_Req - clientes que concluíram a autenticação mas não ganharam IP. Verificar o estado da rede e servidor de DHCP
Webauth_Req - clientes, geralmente guests, que por alguma razão ainda não concluíram o processo de acesso ao webauth. Tanto pode ser um cliente que tenha colocado credenciais erradas como um utilizador que ligou o wifi mas ainda não se submeteu ao processo de autenticação do portal.
Como está o fastroaming dos clientes?
(Cisco Controller) >show pmk-cache all
Evidentemente que os WLC terão de pretencer ao mesmo Roaming Group para o fastroaming funcionar corretamente.
Como está o ARP do WLC?
(Cisco Controller) >show arp stats show arp kernel
Verificar as entradas na tabela de ARP e o detalhe de cada entrada.
É suposto o WLC estar ligado à rede em modo LAG (Link AGgregation)?
(Cisco Controller) >show lag summary
Alteração do LAG implica um reset ao WLC
DATA PLANE
Como estão os buffers?
(Cisco Controller) >debug fastpath dump fpapool
Deverá estar na _GREENZONE.
YELLOWZONE significa que o houve uma altura que o buffer ficou muito carregado. Geralmente resultante de picos de tráfego.
ORANGEZONE significa que o buffer chegou a atingir o seu limite de processamento de comunicações. Multicast é descartado e CAPWAP passa a ser a prioridade
_REDZONE, significa que o buffer ficou de tal modo carregado que passou só a tratar do CAPWAP
BLACKZONE.... significa... puff! fez-se o chocapic...
RED e BLACK implicam uma recuperação por crash
O Data Plane "fala" com o Control Plane?
(Cisco Controller) >debug fastpath dump dpcp-stats
Verificar a existência de DROPS
Então e se o problema não for no WLC? Como é que vejo que está tudo bem com o AP?
- CPU
- Memória
- Interfaces
- Radios
- CAPWAP
O que é que o AP está a propagar?
#show controller d0 | d1
Este comando gera um "testamento". Verificar:
- interface status
- qual o canal atribuído?
- o estado do PoE. Há alarme de LowPoE?
- QBSS load. Se tiver acima de 80% ( 0xCC) há problemas
- há txblocks?
- existem muitos resets counts?
- foi detetado algum jammer?
- há beacon stops?
- silent radio hang? quanto há clientes mas não há tráfego enviado/recebido
- PCI resets? Se há, temos problemas.
O método é o mesmo para os novos APs 1800/2800/3800/1560 que são AP-COS (linux kernel?
Mais ou menos, as estruturas são semelhantes mas alguma mudaram.
#show tech
Verificamos:
- memória
- cpu
- temperatura do equipamento e do ambiente
#show flash cores
Houve crash? Onde é que está a "blackbox" para tentarmos perceber o que se passou?
#show flash syslogs
Verificar o syslogs do AP
#show dot11 clients
Como estão os meus clientes? Em que WLAN estão ligados? Com que sinal estão a chegar ao AP?
#show client summary
Como estão os clientes associados ao AP?
#show controllers dot11radio 0|1 client <mac>
Detalhes e estatísticas de um determinado cliente
#show rrm neighbor-list
Qual o estado dos APs vizinhos?
#show history interface dot11radio all reset
Houve resets ao radio? Porquê?
#show controllers nss stats
Verificar as estatísticas do Data Plane do AP
#show interfaces dot11radio 0|1 wlan <wlan id> statistics
Estatísticas de uma WLAN num radio
Resumidamente:
- Mais vale prevenir que remediar
- Há várias maneiras de detetar o que se passa na rede antes de rebentar
- key metrics são excelentes para saber o que se passa e como se passa
Mais sobre o apresentador:
Wireless LAN Controller Config Analyzer (WLCCA)
Ferramenta obrigatória para qualquer pessoa que tenha de analisar configurações de WLCs
Apresentações no CiscoLive
BRKEWN-3011 - Advanced Troubleshooting of Wireless LANs
BRKEWN-3012 - Performance Monitoring on AireOS controllers and APs
No comments:
Post a Comment