Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

G.R.C. - Capítulo 3 - Troubleshooting

No description
by

erika santos

on 15 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of G.R.C. - Capítulo 3 - Troubleshooting

Agenda Introdução ao troubleshooting;

Elementos essenciais de um problema;

Catálogo de problemas;

Metodologia geral de Detecção, Diagnóstico e Resolução de Problemas;

Referências Bibliográficas. Referências bibliográfcas Apostilha de Introdução ao Troubleshooting – Roberto Mendonça;
Melhores Práticas para Gerência de Redes de Computadores http://www2.lsd.ufcg.edu.br/~raquel/livro/melhoresPraticas.htm. Troubleshooting Gerenciamento de Redes de Computadores Introdução ao troubleshooting Elementos essenciais de um problema Os cinco os elementos essenciais de um problema são:
Descrição
Sintomas
Sinais
Testes confirmatórios
Sugestões de tratamento

A metodologia para detecção de problemas sugere que as hipóteses sejam testadas por camadas, iniciando da camada física para a camada de aplicação Prof. Érika Santos
III Ano/Módulo As empresas querem que o tempo médio entre as falhas sejam o mais longo possível.
Qualquer manutenção na rede tem que ser programada para não comprometer os negócios da empresa, pois qualquer tempo fora pode gerar grandes perdas. Quais os trabalhos do gerente de rede para manter a rede saudável?

Instalação de equipamentos novos;
Resposta à Falhas - NOC (Network Operation Center) /Objetivo - Se antecipar as falhas;
Análise de Desempenho da rede;
Procedimentos necessários para deixar a rede funcionando;
Procedimentos de Segurança. Por que a rede fica lenta?
Não existe uma causa raiz, pode ser inúmeros problemas.

O que as ferramentas levantam, coletam, sobre a rede?
Uso da banda, erros, colisões, broadcast, uso de cpu, uso de memória, ou seja, tem uma série de variáveis.

O que é normal pra uma rede pode não ser pra outra, que tem um outro perfil, outra necessidade.

Deve-se definir uma baseline (valores padrões da rede) e documentar.

Prontuário da rede = Logs.

Quem vai procurar resolver problemas na rede, precisa inicialmente conhecê-la. Documentação

A documentação da rede é bastante importante.

Um profissional pode ser consultado para verificar a rede, porém sem a documentação fica difícil.

Topologia física, topologia lógica, o inventário, últimas alterações ocorridas, tudo isso ajuda a identificar a rede, conhecer a rede. Modelo
A Empresa deve escolher um Modelo ou Metodologia.
ITIL (IT Infrastructure Library) – Melhores práticas de TI.

FCAPS – ISO
Fault management;
Configuration management;
Accounting management;
Performance Management;
Security Management.

O modelo é adotado e baseado no modelo são definidos os procedimentos. Descrição Saber de onde surgiu o problema;

Problemas também podem ser causados por um subconjunto específicos destes problemas;

É necessário saber identificar os problemas e qual camada da arquitetura de rede ele está relacionado. Primeiro elemento essencial na identificação de um problema. Sintomas Segundo elemento essencial na identificação de um problema Os sintomas de um problema geralmente são refletidos diretamente no usuário;

Os sintomas descrevem o efeito negativo do problema para os usuários;

Os sinais mais comuns de reclamação por parte dos usuários são:
Rede lenta e/ou a rede não está funcionando;
Serviço indisponível. Os membros da equipe de TIC também são usuários da rede, portanto, esses podem e devem resolver os problemas até mesmo antes dos usuários finais começarem a abrir chamados. Sinais Terceiro elemento essencial na identificação de um problema São características mais internas da rede;
A rede tem seu estado alterado em consequência da existência do problema;
Os sinais em geral, não são percebidos pelos usuário, mas apenas por meio das ferramentas de gerencia da rede, analisadores de protocolos e estação de gerencia;
Além da manifestação externa que se apresentam aos usuários;
Cada sinal referencia um procedimento; Testes confirmatórios Quarto elemento essencial na indentificação de um problema. Passos a serem seguidos para confirmar ou negar a existência de um problema de rede que está sendo apresentado;

Ao detectar sinais diferentes, não há a necessidade de realizar teste adicionais. Sugestões de tratamento Quinto elemento essencial na identificação de um problema Soluções eficientes para o problema;

O problema encontrado deve ser resolvido o mais breve possível;

A solução deve ser correta para não provocar outros problemas na rede. Catálogo de problemas Camada FÍSICA Camada de ENLACE Camada de REDE Camada de APLICAÇÃO Camada FÍSICA Cabo rompido ou danificado;
Conector defeituoso ou mal instalado;
Placa de rede ou porta de equipamento de interconexão defeituosas;
Saturação de banda em segmentos Ethernet compartilhados;
Equipamento de interconexão defeituosos;
Interferência no cabo;
Tipo errado de cabo;
Violação de regras de cabeamento Ethernet. Camada de ENLACE Interface desabilitada;

Problema com árvore de cobertura;

Saturação de recursos devido a excesso de quadros de difusão;

Tempo de envelhecimento de tabelas de endereços inadequado;

Validade do cache ARP inadequada. É comum problema com cabeamento de baixa qualidade. O cabo de par trançado, não é trançado por acaso.
A trança é utilizada para que os ruídos emitidos por cada fio sejam cancelados um pelo outro. Evitar situações onde o cabeamento elétrico é instalado próximo da rede. arp -a Tempo médio de atualização da tabela ARP em swiches é de 45 segundos. Camada de REDE Hospedeiro com máscara de rede incorreta;
Cliente DNS mal configurado;
Servidor DHCP mal configurado;
Rotas estáticas mal configuradas;
Equipamento inserido em VLAN incorreta;
VLANs não estão configuradas;
Comutadores não conseguem trocar informações sobre VLANs entre si. IP: 172.16.20.1
Masc.: 255.255.255.0 IP: 172.16.20.2
Masc.: 255.255.0.0 ip route <rede_que_deseja_configurar> <máscara_da_rede_que_deseja_configurar> <end._de_acesso_a_nova_rede> Camada de APLICAÇÃO Serviço de nomes está desabilitado;

Inconsistência entre registros dos servidores de DNS primário e secundários;

Filtro IP barrando tráfego DNS;

Servidor de correio eletrônico com totalmente aberto ou fechado. Metodologia geral de detecção, diagnóstico e resolução de problemas Detecção: a rede está apresentando comportamento estranho
Busca de informações
Recorrência de problemas?
Mudanças na rede?
Desenvolva hipóteses
Organize a lista de hipóteses
Teste as hipóteses levantadas
Solucione o problema
Teste a solução implantada
Documente suas atividades Vale ressaltar que além da metodologia é bastante importante manter sempre atualizada toda a documentação da rede e uma equipe especializada, com conhecimentos em redes de computadores. Detecção: a rede está apresentando algum comportamento estranho Notificação de que a rede está com um comportamento anormal
Usuários ligam para o help desk informando os sintomas do problema.
O operador percebe a existência de dispositivos ou interfaces não operacionais, limiares excedidos ou padrões de tráfego estranhos.

Iniciar imediatamente a fase de coleta de informações.

Situações graves que levam grande parte da rede a não funcionar são geralmente provocados por:
Inexistência de estação de gerencia ou ferramentas de monitoração dos enlaces e equipamentos mais críticos da rede;
Ferramentas não monitoradas ou utilizadas de forma errada;
Falta de análise frequente dos dados apresentados nas ferramentas por parte da equipe. Busca de informações Buscar informações relevantes que possam ajudar a identificar qual o problema está ocorrendo e a sua localização.

Tentar responder a seguintes questões:
Quem está sendo afetado pelo problema? Apenas um usuário? Todos os usuários? Alguns usuários que fazem parte de uma mesma sub-rede?
Quando o problema começou a ser percebido? Desde então, o problema ocorre sempre, ou apenas em certos horários? Neste caso, em que horários?
O problema de manifesta quando uma aplicação ou um serviço é executado?
Alguma mensagem de erro está sendo gerada? Qual?
O problema é intermitente?

Use a estação de gerencia para obter o máximo de informações possível.

Procure ajuda nos procedimentos.

Utilize os analisadores de protocolos.

As informações obtidas nessa etapa da metodologia nos deixam mais próximos do problema. Recorrência de problemas?
Mudanças na rede? Na etapa anterior as perguntas nos ajudaram a chegarmos mais perto da causa do problema, mas ainda há duas dúvidas a serem esclarecidas:
Esse problema ocorreu nos últimos 30 ou 60 dias?
Houve alguma modificação na rede que possa ter causado os sinais e sintomas verificados na etapa anterior?

Agora, possivelmente você já localizou o problema, ou já identificou que ele envolve um determinado serviço, ou ainda um elemento da rede.

Criar lista de hipóteses.

Consultar documentação de problemas solucionados anteriormente. Desenvolva hipóteses A pergunta agora é:
Que problemas podem causar os sintomas e sinais percebidos?

A lista de hipóteses é o primeiro passo para a identificação do problema.

É necessário que tenhamos um bom conhecimento sobre redes e os serviços oferecidos por elas funcionam.

Ter conhecimento sobre a configuração do DHCP, dos serviços disponíveis na rede, como deve ser o roteamento, onde estão implantados os firewalls.

Equipe irá fazer um brain storm (cérebro em tempestade). Dr. House Em muitos momentos precisou fazer um brain storm com sua equipe. Organize a lista de hipóteses Após listar as hipóteses, classifique-as com base nas camadas do modelo de referência OSI, separando hipóteses relacionada a camada física, enlace, rede e aplicação;
As hipóteses de camada física, sempre devem ser as primeiras a serem testadas, em seguida as demais camadas;
Uma das questões para se iniciar as hipóteses com base na camada física, são as comprovações por parte de pesquisas que diz que 90% dos problemas da rede estão relacionados a cabeamento, além de, se a camada física não vai bem é muito provável que as demais camadas também não estarão, pois dependem dela para o seu perfeito funcionamento;
Gerentes mais experientes e/ou que possuem maior conhecimento da rede que gerencia, já sabem a probabilidade de ocorrência de um erro, o que dispensa muitas vezes a lista de hipóteses, porém pode ser que em algum momento essas hipóteses estejam erradas, daí então o gerente terá que criar a lista de hipóteses. Teste as hipóteses levantadas Nessa etapa você irá implementar o plano de ação (lista de hipóteses).
Inicie das hipóteses da camada física;
Após essa etapa, realize os testes confirmatórios.
Caso as hipóteses não tenham sido confirmadas, volte a primeira etapa e tente obter mais informações sobre o problema.
Realize um teste por vez. Solucione o problema Nessa etapa o problema já foi confirmado.
Então deve solucioná-lo no menor prazo e da melhor forma.
Muitas vezes é inevitável utilizar uma solução paliativa, porém pode ser temporária e provavelmente o problema voltará a acontecer (soluções emergenciais, nunca utilize o termo “gambiarras”).
Lembre-se, em redes de computadores há uma ou muitas soluções para tudo. Teste a solução implantada Sempre faça um teste para a solução implantada.
Muitas vezes essas soluções criam mais problemas na rede. Fique atento!
Para realizar teste, utilize a rede, ferramentas de análise da rede e a estação gerente para obter tais informações.
30 ou 40 minutos muitas vezes são o suficiente para você perceber se a solução foi temporária, ou sem êxito.
Analise o motivo para a solução não ter resolvido o problema. Pode até ser um detalhe de implementação;
Ou ainda pode está ocorrendo mais de um problema na rede, então retorne para resolver o outro problema da rede. Documente suas atividades Documente tudo:
Informações obtidas;
Lista de hipóteses;
Testes;
Soluções propostas;
Até mesmo o que não resolveu o problema deve ser documentado.
Essa documentação pode ajudar sua equipe e a você mesmo mais adiante.
Vale lembrar que essa documentação não pode ser gerada durante o processo de resolução do problema, pois seria perda de tempo, porém é bastante importante que sejam escrita frases objetivas para que possam ser melhoradas após a solução do problema.
A utilização dessa metodologia não é obrigatória, mas auxilia bastante no momento de resolução de problemas. Dúvidas? Prof. Érika Santos

E-mail: erikapss.ete.carpina@gmail.com

Twitter: @erikapss Fazer laboratório sobre VLAN proposto, para melhor compreendê-la: Acesse laboratório proposto para teste: https://www.dropbox.com/sh/sxjiog2xnjh4s8l/f5XeIIgNPS/G.R.C./G.R.C.%20-%20Cap%C3%ADtulo%203%20-%20Troubleshooting%20%28%202%C2%BA%20LABORAT%C3%93RIO%20-%20ROTEAMENTO%20EST%C3%81TICO%29.pkt
https://www.dropbox.com/sh/sxjiog2xnjh4s8l/PL-8bT1rlF/G.R.C./G.R.C.%20-%20Cap%C3%ADtulo%203%20-%20Troubleshooting%20%281%C2%BA%20LABORAT%C3%93RIO%20-%20VLAN%29.docx
Full transcript