Troubleshooting Problemas de Linha Serial

Introduction

Este capítulo apresenta informações gerais de troubleshooting e uma discussão das ferramentas e técnicas para o troubleshooting de conexões seriais. O capítulo consiste nas seguintes seções:

• Solução de problemas usando o comando show interfaces serial

• Usando o comando show controllers

• Utilizando comandos debug

• Usando testes estendidos de ping

• Solução de problemas de temporização

• Ajustando buffers

• Testes de linha serial especiais

• Informações detalhadas sobre o comando show interfaces serial

• Troubleshooting de Problemas T1

• Troubleshooting de Problemas de E1

Prerequisites

Requirements

Os leitores deste documento devem conhecer as seguintes definições.

• DTE = equipamento terminal de dados

• CD = Detecção da portadora

• CSU = channel service unit

• DSU = unidade de serviço digital

• SCTE = transmissão externa do relógio serial

• DCE = equipamento de terminação de circuito de dados

• CTS = clear-to-send

• DSR = pronto para o conjunto de dados

• SAP = Service Advertising Protocol (Protocolo de Propaganda de Serviço)

• IPX = Internetwork Packet Exchange

• FDDI = Fiber Distributed Data Interface

• ESF = formato de superframe estendido

• B8ZS = substituição binária de oito zeros

• LBO = Linha construída

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Solução de problemas usando o comando show interfaces serial

A saída do comando EXEC show interfaces serial exibe informações específicas às interfaces seriais. A Figura 15-1 mostra a saída do comando EXEC show interfaces serial para uma interface serial HDLC (High-Level Data Link Control).

Esta seção descreve como usar o comando show interfaces serial para diagnosticar problemas de conectividade de linha serial em um ambiente de rede de longa distância (WAN). As seções a seguir descrevem alguns dos campos importantes da saída do comando.

Outros campos mostrados na exibição são descritos em detalhes na seção "Detailed Information on the show interfaces serial Command", mais adiante neste capítulo.

Linhas seriais: show interfaces serial Status Line Conditions

Você pode identificar cinco possíveis estados de problema na linha de status da interface do visor serial show interfaces (consulte a Figura 15-1):

• Serial x está inoperante, protocolo de linha está inativo

• Serial x is up, line protocol is down

• Serial x is up, line protocol is up (looped) (serial x está ativa, protocolo de linha está ativo em loop)

• Serial x is up, line protocol is down (desativado)

• Serial x está administrativamente inoperante, protocolo de linha está inoperante

Figura 15-1 Saída do Comando show interface serial HDLC

Tabela 15-1: Linhas seriais: show interfaces serial Status Line Conditions - Esta tabela mostra as condições de status da interface, possíveis problemas associados às condições e as soluções para esses problemas.

Condição de linha de status	Possível problema	Solução
Serial x is up, line protocol is up		Essa é a condição de linha de status correta. Nenhuma ação é necessária.
Serial x está inoperante, protocolo de linha está inoperante (modo DTE)	Geralmente indica que o roteador não está detectando um sinal de CD (ou seja, o CD não está ativo). Problema da companhia telefônica - A linha está inativa ou não está conectada à CSU/DSU Cabeamento defeituoso ou incorreto Falha de hardware (CSU/DSU)	Verifique os LEDs na CSU/DSU para ver se o CD está ativo ou insira uma caixa de breakout na linha para verificar o sinal do CD. Verifique se você está usando o cabo e a interface apropriados (consulte a documentação de instalação do hardware). Insira uma caixa de breakout e marque todos os leads de controle. Entre em contato com seu serviço de linha alugada ou outro serviço da operadora para ver se há algum problema. Troque peças defeituosas. Se você suspeitar que o hardware do roteador está com defeito, altere a linha serial para outra porta. Se a conexão for ativada, a interface conectada anteriormente tem um problema.
Serial x is up, line protocol is down (modo DTE)	Roteador local ou remoto mal configurado Os keepalives não estão sendo enviados pelo roteador remoto Problema de linha alugada ou outro serviço da operadora - Linha ruidosa ou switch com falha ou configurado incorretamente Problema de temporização no cabo (SCTE não definido na CSU/DSU) Falha na CSU/DSU local ou remota CSU/DSU local ou remota com falha Falha de hardware do roteador (local ou remoto)	Coloque o modem, CSU ou DSU no modo de loopback local e use o comando show interfaces serial para ver se o protocolo de linha é ativado. Se o protocolo de linha for ativado, o problema de uma companhia telefônica ou de um roteador remoto com falha é provavelmente o problema. Se o problema parecer estar na extremidade remota, repita a Etapa 1 no modem remoto, CSU ou DSU. Verifique todo o cabeamento. Verifique se o cabo está conectado à interface correta, à CSU/DSU correta e ao ponto de terminação de rede da companhia telefônica correto. Use o comando EXEC show controllers para determinar qual cabo está conectado a qual interface. Ative o comando EXEC debug serial interface. Cuidado: como a saída de depuração recebe uma alta prioridade no processo da CPU, ela pode tornar o sistema inutilizável. Por esta razão, use comandos de depuração somente para troubleshoot problemas específicos ou durante sessões de Troubleshooting com a equipe de suporte técnico Cisco. Além disso, é melhor usar comandos debug durante períodos de tráfego baixo de rede e menos usuários. A depuração durante esses períodos diminui a probabilidade de o aumento da sobrecarga de processamento de comandos debug afetar o uso do sistema. Se o protocolo de linha não aparecer no modo de loopback local e se a saída do comando EXEC debug serial interface mostrar que o contador keepalive não está aumentando, é provável que haja um problema de hardware do roteador. Troque o hardware da interface do roteador. Se o protocolo de linha for ativado e o contador keepalive incrementar, o problema não está no roteador local. Solucione problemas da linha serial conforme descrito nas seções "Solução de problemas de temporização" e "Testes de loopback CSU e DSU", mais adiante neste capítulo. Se você suspeitar que o hardware do roteador está com defeito, altere a linha serial para uma porta não utilizada. Se a conexão for ativada, a interface conectada anteriormente tem um problema.
Serial x is up, line protocol is down (modo DCE)	Falta o comando de configuração da interface clockrate O dispositivo DTE não é compatível ou não está configurado para o modo SCTE CSU ou DSU remota com falha Cabo com falha ou incorreto Falha de hardware do roteador	Adicione o comando de configuração da interface clockrate na interface serial. Sintaxe: Descrição da sintaxe bps da taxa de clock: bps Taxa de clock desejada em bits por segundo: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148 000, 250000, 50000, 800000, 1000000, 1300000, 200000, 4000000, ou 8 000000. Defina o dispositivo DTE para o modo SCTE, se possível. Se a CSU/DSU não suportar SCTE, talvez seja necessário desativar a SCTE na interface do roteador Cisco. Consulte a seção "Invertendo o Relógio de Transmissão", mais adiante neste capítulo. Verifique se o cabo correto está sendo usado. Se o protocolo de linha ainda estiver inativo, há uma possível falha de hardware ou problema de cabeamento. Insira uma caixa de breakout e observe os leads. Substitua peças defeituosas conforme necessário.
Serial x is up, line protocol is up (looped) (serial x está ativa, protocolo de linha está ativo em loop)	Existe um loop no circuito. O número de sequência no pacote keepalive muda para um número aleatório quando um loop é detectado inicialmente. Se o mesmo número aleatório for retornado pelo link, existe um loop.	Use o comando EXEC privilegiado show running-config para procurar quaisquer entradas de comando de configuração de interface de loopback. Se você encontrar uma entrada de comando de configuração de interface loopback, use o comando de configuração de interface no loopback para remover o loop. Se você não encontrar o comando de configuração da interface loopback, examine a CSU/DSU para ver se eles estão configurados no modo loopback manual. Se estiverem, desative o loopback manual. Redefina a CSU ou DSU e inspecione o status da linha. Se o protocolo de linha for ativado, nenhuma outra ação será necessária. Se a CSU ou DSU não estiver configurada no modo de loopback manual, entre em contato com o serviço de linha alugada ou outro serviço da operadora para obter assistência na solução de problemas de linha.
Serial x is up, line protocol is down (desativado)	Alta taxa de erros devido ao problema de serviço da companhia telefônica problema de hardware CSU ou DSU Hardware de roteador (interface) com problema	Solucione problemas da linha com um analisador serial e uma caixa de breakout. Procure sinais de CTS e DSR alternados. Loop CSU/DSU (loop DTE). Se o problema continuar, é provável que haja um problema de hardware. Se o problema não continuar, é provável que haja um problema na companhia telefônica. Troque o hardware com defeito conforme necessário (CSU, DSU, switch, roteador local ou remoto).
Serial x está administrativamente inoperante, protocolo de linha está inoperante	A configuração do roteador inclui o comando de configuração da interface shutdown Endereço IP duplicado	Verifique a configuração do roteador para obter o comando shutdown. Use o comando de configuração de interface no shutdown para remover o comando shutdown. Verifique se não há endereços IP idênticos usando o comando EXEC privilegiado show running-config ou o comando EXEC show interfaces. Se houver endereços duplicados, resolva o conflito alterando um dos endereços IP.

Linhas seriais: Aumento das quedas de saída no link serial

As quedas de saída aparecem na saída do comando show interfaces serial (veja a Figura 15-1) quando o sistema está tentando entregar um pacote para um buffer de transmissão, mas não há buffers disponíveis.

Sintoma: Um número cada vez maior de saídas cai no link serial.

Tabela 15-2 Linhas Seriais: Aumentando as quedas de saída no link serial - Esta tabela descreve o possível problema que pode causar esse sintoma e sugere soluções.

Possível problema

Solução

A taxa de entrada para a interface serial excede a largura de banda disponível no link serial

Minimizar o tráfego de broadcast periódico (como roteamento e atualizações SAP) usando listas de acesso ou por outros meios. Por exemplo, para aumentar o atraso entre as atualizações SAP, use o comando de configuração da interface ipx sap-interval. Aumente o tamanho da fila de espera de saída em pequenos incrementos (por exemplo, 25%), usando o comando de configuração de interface hold-queue out. Nas interfaces afetadas, desative a comutação rápida para protocolos muito usados. Por exemplo, para desativar a comutação rápida IP, insira o comando de configuração da interface no ip route-cache. Para obter a sintaxe de comando para outros protocolos, consulte os guias de configuração do Cisco IOS e as referências de comandos. Implemente o enfileiramento de prioridade em links seriais mais lentos configurando listas de prioridade. Para obter informações sobre como configurar listas de prioridade, consulte os guias de configuração do Cisco IOS e as referências de comandos. Observação: quedas de saída são aceitáveis em determinadas condições. Por exemplo, se um link é conhecido por ser usado em excesso (sem nenhuma forma de corrigir a situação), geralmente é preferível descartar pacotes do que segurá-los. Isso vale para os protocolos que suportam controle de fluxo e podem retransmitir dados (como TCP/IP e Novell IPX). No entanto, alguns protocolos, como DECnet e transporte local, são sensíveis a pacotes descartados e acomodam a retransmissão mal, se é que são.

Linhas seriais: Aumento das quedas de entrada no link serial

As quedas de entrada aparecem na saída do comando EXEC show interfaces serial (consulte a Figura 15-1) quando muitos pacotes dessa interface ainda estão sendo processados no sistema.

Sintoma: Um número crescente de quedas de entrada no link serial.

Tabela 15-3: Linhas seriais: Aumentando as quedas de entrada no link serial - Esta tabela descreve o possível problema que pode causar esse sintoma e sugere soluções.

Possível problema

Solução

A taxa de entrada excede a capacidade do roteador ou das filas de entrada que excedem o tamanho das filas de saída

Observação: os problemas de queda de entrada geralmente são vistos quando o tráfego está sendo roteado entre interfaces mais rápidas (como Ethernet, Token Ring e FDDI) e interfaces seriais. Quando o tráfego é leve, não há problema. À medida que as taxas de tráfego aumentam, os backups começam a ocorrer. Os roteadores descartam pacotes durante esses períodos congestionados. Aumente o tamanho da fila de saída em interfaces de destino comuns para a interface que está descartando pacotes. Use o comando de configuração de interface hold-queue out. Aumente essas filas em pequenos incrementos (por exemplo, 25%) até que você não veja mais quedas na saída show interfaces. O limite de fila de espera de saída padrão é de 100 pacotes. Reduza o tamanho da fila de entrada, usando o hold-queue no comando de configuração de interface, para forçar as quedas de entrada a se tornarem descartes de saída. As quedas de saída têm menos impacto no desempenho do roteador do que as quedas de entrada. A fila de espera de entrada padrão é de 75 pacotes.

Linhas seriais: Aumento de erros de entrada em excesso de um por cento do tráfego total da interface

Se os erros de entrada aparecerem na saída show interfaces serial (consulte a Figura 15-1), há várias fontes possíveis desses erros. As fontes mais prováveis estão resumidas na Tabela 15-4.

Observação: qualquer valor de erro de entrada para erros de verificação de redundância cíclica (CRC), erros de enquadramento ou aborta acima de um por cento do tráfego total da interface sugere algum tipo de problema de link que deve ser isolado e reparado.

Sintoma: Um número cada vez maior de erros de entrada que excedem um por cento do tráfego total da interface.

Tabela 15-4: Linhas seriais: Aumento de erros de entrada em excesso de um por cento do tráfego total da interface

Possível problema

Solução

Os seguintes problemas podem resultar neste sintoma: Equipamento da companhia telefônica defeituoso Linha serial com ruído Configuração de temporização incorreta (SCTE não definido) Cabo ou cabo incorreto muito longo Cabo ou conexão defeituosos CSU ou DSU com problema Hardware de roteador com problema Conversor de dados ou outro dispositivo sendo usado entre o roteador e a DSU

Observação: a Cisco recomenda enfaticamente não usar conversores de dados quando você estiver conectando um roteador a uma WAN ou rede serial. Use um analisador serial para isolar a origem dos erros de entrada. Se você detectar erros, é provável que haja um problema de hardware ou uma incompatibilidade de relógio em um dispositivo externo ao roteador. Use os testes de loopback e ping para isolar a fonte de problema específica. Para obter mais informações, consulte as seções "Using the trace Command" e "CSU and DSU Loopback Tests", mais adiante neste capítulo. Procure padrões. Por exemplo, se ocorrerem erros em um intervalo consistente, eles podem estar relacionados a uma função periódica, como o envio de atualizações de roteamento.

Linhas seriais: Troubleshooting de Erros de Entrada de Linha Serial

Tabela 15-5: Esta tabela descreve os vários tipos de erros de entrada exibidos pelo comando show interfaces serial (consulte a Figura 15-1), possíveis problemas que podem estar causando os erros e as soluções para esses problemas.

Tipo de erro de entrada (nome do campo)	Possível problema	Solução
Erros de CRC (CRC)	Os erros de CRC ocorrem quando o cálculo de CRC não passa indicando que os dados estão corrompidos - por um dos seguintes motivos: Linha serial com ruído O cabo serial é muito longo ou o cabo da CSU/DSU para o roteador não está protegido O modo SCTE não está ativado em DSU O relógio de linha da CSU está configurado incorretamente Problema de densidade de um link T1 (enquadramento incorreto ou especificação de codificação)	Verifique se a linha está limpa o suficiente para os requisitos de transmissão. Blinde o cabo, se necessário. Certifique-se de que o cabo esteja dentro do comprimento recomendado: não mais de 50 pés (15,24 metros) ou 7,62 metros (25 pés) para o link T1. Verifique se todos os dispositivos estão configurados corretamente para um relógio de linha comum. Defina SCTE na DSU local e remota. Se a CSU/DSU não suportar SCTE, consulte a seção "Inverting the Transmit Clock" (Invertendo o relógio de transmissão), mais adiante neste capítulo. Certifique-se de que a CSU/DSU local e remota esteja configurada para o mesmo esquema de enquadramento e codificação usado pela linha alugada ou outro serviço de operadora (por exemplo, ESF/B8ZS). Entre em contato com seu serviço de linha alugada ou de outra operadora e faça com que ele realize testes de integridade na linha.
Erros de enquadramento (quadro)	Um erro de enquadramento ocorre quando um pacote não termina em um limite de byte de 8 bits por um dos seguintes motivos: Linha serial com ruído Cabo mal projetado; O cabo serial é muito longo; o cabo da CSU ou DSU para o roteador não está protegido O modo SCTE não está ativado na DSU; o relógio de linha da CSU está configurado incorretamente; um dos relógios está configurado para temporização local Problema de densidade de um link T1 (enquadramento incorreto ou especificação de codificação)	Verifique se a linha está limpa o suficiente para os requisitos de transmissão. Blinde o cabo, se necessário. Verifique se você está usando o cabo correto. Certifique-se de que o cabo esteja dentro do comprimento recomendado: não mais de 50 pés (15,24 metros) ou 7,62 metros (25 pés) para o link T1. Verifique se todos os dispositivos estão configurados corretamente para usar um relógio de linha comum. Defina SCTE na DSU local e remota. Se a CSU/DSU não suportar SCTE, consulte a seção "Inverting the Transmit Clock" (Invertendo o relógio de transmissão) mais adiante neste capítulo. Certifique-se de que a CSU/DSU local e remota esteja configurada para o mesmo esquema de enquadramento e codificação usado pela linha alugada ou outro serviço de operadora (por exemplo, ESF/B8ZS). Entre em contato com seu serviço de linha alugada ou de outra operadora e faça com que ele realize testes de integridade na linha.
Transmissão cancelada (abortar)	Os abortos indicam uma sequência ilegal de um bit (mais de sete em uma sequência). As seguintes são possíveis razões para esta ocorrência: O modo SCTE não está ativado em DSU O relógio de linha da CSU está configurado incorretamente O cabo serial é muito longo ou o cabo da CSU ou DSU para o roteador não está protegido Problema de densidade de um link T1 (enquadramento incorreto ou especificação de codificação) Pacote terminado no meio de uma causa típica de transmissão sendo uma redefinição de interface ou um erro de enquadramento Circuito com problemas de hardware, CSU/DSU defeituoso ou interface de envio defeituosa no roteador remoto	Verifique se todos os dispositivos estão configurados corretamente para usar um relógio de linha comum. Defina SCTE na DSU local e remota. Se a CSU/DSU não suportar SCTE, consulte a seção "Inverting the Transmit Clock" (Invertendo o relógio de transmissão), mais adiante neste capítulo. Blinde o cabo, se necessário. Certifique-se de que o cabo esteja dentro do comprimento recomendado: não mais de 50 pés (15,24 metros) ou 7,62 metros (25 pés) para o link T1. Verifique se todas as conexões estão boas. Verifique o hardware em ambas as extremidades do link. Troque equipamentos defeituosos, conforme necessário. Reduza as taxas de dados e veja se os abortos diminuem. Usar testes de loopback local e remoto para determinar onde ocorrem os abortos. Consulte a seção "Testes especiais de linha serial", mais adiante neste capítulo. Entre em contato com seu serviço de linha alugada ou de outra operadora e faça com que ele realize testes de integridade na linha.

Linhas seriais: Aumentando as redefinições da interface no link serial

As redefinições de interface que aparecem na saída do comando EXEC show interfaces serial (consulte a Figura 15-1) são o resultado de pacotes de manutenção de atividade perdidos.

Sintoma: Um número cada vez maior de reinicializações de interface no link serial.

Tabela 15-6: Esta tabela descreve os possíveis problemas que podem causar esse sintoma e sugere soluções.

Possível problema

Solução

Os seguintes problemas podem resultar neste sintoma: Congestionamento no link (normalmente associado a quedas de saída) Linha incorreta que causa transições de CD Possível problema de hardware na CSU, DSU ou switch

Quando houver redefinições de interface, examine outros campos da saída do comando show interfaces serial para determinar a origem do problema. Supondo que um aumento nas redefinições de interface esteja sendo registrado, examine os seguintes campos: Se houver um alto número de descartes de saída na saída show interfaces serial, consulte a seção "Linhas seriais: Aumentando as quedas de saída no link serial", no início deste capítulo. Verifique o campo transições da portadora na tela serial show interfaces. Se as transições de portadora forem altas enquanto as redefinições de interface estiverem sendo registradas, o problema provavelmente será um link inválido ou CSU ou DSU inválida. Entre em contato com seu serviço de linha alugada ou operadora e troque equipamentos defeituosos conforme necessário. Examine o campo de erros de entrada na tela serial show interfaces. Se os erros de entrada estiverem altos enquanto as redefinições da interface estiverem aumentando, o problema provavelmente é um link inválido ou CSU/DSU inválido. Entre em contato com seu serviço de linha alugada ou outra operadora e troque equipamentos defeituosos conforme necessário.

Linhas seriais: Aumento da contagem de transições de operadora no link serial

As transições da portadora aparecem na saída do comando EXEC show interfaces serial sempre que há uma interrupção no sinal da portadora (como uma reinicialização da interface na extremidade remota de um link).

Sintoma: Um número cada vez maior de transições de portadora conta no link serial.

A Tabela 15-7 descreve os possíveis problemas que podem causar esse sintoma e sugere soluções.

Tabela 15-7: Linhas seriais: Aumento da contagem de transições de operadora no link serial

Possível problema	Solução
Os seguintes problemas podem resultar neste sintoma: Interrupções de linha devido a uma fonte externa (como separação física do cabeamento, alarmes T1 vermelhos ou amarelos ou relâmpagos em algum lugar da rede) Switch, DSU ou hardware de roteador com defeito	Verifique o hardware nas duas extremidades do link. Conecte uma caixa de breakout ou um analisador serial e teste para determinar a origem dos problemas. Se um analisador ou caixa de breakout não conseguir identificar nenhum problema externo, verifique o hardware do roteador. Troque equipamentos defeituosos, conforme necessário.

Usando o comando show controllers

O comando EXEC show controllers é outra ferramenta de diagnóstico importante ao solucionar problemas de linhas seriais. A sintaxe do comando varia dependendo da plataforma:

• Para interfaces seriais em roteadores da série Cisco 7000, use o comando EXEC show controllers cbus.

• Para produtos de acesso Cisco, use o comando EXEC show controllers.

• Para AGS, CGS e MGS, use o comando EXEC show controllers mci.

A Figura 15-2 mostra a saída do comando EXEC show controllers cbus. Esse comando é usado em roteadores da série Cisco 7000 com a placa Fast Serial Interface Processor (FSIP). Verifique a saída do comando para ter certeza de que o cabo para a unidade de serviço de canal/unidade de serviço digital (CSU/DSU) está conectado à interface apropriada. Você também pode verificar a versão do microcódigo para ver se ela está atual.

Figura 15-2: Saída do comando show controllers cbus

Em produtos de acesso como os servidores e roteadores de acesso das séries Cisco 2000, Cisco 2500, Cisco 3000 e Cisco 4000, use o comando EXEC show controllers. A Figura 15-3 mostra a saída do comando show controllers da BRI (Basic Rate Interface) e das interfaces seriais em um servidor de acesso Cisco 2503. Observe que algumas saídas não são mostradas.

A saída show controllers indica o estado dos canais de interface e se um cabo está conectado à interface. Na Figura 15-3, a interface serial 0 tem um cabo DTE RS-232 conectado. A interface serial 1 não tem cabo conectado.

A Figura 15-4 mostra a saída do comando show controllers mci. Esse comando é usado somente em roteadores AGS, CGS e MGS. Se a interface elétrica for exibida como DESCONHECIDA (em vez de V.35, EIA/TIA-449 ou algum outro tipo de interface elétrica), um cabo conectado incorretamente é o provável problema. Também é possível um applique com defeito ou um problema com o cabeamento interno da placa. Se a interface elétrica for desconhecida, a exibição correspondente do comando EXEC show interfaces serial mostrará que a interface e o protocolo de linha estão inoperantes.

Figura 15-3: Saída do comando show controllers

Figura 15-4: Saída do comando show controllers mci

Utilizando comandos debug

A saída dos vários comandos EXEC privilegiados debug fornece informações de diagnóstico relacionadas ao status do protocolo e à atividade da rede para muitos eventos de internetworking.

Cuidado: como a saída de depuração recebe uma alta prioridade no processo da CPU, ela pode tornar o sistema inutilizável. Por esta razão, use comandos de depuração somente para troubleshoot problemas específicos ou durante sessões de Troubleshooting com a equipe de suporte técnico Cisco. Além disso, é melhor usar comandos debug durante períodos de tráfego baixo de rede e menos usuários. A depuração durante esses períodos diminui a probabilidade de o aumento da sobrecarga de processamento de comandos debug afetar o uso do sistema. Ao concluir o uso de um comando debug, lembre-se de desativá-lo com o comando específico no debug ou com o comando no debug all.

Os seguintes comandos debug são úteis na solução de problemas seriais e de WAN. Mais informações sobre a função e a saída de cada um desses comandos são fornecidas na publicação Debug Command Reference:

• debug serial interface – Verifica se os pacotes de manutenção de atividades HDLC estão sendo incrementados. Se não, é provável que exista um problema de cronometragem na placa de interface ou na rede.

• debug x25 events - Detecta eventos X.25, como a abertura e fechamento de circuitos virtuais comutados (SVCs). As informações de "causa e diagnóstico" resultantes estão incluídas no relatório de eventos.

• debug lapb - SAIs Link Access Procedure, Balanced (LAPB) ou Level 2 X.25 information.

• debug arp - Indica se o roteador está enviando informações sobre ou aprendendo sobre os roteadores (com pacotes ARP) do outro lado da nuvem da WAN. Use este comando quando alguns nós em uma rede TCP/IP estiverem respondendo, mas outros não.

• debug frame-relay lmi - Obtém informações da LMI (Local Management Interface, interface de gerenciamento local) úteis para determinar se um switch Frame Relay e um roteador estão enviando e recebendo pacotes LMI.

• debug frame-relay events - Determina se ocorrem trocas entre um roteador e um switch Frame Relay.

• debug ppp negotiation - Mostra pacotes PPP (Point-to-Point Protocol) transmitidos durante a inicialização do PPP, em que as opções do PPP são negociadas.

• debug ppp packet - Mostra os pacotes PPP sendo enviados e recebidos. Esse comando exibe os dumps de pacote de nível baixo.

• debug ppp errors - Mostra erros de PPP (como quadros ilegais ou malformados) associados à operação e negociação da conexão PPP.

• debug ppp chap - Mostra as trocas de pacotes CHAP (Challenge Handshake Authentication Protocol Protocolo de Autenticação de Handshake de Desafio) e PAP (Password Authentication Protocol Protocolo de Autenticação de Senha) do PPP.

• debug serial packet - Mostra os pacotes do serviço de dados multimegabit comutado (SMDS) sendo enviados e recebidos. Essa tela também imprime mensagens de erro para indicar por que um pacote não foi enviado ou foi recebido erroneamente. Para SMDS, o comando despeja todo o cabeçalho SMDS e alguns dados de payload quando um pacote SMDS é transmitido ou recebido.

Usando testes de ping estendidos

O comando ping é um teste útil disponível nos dispositivos de inter-redes Cisco, bem como na maioria dos sistemas host. No TCP/IP, essa ferramenta de diagnóstico também é conhecida como uma solicitação de eco de ICMP (Internet Control Message Protocol ).

Observação: o comando ping é particularmente útil quando altos níveis de erros de entrada estão sendo registrados na tela serial show interfaces. Veja a Figura 15-1.

Os dispositivos de comunicação entre redes Cisco fornecem um mecanismo de automação de envio de diversos pacotes de ping em seqüência. A Figura 15-5 ilustra o menu usado para especificar opções de ping estendidas. Este exemplo especifica 20 pings sucessivos. No entanto, ao testar os componentes em sua linha serial, você deve especificar um número muito maior, como 1000 pings.

Figura 15-5: Menu de especificação de ping estendido

Execução de testes de ping

Em geral, execute o ping de linha serial da seguinte maneira:

1. Coloque a CSU ou DSU no modo de loopback local.

2. Configure o comando ping estendido para enviar diferentes padrões de dados e tamanhos de pacote. A Figura 15-6 e a Figura 15-7 ilustram dois testes de ping úteis, um ping totalmente zero (1500 bytes) e um ping all-ones (1500 bytes), respectivamente.

3. Examine a saída do comando show interfaces serial (consulte a Figura 15-1) e determine se os erros de entrada aumentaram. Se os erros de entrada não aumentaram, o hardware local (DSU, cabo, placa de interface de roteador) provavelmente está em boas condições.

   Supondo que essa sequência de teste foi provocada pela aparência de um grande número de erros de CRC e enquadramento, é provável que haja um problema de temporização. Verifique se há um problema de temporização na CSU ou DSU. Consulte a seção "Solução de problemas de temporização", mais adiante neste capítulo.

4. Se você determinar que a configuração de temporização está correta e está operando corretamente, coloque a CSU ou DSU no modo de loopback remoto.

5. Repita o teste de ping e procure alterações nas estatísticas de erro de entrada.

6. Se os erros de entrada aumentarem, há um problema na linha serial ou na CSU/DSU. Entre em contato com o provedor de serviços de WAN e troque a CSU ou DSU. Se os problemas persistirem, entre em contato com o representante do suporte técnico.

Figura 15-6: Teste de ping ALl-Zeros de 1.500 bytes

Figura 15-7 Teste de ping All-One de 1.500 bytes

Solução de problemas de temporização

Conflitos de temporização em conexões seriais podem levar à perda crônica do serviço de conexão ou a um desempenho degradado. Esta seção discute os aspectos importantes dos problemas de temporização: problemas de temporização, detecção de problemas de temporização, isolamento de problemas de temporização e solução de problemas de temporização.

Visão geral do relógio

A CSU/DSU deriva o relógio de dados dos dados que passam por ela. Para recuperar o relógio, o hardware CSU/DSU deve receber pelo menos um valor de 1 bit para cada 8 bits de dados que passam por ele; isto é conhecido como densidade de uns. A manutenção da densidade de uns permite que o hardware recupere o relógio de dados de forma confiável.

As implementações T1 mais recentes geralmente usam enquadramento de Formato de Superquadro Estendido (ESF - Extended Superframe Format) com codificação de substituição binária de oito zeros (B8ZS - 8 zeros). B8ZS fornece um esquema pelo qual um código especial é substituído sempre que oito zeros consecutivos são enviados através do link serial. Esse código é interpretado na extremidade remota da conexão. Essa técnica garante densidade de uns independente do fluxo de dados.

As implementações T1 mais antigas usam D4 - também conhecido como enquadramento do formato de superquadro (SF - Superframe Format) e codificação de AMI (Alternate Mark Inversion). A AMI não utiliza um esquema de codificação como B8ZS. Isso restringe o tipo de dados que pode ser transmitido porque a densidade de uns não é mantida independentemente do fluxo de dados.

Outro elemento importante nas comunicações seriais é a temporização do terminal SCTE (Serial clock transmit external - transmissão externa do relógio serial). SCTE é o relógio ecoado do dispositivo DTE (equipamento terminal de dados) (por exemplo, um roteador) para o dispositivo DCE (equipamento de comunicação de dados) (por exemplo, CSU/DSU).

Quando o dispositivo DCE usa SCTE em vez de seu relógio interno para coletar dados do DTE, ele é melhor capaz de coletar os dados sem erros mesmo que haja um deslocamento de fase no cabo entre a CSU/DSU e o roteador. O uso do SCTE é altamente recomendado para transmissões seriais mais rápidas que 64 kbps. Se a CSU/DSU não suportar SCTE, consulte a seção "Inverting the Transmit Clock" (Invertendo o relógio de transmissão), mais adiante neste capítulo.

Causas do problema de relógio

Em geral, os problemas de temporização nas interconexões seriais de WAN podem ser atribuídos a uma das seguintes causas:

• Configuração de DSU incorreta

• Configuração de CSU incorreta

• Cabos fora da especificação - isto é, mais de 15,24 metros (50 pés) ou não blindados

• Conexões ruidosas ou deficientes no patch panel

• Vários cabos conectados em fileira

Detectando problemas de temporização

Para detectar conflitos de temporização em uma interface serial, procure os erros de entrada da seguinte maneira:

1. Use o comando EXEC show interfaces serial nos roteadores em ambas as extremidades do link.

2. Examine a saída do comando para CRC, erros de enquadramento e abortos.

3. Se qualquer uma dessas etapas indicar erros que excedem um intervalo aproximado de 0,5% 2,0% do tráfego na interface, é provável que existam problemas de temporização em algum lugar na WAN.

4. Isole a origem dos conflitos de temporização conforme descrito na seção a seguir, "Isolando problemas de temporização".

5. Ignore ou repare qualquer patch panel defeituoso.

Isolando problemas de temporização

Depois de determinar que os conflitos de temporização são a causa mais provável de erros de entrada, o procedimento a seguir o ajudará a isolar a origem desses erros:

1. Execute uma série de testes de ping e testes de loopback (locais e remotos), conforme descrito na seção "Testes de loopback de CSU e DSU", no início deste capítulo.

2. Determine a extremidade da conexão que é a origem do problema ou se o problema está na linha. No modo de loopback local, execute padrões e tamanhos diferentes nos testes de ping (por exemplo, use datagramas de 1500 bytes). Usar um único padrão e tamanho de pacote pode não forçar a materialização de erros, particularmente quando um cabo serial para o roteador ou CSU/DSU é o problema.

3. Use o comando EXEC show interfaces serial e determine se as contagens de erros de entrada estão aumentando e onde estão se acumulando.

Se os erros de entrada estiverem se acumulando em ambas as extremidades da conexão, a temporização da CSU é o problema mais provável.

Se apenas uma extremidade estiver apresentando erros de entrada, provavelmente há um problema de temporização ou cabeamento de DSU.

Abortos em uma extremidade sugerem que a outra extremidade está enviando informações incorretas ou que há um problema de linha.

Observação: sempre consulte a saída do comando show interfaces serial (consulte a Figura 15-1) e registre todas as alterações na contagem de erros ou observe se a contagem de erros não muda.

Soluções de problemas de temporização

Tabela 15-8 Linhas Seriais: Problemas e soluções de relógio: Esta tabela descreve as alternativas sugeridas para problemas de temporização, com base na origem do problema.

Possível problema	Solução
Configuração de CSU incorreta	Determine se as CSUs em ambas as extremidades concordam com a origem do relógio (local ou linha). Se as CSUs não concordarem, configure-as para que elas concordem. Geralmente, a linha é a origem. Verifique a configuração de LBO na CSU para garantir que a impedância corresponda à da linha física. Para obter informações sobre como configurar sua CSU, consulte a documentação de hardware da CSU.
Configuração de DSU incorreta	Determine se as DSUs em ambas as extremidades têm o modo SCTE ativado. Se o SCTE não estiver ativado em ambas as extremidades da conexão, ative-o. Verifique se a densidade de uns é mantida. Isso exige que a DSU use os mesmos esquemas de enquadramento e codificação (por exemplo, ESF e B8ZS) usados pela linha alugada ou outro serviço de operadora. Consulte o seu provedor de linhas alugadas para obter informações sobre seus esquemas de enquadramento e codificação. Se o serviço da operadora usar a codificação AMI, inverta o relógio de transmissão em ambos os lados do link ou execute a DSU no modo bit-stuff. Para obter informações sobre como configurar a DSU, consulte a documentação do hardware da DSU.
O cabo para o roteador está fora da especificação	Se o cabo tiver mais de 15,24 metros (50 pés), use um cabo mais curto. Se o cabo não estiver blindado, substitua-o por um cabo blindado.

Invertendo o relógio de transmissão

Se você estiver tentando conexões seriais a velocidades superiores a 64 kbps com uma CSU/DSU que não suporta SCTE, talvez seja necessário inverter o relógio de transmissão no roteador. Inverter o relógio de transmissão compensa os deslocamentos de fase entre os sinais de dados e do relógio.

O comando específico usado para inverter o relógio de transmissão varia entre plataformas. Em um Cisco 7000 Series Router, insira o comando invert-transmit-clock interface configuration. Para os roteadores da série Cisco 4000, use o comando de configuração da interface dte-invert-txc.

Para garantir que você esteja usando a sintaxe de comando correta para o roteador, consulte o guia do usuário para o roteador ou servidor de acesso e os guias de configuração e referências de comandos do Cisco IOS.

Observação: em plataformas mais antigas, inverter o relógio de transmissão pode exigir que você mova um jumper físico.

Ajustando buffers

A utilização excessiva da largura de banda (acima de 70%) resulta em desempenho geral reduzido e pode causar falhas intermitentes. Por exemplo, as transmissões de arquivos DECnet podem estar falhando devido aos pacotes que estão sendo descartados em algum lugar da rede.

Se a situação for suficientemente ruim, você deve aumentar a largura de banda do link. No entanto, aumentar a largura de banda pode não ser necessário ou imediatamente prático. Uma maneira de resolver problemas de superutilização da linha serial marginal é controlar como o roteador usa buffers de dados.

Cuidado: em geral, não ajuste os buffers do sistema a menos que você esteja trabalhando junto com um representante de suporte técnico da Cisco. Você pode afetar gravemente o desempenho do hardware e da rede se ajustar incorretamente os buffers do sistema no roteador.

Use uma das três opções a seguir para controlar como os buffers são usados:

• Ajustar parâmetros associados aos buffers do sistema

• Especifique o número de pacotes mantidos em filas de entrada ou saída (filas de espera)

• Priorizar como o tráfego é enfileirado para transmissão (enfileiramento de saída de prioridade)

Os comandos de configuração associados a essas opções são descritos nos guias de configuração do Cisco IOS e nas referências de comandos.

A seção a seguir concentra-se na identificação de situações nas quais essas opções provavelmente serão aplicadas e na definição de como você pode usar essas opções para ajudar a resolver problemas de conectividade e desempenho em interconexões seriais/WAN.

Ajustando buffers do sistema

Há dois tipos gerais de buffer nos roteadores Cisco: buffers de hardware e buffers de sistema. Somente os buffers do sistema são configuráveis diretamente pelos administradores do sistema. Os buffers de hardware são especificamente usados como os buffers de recepção e transmissão associados a cada interface e (na ausência de qualquer configuração especial) são gerenciados dinamicamente pelo próprio software do sistema.

Os buffers do sistema são associados à memória principal do sistema e alocados para blocos de memória de tamanhos diferentes. Um comando útil para determinar o status dos buffers do sistema é o comando EXEC show buffers. A Figura 15-8 mostra a saída do comando show buffers.

Figura 15-8 - Saída do comando show buffers

Na saída de show buffers:

• total - Identifica o número total de buffers no pool, incluindo buffers usados e não utilizados.

• permanente - Identifica o número permanente de buffers alocados no pool. Esses buffers estão sempre no pool e não podem ser aparados.

• na lista livre - Identifica o número de buffers atualmente no pool que estão disponíveis para uso.

• min - Identifica o número mínimo de buffers que o Route Processor (RP) deve tentar manter na lista livre:

  • O parâmetro min é usado para antecipar a demanda do conjunto por buffers em qualquer momento especificado.

  • Se o número de buffers na lista livre cair abaixo do valor min, o RP tentará criar mais buffers para esse pool.

• max allowed - Identifica o número máximo de buffers permitidos na lista livre:

  • O parâmetro max allowed impede que um pool monopolize buffers de que não precisa mais e libera essa memória de volta ao sistema para uso posterior.

  • Se o número de buffers na lista livre for maior que o valor permitido máximo, o RP deve tentar aparar buffers do pool.

• hits - Identifica o número de buffers que foram solicitados do pool. Esse contador de acertos fornece um mecanismo para determinar qual pool deve atender a demanda mais alta para buffers.

• erros - Identifica o número de vezes que um buffer foi solicitado e o RP detectou que buffers adicionais eram necessários. (Em outras palavras, o número de buffers na lista livre caiu abaixo de min.) A contagem de ausências representa o número de vezes que o RP foi forçado a criar buffers adicionais.

• trims - Identifica o número de buffers que o RP cortou do pool quando o número de buffers na lista livre excedeu o número máximo de buffers permitidos.

• criado - Identifica o número de buffers que foram criados no pool. O RP cria buffers quando a demanda por buffers aumenta até que o número de buffers na lista livre seja menor do que os buffers min e/ou ocorre uma falha devido a buffers zero na lista livre.

• falhas - Identifica o número de falhas para conceder um buffer a um solicitante mesmo após tentar criar um buffer adicional. O número de falhas representa o número de pacotes que foram descartados devido à falta de buffer.

• no memory - Identifica o número de falhas causadas por memória insuficiente para criar buffers adicionais.

A saída do comando show buffers na Figura 15-8 indica números altos nos campos trims e criados para buffers grandes. Se estiver recebendo números altos nesses campos, você pode aumentar o desempenho do link serial aumentando o valor livre máximo configurado para os buffers do sistema. trims identifica o número de buffers que o RP cortou do pool quando o número de buffers na lista livre excedeu o número de buffers máximos permitidos.

Use o comando global configuration max free number para aumentar o número de buffers de sistema livres. O valor que você configura deve ser aproximadamente 150% da figura indicada no campo total da saída do comando show buffers. Repita esse processo até que a saída do show buffers não indique mais os limites e os buffers criados.

Se a saída do comando show buffers mostrar um grande número de falhas no campo (sem memória) (veja a última linha de saída na Figura 15-8), você deve reduzir o uso dos buffers do sistema ou aumentar a quantidade de memória compartilhada ou principal (RAM física) no roteador. Entre em contato com seu representante de suporte técnico para obter assistência.

Implementando limites da fila de espera

As filas de espera são buffers usados por cada interface do roteador para armazenar pacotes de saída ou de entrada. Use o comando de configuração de interface hold-queue para aumentar o número de pacotes de dados enfileirados antes que o roteador descarte pacotes. Aumente essas filas em pequenos incrementos (por exemplo, 25%) até que você não veja mais quedas na saída show interfaces. O limite de fila de espera de saída padrão é de 100 pacotes.

Observação: o comando hold-queue é usado para pacotes comutados por processos e atualizações periódicas geradas pelo roteador.

Use o comando hold-queue para evitar que os pacotes sejam descartados e para melhorar o desempenho do link serial sob as seguintes condições:

• Você tem um aplicativo que não pode tolerar descartes e o protocolo pode tolerar atrasos maiores. A DECnet é um exemplo de um protocolo que atende a ambos os critérios. O transporte local (LAT) não é tolerado por não tolerar atrasos.

• A interface é muito lenta. A largura de banda é baixa ou a utilização prevista provavelmente excederá esporadicamente a largura de banda disponível.

Observação: quando você aumenta o número especificado para uma fila de espera de saída, pode ser necessário aumentar o número de buffers do sistema. O valor usado depende do tamanho dos pacotes associados ao tráfego antecipado para a rede.

Uso do Priority Queuing para reduzir gargalos

O enfileiramento de prioridade é um mecanismo de controle baseado em lista que permite que o tráfego seja priorizado em uma base interface por interface. O enfileiramento de prioridade envolve duas etapas:

1. Crie uma lista de prioridades por tipo de protocolo e nível de prioridade.

2. Atribua a lista de prioridades a uma interface específica.

Ambas as etapas usam versões do comando de configuração global priority-list. Além disso, o controle de tráfego adicional pode ser aplicado referindo-se aos comandos de configuração global access-list das especificações priority-list. Para obter exemplos de definição de listas de prioridade e detalhes sobre a sintaxe de comando associada ao enfileiramento de prioridade, consulte os guias de configuração do Cisco IOS e as referências de comandos.

Observação: o enfileiramento de prioridade cria automaticamente quatro filas de espera de tamanho variável. Isso substitui qualquer especificação de fila de espera incluída na sua configuração.

Use o enfileiramento de prioridade para evitar que os pacotes sejam descartados e para melhorar o desempenho do enlace serial sob as seguintes condições:

• Quando a interface está lenta, há uma variedade de tipos de tráfego sendo transmitidos e você deseja melhorar o desempenho do tráfego terminal.

• Se você tiver um enlace serial com cargas muito pesadas intermitentemente (como transferências de arquivos ocorrendo em horários específicos), o enfileiramento de prioridade ajudará a selecionar os tipos de tráfego que devem ser descartados em períodos de tráfego intenso.

Em geral, comece com o número padrão de filas ao implementar filas de prioridade. Depois de habilitar o enfileiramento de prioridade, a saída do monitor cai com o comando EXEC show interfaces serial. Se você observar que as quedas de saída estão ocorrendo na fila de tráfego especificada como alta prioridade, aumente o número de pacotes que podem ser enfileirados (usando a opção de palavra-chave queue-limit do comando de configuração global priority-list). Os argumentos de limite de fila padrão são 20 pacotes para a fila de alta prioridade, 40 para o meio, 60 para o normal e 80 para o baixo.

Observação: ao ligar o tráfego LAT da Digital Equipment Corporation (DEC), o roteador deve descartar muito poucos pacotes ou as sessões LAT podem terminar inesperadamente. Uma profundidade de fila de alta prioridade de cerca de 100 (especificada com a palavra-chave queue-limit) é um valor de trabalho típico quando o roteador está descartando pacotes de saída e as linhas seriais estão sujeitas a cerca de 50% de utilização da largura de banda. Se o roteador estiver descartando pacotes e com 100% de utilização, você precisará de outra linha.

Outra ferramenta para aliviar o congestionamento durante o bridging DEC LAT é a compactação LAT. Você pode implementar a compactação LAT com o comando interface configuration bridge-group group lat-compression.

Testes de linha serial especiais

Além dos recursos básicos de diagnóstico disponíveis nos roteadores, uma variedade de ferramentas e técnicas suplementares podem ser usadas para determinar as condições dos cabos, equipamentos de comutação, modems, hosts e hardware de interconexão remota. Para obter mais informações, consulte a documentação da CSU, DSU, analisador serial ou outro equipamento.

Testes de loopback de CSU e DSU

Se a saída do comando EXEC show interfaces serial indicar que a linha serial está ativa, mas que o protocolo de linha está inativo, use os testes de loopback CSU/DSU para determinar a origem do problema. Execute primeiro o teste de loop local e depois o teste remoto. A Figura 15-9 ilustra a topologia básica dos testes de loopback local e remoto de CSU/DSU.

Figura 15-9: Testes de loopback remoto e local CSU/DSU

Observação: esses testes são de natureza genérica e presumem a conexão do sistema de internetworking a uma CSU ou DSU. No entanto, os testes são essencialmente os mesmos para a conexão a um multiplexador com funcionalidade CSU/DSU integrada. Como não há conceito de loopback em ambientes X.25 ou de rede comutada por pacotes (PSN - Packet-Switched Network) Frame Relay, os testes de loopback não se aplicam às redes X.25 e Frame Relay.

Testes de loopback local CSU e DSU para links HDLC ou PPP

A seguir está listado um procedimento geral para executar testes de loopback em conjunto com recursos de diagnóstico de sistema integrados:

1. Coloque a CSU/DSU no modo de loop local (consulte a documentação do fornecedor). No modo de loop local, o uso do relógio de linha (do serviço T1) é terminado e a DSU é forçada a usar o relógio local.

2. Use o comando EXEC show interfaces serial para determinar se o status da linha muda de "line protocol is down" para "line protocol is up (looped)" ou se permanece inativo.

3. Se o protocolo de linha for ativado quando a CSU ou DSU estiver no modo de loopback local, isso sugere que o problema está ocorrendo na extremidade remota da conexão serial. Se a linha de status não alterar o estado, há um possível problema no roteador, no cabo de conexão ou na CSU/DSU.

4. Se o problema parecer ser local, use o comando EXEC privilegiado debug serial interface.

5. Retire a CSU/DSU do modo de loop local. Quando o protocolo de linha está inativo, a saída do comando debug serial interface indicará que os contadores de keepalive não estão aumentando.

6. Coloque a CSU/DSU no modo de loop local novamente. Isso deve fazer com que os pacotes keepalive comecem a aumentar. Especificamente, os valores para mineseen e suas keepalives vistas serão incrementados a cada 10 segundos. Essas informações aparecerão na saída da interface serial de depuração.

   Se os keepalives não forem incrementados, pode haver um problema de temporização na placa de interface ou na rede. Para obter informações sobre como corrigir problemas de temporização, consulte a seção "Solução de problemas de temporização", no início deste capítulo.

   Se os keepalives não forem incrementados, pode haver um problema de temporização na placa de interface ou na rede. Para obter informações sobre como corrigir problemas de temporização, consulte a seção "Solução de problemas de temporização", no início deste capítulo.

7. Verifique o roteador local, o hardware CSU/DSU e todos os cabos conectados. Certifique-se de que os cabos estejam dentro dos comprimentos recomendados - não mais de 50 pés (15,24 metros) ou 25 pés (7,62 metros) para um link T1. Verifique se os cabos estão conectados às portas corretas. Troque equipamentos defeituosos, conforme necessário.

A Figura 15-10 mostra a saída do comando debug serial interface para uma conexão serial HDLC, com keepalives perdidos, fazendo com que a linha caia e a interface seja redefinida.

Figura 15-10: Saída do comando debug serial interface

Testes de loopback remoto de CSU e DSU para enlaces HDLC ou PPP

Se você determinar que o hardware local está funcionando corretamente, mas ainda encontrar problemas ao tentar estabelecer conexões pelo link serial, tente usar o teste de loopback remoto para isolar a causa do problema.

Observação: este teste de loopback remoto pressupõe que o encapsulamento HDLC está sendo usado e que o teste de loop local anterior foi executado imediatamente antes deste teste.

As seguintes etapas são necessárias para executar o teste de loopback:As seguintes etapas são necessárias para executar o teste de loopback:

1. Coloque a CSU ou DSU remota no modo loopback remoto (consulte a documentação do fornecedor).

2. Usando o comando EXEC show interfaces serial, determine se o protocolo de linha permanece ativo com a linha de status que indica "Serial x is up, line protocol is up (looped)" (Serial x está ativado, protocolo de linha ativado (looped)) ou se vai com a linha de status que indica "line protocol is down" (o protocolo de linha está desativado).

3. Se o protocolo de linha permanecer ativo (em loop), o problema provavelmente está na extremidade remota da conexão serial (entre a CSU/DSU remota e o roteador remoto). Realize testes locais e remotos na extremidade remota para isolar a fonte do problema.

4. Se o status da linha mudar para "line protocol is down" quando o modo de loopback remoto estiver ativado, verifique se a densidade de uns está sendo mantida corretamente. A CSU/DSU deve ser configurada para usar os mesmos esquemas de enquadramento e codificação usados pela linha alugada ou outro serviço de operadora (por exemplo, ESF e B8ZS).

5. Se os problemas persistirem, entre em contato com o gerente de rede da WAN ou com a organização de serviços da WAN.

Informações detalhadas sobre o comando show interfaces serial

As subseções a seguir abordam os parâmetros do comando show interfaces serial, a descrição da sintaxe, a saída de exemplo e as descrições dos campos.

show interfaces serial Parameters

Para exibir informações sobre uma interface serial, use o comando EXEC privilegiado show interfaces serial:

show interfaces serial [number] [accounting]
show interfaces serial [number [:channel-group] [accounting] (Cisco 4000 series)
show interfaces serial [slot | port [:channel-group]] [accounting] (Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [serial] 
(ports on VIP cards in the Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [:t1-channel] [accounting | crb]
(CT3IP in Cisco 7500 series)

Descrição da sintaxe

• number-Opcional. Número de porta.

• accounting-Opcional. Exibe o número de pacotes de cada tipo de protocolo que foram enviados através da interface.

• :channel-group -Opcional. Na série Cisco 4000 com um NPM ou uma série Cisco 7500 com um MIP, especifica o número do grupo de canais T1 no intervalo de 0 a 23, definido com o comando de configuração channel-group controller.

• slot - Refere-se ao manual de hardware apropriado para informações sobre slot.

• port - Refere-se ao manual de hardware apropriado para informações de porta.

• adaptador de porta - Refere-se ao manual de hardware apropriado para obter informações sobre a compatibilidade do adaptador de porta.

• :t1-channel -Opcional. Para o CT3IP, o canal T1 é um número entre 1 e 28.

• Os canais T1 no CT3IP são numerados de 1 a 28 em vez do esquema baseado em zero mais tradicional (0 a 27) usado com outros produtos da Cisco. Isso garante a consistência com esquemas de numeração Telco para canais T1 em equipamentos T3 canalizados.

• crb-Opcional. Mostra informações de roteamento e bridging da interface.

Modo de comando

EXEC Privilegiado

Diretrizes de uso

Esse comando apareceu pela primeira vez no Cisco IOS versão 10.0 para a série Cisco 4000. Ele apareceu pela primeira vez no Cisco IOS versão 11.0 para a série Cisco 7000 e foi modificado no Cisco IOS versão 11.3 para incluir o CT3IP.

Exemplos de exibições

Veja a seguir um exemplo de saída do comando show interfaces para uma interface serial síncrona:

Router# show interfaces serial
Serial 0 is up, line protocol is up
   Hardware is MCI Serial
   Internet address is 150.136.190.203, subnet mask is 255.255.255.0
   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation HDLC, loopback not set, keepalive set (10 sec)
   Last input 0:00:07, output 0:00:00, output hang never
   Output queue 0/40, 0 drops; input queue 0/75, 0 drops
   Five minute input rate 0 bits/sec, 0 packets/sec
   Five minute output rate 0 bits/sec, 0 packets/sec
       16263 packets input, 1347238 bytes, 0 no buffer
       Received 13983 broadcasts, 0 runts, 0 giants
       2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
1 carrier transitions 
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts

Descrição do campo

Tabela 15-9: show interfaces serial Field Descriptions - esta tabela descreve campos significativos mostrados na saída.

Campo	Descrição
Serial...é {up | inativo}...está administrativamente inativo	Indica se o hardware da interface está atualmente ativo (a detecção da portadora está presente) ou se foi desativado por um administrador.
protocolo de linha é {up | inativo}	Indica se os processos de software que manipulam o protocolo de linha consideram a linha utilizável (isto é, manutenções de atividade bem-sucedidas) ou se foi desativada por um administrador.
protocolo de linha é {up | inativo}	Indica se os processos de software que manipulam o protocolo de linha consideram a linha utilizável (isto é, manutenções de atividade bem-sucedidas) ou se foi desativada por um administrador.
O hardware é	Especifica o tipo de hardware.
O endereço de Internet é	Especifica o endereço de Internet e a máscara de sub-rede.
MTU	Unidade máxima de transmissão da interface.
BW	Indica o valor do parâmetro de largura de banda configurado para a interface (em kilobits por segundo). O parâmetro de largura de banda é usado para calcular somente as métricas do IGRP. Se a interface estiver conectada a uma linha serial com uma velocidade de linha que não corresponda ao padrão (1536 ou 1544 para T1 e 56 para uma linha serial síncrona padrão), use o comando bandwidth para especificar a velocidade de linha correta para essa linha serial.
DLY	Atraso da interface em microssegundos.
raramente	Confiabilidade da interface como uma fração de 255 (255/255 é 100% de confiabilidade), calculada como uma média exponencial em cinco minutos.
carga	Confiabilidade da interface como uma fração de 255 (255/255 é 100% de confiabilidade), calculada como uma média exponencial em cinco minutos.
Encapsulamento	Método de encapsulamento atribuído à interface.
loopback	Indica se o loopback está definido.
manutenção de atividade	Indica se keepalives estão definidos.
Última entrada	Número de horas, minutos e segundos desde que o último pacote foi recebido com êxito por uma interface. Útil para saber quando uma interface inoperante falhou.
Última saída	Número de horas, minutos e segundos desde que o último pacote foi transmitido com êxito por uma interface.Número de horas, minutos e segundos desde que o último pacote foi transmitido com êxito por uma interface.
saída travada	Número de horas, minutos e segundos (ou nunca) desde que a interface foi redefinida pela última vez devido a uma transmissão que levou muito tempo. Quando o número de horas em qualquer um dos últimos campos excede 24, o número de dias e horas é impresso. Se esse campo transbordar, os asteriscos serão impressos.
Fila de saída, descarta fila de entrada, descarta	Número de pacotes em filas de saída e entrada. Cada número é seguido por uma barra, o tamanho máximo da fila e o número de pacotes porque a fila está cheia.
Taxa de entrada de 5 minutos taxa de saída de 5 minutos	Número médio de bits e pacotes transmitidos por segundo nos últimos cinco minutos. As taxas de entrada e saída de cinco minutos devem ser utilizadas apenas como uma aproximação do tráfego por segundo durante um período de cinco minutos. Essas taxas são médias ponderadas exponencialmente com uma constante de tempo de cinco minutos. Um período de quatro constantes de tempo deve passar antes que a média esteja dentro de 2% da taxa instantânea de um fluxo uniforme de tráfego nesse período.
packets input	Número total de pacotes sem erros recebidos pelo sistema.
bytes	Número total de bytes, incluindo dados e encapsulamento MAC, nos pacotes sem erros recebidos pelo sistema.
sem buffer	Número de pacotes recebidos descartados porque não havia espaço de buffer no sistema principal. Compare com a contagem ignorada. Tempestades de broadcast em redes Ethernet e surtos de ruído em linhas seriais são geralmente responsáveis por nenhum evento de buffer de entrada.
Recebido... transmissões	Número total de pacotes de broadcast ou multicast recebidos pela interface.
runts	Número de pacotes descartados porque são menores que o tamanho mínimo do pacote do meio.
giants	Número de pacotes descartados porque excedem o tamanho máximo do pacote do meio.
Erros de Entrada	Número total de contagens sem buffer, runts, giants, CRCs, frame, overrun, ignored e abort. Outros erros relacionados à entrada também podem incrementar a contagem, portanto, essa soma pode não balancear com as outras contagens.
CRC	A verificação de redundância cíclica gerada pela estação de origem ou pelo dispositivo remoto não corresponde à soma de verificação calculada a partir dos dados recebidos. Em um link serial, os CRCs geralmente indicam ruído, acertos de ganhos ou outros problemas de transmissão no enlace de dados.
quadro	O número de pacotes recebidos incorretamente com um erro de CRC e um número não inteiro de octetos. Em uma linha serial, isso geralmente é resultado de ruído ou outros problemas de transmissão.
sobrecarga	Número de vezes que o hardware do receptor serial não conseguiu entregar os dados recebidos a um buffer de hardware porque a taxa de entrada excedeu a capacidade do receptor de manipular os dados.
ignorado	O número de pacotes recebidos ignorados pela interface porque o hardware da interface foi executado em poucos buffers internos. Sobrecargas e surtos de ruído de broadcast podem provocar aumento na contagem ignorada.
abortar	Sequência inválida de um bit em uma interface serial. Isso geralmente indica um problema de temporização entre a interface serial e o equipamento de enlace de dados.
transições de portadora	Número de vezes que o sinal de detecção da portadora de uma interface serial mudou de estado. Por exemplo, se a detecção da portadora de dados (DCD) for desativada e ativada, o contador de transição da portadora será incrementado duas vezes. Indica problemas de modem ou de linha se a linha de detecção da portadora estiver mudando frequentemente de estado.
packets output (saída de pacotes)	Número total de mensagens transmitidas pelo sistema.
saída de bytes	Número total de bytes, incluindo dados e encapsulamento MAC, transmitidos pelo sistema.
déficit	Número de vezes que o transmissor está sendo executado mais rápido do que o roteador pode lidar. Isso pode nunca ser relatado em algumas interfaces.
erros de saída	Soma de todos os erros que impediram a transmissão final de datagramas para fora da interface que estava sendo examinada. Observe que isso pode não balancear com a soma dos erros de saída enumerados porque alguns datagramas podem ter mais de um erro, e outros podem ter erros que não se enquadram em nenhuma das categorias especificamente tabuladas.
colisões	Número de mensagens retransmitidas devido a uma colisão Ethernet. Isso geralmente é o resultado de uma LAN estendida (ou seja, cabo Ethernet ou transceptor muito longo, mais de dois repetidores entre estações ou muitos transceptores multiporta em cascata). Algumas colisões são normais. No entanto, se sua taxa de colisão subir para cerca de 4% ou 5%, você deve considerar verificar se não há equipamentos defeituosos no segmento e/ou mover algumas estações existentes para um novo segmento. Um pacote que colide é contado apenas uma vez em pacotes de saída.
reinicializações de interface	Número de vezes que uma interface foi completamente redefinida. Isso pode acontecer se os pacotes enfileirados para transmissão não forem enviados dentro de alguns segundos. Em uma linha serial, isso pode ser causado por um modem que não está fornecendo o sinal do relógio de transmissão ou por um problema de cabo. Se o sistema perceber que a linha de detecção da portadora de uma interface serial está ativa, mas o protocolo de linha está inativo, ele reinicia periodicamente a interface em um esforço para reiniciá-la. Também pode ocorrer a reinicialização da interface quando uma interface tiver o circuito fechado ou for fechada.
reinicializações	Número de vezes que o controlador foi reiniciado devido a erros.
indicações de alarme, alarmes remotos, rx LOF, rx LOS	Número de alarmes CSU/DSU e número de ocorrências de perda de quadro de recepção e perda de sinal de recepção.
BER inativo, NELR inativo, FELR inativo	Status dos contadores G.703-E1 para alarme de taxa de erro de bit (BER), NELR (near-end loop remote) e FELR (far-end loop remote). Observe que não é possível definir o NELR ou FELR.

Troubleshooting de T1

Esta seção descreve as técnicas e os procedimentos para a solução de problemas de circuitos T1 para clientes de discagem.

Solução de problemas usando o comando show controller t1

Esse comando exibe o status do controlador específico para o hardware do controlador. As informações exibidas são geralmente úteis para tarefas de diagnóstico executadas apenas pelo pessoal de suporte técnico.

O NMP (Network Management Processor - Processador de Gerenciamento de Rede) ou MIP (MultiChannel Interface Processor - Processador de Interface Multicanal) pode consultar os adaptadores de porta para determinar seu status atual. Emita um comando show controller t1 para exibir estatísticas sobre o link T1.

Se você especificar um slot e um número de porta, as estatísticas para cada período de 15 minutos serão exibidas. O comando EXEC show controller t1 fornece informações para solucionar problemas lógicos da camada física e da camada de enlace. Esta seção descreve como solucionar problemas logicamente usando o comando show controller t1.

A maioria dos erros de T1 é causada por linhas configuradas incorretamente. Assegure-se de que a codificação de linha, o enquadramento e a fonte de tempo estejam configurados de acordo com o que o provedor de serviços recomenda.

show controller t1 Condições

O controlador T1 pode estar em um dos três estados a seguir.

• Administrativamente fora do ar

• Down

• Para cima

O controlador T1 está inoperante administrativamente?

O controlador fica administrativamente desativado quando é encerrado manualmente. Você deve reiniciar a controladora para corrigir esse erro.

1. Insira o modo enable.

   maui-nas-03>en
   Password: 
   maui-nas-03#

2. Insira o modo de configuração global.

   maui-nas-03#configure terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   maui-nas-03(config)#

3. Insira o modo de configuração de controlador.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#

4. Reinicie o controlador.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

A fila está alta?

Se o controlador T1 e a linha não estiverem ativados, verifique se uma das seguintes mensagens aparece na saída EXEC show controller t1:

• Receptor tem perda de quadro

• Receptor tem perda de sinal

Se o receptor T1 tiver perda de quadro:

Siga estas etapas se o receptor T1 tiver perda de quadro:

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Você pode verificar o formato de enquadramento do controlador na configuração em execução ou na saída do comando show controller t1.

   Para alterar o formato do enquadramento, use o enquadramento {SF | ESF} no modo de configuração do controlador, conforme mostrado abaixo:

   maui-nas-03#configure terminal
   

   Enter configuration commands, one per line. Finalize com CNTL/Z.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#framing esf
   

2. Tente o outro formato de enquadramento para verificar se o alarme é cancelado.

3. Altere a configuração do buildout de linha usando o cablelength {long comando | short}.

A construção de linha (LBO) compensa a perda em decibéis com base na distância do dispositivo ao primeiro repetidor no circuito. Uma distância maior entre o dispositivo e o repetidor exige que a intensidade do sinal no circuito seja aumentada para compensar a perda naquela distância.

Consulte o seu provedor de serviços e a Referência de Comandos do Cisco IOS0 para obter detalhes sobre as configurações do buildout.

Se isso não corrigir o problema, vá para a seção "Se o receptor T1 tiver perda de sinal" abaixo.

Se o receptor T1 tiver perda de sinal:

Siga estas etapas se o receptor T1 tiver perda de sinal:

1. Verifique se o cabo entre a porta da interface e o equipamento do provedor de serviços T1 (ou equipamento terminal T1) está conectado corretamente. Verifique se o cabo está conectado às portas corretas. Corrija as conexões de cabo, se necessário.

2. Verifique a integridade do cabo. Procure rupturas ou outras anormalidades físicas no cabo. Verifique se as pinagens estão definidas corretamente. Se necessário, substitua o cabo.

3. Verifique os conectores de cabo. Uma inversão dos pares de transmissão e recebimento ou um par de recebimento aberto pode causar erros. Defina o par de recepção para as linhas 1 e 2. Defina o par de transmissão para as linhas 4 e 5.

   Os pinos em um conector RJ-45 são numerados de 1 a 8. O pino 1 é o pino mais à esquerda ao observar o conector com os pinos de metal voltados para você. Consulte a figura abaixo.

   Figura 15-10: Cabo RJ-45

   

4. Tente usar um cabo rollover.

Execute o comando EXEC show controller t1 após cada etapa para verificar se a controladora exibe erros.

Verifique se a linha está no modo loopback na saída show controller t1. Uma linha deve estar no modo loopback somente para fins de teste.

Para desligar o loopback, use o comando no loopback no modo de configuração do controlador como mostrado abaixo:

maui-nas-03(config-controlle)#no loopback

Se o controlador exibir qualquer alarme:

Verifique a saída do comando show controller para ver se há alarmes exibidos pelo controlador.

Discutiremos agora vários alarmes e o procedimento necessário para os corrigir.

Sinal de Indicação de Alarme (AIS - Alarm Indication Signal) de Recepção (RX) (Azul):

Um Alarm Indication Signal (AIS) recebido significa que há um alarme ocorrendo na linha upstream do equipamento conectado à porta.

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Caso contrário, altere o formato do enquadramento no controlador para corresponder ao da linha.

2. Entre em contato com seu provedor de serviços para verificar se há configuração incorreta na Telco.

Indicação de Alarme Remoto (RAI - Remote Alarm Indication) de recepção (Rx - Receive Remote Alarm Indication) (Amarelo):

Um RAI recebido significa que o equipamento da extremidade oposta tem um problema com o sinal que está recebendo de seu equipamento upstream.

1. Insira um cabo de circuito fechado externo na porta. Para criar um plugue de loopback, consulte a seção "Criando um Plug de Loopback", mais adiante neste capítulo.

2. Verifique se há alarmes. Se você não visualiza nenhum alarme, o hardware local provavelmente está em boas condições. Nesse caso:

   1. Verifique o cabeamento. Consulte a seção "Se o receptor T1 tiver perda de sinal" para obter mais informações.

   2. Verifique as configurações do lado remoto e verifique se elas são compatíveis com suas configurações de porta.

   3. Se o problema persistir, entre em contato com seu provedor de serviços.

3. Remova o plugue de circuito fechado e reconecte a linha T1.

4. Verifique o cabeamento. Consulte a seção "Se o receptor T1 tiver perda de sinal" para obter mais informações.

5. Desligue e religue o roteador.

6. Conecte a linha T1 a uma porta diferente. Configure a porta com as mesmas configurações da linha. Se o problema não persistir, a falha está em uma porta:

   1. Reconecte a linha T1 para a porta original.

   2. Vá para a seção "Troubleshooting de Eventos de Erro T1".

      Se o problema persistir, então:

7. Execute um teste de loop de hardware, conforme descrito na seção "Performing Hardware Loopback Plug Test" (Executando teste de conexão de loopback de hardware).

8. Substitua a placa de controle T1.

9. Vá para a seção "Troubleshooting de Eventos de Erro T1".

Alarme remoto de envio do transmissor (vermelho):

Um alarme vermelho é declarado quando a CSU não pode sincronizar com o padrão de enquadramento na linha T1.

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Caso contrário, altere o formato do enquadramento no controlador para corresponder ao da linha.

2. Verifique as configurações do lado remoto e verifique se elas são compatíveis com suas configurações de porta.

3. Entre em contato com seu provedor de serviços.

Indicação de Alarme Remoto (RAI - Remote Alarm Indication) de Transmissão (Tx - Transmit Remote Alarm Indication) (Amarelo):

Um RAI transmitido na interface indica que a interface tem um problema com o sinal que está recebendo do equipamento da extremidade oposta.

1. Verifique as configurações do lado remoto e verifique se elas são compatíveis com suas configurações de porta.

2. Um RAI de transmissão deve ser acompanhado por algum outro alarme que indique a natureza do problema que a placa/porta T1 está tendo com o sinal do equipamento da extremidade oposta.

Solucione esse problema para resolver o RAI de transmissão.

AIS de transmissão (Tx) (Azul):

Siga as etapas abaixo para corrigir o AIS de transmissão (Tx) (azul).

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Caso contrário, corrija a incompatibilidade.

2. Desligue e religue o roteador.

3. Conecte a linha T1 a uma porta diferente. Configure a porta com as mesmas configurações da linha.

4. Execute um teste de loop de hardware, conforme descrito na seção "Performing Hardware Loopback Plug Test" (Executando teste de conexão de loopback de hardware).

5. Substitua a placa de controle T1.

6. Vá para a seção "Troubleshooting de Eventos de Erro T1".

Troubleshooting de Eventos de Erro T1

O comando EXEC show controller t1 fornece mensagens de erro que podem ser usadas para solucionar problemas. Agora discutiremos várias mensagens de erro e como corrigir os erros.

Para ver se os contadores de erro estão aumentando, execute o comando show controller t1 repetidamente. Observe os valores dos contadores para o intervalo atual.

Consulte seu provedor de serviços para obter as configurações de enquadramento e codificação de linha. Uma boa regra é usar a codificação B8ZS com enquadramento ESF e codificação AMI com enquadramento SF.

O contador Slip Secs está aumentando:

A presença de deslizamentos em uma linha T1 indica um problema de temporização. O provedor de T1 (Telco) fornecerá a temporização para a qual o CPE (Customer Premises Equipment, Equipamento das Instalações do Cliente) deve ser sincronizado.

1. Verifique se a origem do relógio é derivada da rede. Isso pode ser verificado se procurar Clock Source é Line Primary.

   Observação: se houver vários T1s em um servidor de acesso, somente um pode ser o principal, enquanto os outros T1s derivam o relógio do primário. Nesse caso, verifique se a linha T1 designada como origem de relógio primária está configurada corretamente.

2. Defina corretamente a fonte de tempo T1 no modo de configuração do controlador.

   maui-nas-03(config-controlle)#clock source line primary
   

O contador de perda de segundos de enquadramento está aumentando:

Siga estas etapas quando o contador de perda de segundos de enquadramento estiver aumentando.

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Você pode verificar isso procurando o Framing é {ESF|SF} na saída show controller t1.

2. Para alterar o formato do enquadramento, use o enquadramento {SF | ESF} no modo de configuração do controlador, conforme mostrado abaixo:

   maui-nas-03(config-controlle)#framing esf
   

3. Altere a construção da linha usando o cablelength {long | short}.

Consulte o seu provedor de serviços e a Referência de Comandos do Cisco IOS0 para obter detalhes sobre as configurações do buildout.

As violações de código de linha estão aumentando:

Siga estas etapas quando as violações de código de linha estiverem aumentando.

1. Verifique se a codificação de linha configurada na porta corresponde ao formato de enquadramento da linha. Você pode verificar isso procurando que o Código de linha é {B8ZS|AMI} na saída show controller t1.

2. Para alterar a codificação de linha, use o código de linha {ami | b8zs} no modo de configuração do controlador, conforme mostrado abaixo:

   maui-nas-03(config-controlle)#linecode b8zs
   

3. Altere a construção da linha usando o cablelength {long | short}.

Consulte o seu provedor de serviços e a Referência de Comandos do Cisco IOS® para obter detalhes sobre as configurações de construção.

Verificando se o tipo de switch ISDN e o grupo PRI estão configurados corretamente

Use o comando show running-config para ver se o tipo de switch ISDN e os timeslots do grupo PRI estão configurados corretamente. Entre em contato com seu provedor de serviços para obter os valores corretos.

Para alterar o tipo de switch ISDN e o grupo PRI:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-5ess
maui-nas-03(config)#controller t1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-24

Verificando o canal de sinalização

Se os contadores de erro não aumentarem, mas o problema persistir, verifique se o canal de sinalização está ativo e configurado corretamente.

1. Execute o comando show interface serial x:23, no qual x deve ser substituído pelo número da interface.

2. Verifique se a interface está ativada. Se a interface não estiver ativa, utilize o comando no shutdown para ativá-la.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

3. Certifique-se de que o encapsulamento seja PPP. Se a interface não estiver usando PPP, use o comando encapsulation ppp no modo de configuração de interface para corrigi-lo.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Verifique se o loopback está definido. O circuito fechado deve ser configurado somente para propósitos de teste. Utilize o comando no loopback para remover circuitos fechados.

   maui-nas-03(config-if)#no loopback
   

5. Desligue e religue o roteador.

6. Se o problema persistir, entre em contato com o provedor de serviços ou com o Cisco TAC

Solução de problemas de uma PRI

Sempre que solucionar problemas de uma PRI, você precisa verificar se a T1 está funcionando corretamente em ambas as extremidades. Se os problemas da Camada 1 tiverem sido resolvidos, conforme descrito acima, considere os problemas das Camadas 2 e 3.

Solução de problemas usando o comando show isdn status

O comando show isdn status é usado para exibir um snapshot de todas as interfaces ISDN. Exibe o status das Camadas 1, 2 e 3.

1. Verifique se a Camada 1 está ativa.

   O status da Camada 1 deve sempre dizer ATIVE (ATIVO), a menos que T1 esteja inoperante. Se show isdn status indicar que a Camada 1 está DESATIVADA, então há um problema com a conectividade física na linha T1. Consulte a seção "O controlador T1 está inoperante?"

   Verifique também se o T1 não está administrativamente inativo. Use o comando no shutdown para ativar o controlador T1.

2. Verifique se o estado da camada 2 é MULTIPLE_FRAME_ESTABLISHED

O estado desejado da Camada 2 é Multiple_Frame_Estabeleced, que indica que estamos trocando quadros da Camada 2 e concluímos a inicialização da Camada 2.

Se a Camada 2 não for Multiple_Frame_Set , use o comando EXEC show controller t1 para diagnosticar o problema. Consulte a seção Troubleshooting usando o Comando show controller t1 neste capítulo.

Como show isdn status é um snapshot do status atual, é possível que a camada 2 esteja saltando para cima e para baixo apesar de indicar Multipla_Frame_Estabelecida. Use debug isdn q921 para verificar se a camada 2 é estável.

O comando debug isdn q921 exibe os procedimentos de acesso da camada de enlace de dados (camada 2) que estão ocorrendo no roteador no canal D.

Certifique-se de que você esteja configurado para exibir mensagens de depuração usando o comando logging console ou terminal monitor conforme necessário.

Observação: em um ambiente de produção, verifique se o registro do console está desabilitado. Digite o comando show logging. Se o registro estiver ativado, o servidor de acesso poderá congelar intermitentemente assim que a porta do console for sobrecarregada com mensagens de registro. Digite o comando no logging console.

Observação: se debug isdn q921 estiver ativado e você não receber nenhuma saída de depuração, faça uma chamada ou redefina o controlador para obter saídas de depuração.

1. Verifique se a Camada 2 está estável.

   Você deve observar as saídas de depuração para mensagens indicando que o serviço não está aumentando ou diminuindo. Se você vir os seguintes tipos de saídas de depuração, a linha não é estável.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed 
   to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   
   

   Se a Camada 2 não parecer estável, consulte "Troubleshooting T1 Error Events" no início deste capítulo.

2. Verifique se você está vendo apenas mensagens SAPI nos lados de transmissão (TX) e recepção (RX).

   Mar 20 10:06:52.505: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:23: TX ->  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Verifique se você não está vendo mensagens SABME, o que indica que a Camada 2 está tentando reinicializar. Isso geralmente é visto quando estamos transmitindo solicitações de votação (RRp) e não obtendo uma resposta do switch (RRf) ou vice-versa. Abaixo estão exemplos de mensagens SABME.

   Mar 20 10:06:21.702: ISDN Se0:23: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:23: TX ->  SABMEp sapi = 0  tei = 0

   Se você estiver vendo mensagens SABME, use o comando show running-config para ver se o tipo de switch ISDN e os timeslots do grupo PRI estão configurados corretamente. Entre em contato com seu provedor de serviços para obter os valores corretos.

   Para alterar o tipo de switch ISDN e o grupo PRI:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-5ess
   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-24
   

4. Verifique se o canal D está ativo usando o comando show interfaces serial x:23.

   Se o canal D não estiver ativo, use o comando no shutdown para ativá-lo:

   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

5. Verifique se o encapsulamento é PPP. Caso contrário, utilize o comando encapsulation ppp para configurar o encapsulamento.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Verifique se a interface está no modo loopback. Para uma operação normal, a interface não deve estar no modo loopback.

   maui-nas-03(config-if)#no loopback
   

7. Desligue e religue o roteador.

8. Se o problema persistir, entre em contato com seu provedor de serviços ou com o TAC da Cisco.

Executando o teste de conexão de loopback de hardware

O teste do plugue de loopback de hardware pode ser usado para testar se o roteador tem alguma falha. Se um roteador passar em um teste de plugue de circuito fechado, então o problema é em outro lugar da linha.

Criar um Plug de Loopback:

Siga estas etapas para criar um plugue de loopback.

1. Use cortadores de fios para cortar um cabo RJ-45 ou RJ-48 em funcionamento de modo que haja cinco polegadas de cabo e o conector esteja conectado a ele.

2. Retire os fios.

3. Gire os fios dos pinos 1 e 4.

4. Gire os fios dos pinos 2 e 5.

Os pinos em um conector RJ-45/48 são numerados de 1 a 8. O pino 1 é o pino mais à esquerda ao observar o conector com os pinos de metal voltados para você.

Executando o teste de conexão de loopback

Siga estas etapas para executar o teste do plugue de loopback.

1. Insira o plugue na porta T1 em questão.

2. Salve a configuração do roteador usando o comando write memory.

   maui-nas-03#write memory
   Building configuration...
   [OK]

3. Defina o encapsulamento para HDLC

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0
   maui-nas-03(config-if)#enc
   maui-nas-03(config-if)#encapsulation HDLC 
   maui-nas-03(config-if)#^Z
   

4. Use o comando show running-config para ver se a interface tem um endereço IP.

   Se a interface não tiver um endereço IP, obtenha um endereço exclusivo e atribua-o à interface com uma máscara de sub-rede 255.255.255.0.

   maui-nas-03(config)#ip address 172.22.53.1 255.255.255.0
   

5. Zere os contadores de interface com o comando clear counters.

   maui-nas-03#clear counters
   Clear "show interfaces" counters on all interfaces [confirm]
   maui-nas-03#

6. Execute o teste de ping estendido conforme descrito na seção "Usando testes de ping estendido", no início deste capítulo.

Troubleshooting E1

Esta seção descreve as técnicas e os procedimentos para a solução de problemas de circuitos E1 para clientes de discagem.

Solução de problemas usando o comando show controller e1

Esse comando exibe o status do controlador específico para o hardware do controlador. As informações exibidas são geralmente úteis para tarefas de diagnóstico executadas apenas pelo pessoal de suporte técnico.

O NMP ou MIP pode consultar os adaptadores de porta para determinar seu status atual. Emita um comando show controller e1 para exibir estatísticas sobre o link E1. Se você especificar um slot e um número de porta, as estatísticas para cada período de 15 minutos serão exibidas.

O comando EXEC show controller e1 fornece informações para solucionar problemas logicamente da camada física e da camada de enlace. Esta seção descreve como solucionar problemas logicamente usando o comando show controller e1.

A maioria dos erros E1 é causada por linhas configuradas incorretamente. Assegure-se de que a codificação de linha, o enquadramento, a fonte do relógio e a terminação de linha (balanceada ou desbalanceada) sejam configurados de acordo com as recomendações do provedor de serviços.

Condições show controller e1

O controlador E1 pode estar em um dos três estados a seguir.

• Administrativamente fora do ar

• Down

• Para cima

O controlador E1 está inoperante administrativamente?

O controlador fica administrativamente desativado quando é encerrado manualmente. Você deve reiniciar a controladora para corrigir esse erro.

1. Insira o modo enable.

   maui-nas-03>enable
   Password: 
   maui-nas-03#

2. Insira o modo de configuração global.

   maui-nas-03#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#

3. Insira o modo de configuração de controlador.

   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#

4. Reinicie o controlador.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

A fila está alta?

Se a linha E1 não estiver ativa, verifique se a configuração da linha está correta e corresponde às configurações da extremidade remota.

1. Verifique o enquadramento da linha e da extremidade remota. Para linhas E1, o enquadramento é CRC4 ou noCRC4

2. Verifique a codificação de linha da linha e da extremidade remota. A codificação de linha é AMI ou HDB3.

3. Verifique se a terminação da linha está definida como balanceada ou desbalanceada (75 ohms ou 120 ohms).

Consulte o seu provedor de serviços para obter mais informações sobre as configurações corretas. Faça as alterações necessárias nos dispositivos finais locais ou remotos.

Se o controlador E1 e a linha não estiverem ativados, verifique se uma das seguintes mensagens aparece na saída EXEC show controller e1:

• Receptor tem perda de quadro

• Receptor tem perda de sinal

Se o receptor E1 tiver perda de quadro:

Siga estas etapas se o receptor E1 tiver perda de quadro.

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Você pode verificar o formato de enquadramento do controlador na configuração em execução ou na saída do comando show controller e1.

   Para alterar o formato de enquadramento, use o enquadramento {CRC4 | nenhum comando CRC4} no modo de configuração do controlador, como mostrado abaixo:

   maui-nas-03#configure terminal 
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#controller E1 0
   maui-nas-03(config-controlle)#framing CRC4
   

2. Tente o outro formato de enquadramento para verificar se o alarme é cancelado.

   Se isso não corrigir o problema, vá para a seção "Se o receptor E1 tiver perda de sinal" abaixo.

3. Verifique o formato de enquadramento na extremidade remota.

4. Verifique a codificação de linha na extremidade remota.

Se o receptor E1 tiver perda de sinal:

Siga estes passos se o receptor E1 tiver perda de sinal

1. Verifique se o cabo entre a porta da interface e o equipamento do provedor de serviços E1 (ou equipamento terminal E1) está conectado corretamente. Verifique se o cabo está conectado às portas corretas. Corrija as conexões de cabo, se necessário.

2. Verifique a integridade do cabo. Procure rupturas ou outras anormalidades físicas no cabo. Verifique se as pinagens estão definidas corretamente. Se necessário, substitua o cabo.

3. Verifique os conectores de cabo. Uma inversão dos pares de transmissão e recebimento ou um par de recebimento aberto pode causar erros. Defina o par de recepção para as linhas 1 e 2. Defina o par de transmissão para as linhas 4 e 5.

   Os pinos em um conector RJ-48 são numerados de 1 a 8. O pino 1 é o pino mais à esquerda ao observar o conector com os pinos de metal voltados para você. Consulte a figura a seguir para obter mais informações.

   Figura 15-11: Cabo RJ-45

   

4. Tente usar um cabo rollover.

5. Verifique se há erros de bloco da extremidade oposta. Se sim, o problema existe com o lead de recebimento na extremidade local. Entre em contato com o TAC para obter mais assistência.

Execute o comando EXEC show controller e1 após cada etapa para verificar se a controladora exibe erros.

Se a linha estiver no modo de loopback:

Verifique se a linha está no modo loopback na saída show controller e1. Uma linha deve estar no modo loopback somente para fins de teste.

Para desligar o loopback, use o comando no loopback no modo de configuração do controlador como mostrado abaixo:

maui-nas-03(config-controlle)#no loopback

Se o controlador exibir qualquer alarme:

Verifique a saída do comando show controller para ver se há alarmes exibidos pelo controlador.

Discutiremos agora vários alarmes e o procedimento necessário para os corrigir.

O Receptor (Rx) Tem Alarme Remoto:

Um alarme remoto recebido significa que há um alarme ocorrendo na linha upstream do equipamento conectado à porta.

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Caso contrário, altere o formato do enquadramento no controlador para corresponder ao da linha.

2. Verifique a configuração de codificação de linha no equipamento de extremidade remota. Entre em contato com o provedor de serviços para obter as configurações corretas. Corrija os erros de configuração conforme necessário.

3. Insira um cabo de circuito fechado externo na porta. Para criar um plugue de loopback, consulte a seção "Performing Hardware Loopback Plug Test" (Executando teste de conexão de loopback de hardware), no início do capítulo.

4. Verifique se há alarmes. Se você não visualiza nenhum alarme, o hardware local provavelmente está em boas condições. Nesse caso:

   1. Verifique o cabeamento. Consulte a seção "Se o receptor E1 tiver perda de sinal" para obter mais informações.

   2. Verifique as configurações do lado remoto e verifique se elas são compatíveis com suas configurações de porta.

   3. Se o problema persistir, entre em contato com seu provedor de serviços.

5. Remova o plugue de loopback e reconecte sua linha E1.

6. Verifique o cabeamento. Consulte a seção "Se o receptor E1 tiver perda de sinal" para obter mais informações.

7. Desligue e religue o roteador.

8. Conecte a linha E1 a uma porta diferente. Configure a porta com as mesmas configurações da linha. Se o problema não persistir, a falha está em uma porta:

   1. Reconecte a linha E1 à porta original.

   2. Vá para a seção "Troubleshooting de Eventos de Erro E1".

      Se o problema persistir, então:

9. Execute um teste de loop de hardware conforme descrito na seção "Performing Hardware loopback Plug Test"

10. Substitua a placa controladora E1.

11. Vá para a seção "Troubleshooting de Eventos de Erro E1".

Alarme remoto de envio do transmissor (vermelho):

Um alarme vermelho é declarado quando a CSU não pode sincronizar com o padrão de enquadramento na linha E1.

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Caso contrário, altere o formato do enquadramento no controlador para corresponder ao da linha.

2. Verifique as configurações do lado remoto e verifique se elas são compatíveis com suas configurações de porta.

3. Insira um cabo de circuito fechado externo na porta. Para criar um plugue de loopback, consulte a seção "Performing Hardware Loopback Plug Test" (Executando teste de conexão de loopback de hardware), no início do capítulo.

4. Verifique se há alarmes. Se você não visualiza nenhum alarme, o hardware local provavelmente está em boas condições. Nesse caso:

   1. Verifique o cabeamento. Consulte a seção "Se o receptor E1 tiver perda de sinal" para obter mais informações.

   2. Se o problema persistir, entre em contato com seu provedor de serviços.

5. Conecte a linha E1 a uma porta diferente. Configure a porta com as mesmas configurações da linha. Se o problema não persistir, a falha será em uma porta.

   1. Reconecte a linha E1 à porta original.

   2. Vá para a seção "Troubleshooting de Eventos de Erro E1".

      Se o problema persistir, então:

6. Execute um teste de loop de hardware, conforme descrito na seção "Performing Hardware Loopback Plug Test" (Executando teste de conexão de loopback de hardware).

7. Substitua a placa controladora E1.

8. Vá para a seção "Troubleshooting de Eventos de Erro E1".

9. Entre em contato com seu provedor de serviços.

Troubleshooting de Eventos de Erro E1

O comando EXEC show controller e1 fornece mensagens de erro que podem ser usadas para solucionar problemas. Agora discutiremos várias mensagens de erro e como corrigir os erros.

Para ver se os contadores de erro estão aumentando, execute o comando show controller e1 repetidamente. Observe os valores dos contadores para o intervalo atual. Consulte seu provedor de serviços para obter as configurações de enquadramento e codificação de linha.

O contador Slip Secs está aumentando:

A presença de lapsos em linhas E1 indica um problema de temporização. O provedor E1 (Telco) fornecerá a temporização para a qual o Customer Premises Equipment (CPE) deve ser sincronizado.

1. Verifique se a origem do relógio é derivada da rede. Isso pode ser verificado se procurar Clock Source é Line Primary.

   Observação: se houver vários E1s em um servidor de acesso, somente um pode ser o principal, enquanto os outros E1s derivam o relógio do primário. Nesse caso, verifique se a linha E1 designada como origem de relógio primária está configurada corretamente.

2. Defina corretamente a origem do relógio E1 no modo de configuração do controlador.

   maui-nas-03(config-controlle)#clock source line primary
   

O contador de perda de segundos de enquadramento está aumentando:

Siga estas etapas quando o contador de segundos de perda de enquadramento estiver aumentando:

1. Verifique se o formato de enquadramento configurado na porta corresponde ao formato de enquadramento da linha. Você pode verificar isso procurando que Framing é {CRC4|no CRC4} na saída show controller e1.

2. Para alterar o formato de enquadramento, use o enquadramento {CRC4 | no CRC4} no modo de configuração do controlador, como mostrado abaixo:

   maui-nas-03(config-controlle)#framing crc4
   

As violações de código de linha estão aumentando:

Siga estas etapas quando as violações de código de linha estiverem aumentando.

1. Verifique se a codificação de linha configurada na porta corresponde ao formato de enquadramento da linha. Você pode verificar isso procurando que o Código de linha é {AMI/HDB3} na saída show controller e1.

2. Para alterar a codificação de linha, use o código de linha {ami | hdb3} no modo de configuração do controlador, conforme mostrado abaixo:

   maui-nas-03(config-controlle)#linecode ami
   

Verificando se o tipo de switch ISDN e o grupo PRI estão configurados corretamente

Use o comando show running-config para verificar se o tipo de switch ISDN e os timeslots do grupo PRI estão configurados corretamente. Entre em contato com seu provedor de serviços para obter os valores corretos.

Para alterar o tipo de switch ISDN e o grupo PRI:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-net5
maui-nas-03(config)#controller e1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-31

Verificando o canal de sinalização

Se os contadores de erro não aumentarem, mas o problema persistir, verifique se o canal de sinalização está ativo e configurado corretamente.

1. Execute o comando show interface serial x:15, no qual x deve ser substituído pelo número da interface.

2. Verifique se a interface está ativada. Se a interface não estiver ativa, utilize o comando no shutdown para ativá-la.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

3. Certifique-se de que o encapsulamento seja PPP. Se a interface não estiver usando PPP, use o comando encapsulation ppp no modo de configuração de interface para corrigi-lo.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Verifique se o loopback está definido. O circuito fechado deve ser configurado somente para propósitos de teste. Utilize o comando no loopback para remover circuitos fechados.

   maui-nas-03(config-if)#no loopback
   

5. Desligue e religue o roteador.

6. Se o problema persistir, entre em contato com seu provedor de serviços ou com o TAC da Cisco.

Solução de problemas de uma PRI

Ao solucionar problemas de uma PRI, você precisa determinar se a E1 está funcionando corretamente em ambas as extremidades. Se os problemas da Camada 1 tiverem sido resolvidos conforme descrito acima, considere os problemas das Camadas 2 e 3.

Solução de problemas usando o comando show isdn status

O comando show isdn status é usado para exibir um snapshot de todas as interfaces ISDN. Exibe o status das Camadas 1, 2 e 3.

1. Verifique se a Camada 1 está ativa.

   O status da Camada 1 deve sempre dizer ATIVE (ATIVO), a menos que E1 esteja inoperante.

   Se show isdn status indicar que a Camada 1 está DESATIVADA, então há um problema com a conectividade física na linha E1. Consulte a seção "O controlador E1 está inoperante administrativamente?"

   Verifique também se o E1 não está inoperante administrativamente. Use o comando no shutdown para ativar o controlador E1.

2. Verifique se o estado da camada 2 é MULTIPLE_FRAME_ESTABLISHED.

O estado desejado da Camada 2 é Multiple_Frame_Estabeleced, que indica que o protocolo de inicialização entre o switch ISDN e o dispositivo final foi estabelecido e que estamos trocando quadros da Camada 2.

Se a Camada 2 não for Multiple_Frame_Set, use o comando EXEC show controller e1 para diagnosticar o problema. Consulte a seção "Troubleshooting Using the show controller e1 Command" neste capítulo e a seção "Troubleshooting E1 Error Events".

Como show isdn status é um instantâneo do status atual, é possível que a Camada 2 esteja saltando para cima e para baixo apesar de indicar Multipla_Frame_Estabelecida. Use o comando debug isdn q921 para verificar se a Camada 2 está estável.

Usando debug q921

O comando debug isdn q921 exibe os procedimentos de acesso da camada de enlace de dados (Camada 2) que estão ocorrendo no roteador no canal D.

Verifique se você está configurado para exibir mensagens de depuração usando o console de registro ou o monitor terminal, conforme necessário.

Observação: em um ambiente de produção, verifique se o registro do console está desabilitado. Digite o comando show logging. Se o registro estiver ativado, o servidor de acesso poderá congelar intermitentemente assim que a porta do console for sobrecarregada com mensagens de registro. Digite o comando no logging console.

Observação: se debug isdn q921 estiver ativado e você não receber nenhuma saída de depuração, faça uma chamada ou redefina o controlador para obter saídas de depuração.

1. Verifique se a Camada 2 está estável. Você deve observar as saídas de depuração para mensagens indicando que o serviço não está aumentando ou diminuindo. Se você vir os seguintes tipos de saídas de depuração, a linha não é estável.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:15, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:15, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:15, TEI 0 
   changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:15, changed state to up
   
   

   Se a Camada 2 não parecer estável, consulte "Troubleshooting E1 Error Events" no início deste capítulo.

2. Verifique se você está vendo apenas mensagens SAPI nos lados de transmissão (TX) e recepção (RX).

   Mar 20 10:06:52.505: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:15: TX ->  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Verifique se você não está vendo mensagens SABME, o que indica que a Camada 2 está tentando reinicializar. Isso geralmente é visto quando estamos transmitindo solicitações de votação (RRp) e não obtendo uma resposta do switch (RRf) ou vice-versa. Abaixo estão exemplos de mensagens SABME. Devemos obter uma resposta do switch ISDN para nossas mensagens SABME (quadro UA recebido).

   Mar 20 10:06:21.702: ISDN Se0:15: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:15: TX ->  SABMEp sapi = 0  tei = 0

   Se você estiver vendo mensagens SABME, use o comando show running-config para verificar se o tipo de switch ISDN e os timeslots do grupo PRI estão configurados corretamente. Entre em contato com seu provedor de serviços para obter os valores corretos.

   Para alterar o tipo de switch ISDN e o grupo PRI:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-net5
   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-31
   

4. Verifique se o canal D está ativo usando o comando show interfaces serial x:15.

   Se o canal D não estiver ativo, use o comando no shutdown para ativá-lo:

   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

5. Verifique se o encapsulamento é PPP. Caso contrário, use o comando encapsulation ppp para definir o encapsulamento.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Verifique se a interface está no modo loopback. Para uma operação normal, a interface não deve estar no modo loopback.

   maui-nas-03(config-if)#no loopback
   

7. Desligue e religue o roteador.

8. Se o problema persistir, entre em contato com seu provedor de serviços ou com o TAC da Cisco.

Informações Relacionadas

• Suporte Técnico - Cisco Systems

Histórico de revisões