CWAP - Capítulo 1 - Ferramentas para troubleshooting

Um bom profissional deve dispor de um conjunto de ferramentas de modo a que efetue o seu trabalho da forma mais competente e rápida possível.

1.  Ferramentas para análise de redes
• Geradores de tráfego
• Analisadores de espectro e WLAN
2. Ferramentas de fabricante ( Cisco )
• WLC Config Analyser
•  CleanAir
• Application Visibility Control
3. Comandos disponíveis em Sistema Operativo Windows
• ping
• traceroute
• pathping
• nslookup
• netsh
4. "kit de sobrevivência"
• chave universal
• lanterna
• máquina fotográfica
• pen USB
• braçadeiras

Ferramentas para análise de redes
Geradores de tráfego - Servem para verificar problemas de performance das aplicações, localizar problemas intermitentes de performance da rede, validar a performance das novas WLANs e assegurar o funcionamento consistente e continuado das aplicações.

Existem várias ferramentas disponíveis gratuitamente mas analisaremos apenas duas; IPERF e THROUGHPUT TEST

Em ambos programas necessitam de ser instalados em dois equipamentos distintos. Num lado temos o programa a funcionar em modo servidor e noutro lado temos o programa em modo cliente.

IPERF - Disponível em diversas plataformas (Windows, Unix e MacOS); Programa executado por linha de comando.

iperf help

exemplo de iperf em modo servidor

exemplo de iperf em modo cliente

Página do IPERF - https://iperf.fr/

TamoSoft THROUGHPUT TEST  - Para quem prefira uma interface gráfica existe o Throughput Test da TamoSoft que segue o mesmo conceito do IPPERF.

TamoSoft em modo cliente

TamoSoft em modo servidor

Página do Thoughput Tester da TamoSoft
tamos.com - throughput test

Analisadores de Espectro e WLAN
Servem para :

• Localizar fontes de interferência
• Determinar a utilização de canais por parte de equipamentos wi-fi e não-wifi
• Detetar hardware com performance defeituosa ou inconsistente
• Verificar a potência de sinal

Existem vários analisadores disponíveis no mercado. Neste blog analisaremos o Metageek Channalizer.

Geralmente, o analisador de espectro apresenta dois tipos de gráficos. O FFT (Fast Fourier Transform) que mostra a atividade de RF num determinado domínio de frequência.

A Waterfall view mostra-nos um histórico do FFT representado em cada linha horizontal do gráfico. O código de cores é configurável mas geralmente quanto mais vermelha estiver a linha mais ocupado está o sinal.

Visão geral do Channalizer

Exemplo de uma gráfico que mostra a utilização quase total do Canal 11 durante 5 minutos

Ferramentas de fabricante (Cisco)

WLC Config Analyzer - Ferramenta criada pela equipa de TAC da Cisco para interpretação de configurações de controladores wireless.
WLCCA download (credenciais CiscoID)

Clean Air - Ferramenta incluída nos controladores e nos APs que suportam 802.11n e 802.11ac. Identifica e alerta para as fontes de interferência.

Application Visibility Control - Ferramenta incluída nos controladores. Identifica as aplicações que estão a correr na rede e recolhe as estatísticas de tráfego.


  Ferramentasdisponíveis no Sistema Operativo (Win 8)
Conjunto de comandos utilizados na resolução de problemas de rede.

PING - envio de pacotes ICMP para testar conectividade entre dois pontos de rede.

TRACERT(TRACEROUTE) - difere do PING por enviar ECHO REQUESTS a todos os nós intermédios entre os pontos de rede a que se está a testar a conectividade.

PATHPING - É uma aplicação melhorada do TRACEROUTE. Não só identifica os passos intermédios com ainda disponibiliza estatísticas sobre a performance da rota utilizada.

NSLOOKUP - Comando para efetuar pedidos ao servidor de DNS

NETSH - Conjunto de comandos para despiste de ligações de rede e configurações do sistema operativo.

Comandos mais relevantes dentro de NETwork SHell:

• WLAN SHOW INTERFACES
• WLAN SHOW NETWORKS
• WLAN SHOW DRIVERS
• WLAN SHOW PROFILES
• WLAN SHOW ALL
• INTERFACES IPV4 SHOW ICMPSTATS
• INTERFACES IPV4 SHOW TCPSTATS
• INTERFACES IPV4 SHOW TCPCONNECTIONS

"Kit de sobrevivência"

Convém ter um conjunto mínimo de ferramentas. Ao longo da minha carreira usei diversos tipos de ferramentas mas a minha favorita é o meu sempre fiável Cybertool, da Victorinox.

.

Muito importante é também dispor de:

• 1 smartphone com uma app de sensor de sinal WIFI (ex: Wifi Analyzer), função de laterna e máquina fotografia.
• uma PEN USB
• várias braçadeiras

The Fly

CWAP - Capítulo 1 - Método de Troubleshooting - modelo OSI e TCP/IP

A primeira vez que configurei um par de Wireless Group Bridges foi para interligar dois edifícios de uma escola técnica. No dia da instalação, tudo foi configurado e testado corretamente:

- 1 vlan para a rede de dados

- 1 vlan para a rede para voip
- Portas do switch para laptops dos alunos e professores em modo access da vlan de dados
- Portas do switch para os telefones dos funcionários com a voice vlan e vlan de dados em access

Passados sensilvelmente dois meses, o cliente reportou que o serviço de voz no edifício remoto estava em baixo. Veio logo a dúvida se não me tinha esquecido de nada: "será que configurei tudo corretamente? Será que não gravei as configurações e quando a luz foi abaixo houve configurações que se perderam? Será que um dos APs está avariado?"

Desloquei-me ao local para verificar o que se estava a passar. Comparei as configurações das duas WGB com as configurações que tinha recolhido na altura da instalação e confirmei que não havia qualquer diferença mas de facto o serviço de voip no edifício remoto estava em baixo.

Os APs eram alimentados por PoE por isso tentei fazer um reset ao AP aplicando um "shut/no shut" à porta do switch em que tinha deixado o AP ligado um mês antes.

Após aplicar o reset, não só continuava a ver conectividade entre as WGB em cima como ainda veio uma das funcionárias do edifício perguntar se eu lhe tinha desligado do telefone Voip. "O quê?! Será que apliquei o reset à porta errada? Não, o reset está na porta certa... Queres ver que alguém mexeu nos cabos..."

Bingo! No escritório remoto alguém tinha trocado o cabo da WGB, que estava numa porta em trunk, para uma porta do switch que só tinha a VLAN de dados. Voltei a colocar o cabo na porta certa e pronto, tudo resolvido. 

Conclusão; levei mais de uma hora para resolver uma situação que se descobria com um singelo "sh cdp nei".

Isto tudo para sublinhar que a resolução deve começar sempre pelo Layer 1.

"Ah, afinal era um cabo mal ligado..." "Olha, afinal o cabo de alimentação estava desligado..." Qualquer técnico ou engenheiro passou por várias situações destas. Problemas que podem demorar horas a serem resolvidos quando afinal a solução é quase pueril.

Modelo OSI:

Physical - Data - Network - Transport - Session - Presentation - Application

"Please Do Not Thow Sausage Pizza Away" (ou se quiserem ser mauzinhos "Please Do Not Take Sales People's Advice")

Mas como trabalho quase exclusivamente com TCP/IP, o modelo pode ser simplificado da seguinte maneira:

Modelo TCP/IP

Exemplos de perguntas a fazer no troubleshooting de cada layer:

Layer 1 - Phisical

- Qual o estado da energia do edifício?

- Qual o estado da cablagem?

- Há adaptadores SFP instalados? 

- Todos os equipamentos estão ligados como suposto?

- Qual o estado das portas dos equipamentos?

- Qual o estado do Power Over Ethernet? O equipamento precisa de PoE ou PoE+?

- Estão todos ligados nas portas corretas?
- Onde é que os equipamentos estão instalados? Houve alterações?

- Qual é o estado do sinal wifi?

- Qual o estado do local? Houve alterações na morfologia? Está em obra?

- No caso de APs com antenas externas; qual é o estado das antenas?
- O problema acontece na gama dos 2,4Ghz, na dos 5Ghz ou em ambos?

  

Layer 2 - Data

- As VLANs estão propagadas corretamente?

- As portas estão configuradas em TAG ou UNTAG (Trunk ou Access para malta da Cisco) ?

- Os MAC addresses dos equipamentos estão registados nas VLANs corretas?

- Há mac-filtering e/ou port security?
- Qual o estado do STP?

- Qual o estado do COS (Class Of Service)?

- Qual o estado dos SSIDs?

- Há AP Groups? Como estão distribuídas as WLANs?

- Há serviços de Flexconnect? Como está o mapeamento de WLAN-VLAN?

Layer 3 - Network

- Os endereços IP estão configurados corretamente?

- A máscara de rede está configurada corretamente?

- Há conectividade entre os equipamentos?

- As WLANs estão configuradas com os interfaces correctos?

- Qual o estado do serviço de DHCP?

- Qual o estado do serviço de DNS?

- Como estão as rotas?

- Qual o estado do NTP?

- Há VRFs? Como é que estão configurados?

- Qual o estado do QoS

- Há alguma ACL de Layer 3?

Layer 4 - Transport

- Há alguma ACL de Layer 4?

- Quais as portas que interessam? E são TCP ou UDP?

Lista de portas e protocols: 

packetlife.net - common ports

Layer 5,6,7 - Application

- Quais as aplicações ou programas estão a falhar?

- Qual o comportamento espectável das aplicações?

- Houve alterações nos programas?

- Os drivers estão atualizados?

- Que tipo de autenticação está a ser utilizada?

- Nos servidores de autenticação, os equipamentos de rede estão incluídos na lista de equipamentos autorizados? (RADIUS, TACACS, LDAP)

- Quais as mensagens que aparecem nos servidores de autenticação?

CWAP - Capítulo 1 - Processos de Troubleshooting

É fundamental seguir um plano ou um método para resolver problemas de rede da maneira mais rápida e eficaz. Poupamos horas e horas de trabalho, agilizamos a aplicação da solução com o menor impacto possível na rede e nos serviços.

Alguns fabricantes até disponibilizam documentação sobre qual a metodologia de troubleshooting a seguir. Basta fazer uma procura por <fabricante> troubleshooting methodology que aparecem logo várias páginas. Por exemplo, a Cisco disponibiliza o seguinte documento:

Cisco - Troubleshooting Overview

Mas todas a metodologias são muito semelhantes e não se afastam muito da seguinte metodologia:

1- Identificar o problema

2- Descobrir a escala do problema

3- Definir as possíveis causas do problema

4- Identificar a causa mais provável do problema

5- Criar um plano de ação ou escalar o problema

6- Aplicar as ações corretivas

7- Verificar a solução

8- Documentar os resultados

Veremos agora cada passo em mais detalhe.

1- Identificar o problema

Um dos erros mais comuns é se assumir um problema sem verificar as suas causas ou tirar conclusões com base nas informações dadas pelos utilizadores. Qualquer especialista em redes wifi tem dezenas e dezenas de histórias em que foi chamado para resolver problemas na rede wifi, que mais tarde se vem a descobrir que não havia qualquer problema com a rede.

“Não assumir nada e verificar tudo” de modo a evitar horas de troubleshooting desnecessárias. Por isso, antes de abrir a sessão de CLI ou olhar para os gráficos do GUI, devemos começar por fazer as perguntas certas. Como por exemplo:

   - Há alguma mensagem de erro?

   - O que leva a pensar que a rede está em baixo?

   - Já alguma vez tiveram este problema? Se sim, é recorrente? E com que periodicidade?

   - Onde está a tentar a aceder à rede?

   - Continua no mesmo local onde se autenticou na rede ou deslocou-se para outro lugar?

   - Que tipo de equipamento está a usar?

   - Que software está a usar?

   - Há algum outro tipo de equipamento ou software que está com o mesmo problema?

   - O problema ocorre a uma hora específica do dia?

Estas perguntas e outras semelhantes, irão ajudar a melhor identificar o problema.

2- Descobrir a escala do problema

Descobrir qual o impacto e a verdadeira dimensão do problema na rede.

   - Acontece a um único utilizador ou a vários?

   - Acontece numa zona específica ou acontece por toda a rede?

   - Acontece a uma hora específica ou a qualquer hora?

   - Quantos utilizadores estão na zona quando acontece o problema?

3- Definir as possíveis causas do problema

Um único problema pode ter várias causas. Por exemplo, um cliente que reporta que está com problema de wifi porque não consegue aceder às aplicações que estão a correr num servidor remoto. Isso pode ser porque:

   - O equipamento do cliente está mal configurado

   - A cablagem está com problemas

   - O AP está em baixo

   - O controlador está em baixo

   - A pool de DHCP está cheia

   - O servidor de DHCP está em baixo ou incontactável

   - O servidor de DNS está em baixo ou incontactável

   - O switch ou o router estão com problemas

   - A ligação da internet está em baixo

   - O servidor está em baixo ou sobrelotado

   - O hardware do cliente está com falhas

Nestes 3 primeiros passos também será utilizado um método tecnológico como por exemplo o Método do Modelo OSI. Este método não é mais que fazer a resolução do problema de acordo com as tecnologias e protocolos de cada camada do modelo OSI. Muito importante quando se aplica este método é começar sempre pelo Layer 1 ou camada Física, seguindo depois para as outras camadas.

4- Identificar a causa mais provável do problema

Cumpridos os primeiros 3 passos já ficamos com uma boa ideia sobre o problema e a sua mais que provável solução. Podemos fundamentar as nossas suspeitas sobre o que está a acontecer e o que deve ser feito para o solucionar.

5- Criar um plano de acção ou escalar o problema

Não podemos simplesmente avançar com uma solução e correr o risco de provocar uma quebra de serviço durante o horário de expediente. Antes de se avançar com qualquer ação, é necessário confirmar o impacto que terá na rede e ponderar os riscos versus os benefícios.

Por exemplo, um problema que se venha a descobrir que é solucionado fazendo um upgrade ao controlador. Antes de avançar com o upgrade é importante estabelecer um plano de acção e colocar todas as partes interessadas de quais os impactos que vamos ter na rede porque um upgrade de um controlador Cisco, mesmo fazendo o predownload das imagens no controlador e nos APs, implica que a rede de wifi esteja em baixo durante 5 a 10 minutos.

É necessário:

  - Assegurar que temos um backup atualizado das configurações de todos os equipamentos que serão intervencionados. Por exemplo, com controladores Cisco, usar o WLCCA ( WLCCA Forum )

  - Assegurar que temos um diagrama de rede atualizado.

  - Assegurar que temos um registo do estado da rede antes de aplicar as alterações. Por exemplo:

         - Qual o estado das portas dos equipamentos?

         - Qual o estado das configurações?

         - Quantos APs estão em produção?

         - Quais os estados das WLANs?

  - Analisar as Release Notes da nova versão e confirmar qual o processo de upgrade aconselhado e qual a compatibilidade com os equipamentos em produção.

  - Assegurar que sabemos o que é necessário fazer caso seja necessário desfazer as alterações aplicadas.

Nem sempre é possível documentar o plano de ação mas é fundamental ter um plano de contingência caso o upgrade não corra conforme planeado ou mesmo que resolva o problema mas que provoque um algo mais grave na rede.

6- Aplicar as ações corretivas

Chegados a este ponto já temos uma boa ideia do problema, da solução, do plano de ação e do que fazer caso seja necessário voltar atrás.

Também é importante que todos os intervenientes estejam a par do plano de trabalhos.

7- Verificar a solução

Verificar que o problema ficou resolvido mas ainda mais importante, verificar que o comportamento da rede não se degradou com as novas alterações. Por vezes, existem situações em que não é possível confirmar a solução na altura da intervenção (ex: trabalhos fora da hora de expediente, poucos utilizadores/carga na rede) pelo que mesmo que após os trabalhos pareça que está tudo operacional, convém reverificar tudo.

É possível que chegados a este ponto verifiquemos que o problema não ficou resolvido e necessitemos de repetir todo a metodologia. As vezes que forem precisas até o problema ficar resolvido.

8- Documentar os resultados

Este ponto costuma ser negligenciado mas não deixa de ser importante. Ajuda a cimentar o conhecimento do problema e a solução.

Ajuda que em futuras ocorrências de problemas idênticos ou semelhantes, sejam resolvidas mais rapidamente.
Ajuda a passar a informação a outros colegas que se deparem com o mesmo problema.

Links para apresentações sobre o assunto:

Magic Analysis - Peter Mackenzie - wlpc phoenix 2017

BRKEWN-3011 - Advanced Troubleshooting of Wireless LANs (2017 Berlin)   *nota: necessita de acesso a apresentações CiscoLive

o caminho...