Vous êtes sur la page 1sur 33

Alternar idioma para English | Pesquisar | Glossário

Índice do curso: 8 Identificação e solução de problemas de rede Selecionar
Índice do curso:
8 Identificação e solução de problemas de rede
Selecionar

CCNA Exploration - Acessando a WAN

8 Identificação e solução de problemas de rede

  • 8.0 Introdução do capítulo

    • 8.0.1 Introdução do capítulo

Página 1:

Quando uma rede está funcionando, os administradores têm que monitorar seu desempenho para garantir a produtividade da organização. De vez em quando, podem ocorrer quedas da rede. Muitas

vezes elas são planejadas e o impacto disso na organização é gerenciado facilmente. Muitas vezes elas não são planejadas e o impacto disso na organização pode ser grave. No caso de quedas inesperadas da rede, os administradores devem ser capazes de identificar e solucionar problemas, e restabelecer o funcionamento total da rede. Neste capítulo, você aprenderá um processo sistemático para identificar e solucionar problemas de quedas de rede.

Exibir meio visual

  • 8.1 Estabelecendo a linha de base de desempenho da rede

    • 8.1.1 Documentando a sua rede

Página 1:

Documentando a sua rede

Para diagnosticar e corrigir problemas de rede com eficiência, um engenheiro de rede precisa saber como ela foi criada e o qual o desempenho esperado sob condições normais de funcionamento. Estas informações são chamadas de linha de base de rede e são capturadas em documentação como tabelas de configuração e diagramas de topologia.

A documentação de configuração de rede fornece um diagrama lógico da rede e informações detalhadas sobre cada componente. Estas informações devem ser mantidas em um único local, ou como cópia impressa ou na rede em um site protegido. A documentação de rede deve incluir esses componentes:

Tabela de configuração de rede Tabela de configuração de sistema final Diagrama de topologia da rede

Tabela de configuração de rede

Contém registros precisos e atualizados do hardware e do software usados em uma rede. A tabela de configuração de rede deve proporcionar ao engenheiro de rede todas as informações necessárias para identificar e corrigir a falha da rede.

Clique no botão Documentação de roteador e switch na figura.

A tabela na figura ilustra o conjunto de dados que deve ser incluído para todos os componentes:

Tipo de dispositivo, designação de modelo Nome da imagem IOS Hostname de rede do dispositivo Local do dispositivo (edifício, andar, sala, rack, painel) Se for um dispositivo modular, inclua todos os tipos de módulo e em qual slot de módulo eles estão localizados Endereços de camada de enlace de dados Endereços de camada de rede Qualquer outra informação importantes sobre aspectos físicos do dispositivo

Clique no botão Documentação de sistema final na figura.

Tabela de configuração de sistema final

Contém registros de linha de base do hardware e do software usados em dispositivos de sistema final como servidores, consoles de gerenciamento de rede e estações de trabalho desktop. Um sistema final configurado incorretamente pode prejudicar o desempenho global de uma rede.

Para fins de identificação e solução de problemas, as informações seguintes devem ser documentadas:

Nome do dispositivo (propósito) Sistema operacional e versão Endereço IP Máscara de sub-rede Gateway padrão, servidor DNS e servidor de endereços WINS Toda aplicativo de rede de largura de banda alta que o sistema final execute

Clique no botão Diagrama de topologia de rede na figura.

Diagrama de topologia da rede

Representação gráfica de uma rede, que ilustra como cada dispositivo em uma rede é conectado e sua arquitetura lógica. Um diagrama de topologia compartilha muitos dos mesmos componentes como, por exemplo, a tabela de configuração de rede. Cada dispositivo de rede deve ser representado no diagrama com notação consistente ou um símbolo gráfico. Além disso, cada conexão lógica e física deve ser representada usando uma linha simples ou outro símbolo apropriado. Também podem ser ilustrados os protocolos de roteamento.

O diagrama de topologia deve incluir pelo menos o seguinte:

Símbolos para todos os dispositivos e para o modo como eles são conectados Tipos de interface e números Endereços IP Máscaras de sub-rede

Exibir meio visual

8.1.2 Documentando a sua rede

Página 1:

Processo de documentação de rede

A figura mostra o processo de documentação de rede.

Passe o mouse sobre cada estágio na figura para aprender mais sobre o processo.

Quando você documentar sua rede, poderá ter que reunir informações diretamente de roteadores e switches. Os comandos úteis ao processo de documentação de rede incluem:

O comando ping é usado para testar a conectividade com dispositivos vizinhos antes de fazer o logon neles. Fazer ping em outros PCs na rede também inicia o processo de detecção automática do endereço MAC. O comando telnet é usado para fazer o logon remotamente em um dispositivo para acessar informações de configuração. O comando show ip interface brief é usado para exibir o status para cima ou para baixo e o endereço IP de todas as interfaces em um dispositivo. O comando show ip route é usado para exibir a tabela de roteamento em um roteador a fim de conhecer os vizinhos diretamente conectados, mais dispositivos remotos (através de rotas conhecidas) e os protocolos de roteamento que foram configurados.

O comando show cdp neighbor detail é usado para obter informações detalhadas sobre dispositivos vizinhos Cisco diretamente conectados.

Exibir meio visual

Página 2:

Esta atividade abrange as etapas necessárias para descobrir uma rede que usa principalmente os comandos telnet, show cdp neighbors detail e show ip route. Esta é a Parte I de uma atividade de duas partes.

A topologia visualizada ao abrir a atividade do Packet Tracer não revela todos os detalhes da rede. Os detalhes foram ocultados usando a função de cluster do Rastreador de pacote. A infra-estrutura de rede foi recolhida e a topologia do arquivo mostra somente os dispositivos finais. Sua tarefa é utilizar seu conhecimento de rede e comandos de detecção para obter informações sobre toda a topologia de rede e documentá-la.

São fornecidas instruções detalhadas na atividade, bem como no link do PDF abaixo.

Instruções da atividade (PDF)

Clique no ícone do Packet Tracer para obter mais detalhes.

Exibir meio visual

  • 8.1.3 Por que estabelecer uma linha de base de rede é importante?

Página 1:

Para estabelecer uma linha de base de desempenho da rede é preciso reunir os principais dados de desempenho de portas e dispositivos essenciais para o funcionamento da rede. Estas informações ajudam a determinar a "personalidade" da rede e fornecem respostas às perguntas seguintes:

Como é o desempenho da rede durante um dia normal ou comum? Quais são as áreas subutilizadas e saturadas? Onde ocorre a maioria dos erros? Que limites devem ser definidos para os dispositivos que precisam ser monitorados? A rede consegue atender às políticas identificadas?

Um administrador de rede precisa medir o desempenho inicial e a disponibilidade de dispositivos de rede e links críticos para poder determinar a diferença entre comportamento anormal e desempenho correto da rede à medida que ela cresce ou que mudem os padrões de tráfego. A linha de base também ajuda a identificar se o design de rede atual pode atender às políticas exigidas. Sem uma linha de base, não existe padrão para medir a natureza ótima de tráfego da rede e níveis de congestionamento.

Além disso, a análise posterior a uma linha de base inicial tende a revelar problemas ocultos. Os dados reunidos revelam a verdadeira natureza do congestionamento ou congestionamento em potencial em uma rede. A reunião também pode revelar áreas na rede que são subutilizadas e muito freqüentemente podem levar a um novo design da rede com base em observações de qualidade e capacidade.

Exibir meio visual

  • 8.1.4 Etapas para estabelecer uma linha de base de rede

Página 1:

Planejando a primeira linha de base

Como a linha de base de desempenho da rede inicial prepara as condições para medir os efeitos de alterações da rede e os esforços subseqüentes de solução de problemas, é importante planejar isso com cuidado. Aqui estão as etapas recomendadas para planejar a primeira linha de base de rede:

Etapa 1. Determine os tipos de dados que devem ser reunidos

Ao definir a linha de base, comece selecionando algumas variáveis que representam as políticas definidas. Se forem selecionados pontos de dados demais, a quantidade de dados poderá ser excessiva, dificultando a análise dos dados reunidos. Comece simplesmente e ajuste com o tempo. Geralmente, algumas medidas iniciais recomendadas são utilização de interface e utilização de CPU. A figura mostra algumas capturas de tela de interface e dados de utilização de CPU, como exibido por um sistema de gerenciamento de rede chamado de WhatsUp Gold.

Clique no botão Dispositivos e portas de interesse na figura.

Etapa 2. Identifique dispositivos e portas de interesse

O próximo passo é identificar os principais dispositivos e portas que devem ter os dados de desempenho medidos. Dispositivos e Portas de Interesse são:

Portas de dispositivo de rede que conectam-se a outros dispositivos de rede Servidores Usuários principais Outros elementos considerados críticos para o funcionamento

Na topologia mostrada na figura, o administrador de rede destacou os dispositivos e as portas de interesse para monitorar durante o teste de linha de base. Os dispositivos de interesse incluem roteadores R1, R2 e R3, PC1 (o terminal do Administrador) e SRV1 (o servidor Web/TFTP). As portas de interesse incluem as portas de R1, R2 e R3 que se conectam a outros roteadores ou a switches, e do roteador R2, a porta que se conecta a SRV1 (Fa0/0).

Ao escolher corretamente as portas, os resultados serão concisos e a carga de gerenciamento de rede será minimizada. Lembre-se de que uma interface em um roteador ou switch pode ser uma interface virtual, como uma interface virtual do switch (SVI).

Este passo será mais fácil se você configurou os campos de descrição de porta do dispositivo para indicar o que se conecta à porta. Por exemplo, para uma porta de roteador que se conecta ao switch de distribuição no grupo de trabalho de Engenharia, você poderia configurar a descrição "Switch de distribuição de LAN da Engenharia."

Clique no botão Determine a duração da linha de base na figura.

Etapa 3. Determine a duração da linha de base

É importante que o período de tempo e as informações de linha de base reunidas sejam suficientes para estabelecer uma imagem típica da rede. Este período deve ser de pelo menos sete dias para capturar tendências diárias ou semanais. Tendências semanais têm a mesma importância que tendências diárias e horárias.

A figura mostra exemplos de várias capturas de tela de tendências de utilização de CPU capturados em períodos diários, semanais, mensais e anuais. As tendências de semana de trabalho são muito curtas para revelar com precisão a natureza recorrente da onda de utilização que ocorre todos os fins de semana, nas noites de sábado, quando uma grande operação de backup de banco de dados consome largura de banda da rede. Este padrão recorrente é revelado na tendência mensal. A tendência anual mostrada no exemplo tem uma duração muito longa para fornecer detalhes significativos de desempenho de linha de base. Uma linha de base precisa durar não mais que seis semanas, a menos que tendências específicas de longo prazo precisem ser medidas. Geralmente, uma linha de base de duas a quatro semanas é suficiente.

Você não deve executar uma medição de linha de base durante horários de padrões de tráfego incomuns porque os dados forneceriam uma imagem inexata do funcionamento normal da rede. Por exemplo, você obteria uma medida inexata do desempenho da rede se executasse uma medição de linha de base em um feriado ou durante um mês em que a maioria da empresa estivesse de férias.

A análise de linha de base da rede deve ser realizada regularmente. Realize uma análise anual da rede inteira ou seções diferentes de linha de base da rede de uma maneira rotativa. A análise deve ser administrada para entender regularmente como a rede é afetada por crescimento e outras alterações.

Exibir meio visual

Página 2:

Medição de dados de desempenho da rede

Um software sofisticado de gerenciamento de rede é usado geralmente para definir a linha de base de redes grandes e complexas. Por exemplo, o módulo Fluke Network SuperAgent permite que os administradores automaticamente criem e revisem relatórios usando o recurso Intelligent Baselines (Linhas de Base Inteligentes). Esse recurso compara níveis de desempenho atual com observações históricas e pode identificar automaticamente problemas de desempenho e aplicações que não fornecem níveis esperados de serviço.

Clique no botão Comandos manuais na figura.

Em redes mais simples, as tarefas de linha de base devem exigir uma combinação de coleta manual de dados e inspetores simples de protocolo de rede. Estabelecer uma linha de base inicial ou realizar uma análise de monitoramento de desempenho pode exigir muitas horas ou dias para refletir com precisão o desempenho da rede. O software de gerenciamento de rede ou inspetores de protocolo e farejadores podem ser executados continuamente durante o processo de reunião de dados. Reunir dados manualmente usando comandos show em dispositivos de rede individuais é extremamente demorado e deve ser limitado a dispositivos de rede de missão crítica.

Exibir meio visual

8.2 Metodologias e Ferramentas de Identificação e Solução de Problemas

  • 8.2.1 Uma abordagem geral para identificar e solucionar problemas

Página 1:

Engenheiros de rede, administradores e pessoal de suporte estão cientes de que identificação e solução de problemas é um processo que leva o maior percentual de seu tempo. Usar técnicas eficientes de identificação e solução de problemas é uma forma de reduzir o tempo global gasto na tarefa quando se trabalha em um ambiente de produção.

Duas abordagens extremas quase sempre resultam em decepção, atraso ou falha. Em um extremo está a abordagem teorista ou científica. No outro extremo está a abordagem não prática ou pré-histórica.

A científica analisa e reanalisa a situação até que a causa exata à raiz do problema seja identificada e corrigida com precisão cirúrgica. Se por um lado, esse processo é relativamente confiável, poucas empresas podem permitir que suas redes fiquem sem funcionar pelas horas ou dias necessários para essa análise exaustiva.

O primeiro instinto da abordagem pré-histórica é começar a trocar placas, cabos, hardware e software até que a rede volte a funcionar miraculosamente. Isso não significa que a rede está funcionando corretamente, apenas que está funcionando. Essa abordagem pode até obter mais rapidamente uma alteração nos sintomas, porém não é muito confiável e a causa raiz do problema pode ainda estar presente.

Como ambas abordagens são extremas, a melhor deve ser o meio termo entre as duas, usando elementos de ambos. É importante analisar a rede como um todo em vez de isoladamente. Uma abordagem sistemática minimiza a confusão e evita o desperdício de tempo gasto com tentativa e erro.

Exibir meio visual

  • 8.2.2 Usando modelos de camadas para identificar e solucionar problemas

Página 1:

OSI em comparação com modelos de camadas de TCP/IP

Os modelos lógicos de rede, como OSI e TCP/IP, separam funcionalidade de rede em camadas modulares. Ao identificar e solucionar problemas, esses modelos de camadas podem ser aplicados à

rede física para isolar problemas de rede. Por exemplo, se os sintomas sugerirem um problema de conexão física, o técnico de rede tentará consertar o circuito que funciona na camada Física. Se o circuito funcionar corretamente, o técnico analisará as áreas em outra camada que possa estar causando o problema.

Modelo de referência OSI

O modelo OSI utiliza uma linguagem comum para engenheiros de rede e é usado geralmente para identificar e solucionar problemas de rede. Os problemas são geralmente descritos em termos de uma determinada camada do modelo OSI.

O modelo de referência OSI descreve como as informações de um software em um computador movem- se através da rede para um software em outro computador.

As camadas superiores (5-7) do modelo OSI lidam com problemas de aplicações e geralmente são implementadas somente no software. A camada de Aplicativo é a mais próxima do usuário final. Os processos de camada de Usuários e de Aplicativo interagem com aplicativos de software que contêm um componente de comunicação.

As camadas inferiores (1-4) do modelo OSI lidam com problemas de transporte de dados. As camadas 3 e 4 são geralmente implementadas somente em software. A camada Física (Camada 1) e a camada de enlace (Camada 2) são implementadas em hardware e software. A camada Física é a mais próxima do meio de rede físico, como o cabeamento de rede, e é responsável por colocar informações no meio.

Modelo TCP/IP

Assim como o modelo de rede OSI, o modelo de rede TCP/IP também divide a arquitetura de rede em camadas modulares. A figura mostra como o modelo de rede TCP/IP mapeia para as camadas do modelo de rede OSI. Esse mapeamento próximo permite que a suíte de protocolos TCP/IP comuniquem- se com êxito com tantas tecnologias de rede.

A camada de Aplicativo na suíte TCP/IP na verdade combina as funções das 3 camadas do modelo OSI:

Sessão, Apresentação e Aplicativo. A camada de Aplicativo fornece comunicação entre aplicações como FTP, HTTP e SMTP em hosts separados.

As camadas de Transporte de TCP/IP e OSI correspondem diretamente em função. A camada de Transporte é responsável por trocar segmentos entre dispositivos em uma rede TCP/IP.

A camada de Internet TCP/IP relaciona-se com a camada de rede OSI. A camada de Internet é responsável por colocar mensagens em um formato fixo para permitir que os dispositivos lidem com eles.

A Camada de Acesso à Rede TCP/IP corresponde às camadas de Enlace e Físicas OSI. A camada de acesso à rede comunica-se diretamente com os meios de rede e fornece uma interface entre a arquitetura da rede e a camada de Internet.

Clique no botão Dispositivos nas camadas de OSI na figura.

Passe o mouse sobre cada dispositivo para saber de quais Camadas OSI você geralmente precisa para identificar e solucionar problemas naquele tipo de dispositivo.

Exibir meio visual

8.2.3 Procedimentos gerais de identificação e solução de problemas

Página 1:

As fases do processo geral de identificação e solução de problemas são:

Fase 1 Reunir sintomas - Identificação e solução de problemas começa com o processo de reunir e documentar sintomas da rede, sistemas finais e usuários. Além disso, o administrador de rede determina quais componentes de rede foram afetados e como a funcionalidade da rede foi alterada em comparação com a linha de base. Sintomas podem aparecer em muitos formulários diferentes, inclusive alertas do sistema de gerenciamento de rede, mensagens de console e reclamações de usuário. Ao reunir sintomas, as perguntas devem ser usadas como um método de localizar o

problema em um intervalo menor de possibilidades. Fase 2 Isolar o problema - O problema não é de fato isolado até que um único problema, ou um conjunto de problemas relacionados, seja identificado. Para fazer isso, o administrador de rede examina as características dos problemas nas camadas lógicas da rede de forma que a causa mais provável possa ser selecionada. Nesta fase, o administrador de rede pode reunir e documentar mais sintomas dependendo das características do problema que são identificadas. Fase 3 Corrigir o problema - Após isolar e identificar a causa, o administrador de rede tenta corrigir o problema implementando, testando e documentando uma solução. Se o administrador de rede determinar que a ação corretiva criou outro problema, a solução tentada será documentada, as alterações serão removidas e o administrador de rede voltará a reunir sintomas e isolar o problema.

Essas fases não são mutuamente exclusivas. A qualquer ponto no processo, pode ser necessário voltar a fases anteriores. Por exemplo, pode ser necessário reunir mais sintomas enquanto estiver isolando um problema. Além disso, ao tentar corrigir um problema, outro problema não identificado poderá ser criado. Como resultado, seria necessário reunir os sintomas, isolar e corrigir o novo problema.

Uma política de identificação e solução de problemas deve ser estabelecida para cada fase. Uma política fornece uma maneira consistente de executar cada fase. É parte da política documentar todas as informações importantes.

Exibir meio visual

8.2.4 Métodos de identificação e solução de problemas

Página 1:

Métodos de identificação e solução de problemas

Seguem os três métodos principais para identificar e solucionar problemas de rede:

De baixo para cima De cima para baixo Dividir e conquistar

Cada abordagem tem suas vantagens e desvantagens. Este tópico descreve os três métodos e fornece diretrizes para escolher o melhor método para uma situação específica.

Método de identificação e solução de problemas de baixo para cima

Nesse método, você deve iniciar com os componentes físicos da rede e subir pelas camadas do modelo OSI até que a causa do problema seja identificada. Esta é uma abordagem interessante quando desconfia-se que o problema seja físico. A maior parte dos problemas de rede estão nos níveis inferiores; portanto, implementar a abordagem De baixo para cima geralmente tem resultados efetivos. A figura mostra a abordagem De baixo para cima para identificar e solucionar problemas.

A desvantagem com a abordagem de solução de problemas De baixo para cima é que ela exige que você verifique cada dispositivo e interface na rede até que a possível causa do problema seja localizada. Lembre-se de que devem ser documentadas todas as conclusões e todas as possibilidades, de modo que possa haver bastante documentação associada a esta abordagem. Um desafio maior é determinar quais dispositivos devem ser examinados primeiro.

Clique no botão Mét. de cima para baixo na figura.

Método de identificação e solução de problemas de cima para baixo

Nesse método, você deve iniciar com os aplicativos de usuário final e descer pelas camadas do modelo OSI até que a causa do problema tenha sido identificada. Os aplicativos de usuário final de um sistema final são testados antes que se examinem partes mais específicas da rede. Use esta abordagem para problemas mais simples ou quando você suspeita que o problema seja com o software.

A desvantagem da abordagem De cima para baixo é que exige verificação de todos os aplicativos da

rede até que a possível causa do problema seja localizada. Cada conclusão e possibilidade devem ser documentadas, e o desafio é determinar qual aplicativo deve ser examinado primeiro.

Clique no botão Mét. dividir e conquistar na figura.

Método de identificação e solução de problemas dividir e conquistar

Quando você utilizar a abordagem Dividir e conquistar para identificar e solucionar um problema de rede, selecione uma camada e teste em ambas as direções da camada inicial.

Nessa abordagem, inicie reunindo a experiência de usuário sobre o problema, documente os sintomas e em seguida, usando essas informações, faça uma suposição informada sobre em qual camada OSI você deve iniciar sua investigação. Após verificar que uma camada está funcionando corretamente, presuma que as camadas abaixo dela também estejam funcionando e analise as camadas OSI acima. Se uma camada de OSI não estiver funcionando corretamente, analise as camadas debaixo do modelo de camadas OSI.

Por exemplo, se os usuários não puderem acessar o servidor Web e você puder executar ping no

servidor, então você saberá que o problema é acima da Camada 3. Se você não puder executar ping no servidor, o problema deverá ser em uma camada de OSI inferior.

Exibir meio visual

Página 2:

Diretrizes para selecionar um método de identificação e solução de problemas

Para solucionar problemas de rede rapidamente, selecione o método mais eficaz de identificação e solução de problemas. Examine a figura. Use o processo mostrado na figura para poder selecionar o método de identificação e solução de problemas mais eficiente.

Veja um exemplo de como você poderia escolher um método de solução de problemas para um problema específico. Dois roteadores IP não estão trocando informações de roteamento. Da última vez

que este tipo de problema ocorreu, era um problema de protocolo. Então você escolhe o método de identificação e solução de problemas Dividir e conquistar. Sua análise revela que existe conectividade entre os roteadores. Portanto, você inicia seus esforços de identificação e solução de problemas pela camada física ou de enlace, confirma a conectividade e começa a testar as funções relacionadas a TCP/IP na próxima camada para cima no modelo OSI, a camada de rede.

Exibir meio visual

8.2.5 Reunindo sintomas

Página 1:

Reunindo sintomas

Para determinar o escopo do problema, reúna (documente) os sintomas. A figura mostra um gráfico de fluxo desse processo. Cada etapa neste processo é descrita aqui brevemente:

Etapa 1. Analise os sintomas existentes - Analise os sintomas reunidos de protocolos de problemas, usuários ou sistemas finais afetados para formar uma definição do problema.

Etapa 2. Determine a propriedade - Se o problema estiver dentro de seu sistema, você poderá passar para a próxima fase. Se o problema estiver fora do limite de seu controle, por exemplo, conectividade de Internet perdida fora do sistema autônomo, você precisará entrar em contato com o administrador do sistema externo antes de reunir outros sintomas de rede.

Etapa 3. Restrinja o escopo - Determine se o problema está no núcleo, na distribuição ou na camada de acesso da rede. Na camada identificada, analise os sintomas existentes e use seu conhecimento da topologia de rede para determinar quais equipamentos são a provável causa.

Etapa 4. Reúna sintomas de dispositivos suspeitos - Usando uma abordagem de solução de problemas em camadas, reúna sintomas de hardware e software dos dispositivos suspeitos. Inicie com o que tiver

maior probabilidade, use o conhecimento e a experiência para determinar se é mais provável que seja um problema de configuração de hardware ou software.

Etapa 5. Documente os sintomas - muitas vezes o problema pode ser resolvido usando os sintomas documentados. Se não puder, comece a fase de isolamento do processo geral de identificação e solução de problemas.

Clique no botão Comandos na figura.

Use os comandos do Cisco IOS para reunir sintomas sobre a rede. A tabela na figura descreve os comandos comuns do Cisco IOS que você pode usar para reunir os sintomas de um problema na rede.

Embora o comando debug seja uma ferramenta importante para reunir sintomas, ele gera uma

quantidade grande de tráfego de mensagem de console e o desempenho de um dispositivo de rede pode ser afetado consideravelmente. Avise aos usuários que o desempenho da rede pode ser afetado devido a esse esforço de identificação e solução de problemas. Lembre-se de desabilitar a depuração quando acabar.

Exibir meio visual

Página 2:

Questionando usuários finais

Quando você questiona usuários finais sobre um problema de rede, use técnicas interrogativas efetivas. Deste modo, você obterá as informações necessárias para documentar com eficácia os sintomas de um

problema. A tabela na figura fornece algumas diretrizes e alguns exemplos de perguntas a serem feitas ao usuário final.

Exibir meio visual

8.2.6 Ferramentas para identificação e solução de problemas

Página 1:

Ferramentas de identificação e solução de problemas de software

Uma ampla variedade de ferramentas de software e hardware está disponível para facilitar o processo. Estas ferramentas podem ser usadas para reunir e analisar sintomas de problemas de rede e geralmente possuem funções de monitoramento e relatório que podem ser usadas para estabelecer a linha de base de rede.

Ferramentas NMS

As ferramentas de sistema de gerenciamento de rede (NMS) incluem monitoramento de dispositivo, configuração e gerenciamento de falha. A figura mostra um exemplo de tela do software What's Up Gold da NMS. Estas ferramentas podem ser usadas para investigar e corrigir problemas de rede. O software de monitoramento de rede exibe graficamente uma perspectiva física dos dispositivos de rede, permitindo que os gerentes de rede monitorem dispositivos remotos sem de fato precisarem verificá-los fisicamente. O software de gerenciamento de dispositivo apresenta status dinâmico, estatísticas e informações de configuração para produtos comutados. Exemplos de ferramentas de gerenciamento de rede geralmente usadas são CiscoView, HP Openview, Solar Winds e What's Up Gold.

Clique no botão Base de conhecimento na figura para ver o exemplo de um site da base de conhecimento.

Bases de conhecimento

Bases de conhecimento online de fornecedores de dispositivos de rede têm se tornado fontes indispensáveis de informações. Quando bases de conhecimento de fornecedor são combinadas com mecanismos de pesquisa de Internet como Google, um administrador de rede tem acesso a um conjunto vasto de informações baseadas em experiência.

A figura mostra a página Tools & Resources (Ferramentas e recursos) da Cisco em

http://www.cisco.com. Esta é uma ferramenta grátis que fornece informações sobre hardware e software relacionados à Cisco. Contém procedimentos de identificação e solução de problemas, guias de implementação e artigos originais na maioria dos aspectos da tecnologia de redes.

Clique no botão Ferramentas da linha de base na figura para ver alguns exemplos.

Ferramentas da linha de base

Existem muitas ferramentas usadas para automatizar a documentação de rede e o processo de linha de base. Estas ferramentas estão disponíveis para os sistemas operacionais Windows, Linux e AIX. A figura mostra uma captura de tela do SolarWinds LANsurveyor e software CyberGauge. Ferramentas de linha de base ajudam a realizar tarefas de documentação de linha de base. Por exemplo, eles podem ajudá-lo a desenhar diagramas de rede, manter atualizada a documentação de software e hardware de rede e medir o uso de largura de banda de rede da linha de base.

Clique no botão de Analisador de protocolo na figura para ver um exemplo de um aplicativo típico de analisador de protocolo.

Analisadores de protocolo

Um analisador de protocolo decodifica as várias camadas de protocolo em um quadro registrado e

apresenta estas informações em um formato relativamente fácil de usar. A figura mostra uma captura de tela do analisador de protocolo Wireshark. As informações exibidas por um analisador de protocolo incluem a parte física, o enlace de dados, o protocolo e as descrições para cada quadro. A maioria dos analisadores de protocolo podem filtrar tráfego que atenda a um determinado critério de forma que, por exemplo, todo o tráfego para e de um dispositivo específico possa ser capturado.

Exibir meio visual

Página 2:

Ferramentas de identificação e solução de problemas de hardware

Clique nos botões na figura para ver exemplos de várias ferramentas de identificação e solução de problemas de hardware.

Módulo de análise de rede

Um módulo de análise de rede (NAM) pode ser instalado nos switches da série 6500 do Cisco Catalyst e nos roteadores da série 7600 da Cisco a fim de fornecer uma representação gráfica do tráfego de roteadores e switches locais e remotos. O NAM é uma interface incorporada baseada em navegador que gera relatórios no tráfego que consome recursos de rede críticos. Além disso, o NAM pode capturar e decodificar pacotes e rastrear tempos de resposta para informar à rede ou ao servidor o aplicativo que está com problema.

Multímetro digital

Multímetros digitais (DMMs) são instrumentos de teste usados para medir diretamente valores elétricos de voltagem, corrente e resistência. Em identificação e solução de problemas de rede, a maioria dos testes de multimídia envolve verificação de níveis de voltagem de fonte de alimentação e verificação de que os dispositivos de rede estão recebendo energia.

Testadores de cabo

Testadores de cabos são dispositivos portáteis especializados criados para testar diversos tipos de cabeamento de comunicação de dados. Testadores de cabos podem ser usados para detectar fios quebrados, fios cruzados, conexões em curto e conexões emparelhadas incorretamente. Estes dispositivos podem ser testadores de continuidade baratos, testadores de cabos de preço mediano ou reflectômetros de domínio de tempo caros (TDRs).

Os TDRs são usados para definir a distância até uma interrupção em um cabo. Estes dispositivos enviam sinais ao longo do cabo e esperam que eles sejam refletidos. O tempo entre enviar o sinal e recebê-lo é convertido em uma medida de distância. O TDR normalmente vem com os testadores de cabo de dados. Os TDRs usados para testar cabos de fibra óptica são conhecidos como como reflectômetros ópticos de

domínio de tempo (OTDRs).

Analisadores de cabo

Analisadores de cabo são dispositivos portáteis multifuncionais usados para testar e certificar cabos de cobre e fibra para diferentes serviços e padrões. As ferramentas mais sofisticadas incluem diagnósticos avançados de identificação e solução de problemas que medem a distância até o defeito de desempenho (NEXT, RL), identificam ações corretivas e exibem graficamente diafonia e comportamento de impedância. Os analisadores de cabo geralmente também incluem software para PC. Depois que os dados de campo são reunidos, o dispositivo portátil pode fazer upload de seus dados, e são criados relatórios precisos e atualizados.

Analisadores de rede portáteis

Dispositivos portáveis usados para identificar e solucionar problemas de redes comutadas e VLANs. Ao conectar o analisador de rede em qualquer lugar da rede, o engenheiro de rede pode ver a porta do switch na qual o dispositivo está conectado, e a utilização média e de pico. O analisador também pode ser usado para descobrir a configuração de VLAN, identificar os principais faladores da rede, analisar o tráfego da rede e visualizar detalhes da interface. O dispositivo normalmente é capaz de gerar uma saída para um PC que tenha software de monitoramento de rede instalado para obter uma análise mais detalhada, e identificação e solução de problemas.

Exibir meio visual

Página 3:

Atividade de pesquisa

A seguir, veja links para várias ferramentas de identificação e solução de problemas.

Ferramentas de software

Sistemas de gerenciamento de rede:

http://www.ipswitch.com/products/whatsup/index.asp?t=demo

http://www.solarwinds.com/products/network_tools.aspx

Ferramentas da linha de base:

http://www.networkuptime.com/tools/enterprise/

Bases de conhecimento:

http://www.cisco.com

Analisadores de protocolo:

http://www.flukenetworks.com/fnet/en-us/products/OptiView+Protocol+Expert/

Ferramentas de hardware

Cisco Network Analyzer Module (NAM):

http://www.cisco.com/en/US/docs/net_mgmt/network_analysis_module_software/3.5/user/guide/user.html

Testadores de cabo:

http://www.flukenetworks.com/fnet/en-us/products/CableIQ+Qualification+Tester/Demo.htm

Analisadores de cabo:

http://www.flukenetworks.com/fnet/en-us/products/DTX+CableAnalyzer+Series/Demo.htm

Analisadores de rede:

http://www.flukenetworks.com/fnet/en-

us/products/OptiView+Series+III+Integrated+Network+Analyzer/Demos.htm Exibir meio visual

8.3 Problemas comuns na implementação de WAN

  • 8.3.1 Comunicações de WAN

Página 1:

Um provedor de comunicações ou uma operadora comum geralmente possui os enlaces de dados que compõem uma WAN. Os links estão disponíveis para assinantes mediante o pagamento de uma taxa e são usados para interconectar LANs ou conectar a redes remotas. A velocidade de transferência de dados da WAN (largura de banda) está consideravelmente mais lenta que a largura de banda da LAN comum. Os encargos para a provisão de link são o elemento de custo principal; portanto a implementação de WAN deve objetivar fornecer a máxima largura de banda a um custo aceitável. Considerando-se a pressão do usuário para fornecer mais acesso de serviço a altas velocidades e a pressão do gerenciamento para reduzir custos, determinar uma configuração ótima de WAN não é uma tarefa fácil.

As WANs transportam vários tipos de tráfego, como voz, dados e vídeo. O design selecionado deve fornecer capacidade suficiente e horas de trânsito para atender os requisitos da empresa. Entre outras especificações, o design deve considerar a topologia das conexões entre os vários sites, a natureza dessas conexões e capacidade de largura de banda.

As WANs mais antigas consistiram geralmente em enlaces de dados que conectam diretamente mainframes remotos. As WANs de hoje conectam LANs geograficamente separadas. As tecnologias WAN funcionam nas três camadas inferiores do modelo de referência OSI. Estações de usuário final, servidores e roteadores comunicam-se por LANs e os enlaces de dados da WAN finalizam em roteadores locais.

Os roteadores determinam o caminho mais apropriado ao destino dos dados a partir dos cabeçalhos de

camada de rede e transferem os pacotes para a conexão de enlace de dados apropriada para entrega na conexão física. Os roteadores também podem fornecer gerenciamento de qualidade de serviço (QoS) que atribui prioridades aos diferentes fluxos de tráfego.

Exibir meio visual

  • 8.3.2 Etapas em design de WAN

Página 1:

As empresas instalam conectividade WAN para atender ao requisito comercial estratégico de mover dados entre filiais externas. Como a conectividade WAN é importante para o negócio e caro, você precisa criar a WAN de uma maneira sistemática. Esta figura mostra as etapas para o design de WAN.

Cada vez que uma modificação a uma WAN existente é considerada, essas etapas devem ser seguidas. Porém, como muitas WANs evoluíram com o passar do tempo, algumas das diretrizes discutidas aqui podem não ter sido consideradas. As modificações de WAN podem ocorrer devido à expansão de servidores WAN da empresa ou à acomodação de novas práticas e métodos comerciais.

Essas são as etapas para criar ou modificar uma WAN:

Etapa 1. Localize as LANS - Estabeleça os pontos de extremidade de origem e destino que se conectarão pela WAN.

Etapa 2. Analise o tráfego - Descubra qual tráfego de dados deve ser transportado, sua origem e seu destino. As WANs transportam uma variedade de tipos de tráfego com requisitos variados para largura de banda, latência e atraso. Para cada par de pontos de extremidade e para cada tipo de tráfego, é necessário fornecer informações sobre as características do tráfego.

Etapa 3. Planeje a topologia - A topologia é influenciada por considerações geográficas, mas também por

requisitos como disponibilidade. Um requisito de alto nível para disponibilidade exige links extras que fornecem caminhos de dados alternativos para redundância e balanceamento de carga.

Etapa 4. Estime a largura de banda exigida - O tráfego nos links pode ter requisitos variados para latência e atraso.

Etapa 5. Escolha a tecnologia WAN - Selecione as tecnologias de link adequadas.

Etapa 6. Avalie despesas - Quando todos os requisitos são estabelecidos, os custos operacionais e de instalação para a WAN podem ser determinados e comparados com a necessidade comercial que orienta a implementação de WAN.

Como mostrado na figura, as etapas de design descritas aqui não são um processo linear. Várias iterações dessas etapas podem ser necessárias antes de finalizar um design. Para manter o ótimo desempenho da WAN, é necessário monitorar e reavaliar continuamente.

Exibir meio visual

  • 8.3.3 Considerações sobre o tráfego de WAN

Página 1:

A tabela na figura mostra a ampla variedade de tipos de tráfego e seus requisitos variados de largura de

banda, latência e atraso que os links de WAN exigem para transportar.

Para determinar as condições de fluxo de tráfego e controle de tempo de um link de WAN, você precisa analisar as características específicas de tráfego para cada LAN que está conectada à WAN. A determinação das características de tráfego pode envolver consulta aos usuários da rede e avaliação de suas necessidades.

Exibir meio visual

  • 8.3.4 Considerações sobre a topologia WAN

Página 1:

Depois de estabelecer pontos de extremidade de LAN e características de tráfego, a próxima etapa para implementar uma WAN é criar uma topologia satisfatória. Criar uma topologia de WAN essencialmente consiste no seguinte:

Selecione um padrão de interconexão ou layout para os links entre os vários locais

Selecione as tecnologias para que esses links satisfaçam os requisitos de empresa a um custo aceitável

Clique nos botões na figura para exibir um exemplo de cada tipo de topologia de WAN.

Muitas WANs usam uma topologia em estrela. À medida em que a empresa cresce e são adicionadas novas filiais, elas são conectadas com a matriz, criando uma topologia em estrela tradicional. Os pontos de extremidade em estrela muitas vezes são conectados de maneira cruzada, criando uma malha ou topologia de malha parcial. Isto propicia muitas combinações possíveis para interconexões. Ao criar, reavaliar ou modificar uma WAN, selecione uma topologia que atenda os requisitos de design.

Ao selecionando um layout, há vários fatores para considerar. Mais links aumentam o custo dos serviços da rede, mas ter vários caminhos entre destinos aumenta a confiabilidade. Acrescentar mais dispositivos de rede ao caminho de dados aumenta a latência e diminui a confiabilidade. Geralmente, cada pacote deve ser completamente recebido em um nó antes de ser transmitido ao próximo.

Clique no botão Hierárquico na figura.

Quando muitos locais devem ser agrupados, é recomendada uma solução hierárquica. Por exemplo, imagine uma empresa que tem filiais em todos os países da União européia e tem uma filial em todas as cidades com mais de 10.000 habitantes. Cada filial tem uma LAN e decidiram interconectar as filiais. Uma rede de malha obviamente não é viável porque seriam centenas de milhares de links.

A solução é implementar uma topologia hierárquica. Agrupe as LANs em cada área e interconecte-as para formar uma região; em seguida, interconecte as regiões para formar o núcleo da WAN. A área poderia se basear no número de locais a serem conectados com um limite superior entre 30 e 50. A área teria uma topologia estrela, com os hubs das estrelas vinculados para formar a região. As regiões poderiam ser geográficas, conectando entre três e 10 áreas e o hub de cada região poderia ser vinculado de ponto a ponto.

Uma hierarquia de três camadas é geralmente útil quando o tráfego da rede espelha a estrutura de filial da empresa e é dividido em regiões, áreas e filiais. Também é útil quando existe um serviço central para o qual todas as filiais devem ter acesso, mas os níveis de tráfego são insuficientes para justificar a conexão direta de uma filial com o serviço.

A LAN no centro da área pode ter servidores que fornecem serviços locais e também baseados em área. Dependendo dos volumes de tráfego e tipos, as conexões de acesso podem ser dialup, alugadas ou de frame relay. O Frame Relay facilita a formação em malha para obter redundância sem exigir conexões físicas adicionais. Links de distribuição podem ser Frame Relay ou ATM e o núcleo da rede pode ser ATM ou linha alugada.

Ao planejar redes mais simples, uma topologia hierárquica ainda deve ser considerada porque pode fornecer melhor escalabilidade de rede. O hub ao centro de um modelo de duas camadas também é um núcleo, mas sem outros roteadores de núcleo conectados a ele. Da mesma maneira, em uma solução de

camada única, o hub de área funciona como o hub regional e o hub de núcleo. Isto permite o crescimento fácil e rápido no futuro, porque o design básico pode ser replicado para adicionar novas áreas de serviço.

Exibir meio visual

Página 2:

Tecnologias de conexão WAN

Uma WAN privada típica usa uma combinação de tecnologias que normalmente são escolhidas com base no tipo de tráfego e volume. São usados ISDN, DSL, Frame Relay ou linhas alugadas para conectar filiais individuais em uma área. São usados Frame Relay, ATM ou linhas alugadas para conectar áreas externas ao backbone. ATM ou linhas alugadas formam o backbone de WAN. As tecnologias que exigem o estabelecimento de uma conexão antes de poder transmitir dados, como telefone básico, ISDN ou X.25, não são adequadas para WANs que exigem tempo de resposta rápido ou baixa latência.

Diferentes partes de uma empresa podem ser diretamente conectadas com linhas alugadas ou com um link de acesso ao ponto-de-presença (POP) mais próximo de uma rede compartilhada. Frame Relay e ATM são exemplos de redes compartilhadas. As linhas alugadas são geralmente mais caras que links de acesso, mas estão disponíveis a praticamente qualquer largura de banda e possuem latência e atraso muito baixos.

Redes ATM e de Frame Relay transportam tráfego de vários clientes usando os mesmos links internos. A empresa não tem nenhum controle sobre o número de links ou saltos que os dados devem atravessar na rede compartilhada. Ela não pode controlar o tempo que os dados devem esperar em cada nó antes de mover para o próximo link. Esta incerteza em latência e atraso torna essas tecnologias inadequadas para alguns tipos de tráfego de rede. Porém, as desvantagens de uma rede compartilhada podem geralmente ser compensadas pelo custo reduzido. Como vários clientes estão compartilhando o link, o custo para cada é geralmente menor que o custo de um link direto da mesma capacidade.

Embora ATM seja uma rede compartilhada, ele foi criado para produzir latência e atraso mínimos através de links internos de alta velocidade que enviam unidades de dados facilmente gerenciáveis, chamadas de células. As células de ATM têm um comprimento fixo de 53 bytes, 48 bytes para dados e 5 bytes para o cabeçalho. O ATM é usado amplamente para transportar tráfego que não tolera atrasos.

O Frame Relay também pode ser usado para tráfego que não tolera atrasos, geralmente usando mecanismos de QoS para dar prioridade para os dados mais importantes.

Exibir meio visual

Página 3:

Muitas WANs de empresa têm conexões com a Internet. Embora a Internet possa representar um

problema de segurança, ela fornece uma alternativa para o tráfego entre filiais. Parte do tráfego que deve ser considerado durante o design vai ou vem da Internet. Implementações comuns devem fazer cada rede na empresa conectar-se a um ISP diferente ou fazer todas as redes de empresa conectarem-se a um único ISP a partir de uma conexão de camada de núcleo.

Exibir meio visual

  • 8.3.5 Considerações sobre largura de banda WAN

Página 1:

Lembre-se de que uma rede suporta as necessidades comerciais de uma empresa. Muitas empresas dependem da transferência de dados em alta velocidade entre locais remotos. Consequentemente, é crucial possuir largura de banda mais alta para transmitir mais dados em um determinado tempo. Quando a largura de banda é inadequada, a competição entre vários tipos de tráfego faz os tempos de resposta

aumentarem, o que reduz a produtividade dos funcionário e reduz a velocidade de processos baseados em web que são críticos para a empresa.

A figura mostra como links de WAN são geralmente classificados como de velocidade alta ou baixa.

Exibir meio visual

  • 8.3.6 Problemas comuns na implementação de WAN

Página 1:

A figura resume os problemas comuns de implementação de WAN e as perguntas que você precisa fazer antes de efetivamente implementar uma WAN.

Exibir meio visual

  • 8.3.7 Estudo de caso: Diagnóstico de WAN a partir de uma perspectiva de ISPs

Página 1:

O gráfico ilustra as perguntas típicas que a equipe de suporte técnico de um ISP deve fazer a um cliente

que está pedindo suporte.

Uma proporção significativa das chamadas de suporte recebidas por um ISP refere-se à lentidão da rede. Para solucionar esse problemas com eficácia, você deve isolar os componentes individuais e testar cada um como segue:

Host de PC individual - Um número grande de aplicações de usuário abertas ao mesmo tempo no PC pode ser responsável pela lentidão que está sendo atribuída à rede. Ferramentas como o Gerenciador de Tarefas em um Windows PC podem ajudar a determinar a utilização da CPU.

LAN - Se o cliente tiver um software de monitoramento de rede na LAN, o gerente de rede pode informar se a largura de banda na LAN está alcançando 100 por cento de utilização com frequência. Esse é um problema que a empresa do cliente precisaria resolver internamente. Esse é o motivo por que é tão importante conhecer a linha de base de rede e realizar um monitoramento contínuo.

Link da extremidade da rede do usuário à extremidade do ISP - Teste o link do roteador de extremidade do cliente para o roteador de extremidade do ISP pedindo para o cliente fazer o logon no roteador e enviar cem pings de 1500 bytes (pings de estresse) para o endereço IP do roteador de extremidade do ISP. O cliente não pode corrigir esse problema. É responsabilidade do ISP comunicar-se com o provedor de link para corrigir isso.

Backbone do ISP - O representante de serviço do cliente do ISP pode realizar pings de estresse a partir da extremidade do roteador de ISP para o roteador de extremidade do cliente. Eles também podem executar pings de estresse em cada link pelo qual circula o tráfego do cliente. Ao isolar e testar cada link, o ISP pode determinar qual link está causando o problema.

Servidor sendo acessado - Em alguns casos, a lentidão atribuída à rede pode ser causada por congestionamento do servidor. Esse problema é o mais difícil de diagnosticar e deve ser a última opção a

ser investigada depois de eliminar todas as outras.

Exibir meio visual

Página 2:

Nesta atividade, você e outro aluno criarão a rede exibida no diagrama de topologia. Você configurará o

NAT, DHCP e OSPF e então verificará a conectividade. Quando a rede estiver funcionando completamente, um aluno apresentará diversos erros. Em seguida, o outro aluno usará técnicas de solução de problemas para isolar e resolver o problema. Em seguida, os alunos inverterão as funções e repetirão o processo. Esta atividade pode ser feita em equipamento real ou com o Packet Tracer.

Exibir meio visual

8.4 Solução de problemas da rede

8.4.1 Interpretando diagramas de rede para identificar problemas

Página 1:

É quase impossível solucionar qualquer tipo de problema de conectividade de rede sem um diagrama de

rede que descreve endereços IP, rotas IP, dispositivos como firewalls e switches, e assim por diante. Geralmente, topologias lógicas e físicas ajudam a identificar e solucionar problemas.

Diagrama físico de rede

Um diagrama físico de rede mostra o layout físico dos dispositivos conectado à rede. É necessário saber como os dispositivos são conectados fisicamente para identificar e solucionar problemas na camada Física, como cabeamento ou problemas de hardware. As informações registradas no diagrama geralmente incluem:

Tipo de dispositivo Modelo e fabricante Versão do sistema operacional Tipo de cabo e identificador Especificação do cabo Tipo de conector Pontos de extremidade de cabeamento

A figura mostra um exemplo de um diagrama físico de rede que fornece informações sobre o local físico dos dispositivos de rede, os tipos de cabeamento entre eles, e os números de identificação de cabo. Estas informações seriam usadas principalmente para identificar e solucionar problemas físicos com dispositivos ou cabeamento. Além do diagrama físico de rede, alguns administradores incluem fotografias reais dos wiring closets como parte da documentação de rede.

Diagrama lógico de rede

Um diagrama lógico de rede mostra como os dados são transferidos na rede. Símbolos representam elementos de rede como roteadores, servidores, hubs, hosts, concentradores de VPN e dispositivos de segurança. As informações registradas em um diagrama lógico de rede podem incluir:

Identificadores de dispositivo Endereço IP e sub-rede Identificadores de interface Tipo de conexão DLCI para circuitos virtuais VPNs ponto a ponto Protocolos de roteamento Rotas estáticas Protocolos de enlace de dados Tecnologias WAN usadas

Clique no botão Lógico na figura para ver um exemplo de um diagrama lógico de rede.

A figura mostra a mesma rede, mas, dessa vez, fornece informações lógicas como endereços IP de dispositivo específicos, números de rede, números de porta, tipos de sinal e atribuições de DCE para links seriais. Estas informações podem ser usadas para identificar e solucionar problemas em todas as camadas de OSI.

Exibir meio visual

8.4.2 Identificação e solução de problemas de camada física

Página 1:

Sintomas de problemas de camada física

A camada Física transmite bits de um computador para outro e regula a transmissão de um fluxo de bits pelo meio físico. A camada Física é a única camada com propriedades tangíveis fisicamente, como fios, placas e antenas.

Falhas e condições abaixo do ideal na camada Física não só incomodam os usuários, mas também afetam a produtividade da empresa inteira. Redes que experimentam essas condições geralmente passam por paradas bruscas. Como as camadas superiores do modelo OSI dependem da camada Física para funcionar, um técnico de rede deve ter a capacidade de isolar e corrigir problemas com eficácia nesta camada.

Um problema de camada Física ocorre quando as propriedades físicas da conexão são inferiores, fazendo os dados serem transferidos a uma taxa que é consistentemente menor que a taxa de fluxo de dados estabelecida na linha de base. Se houver um problema que faça a rede operar abaixo da ideal na camada Física, a rede poderá continuar funcionando, mas o desempenho será intermitente ou consistentemente abaixo do nível especificado na linha de base.

Os sintomas comuns de problemas de rede na camada Física incluem:

Desempenho abaixo da linha de base - Se o desempenho for insatisfatório o tempo todo, o problema provavelmente estará relacionado a uma configuração pobre, à capacidade inadequada em algum lugar, ou a algum outro problema sistêmico. Se o desempenho variar e não for sempre insatisfatório, o problema será relacionado provavelmente a uma condição de erro ou está sendo afetado por tráfego de outras origens. As razões mais comuns para o desempenho lento ou baixo incluem servidores sobrecarregados ou subutilizados, configurações inadequadas de roteador ou switch, congestionamento de tráfego em um link da baixa capacidade e perda de quadro crônica. Perda de conectividade - Se um cabo ou dispositivo falhar, o sintoma mais óbvio é perda de conectividade entre os dispositivos que se comunicam por aquele link ou com o dispositivo ou interface com falha, como indicado por um teste de ping simples. Perda intermitente de conectividade pode indicar uma conexão solta ou oxidada. Alta contagem de colisão - Problemas de domínio de colisão afetam o meio local e rompem comunicações com dispositivos de infra-estrutura, servidores locais ou serviços de Camada 2 ou Camada 3. Colisões são normalmente um problema mais significativo em meios compartilhados do que em portas de switch. A média de contagens de colisão em meios compartilhados geralmente deve estar abaixo de 5 por cento, embora esse número seja conservador. Confira que se as informações são baseadas na média e não no pico das colisões. Problemas referentes a colisões podem ser geralmente rastreados até uma única origem. Pode ser um cabo com defeito em uma única estação, um cabo de uplink com defeito em um hub ou porta em um hub, ou um link exposto a ruído elétrico externo. Uma fonte de ruído próxima a um cabo ou hub pode causar colisões até mesmo quando não houver tráfego aparente. Se as colisões piorarem proporcionalmente ao nível do tráfego, se a quantidade de colisões chegar a 100 por cento ou se não houver nenhum tráfego bom, isso significará falha no sistema de cabo. Gargalos de rede ou congestionamento - Se um roteador, interface ou cabo falharem, protocolos de roteamento poderão redirecionar o tráfego para outras rotas que não são criadas para transportar a capacidade adicional. Isto pode resultar em congestionamento ou gargalos nessas partes da rede. Taxas altas de utilização de CPU - São um sintoma de que um dispositivo, como um roteador, switch ou servidor, está funcionando em ou está excedendo seus limites de design. Se isso não for resolvido rapidamente, a sobrecarga de CPU pode causar falha ou parada do dispositivo. Console mensagens de erro - Mensagens de erro reportadas no console do dispositivo indicam

um problema de camada Física.

Exibir meio visual

Página 2:

Causas de problemas de camada física

As situações que geralmente causam problemas de rede na camada Física incluem:

Alimentação

Problemas relacionados à alimentação são a principal razão de falha de rede. A alimentação CA principal flui para um módulo de transformador CA a CC externo ou interno para dentro de um dispositivo. O transformador fornece corrente de CC modulada corretamente, que age para dar alimentação a circuitos de dispositivo, conectores, portas e as ventoinhas usadas para resfriamento do dispositivo. Se houver suspeita de problema relacionado à alimentação, geralmente é feita uma inspeção física do módulo de alimentação. Verifique o funcionamento das ventoinhas e confira se estão desobstruídas as passagens de ar do chassi. Se outras unidades próximas também pararam de funcionar, poderá estar havendo uma falha da fonte de alimentação principal.

Falhas de hardware

Placas de rede defeituosas (NIC) podem ser a causa de erros de transmissão de rede devido a recentes colisões, quadros curtos e jabber. Jabber é geralmente definido como a condição na qual um dispositivo de rede transmite continuamente dados aleatórios sem sentido pela rede. Outras causas prováveis de jabber são arquivos de driver da placa de rede defeituosos ou corrompidos, cabeamento incorreto ou problemas de aterramento.

Falhas de cabeamento

Muitos problemas podem ser corrigidos simplesmente reconectando-se os cabos que ficaram parcialmente desconectados. Ao executar uma inspeção física, verifique se há cabos danificados, tipos de cabo impróprios e conectores RJ-45 mal instalados. Cabos suspeitos devem ser testados ou trocados por um cabo em perfeito estado de funcionamento.

Verifique se há conexões entre dispositivos ou portas de hub e switch que estejam usando cabos crossover incorretamente. Os cabos de pares separados não funcionam quando estão com defeito, dependendo da velocidade de Ethernet, o comprimento do segmento separado e a distância de qualquer extremidade.

Os problemas com cabos de fibra óptica podem ser causados por conectores sujos, curvas excessivamente apertadas e conexões RX/TX trocadas quando polarizada.

Os problemas com cabo coaxial geralmente ocorrem nos conectores. Quando o condutor do centro na extremidade do cabo coaxial não está reto e com o comprimento correto, não é obtida uma conexão boa.

Atenuação

Um bitstream de dados atenuado é quando a amplitude dos bits é reduzida enquanto trafega por um cabo. Se a atenuação for severa, o dispositivo receptor nem sempre poderá distinguir com êxito os bits de componente do fluxo um do outro. Isto resulta em uma transmissão adulterada e em uma solicitação do dispositivo receptor para nova transmissão do tráfego perdido pelo remetente. A atenuação poderá ser causada se um comprimento de cabo exceder o limite de design para o meio (por exemplo, um cabo Ethernet é limitado a 100 metros, ou 328 pés, para garantir um desempenho bom), ou quando há uma conexão pobre que é o resultado de um cabo solto, sujo ou com contatos oxidados.

Ruído

A interferência eletromagnética local (EMI) geralmente é conhecida como ruído. Há quatro tipos de ruído que são muito significativos para redes de dados:

Ruído de impulso que é causado por flutuações de voltagem ou picos de corrente induzidos no

cabeamento. Ruído aleatório (branco) que é gerado por muitas fontes, como estações de rádio FM, rádio da polícia, seguranças de prédios e ondas de rádio de aviação para aterrissagem automatizada. Diafonia estrangeira que é o ruído induzido por outros cabos no mesmo caminho. Diafonia próxima (NEXT) que é o ruído que se origina da diafonia de outros cabos adjacentes ou ruído de cabos elétricos próximos, dispositivos com motores elétricos de grande porte, ou qualquer coisa que inclua um transmissor mais avançado que um telefone celular.

Erros de configuração de interface

Muitas coisas podem ser configuradas incorretamente em uma interface para causar esse tipo de erro, causando uma perda de conectividade com segmentos de rede anexados. Exemplos de erros de configuração que afetam a camada Física incluem:

Links seriais reconfigurados como assíncronos em vez de síncronos Clock rate incorreto Fonte de clock incorreta Interface não ligada

Limites de design excedidos

Um componente pode estar operando de maneira não ideal na camada Física porque está sendo utilizado a uma taxa média mais alta do que ele é configurado para operar. Ao solucionar problemas desse tipo, fica evidente que os recursos para o dispositivo estão operando na capacidade máxima ou próximo a ela e há um aumento no número de erros de interface.

Sobrecarga CPU

Os sintomas incluem processos com altos percentuais de utilização de CPU, descartes das filas de

entrada, desempenho lento, serviços de roteador como o Telnet e ping lentos ou não respondem, ou não há nenhuma atualização de roteamento. Uma das causas de sobrecarga de CPU em um roteador é o alto tráfego. Se algumas interfaces forem sobrecarregadas regularmente com tráfego, redesenhe o fluxo de tráfego na rede ou atualize o hardware.

Exibir meio visual

Página 3:

Para isolar problemas nas camadas Físicas, faça o seguinte:

Verifique se há cabos ou conexões com defeito

Verifique se o cabo da interface de origem está conectado e se está em boas condições. Seu testador de cabo pode revelar um fio aberto. Por exemplo, na figura, o testador Fluke CableIQ revelou que os fios 7 e 8 estão apresentando falha. Para testar a integridade de um cabo, alterne os cabos suspeitos com um cabo que esteja funcionando com certeza. Se estiver em dúvida sobre a conexão estar funcionando, remova o cabo, faça uma inspeção física do cabo e da interface, e reconecte o cabo. Use um testador de cabo nas tomadas que deseja testar para verificar se estão cabeadas corretamente.

Verifique se o padrão de cabeamento correto é consistente ao longo da rede

Verifique se o cabo correto está sendo utilizado. Um cabo crossover pode ser necessário para conexões diretas entre alguns dispositivos. Verifique se o cabo está cabeado corretamente. Por exemplo, na figura, o testador Fluke CableIQ detectou que, embora um cabo estivesse bom para Fast Ethernet, ele não é qualificado para suportar 1000BASE-T porque os fios 7 e 8 não foram conectados corretamente. Esses fios não são necessários para Fast Ethernet, mas são necessários para Gigabit Ethernet.

Verifique se os dispositivos estão cabeados corretamente

Verifique se todos os cabos estão conectados às portas ou interfaces corretas. Verifique se as conexões cruzadas estão corrigidas para o local correto. Esse é o motivo pelo qual um wiring closet deve ser limpo e organizado: poupa muito tempo.

Verifique se as configurações de interface estão corretas

Verifique se todas as portas de switch estão definidas na VLAN correta e se estão configurados corretamente o spanning tree, a velocidade e as configurações bidirecionais. Confirme se as portas ou interfaces ativa não estão desligadas.

Verifique as estatísticas de funcionamento e as taxas de erros de dados

Use os comandos show da Cisco para verificar estatísticas como colisões, erros de entrada e saída. As características destas estatísticas variam, dependendo dos protocolos usados na rede.

Exibir meio visual

8.4.3 Identif. e solução de problemas da camada de enlace de dados

Página 1:

Sintomas de problemas da camada de enlace de dados

Identificar e solucionar problemas de Camada 2 pode ser um processo difícil. A configuração e a operação destes protocolos são críticas para criar uma rede funcional e bem ajustada.

Problemas de camada de enlace causam sintomas comuns que ajudam a identificar problemas de Camada 2. Reconhecer esses sintomas ajuda a reduzir o número de possíveis causas. Os sintomas comuns de problemas de rede na camada de enlace de dados incluem:

Não há funcionalidade ou conectividade na camada de rede ou acima

Alguns problemas de Camada 2 podem interromper a troca de quadros por um link, enquanto outros só degradam o desempenho da rede.

A rede está funcionando abaixo dos níveis de desempenho de linha de base

Há dois tipos distintos de funcionamento não ideal de Camada 2 que podem ocorrer em uma rede:

Quadros trafegam por um caminho ilógico ao seu destino, mas chegam. Um exemplo de um problema que pode levar os quadros a trafegarem por um caminho não ideal é uma topologia de spanning-tree de Camada 2 mal projetada. Neste caso, a rede deve experimentar uso de alta largura de banda em links que não devem ter aquele nível de tráfego. Alguns quadros são ignorados. Esses problemas podem ser identificados por estatísticas de contador de erro e mensagens de erro de console que aparecem no switch ou roteador. Em um ambiente de Ethernet, um toque estendido ou contínuo revelará também se os quadros estiverem sendo ignorados.

Broadcasts em excesso

Os sistemas operacionais modernos usam broadcasts extensivamente para detectar serviços de rede e outros hosts. Onde são observados broadcasts excessivos, é importante identificar a origem dos broadcasts. Geralmente, difusões excessivas são o resultado de uma das situações seguintes:

Aplicativos configurados ou programados incorretamente Domínios de broadcast grandes de Camada 2 Problemas de rede adjacentes, como loops de STP ou alternância de rota.

Mensagens da console

Em algumas instâncias, um roteador reconhece que um problema de Camada 2 ocorreu e envia mensagens de alerta à console. Normalmente, um roteador faz isto quando detecta um problema para interpretar quadros de entrada (encapsulamento ou problemas de enquadramento) ou quando keepalives são esperados, mas não chegam. A mensagem de console mais comum que indica um problema de

Camada 2 é uma mensagem de que o protocolo de linha está inativo.

Exibir meio visual

Página 2:

Causas de problemas da camada de enlace de dados

Os problemas na camada de enlace que geralmente resultam em problemas de conectividade de rede ou desempenho incluem:

Erros de encapsulamento

Um erro de encapsulamento ocorre porque os bits colocados pelo remetente em um campo específico não são o que o receptor espera ver. Esta condição ocorre quando o encapsulamento em uma extremidade de um link de WAN é configurado diferentemente do encapsulamento usado na outra extremidade.

Erros de mapeamento de endereço

Em topologias como ponto-a-multiponto, Frame Relay ou Ethernet broadcast, é essencial que um endereço de destino de Camada 2 apropriado seja dado ao quadro. Isto assegura sua chegada ao destino correto. Para obter isto, o dispositivo de rede deve corresponder um endereço de destino de Camada 3 com o endereço de Camada 2 correto usando mapas estáticos ou dinâmicos.

Ao usar mapas estáticos em Frame Relay, um mapa incorreto é um engano comum. Erros simples de configuração podem resultar em uma incompatibilidade de informações de endereçamento de Camada 2 e Camada 3.

Em um ambiente dinâmico, o mapeamento das informações de Camada 2 e Camada 3 pode falhar pelas seguintes razões:

Os dispositivos podem ter sido especificamente configurados para não responder a solicitações ARP ou ARP inverso. As informações de Camada 2 ou Camada 3 que são armazenadas em cache podem ter se alterado fisicamente. As respostas inválidas de ARP são recebidas devido a uma configuração incorreta ou um ataque de segurança.

Erros de enquadramento

Quadros normalmente funcionam em grupos de bytes de 8 bits. Um erro de enquadramento ocorre quando um quadro não termina em um limite de byte de 8 bits. Quando isto acontece, o receptor pode ter problemas que determinam onde um quadro termina e outro quadro inicia. Dependendo da gravidade do problema de enquadramento, a interface pode ser capaz de interpretar alguns dos quadros. Muitos quadros inválidos podem impedir keepalives válidos de serem trocados.

Erros de enquadramento podem ser causados por uma linha serial ruidosa, um cabo projetado de modo inadequado (muito longo ou não blindado corretamente) ou um relógio de linha de unidade do serviço de canal (CSU) incorretamente configurado.

Falhas ou loops de STP

O propósito do Protocolo Spanning Tree (STP) é transformar uma topologia física redundante em uma topologia em árvore através do bloqueio de portas redundantes. A maioria das problemas de STP gira em torno desses problemas:

Encaminhar loops que ocorrem quando nenhuma porta em uma topologia redundante é bloqueada e o tráfego é encaminhado indefinidamente em círculos. Quando o encaminhamento de loop inicia, isso normalmente congestiona os links de largura de banda mais baixa no caminho. Se todos os links forem da mesma largura de banda, todos estarão congestionados. Este congestionamento causa perda de pacote e leva a uma rede com baixo desempenho no domínio de L2 afetado. Envios excessivos devido a uma taxa alta alterações na topologia de STP. A função do mecanismo

de alteração de topologia é corrigir as tabelas de encaminhamento de Camada 2 depois que a topologia de encaminhamento foi alterada. Isto é necessário para evitar uma interrupção de conectividade porque, depois de uma alteração de topologia, alguns endereços MAC previamente acessíveis por portas particulares podem ficar acessíveis por portas diferentes. Uma alteração de topologia deve ser um evento raro em uma rede bem configurada. Quando um link em uma porta de switch fica ativo ou inativo, eventualmente há uma alteração de topologia quando o estado de STP da porta muda para ou de encaminhar. Porém, quando uma porta oscila (entre os estados ativo e inativo), isso causa mudanças repetitivas de topologia e inundação. A convergência lenta de STP ou reconvergência podem ser causadas por uma incompatibilidade entre a topologia real e a documentada, um erro de configuração, como uma configuração inconsistente de temporizadores de STP, uma CPU de switch sobrecarregada durante a convergência, ou um defeito de software.

Exibir meio visual

Página 3:

Identificação e solução de problemas de Camada 2 (PPP)

A dificuldade para identificar e solucionar problemas de tecnologias de Camada 2, como PPP e Frame Relay, é a indisponibilidade de ferramentas adequadas para Camada 3 comuns, como ping, para ajudar a identificar problemas além de constatar que a rede está inativa. Somente através de um entendimento completo dos protocolos e de sua operação, o técnico de rede consegue escolher a metodologia adequada de identificação e solução de problemas e os comandos Cisco IOS certos para solucionar o problema de uma maneira eficiente.

A maioria das problemas que ocorrem com PPP envolve negociação de link. Os passos para identificar e solucionar problemas de PPP estão a seguir:

Etapa 1. Verifique se o encapsulamento apropriado está sendo usado nas duas extremidades, usando o comando show interfaces serial. Na figura para Etapa 1, a saída de comando revela que R2 foi configurado incorretamente para usar encapsulamento HDLC.

Etapa 2. Confirme que as negociações do Protocolo de Controle de Link (LCP) tiveram sucesso verificando a saída para mensagem do LCP aberto.

Clique no botão Etapa 2 na figura.

Na figura, o encapsulamento em R2 foi alterado a PPP. A saída do comando show interfaces serial mostra a mensagem LCP aberto, que indica que as negociações de LCP tiveram sucesso.

Etapa 3. Verifique a autenticação em ambos os lados do link usando o comando debug ppp authentication.

Clique no botão Etapa 3 na figura.

Na figura, a saída do comando debug ppp authentication mostra que R1 não pode autenticar R2 usando CHAP, porque o nome de usuário e a senha para R2 não foram configurados em R1.

Consulte o Capítulo 2, "PPP" para obter mais detalhes sobre como identificar e solucionar implementações de PPP.

Exibir meio visual

Página 4:

Identificação e solução de problemas de Camada 2 (Frame Relay)

Para identificar e solucionar problemas de rede Frame Relay, divida a tarefa em quatro etapas:

Etapa 1. Verifique a conexão física entre o CSU/DSU (unidade de serviço de dados) e o roteador. Na figura, as conexões físicas entre os roteadores R2 e R3 e os CSU/DSU correspondentes podem ser verificadas usando um testador de cabo e conferindo se todos os LEDs de status na unidade de

CSU/DSU estão verdes. Na figura, algumas luzes de status para o CSU/DSU no R3 estão vermelhas, indicando um problema de conectividade potencial entre o CSU/DSU e roteador R3.

Etapa 2. Verifique se o roteador e o provedor de Frame Relay estão trocando informações de LMI corretamente usando o comando show frame-relay lmi.

Clique no botão Etapa 2 na figura.

Na figura, a saída do comando show frame-relay lmi no R2 não mostra erros ou mensagens perdidas. Isto indica que R2 e o switch do provedor de Frame Relay estão trocando informações de LMI corretamente.

Etapa 3. Verifique se o status de PVC está ativo usando o comando show frame-relay pvc.

Clique no botão Etapa 3 na figura.

Na figura, a saída do comando show frame-relay pvc no R2 verifica que o status de PVC está ativo.

Etapa 4. Verifique se o encapsulamento de Frame Relay corresponde nos dois roteadores, usando o comando show interfaces serial.

Clique no botão Etapa 4 na figura.

Na figura, a saída do comando show interfaces serial nos roteadores R2 e R3 mostra que existe uma incompatibilidade de encapsulamento entre eles. O R3 foi configurado incorretamente para usar o encapsulamento de HDLC em vez de Frame Relay.

Para obter detalhes adicionais sobre como identificar e solucionar problemas de implementações de Frame Relay, consulte o Capítulo 3, "Frame Relay".

Exibir meio visual

Página 5:

Identificação e solução de problemas de Camada 2 (Loops de STP)

Se você suspeitar que um loop de STP esteja causando um problema de Camada 2, verifique se o protocolo Spanning Tree está sendo executado nos dois switches. Um switch somente deverá ter STP desabilitado se não fizer parte de uma topologia fisicamente com loops. Para verificar operação de STP, use o comando show spanning-tree em cada switch. Se você descobrir que aquele STP não está funcionando, você pode habilitá-lo usando o comando spanning-tree vlan ID.

Siga essas etapas para identificar e solucionar problemas de loops de encaminhamento:

Etapa 1. Identifique que um loop de STP está ocorrendo.

Quando um loop de encaminhamento tiver se desenvolvido na rede, estes são os sintomas habituais:

Perda de conectividade para, de e pelas regiões de rede afetadas Alta utilização de CPU em roteadores conectados a segmentos afetados ou VLANs Alta utilização de link (geralmente 100 por cento) Alta utilização de backplane de switch (comparado com a utilização de linha de base) Mensagens de Syslog que indicam looping de pacote na rede (por exemplo, mensagens duplicadas de endereço IP de Protocolo de roteador de espera a quente) Mensagens de Syslog que indicam reaprendizado constante de endereço ou de mensagens de atraso de endereço MAC Aumento no número de descartes de saída em muitas interfaces

Etapa 2. Descubra a topologia (escopo) do loop.

A prioridade mais alta é parar o loop e restaurar a operação da rede. Para parar o loop, você deve saber quais portas estão envolvidas. Observe as portas com a mais alta utilização de link (pacotes por segundo). O comando show interface exibe a utilização para cada interface. Tenha certeza de registrar

estas informações antes de continuar para o próximo passo. Caso contrário, poderia ser difícil determinar no futuro a causa do loop.

Etapa 3. Quebre o loop.

Feche ou desconecte as portas envolvidas uma de cada vez. Depois que você desabilitar ou desconectar cada porta, verifique se a utilização de backplane de switch está de volta ao nível normal. Documente seus resultados. Lembre-se de que algumas portas podem não estar sustentando o loop, mas estão enviando o tráfego que chega com o loop. Quando você fecha essas portas de envio, só reduz a utilização de blackplane a uma quantidade pequena, mas você não interrompe o loop.

Etapa 4. Localize e corrija a causa do loop.

Determinar por que o loop começou é geralmente a parte mais difícil do processo, porque as razões podem variar. Também é difícil formalizar um procedimento exato que funciona em todos os casos. Primeiro, investigue o diagrama de topologia para localizar um caminho redundante.

Para cada switch no caminho redundante, verifique se há esses problemas:

O switch conhece a raiz de STP correta? A porta de raiz é identificada corretamente? As unidades de dados de protocolo da bridge (BPDUs) são recebidas regularmente na porta de raiz e em portas que deveriam supostamente bloquear? As BPDUs são enviadas regularmente em portas designadas não-raiz?

Etapa 5. Restaure a redundância.

Depois de encontrar o dispositivo ou link que está causando o loop e o problema for resolvido, restaure os links redundantes que foram desconectados.

Nós só mencionamos rapidamente o assunto de identificar e solucionar problemas de loops de STP. Identificar e solucionar problemas de loops e outros problemas de STP é uma discussão complexa e detalhada que está além do escopo deste curso. No entanto, se você desejar saber mais sobre identificação e solução de problemas de STP, consulte as observações técnicas excelentes visitando:

http://cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080136673.shtml#troubleshoot.

Exibir meio visual

8.4.4 Identificação e solução de problemas de camada de rede

Página 1:

Sintomas de problemas de camada de rede

Problemas de camada de rede incluem todos os problemas que envolvem um protocolo de Camada 3, protocolos roteados e protocolos de roteamento. Este tópico concentra-se principalmente em protocolos de roteamento de IP.

Problemas na camada de rede podem causar falhas de rede ou desempenho abaixo do nível ideal. Falha

de rede é quando a rede está quase ou completamente sem funcionar, afetando todos os usuários e as aplicações que usam a rede. Estas falhas normalmente são notadas rapidamente pelos usuários e pelos administradores de rede, e são obviamente críticas à produtividade de uma empresa. Problemas de otimização de rede normalmente envolvem um subconjunto de usuários, aplicações, destinos ou um tipo específico de tráfego. Problemas de otimização em geral podem ser mais difíceis de detectar e até mais difíceis de isolar e diagnosticar, porque eles normalmente envolvem várias camadas ou até mesmo o próprio computador host. Determinar que o problema é de camada de rede pode levar muito tempo.

Exibir meio visual

Página 2:

Na maioria das redes, rotas estáticas são usadas em combinação com protocolos de roteamento dinâmico. A configuração imprópria de rotas estáticas pode levar a um roteamento abaixo do nível ideal e, em alguns casos, criar loops de roteamento ou partes da rede podem ficar inalcançáveis.

Identificar e solucionar problemas de protocolos de roteamento dinâmico exige uma compreensão completa de como funcionam os protocolos de roteamento específicos. Alguns problemas são comuns a todos os protocolos de roteamento, enquanto outros são específicos do protocolo de roteamento individual.

Não há nenhum modelo para resolver problemas de Camada 3. Problemas de roteamento são resolvidos com um processo metódico, usando uma série de comandos para isolar e diagnosticar o problema.

Aqui estão algumas áreas para explorar ao diagnosticar um possível problema que envolve protocolos de roteamento:

Problemas gerais de rede

Geralmente uma mudança na topologia, como um link inativo, pode ter outros efeitos em outras áreas da rede que podem não ser óbvios no momento. Isto pode incluir a instalação de novas rotas, estáticas ou dinâmicas, remoção de outras rotas, e assim por diante.

Alguns itens devem ser considerados:

Algo mudou na rede recentemente? Há alguém trabalhando na infra-estrutura de rede nesse momento?

Problemas de conectividade

Verifique se há algum problema nos equipamentos e na conectividade, inclusive problemas de alimentação como interrupções e problemas ambientais como superaquecimento. Verifique também se há problemas de Camada 1, como problemas de cabeamento, portas incorretas e problemas de ISP.

Problemas de vizinhança

Se o protocolo de roteamento estabelecer uma adjacência com um vizinho, verifique se há problemas com os roteadores que formam as relações de vizinhança.

Banco de dados de topologia

Se o protocolo de roteamento usar uma tabela de topologia ou banco de dados, procure na tabela algo inesperado, como entradas faltando ou inesperadas.

Tabela de roteamento

Procure na tabela de roteamento algo inesperado, como rotas faltando ou inesperadas. Use comandos debug para exibir atualizações de roteamento e manutenção de tabela de roteamento. Exibir meio visual

8.4.5 Identificação e solução de problemas de camada de transporte

Página 1:

Problemas comuns de lista de acesso

Problemas de rede podem ocorrer devido a problemas de camada de Transporte no roteador, particularmente na extremidade da rede onde as tecnologias de segurança podem estar examinando e modificando o tráfego. Esse tópico discute duas das tecnologias de segurança de camada de Transporte mais comumente implementadas. Elas são as Listas de Controle de Acesso (ACLs) e a Tradução de Endereço de Rede (NAT).

Clique no botão Problemas de lista de acesso na figura.

Os problemas mais comuns com ACLs são causados por configuração imprópria. Há oito áreas onde as configurações incorretas geralmente ocorrem:

Seleção de fluxo de tráfego

A configuração incorreta de roteador mais comum está aplicando a ACL ao tráfego incorreto. O tráfego é definido pela interface do roteador pela qual o tráfego está passando e também pela direção na qual este tráfego está passando. Uma ACL deve ser aplicada à interface correta e a direção correta de tráfego deve ser selecionada para funcionar corretamente. Se o roteador estiver executando ACLs e NAT, a ordem na qual cada uma destas tecnologias é aplicada a um fluxo de tráfego será importante:

O tráfego de entrada é processado pela ACL de entrada antes de ser processado pela NAT de fora para dentro. O tráfego de saída é processado pela ACL de saída depois de ser processado pela NAT de dentro para fora.

Ordem de elementos de controle de acesso

Os elementos em uma ACL devem ser de específico para geral. Embora uma ACL possa ter um elemento para permitir especificamente um fluxo de tráfego determinado, os pacotes nunca corresponderão àquele elemento se eles estiverem sendo negados por outro elemento anterior na lista.

Negar tudo implicitamente

Em uma situação onde a segurança alta não é exigida na ACL, esquecer este elemento de controle de acesso implícito pode ser a causa de uma configuração incorreta de ACL.

Endereços e máscaras curinga

Máscaras curinga complexas fornecem melhorias significativas em eficiência, mas são mais sujeitas a erros de configuração. Um exemplo de uma máscara curinga complexa é usar o endereço 10.0.32.0 e a máscara curinga 0.0.32.15 para selecionar os primeiros 15 endereços de host na rede 10.0.0.0 ou na rede 10.0.32.0.

Seleção de protocolo de camada de transporte

Ao configurar as ACLs, é importante que somente os protocolos de camada de transporte corretos sejam especificados. Muitos engenheiros de rede, quando não têm certeza se um fluxo de tráfego específico usa uma porta TCP ou uma porta UDP, configuram ambas. Especificar ambas abre um buraco pelo firewall, possivelmente dando aos invasores uma avenida de acesso à rede. Também introduz um elemento adicional na ACL, de forma que a ACL leva mais tempo para processar, introduzindo mais latência nas comunicações da rede.

Portas de origem e destino

Controlar o tráfego corretamente entre dois hosts requer elementos de controle de acesso simétricos para ACLs de entrada e de saída. As informações de endereço e porta para tráfego gerado por um host que responde são uma imagem espelhada das informações de endereço e porta para o tráfego gerado pelo host que iniciou.

Uso da palavra-chave established

A palavra-chave established aumenta a segurança fornecida por uma ACL. Porém, se a palavra-chave for aplicada a uma ACL de saída, resultados inesperados poderão ocorrer.

Protocolos incomuns

ACLs configuradas incorretamente geralmente causam problemas para protocolos menos comuns que TCP e UDP. Protocolos incomuns que estão ganhando popularidade são VPN e protocolos de criptografia.

Solução de problemas de listas de controle de acesso

Um comando útil para exibir o funcionamento de ACL é a palavra-chave log em entradas de ACL. Esta palavra-chave instrui o roteador a colocar uma entrada no log de sistema sempre que aquela condição de entrada é correspondida. O evento registrado inclui detalhes do pacote que correspondeu ao elemento de ACL.

A palavra-chave log é especialmente útil para identificar e solucionar problemas, e também fornece informações sobre tentativas de invasão que são bloqueadas pela ACL.

Exibir meio visual

Página 2:

Problemas NAT comuns

O maior problema com todas as tecnologias de NAT é a interoperabilidade com outras tecnologias de rede, principalmente os que contêm ou derivam informações de endereçamento de rede de host no pacote. Algumas destas tecnologias incluem:

BOOTP e DHCP - Ambos os protocolos gerenciam a atribuição automática de endereços IP a clientes. Lembre-se de que o primeiro pacote que o cliente novo envia é um pacote IP de broadcast de solicitação DHCP. O pacote de solicitação DHCP tem um endereço IP de origem de 0.0.0.0. Como o NAT exige um endereço IP válido de destino e origem, BOOTP e DHCP podem ter dificuldade para funcionar em um roteador que executa o NAT estático ou dinâmico. Configurar o recurso de ajuda de IP pode ajudar a resolver este problema. DNS e WINS - Como um roteador que executa NAT dinâmico altera regularmente a relação entre endereços de entrada e saída já que as entradas de tabela expiram e são recriadas, um servidor DNS ou WINS fora do roteador de NAT não tem uma representação precisa da rede dentro do roteador. Configurar o recurso de ajuda de IP pode ajudar a resolver este problema. SNMP - Da mesma maneia que ocorre com os pacotes de DNS, o NAT não pode alterar as informações de endereçamento armazenadas na payload de dados do pacote. Por causa disto, uma estação de gerenciamento de SNMP em um lado de um roteador de NAT pode talvez não ser capaz de contactar os agentes de SNMP no outro lado do roteador de NAT. Configurar o recurso de ajuda de IP pode ajudar a resolver este problema. Protocolos de tunelamento e criptografia - Os protocolos de criptografia e tunelamento geralmente exigem que o tráfego seja gerado de uma porta UDP ou TCP específica, ou use um protocolo na camada de Transporte que não pode ser processado pelo NAT. Por exemplo, os protocolos de tunelamento de IPsec e os protocolos genéricos de encapsulamento de roteamento usados por implementações de VPM não podem ser processados pelo NAT. Se os protocolos de criptografia e tunelamento devem ser executados por um roteador NAT, o administrador de rede poderá criar uma entrada NAT estática para a porta necessária para um único endereço IP na parte de dentro do roteador NAT.

Se os protocolos de criptografia e tunelamento devem ser executados por um roteador NAT, o administrador de rede poderá criar uma entrada NAT estática para a porta necessária para um único endereço IP na parte de dentro do roteador NAT.

Um dos erros de configuração de NAT mais comuns é esquecer que o NAT afeta tanto o tráfego de entrada como o de saída. Um administrador de rede sem experiência poderia configurar uma entrada de NAT estática para redirecionar o tráfego de entrada para um host de backup específico interno. Esta instrução de NAT estática também altera o endereço de origem do tráfego daquele host, resultando possivelmente em comportamentos indesejáveis e inesperados ou em operação abaixo do nível ideal.

Temporizadores configurados de modo inadequado também podem resultar em comportamento de rede inesperado e operação abaixo do nível ideal de NAT dinâmico. Se os temporizadores de NAT forem muito curtos, as entradas na tabela de NAT poderão expirar antes de as respostas serem recebidas, de forma que os pacotes são descartados. A perda de pacotes gera novas transmissões, consumindo mais largura de banda. Se os temporizadores forem muito longos, as entradas poderão ficar na tabela de NAT mais tempo que o necessário, consumindo o conjunto de conexão disponível. Em redes ocupadas, isto poderá levar a problemas de memória no roteador e os hosts poderão não ser capazes de estabelecer conexões se a tabela de NAT dinâmica estiver cheia.

Consulte o Capítulo 7, "Serviços de endereçamento IP" para obter detalhes adicionais sobre como identificar e solucionar problemas de configuração de NAT.

Exibir meio visual

8.4.6 Identificação e solução de problemas de camada de aplicativo

Página 1:

Visão geral da camada de aplicativo

A maioria dos protocolos de camada de aplicativo fornece serviços de usuário. Os protocolos de camada de aplicativo são usados normalmente para gerenciamento de rede, transferência de arquivos, serviços de arquivo distribuídos, emulação de terminal e email. Porém, são adicionados freqüentemente novos serviços de usuário, como VPNs, VoIP, e assim por diante.

Os mais conhecidos e implementados protocolos de camada de aplicativo de TCP/IP incluem:

Telnet - Permite que os usuários estabeleçam conexões de sessão de terminal com hosts remotos. HTTP - Suporta a troca de texto, imagens gráficas, som, vídeo e outros arquivos de multimídia na Web. FTP - Executa transferências de arquivo interativas entre hosts. TFTP - Executa transferências de arquivo interativas básicas normalmente entre hosts e dispositivos de rede. SMTP - Suporta serviços básicos de entrega de mensagem. POP - Conecta-se a servidores de email e baixa email. Protocolo de gerenciamento de rede comum (SNMP) - Reune informações de gerenciamento de dispositivos de rede. DNS - Mapeia endereços IP para os nomes atribuídos a dispositivos de rede. Sistema de arquivos de rede (NFS) - Permite que computadores montem unidades em hosts remotos e os operem como se elas fossem unidades locais. Originalmente desenvolvido pela Sun Microsystems, ele se combina com dois outros protocolos de camada de aplicativo, representação de dados externa (XDR) e chamada de procedimento remoto (RPC), para permitir acesso transparente a recursos de rede remota.

Clique no botão Protocolos e portas de aplicativos na figura para exibir uma lista de protocolos de aplicativo e as portas associadas.

Exibir meio visual

Página 2:

Sintomas de problemas da camada de aplicativo

Os problemas de camada de aplicativo impedem que os serviços sejam fornecidos aos programas. Um problema na camada de aplicativo pode resultar em recursos inalcançáveis ou inutilizáveis quando as camadas física, de enlace de dados, de rede e de transporte estiverem funcionando. É possível ter conectividade de rede total, mas o aplicativo simplesmente não pode fornecer dados.

Outro tipo de problema na camada de aplicativo ocorre quando as camadas física, de enlace de dados, de rede e de transporte estão funcionando, mas a transferência de dados e as solicitações para serviços de rede de um único serviço de rede ou aplicativo não atende as expectativas normais de um usuário.

Um problema na camada de aplicativo pode fazer os usuários reclamarem que a rede ou o aplicativo específica com a qual eles estão trabalhando está lenta ou mais lenta que o habitual para transferir dados ou solicitar serviços de rede.

A figura mostra alguns dos possíveis sintomas de problemas de camada de aplicativo.

Exibir meio visual

Página 3:

Identificação e solução de problemas de aplicativo

O mesmo processo geral de identificação e solução de problemas que é usado para isolar problemas nas camadas inferiores também pode ser usado para isolar problemas na camada de aplicativo. Os conceitos são os mesmos, mas o foco tecnológico agora envolve coisas como conexões recusadas ou expiradas, listas de acesso e problemas de DNS.

As etapas para solucionar problemas de camada de aplicativo são as seguintes:

Etapa 1. Execute ping no gateway padrão.

Se for bem-sucedido, isso significa que os serviços de Camada 1 e Camada 2 estão funcionando corretamente.

Etapa 2. Verificar a conectividade fim-a-fim.

Use um ping estendido se estiver tentando fazer ping de um roteador Cisco. Se for bem-sucedido, isso significa que a Camada 3 está funcionando corretamente. Se as Camadas 1-3 estão funcionando corretamente, o problema deve existir em uma camada mais alta.

Etapa 3. Verifique a lista de acesso e a operação NAT.

Para identificar e solucionar problemas de listas de controle de acesso, siga os passos seguintes:

Use o comando show access-list. Existe algum ACL que poderia estar parando tráfego? Observe quais listas de acesso têm correspondências. Desmarque os contadores de lista de acesso com o comando clear access-list counters e tente estabelecer uma conexão novamente. Verifique os contadores de lista de acesso. Algum deles aumentou? Eles deveriam aumentar?

Para identificar e solucionar problemas do NAT, siga os passos seguintes:

Use o comando show ip nat translations. Há alguma tradução? As traduções são como o esperado? Desmarque as traduções de NAT com o comando clear ip nat translation * e tente acessar o recurso externo novamente. Use o comando debug ip nat e examine a saída. Observe o arquivo de configuração em execução. Os comandos ip nat inside e ip nat outside estão localizados nas interfaces corretas? O conjunto NAT está configurado corretamente? A ACL está identificando os hosts corretamente?

Se as ACLs e a NAT estão funcionando como o esperado, o problema deve ser em uma camada mais alta.

Etapa 4. Identifique e solucione problemas de conectividade de protocolo de camada superior.

Embora possa haver conectividade de IP entre uma origem e um destino, problemas ainda podem existir para um protocolo de camada superior específico, como FTP, HTTP ou Telnet. Estes protocolos estão no topo do transporte IP básico, mas estão sujeitos a problemas específicos de protocolo em relação a filtros de pacote e firewalls. É possível que tudo exceto email funcione entre uma determinada origem e um destino.

Identificar e solucionar um problema de conectividade de protocolo de camada superior exige um entendimento do processo do protocolo. Estas informações normalmente estão localizadas no RFC mais recente para o protocolo ou na página da Web do desenvolvedor.

Exibir meio visual

Página 4:

Corrigindo problemas de camada de aplicativo

As etapas para corrigir problemas de camada de aplicativo são as seguintes:

Etapa 1: Faça backup. Antes de continuar, verifique se uma configuração válida foi salva em algum dispositivo no qual a configuração possa ser modificada. Isto facilita a recuperação a um estado inicial conhecido.

Etapa 2: Faça uma mudança de configuração inicial de hardware ou software. Se a correção exigir mais de uma alteração, faça uma alteração de cada vez.

Etapa 3: Avalie e documente cada alteração e os resultados. Se os resultados de qualquer etapa de solução de problemas não forem bem-sucedidos, desfaça imediatamente as alterações. Se o problema for intermitente, espere para ver se o problema ocorre novamente antes de avaliar o efeito de qualquer alteração.

Etapa 4: Determine se a alteração resolve o problema. Verifique se a alteração de fato resolve o problema sem introduzir nenhum problema novo. A rede deve voltar à operação de linha de base e nenhum sintoma novo ou antigo deve ser observado. Se o problema não for resolvido, desfaça todas as alterações. Se forem descobertos problemas novos ou adicionais, modifique o plano de correção.

Etapa 5: Pare quando o problema for resolvido. Pare de fazer alterações quando o problema original for resolvido.

Etapa 6: Se necessário, obtenha assistência de recursos externos. Pode ser de um colega de trabalho, um consultor ou o Cisco Technical Assistance Center (TAC). Em ocasiões raras, pode necessário realizar um core dump, para criar uma saída de comando que um especialista da Cisco Systems pode analisar.

Etapa 7: Documente. Depois que o problema for resolvido, documente a solução. Exibir meio visual

Página 5:

Para concluir esta atividade com êxito, você precisa da documentação final da Atividade PT 8.1.2:

Detecção de rede e documentação concluída anteriormente neste capítulo. Esta documentação deve ter uma tabela de endereçamento e um diagrama de topologia precisos. Se você não tiver essa documentação, peça a seu instrutor versões precisas.

São fornecidas instruções detalhadas na atividade, bem como no link do PDF abaixo.

Instruções da atividade (PDF)

Clique no ícone do Packet Tracer para obter mais detalhes.

Exibir meio visual

8.5 Laboratórios do Capítulo

8.5.1 Identificação e solução de problemas de rede da empresa 1

Página 1:

Foi solicitado que você corrija os erros de configuração na rede da empresa. Para este laboratório, não use a proteção por login ou senha em nenhuma linha de console para impedir o bloqueio acidental. Use ciscoccna para todas as senhas deste cenário.

Observação: Como este laboratório é cumulativo, você usará todo o conhecimento e as técnicas de solução de problemas aprendidas no material anterior para concluir este laboratório com êxito.

Exibir meio visual

Página 2:

Esta atividade é uma variação do Laboratório 8.5.1. O Packet Tracer pode não suportar todas as tarefas

especificadas no laboratório prático. Esta atividade não deve ser considerada equivalente à conclusão do

laboratório prático. O Packet Tracer não substitui um experimento em laboratório prático com equipamentos reais.

São fornecidas instruções detalhadas na atividade, bem como no link do PDF abaixo.

Instruções da atividade (PDF)

Clique no ícone do Packet Tracer para obter mais detalhes.

Exibir meio visual

  • 8.5.2 Identificação e solução de problemas de rede da empresa 2

Página 1:

Para este laboratório, não use a proteção por login ou senha em nenhuma linha de console para impedir o bloqueio acidental. Utilize ciscoccna em todas as senhas deste laboratório.

Observação: Como este laboratório é cumulativo, você usará todo o conhecimento e as técnicas de solução de problemas aprendidas no material anterior para concluir este laboratório com êxito.

Exibir meio visual

Página 2:

Esta atividade é uma variação do Laboratório 8.5.2. O Packet Tracer pode não suportar todas as tarefas especificadas no laboratório prático. Esta atividade não deve ser considerada equivalente à conclusão do laboratório prático. O Packet Tracer não substitui um experimento em laboratório prático com equipamentos reais.

São fornecidas instruções detalhadas na atividade, bem como no link do PDF abaixo.

Instruções da atividade (PDF)

Clique no ícone do Packet Tracer para obter mais detalhes.

Exibir meio visual

  • 8.5.3 Identificação e solução de problemas de rede da empresa 3

Página 1:

Para este laboratório, não use a proteção por login ou senha em nenhuma linha de console para impedir o bloqueio acidental. Use ciscoccna para todas as senhas deste cenário.

Observação: Como este laboratório é cumulativo, você usará todo o conhecimento e as técnicas de solução de problemas aprendidas no material anterior para concluir este laboratório com êxito.

Exibir meio visual

Página 2:

Esta atividade é uma variação do Laboratório 8.5.3. O Packet Tracer pode não suportar todas as tarefas especificadas no laboratório prático. Esta atividade não deve ser considerada equivalente à conclusão do

laboratório prático. O Packet Tracer não substitui um experimento em laboratório prático com equipamentos reais.

São fornecidas instruções detalhadas na atividade, bem como no link do PDF abaixo.

Instruções da atividade (PDF)

Clique no ícone do Packet Tracer para obter mais detalhes.

Exibir meio visual

8.6

Resumo do capítulo

8.6.1

Resumo do capítulo

Página 1:

Neste capítulo, você aprendeu que uma linha de base de rede é necessária para identificar e solucionar problemas de forma eficaz. Para criar uma linha de base, é necessário primeiro garantir que a documentação de rede esteja atualizada e precisa. Uma documentação de rede apropriada inclui uma tabela de configuração de rede para todos os dispositivos e um diagrama de topologia que reflete o estado atual da rede. Quando a rede tiver sido documentada completamente, uma medição de linha de base de desempenho da rede deve ser realizada por um período de várias semanas a um mês para estabelecer a personalidade da rede. A primeira linha de base é criada durante um momento de funcionamento normal e estável.

O modo mais eficaz de solucionar problemas é realizar uma abordagem sistemática usando um modelo de camadas, como o modelo OSI ou o modelo TCP/IP. Três métodos geralmente usados para identificar e solucionar problemas inclui De baixo para cima, De cima para baixo, e Dividir e conquistar. Cada método tem suas vantagens e desvantagens e você aprendeu as diretrizes para escolher qual método deve aplicar. Você também aprendeu sobre as várias ferramentas de software e hardware que são usadas por profissionais de rede para reunir sintomas e solucionar problemas de rede.

Embora eles funcionem principalmente nas três primeiras camadas de OSI, as WANs têm problemas de implementação que podem afetar a operação do resto da rede. Você aprendeu sobre algumas das considerações para implementar as WANs e os problemas comuns que as WANs introduzem nas redes, como ameaças de segurança, problemas de largura de banda, latência e problemas de QoS.

Por fim, você explorou os sintomas e as causas de problemas comuns em cada camada de OSI, e as etapas para identificar e solucionar os problemas.

 

Exibir meio visual

Página 2:

 

Exibir meio visual

Página 3:

Nesta atividade de habilidades CCNA abrangente, a Corporação XYZ usa uma combinação de Frame Relay e PPP para conexões WAN. O roteador HQ fornece acesso ao farm de servidores e à Internet através do NAT. O HQ também usa uma ACL básica de firewall para filtrar o tráfego de entrada. Cada roteador de filial é configurado para o roteamento inter-VLAN e DHCP. O roteamento é obtido por meio de EIGRP, bem como rotas estáticas e padrão. As VLANs, o VTP e o STP são configurados em cada uma das redes comutadas. A segurança de porta é habilitada, e o acesso sem fio é fornecido. Seu trabalho é implementar com êxito todas estas tecnologias, aproveitando o que você aprendeu ao longo dos quatro cursos de exploração até esta atividade final.

São fornecidas instruções detalhadas na atividade, bem como no link do PDF abaixo.

Instruções da atividade (PDF)

Clique no ícone do Packet Tracer para obter mais detalhes.

 

Exibir meio visual

8.7

Teste do capítulo

8.7.1

Teste do capítulo

Página 1:

Exibir meio visual

Ir para a anterior Ir para a parte superior

All contents copyright © 2007-2009 Cisco Systems, Inc. | Traduzido por Cisco Networking Academy. Sobre

Ir para a anterior Ir para a parte superior All contents copyright © 2007-2009 Cisco Systems,