Você sabe identificar e resolver os problemas da camada física do modelo OSI que podem ser cobrados no CCNA Routing & Switching (CCNAX, CCENT e ICND-2)?

Mais especificamente no item “2.3 Troubleshoot interface and cable issues (collisions, errors, duplex, speed)” são listados os 7 problemas relacionados a camada 1 do modelo OSI que um candidato a certificação Cisco CCNA deve saber identificar e resolver.

Nesse artigo você vai aprender a identificar e resolver os problemas dos 4 primeiros itens da listagem do blueprint oficial da prova CCNA.

Você vai estudar nesse artigo os seguintes itens:

• Troubleshooting para a Certificação CCNA
• Framing
• CRC – Check de redundância cíclica
• Runts
• Giants
• Dicas e Conclusões

Deixa eu só adiantar uma coisa muito importante, nas dicas e conclusões desse artigo vou ensinar como zerar os contadores das interfaces para realizar troubleshooting mais precisos, assim como procurar direto o parâmetro que realmente interessa sem precisar olhar o comando inteiro.

Apesar de não ser parte do conteúdo do CCNA, como profissional certificado CCNA essas informações podem ajudar a você se diferenciar da multidão!

Se você é Membro Premuim da DlteC basta se logar clicando aqui que esses itens estão dentro do curso CCNA CCENT, mais especificamente no capítulo 12 item a partir do tópico 5 “Examinando e Resolvendo Problemas em Interfaces”.

Então é hora de arregaçar as mangas e estudar!

Troubleshooting para a Certificação CCNA

Troubleshooting em português pode ser traduzido para resolução de problemas, simples assim.

Esse assunto está descrito no blueprint da prova CCNA dentro do item “2.0 LAN Switching Technologies” e equivale a 21% do peso total da prova de certificação, ou seja, é um item muito importante para quem quer passar no exame do CCNA R&S!

Para os candidatos a CCNA que farão o exame em duas provas esse item é diferente nas provas CCENT e ICND-2.

No CCENT será cobrado apenas problemas com interfaces LAN e itens básicos, sendo o restante parte da prova ICND-2.

Para resolver as questões de troubleshooting no CCNA você precisará saber como é o funcionamento normal da rede, tecnologia ou item da questão para poder isolar o problema e encontrar sua causa raiz.

Para isso você vai contar com saídas de comandos show, descrição de sintomas dos problemas e algumas saídas de comando debug.

Os itens descritos no tópico 2 do blueprint fazem parte da saída do comando “show interfaces” das interfaces LAN de roteadores e switches.

Conforme destacado na saída do show interfaces abaixo, os problemas de Frame (framing), CRC, Runts e Giants são todos relacionados aos pacotes de entrada da interface (input).

Uma dica importante para quem está no caminho da sua primeira certificação Cisco é de não esquecer de praticar os comandos show que são cobrados na prova, pois é muito comum darmos mais importância no dia a dia dos estudos às configurações…

A seguir você vai estudar os quatro principais problemas do item 2 do blueprint do CCNA.

Uma dica para os iniciantes, caso você esteja querendo uma ajuda para seu planejamento e saber o que é o blueprint clique aqui e leia esse artigo com 8 Passos para a Primeira Certificação Cisco e depois volte, pois tenho certeza que vai ajudar.

Framing

Problemas de framing ou com os quadros são registrados no contador “Frame” do comando “show interfaces”.

O Frame representa o número de quadros recebidos incorretamente com erros de CRC e um número não inteiro de octetos com erro de alinhamento.

Geralmente os problemas que causam o incremento desse contador são causados por colisões, problemas físicos (cabeamento, placas de rede e outros) ou disparidade no modo duplex configurado.

Portanto, se o contador Frame estiver sendo incrementado verifique o cabeamento e também se não houve nenhuma alteração na configuração da porta do switch ou no computador em relação ao modo duplex configurado.

Lembre-se que o padrão das portas LAN é negociar tanto a velocidade (speed) como o modo duplex, se você não sabe fazer essa configuração clique aqui e leia artigo que vai ajudar.

CRC – Check de Redundância Cíclica

Esse contador incrementa quando o CRC (check de redundância cíclica) gerado pelo dispositivo remoto não coincide com o checksum calculado no receptor.

Normalmente é um indicativo de ruído, interferência ou problema na transmissão.

Um elevado número de erros de CRC pode também ser causado por colisões, mas também pode ser um indicativo de problemas físicos (cabeamento ou placa de rede) ou disparidade no modo duplex configurado.

Runts

O contador Runt exibe o número de quadros recebidos que são menores do que o tamanho de quadro mínimo do IEEE 802.3 de 64 bytes para o padrão Ethernet e com inconsistência no CRC.

A possível causa pode ser incompatibilidade no modo duplex ou problemas físicos, como cabeamento, porta ou placa de rede no dispositivo conectado.

Esse é um problema comum de ser encontrado em redes antigas com Hubs e altos índices de colisão.

Em redes com switches o Runt, assim como os dois problemas anteriores são fortes indicativos de problemas de configuração do modo duplex nas placas de rede.

Giants

Os Giants representam número de quadros recebidos que ultrapassam o tamanho máximo permitido pelo IEEE 802.3 de 1500 bytes.

Na maioria dos casos esse erro é causado por problema na placa de rede de algum dispositivo (NIC) ou configurações nas portas dos switches.

Vou fazer um exemplo teórico… Suponha que em um servidor você tem o 802.1Q configurado na placa de rede e não configurou a porta do switch corretamente.

Esse protocolo (802.1Q) que marca o quadro com uma Tag (bytes adicionais) e a porta do switch espera receber quadros normais de até 1500 bytes.

Se o servidor enviar um quadro marcado de 1500 bytes o total do quadro vai ultrapassar esse valor, pois tem os bytes adicionais da Tag, e um Giant será incrementado nos contadores da interface.

Para resolver esse problema procure pelo dispositivo que está conectado ao que está incrementando Giants e retire-o da rede ou corrija o MTU configurado para um valor “bata” em ambos os lados da conexão.

Dicas e Conclusões

Como prometi lá no começo do artigo seguem duas dicas para zerar os contadores e também melhorar a busca pelo parâmetro específico do comando show.

Quando estamos analisando erros em interfaces os valores crescem ao longo do tempo e se você não zerar a interface deve anotar o valor inicial e ficar fazendo continha…

Por exemplo, no início tinham 324 Runts, depois de 10 minutos o valor foi para 1234.

Tudo bem que é uma conta ridícula, mas se você esqueceu de anotar os valores iniciais vai ter que recomeçar o trabalho.

Para evitar isso utilize o comando “clear counters” em modo privilegiado que os contadores de interface serão zerados e você vai ter certeza de que valores diferente de zero são realmente erros.

Você pode limpar os contadores de todas as interfaces ou de uma interface específica, veja abaixo os dois exemplos.

DlteC-FW-GW#clear counters 
Clear "show interface" counters on all interfaces [confirm]
DlteC-FW-GW#
DlteC-FW-GW#clear counters fastEthernet 0/1
Clear "show interface" counters on this interface [confirm]
DlteC-FW-GW#

A segunda dica é para encontrar só uma coisa específica que você quer ver no comando, por exemplo, os Runts. Veja saída abaixo.

DlteC-FW-GW#show interfaces fast0/1 | include runt
 Received 14 broadcasts, 0 runts, 0 giants, 0 throttles
DlteC-FW-GW#

O segredo aqui são as opções “| include” e o que você quer saber na sequência. Assim você pode buscar direto a linha onde tem a informação desejada sem precisar analisar o comando todo.

Ufa… Chegamos ao final e agora você pode praticar um pouco o comando show interfaces em seu laboratório ou simulador, lembre-se que só a prática leva a perfeição!  😎

Espero que o artigo tenha sido útil na sua busca pelo CCNA e aguardo os comentários, dúvidas e sugestões no final dessa página na área de comentários!

É só descer um pouco que você encontra a área de comentários está lá embaixo…

Claro que você também pode usar os botões de compartilhamento se achar que o artigo vai ser útil para seus amigos.

Que a força esteja com você e até uma próxima!

Prof Marcelo Nascimento