WAN : T1/E1 e T3/E3

Troubleshooting Problemas de Linha Serial

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

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:

  • Pesquisa de defeitos usando o comando show interfaces serial

  • Usando o comando show controllers

  • Utilizando comandos debug

  • Usando testes ping extendido

  • Pesquisando defeitos problemas de relógio

  • Ajustando bufferes

  • Testes de linha serial especiais

  • Informação detalhada no comando show interfaces serial

  • Pesquisando defeitos os problemas T1

  • Pesquisando defeitos os problemas E1

Pré-requisitos

Requisitos

Os leitores deste documento devem ser conhecedors das seguintes definições.

  • DTE = equipamento de terminal de dados

  • CD = revelação do sinal de comunicação

  • CSU = unidade de serviço de canal

  • DSU = unidade de serviço digital

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

  • DCE = equipamento determinação dos dados

  • CTS = Clear To Send

  • DSR = conjunto de dados pronto

  • SAP = protocolo service advertising

  • IPX = trocas de pacote Internetwork IPX

  • FDDI = Fiber Distributed Data Interface

  • ESF = formato de superframe estendido

  • B8ZS = substituição oito-zero binária

  • LBO = Line Build Out

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. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Convenções

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

Pesquisa de defeitos usando o comando show interfaces serial

A saída do comando show interfaces serial exec indica o específico da informação às interfaces serial. Figura 15-1 mostra a saída do comando show interfaces serial exec para uma interface serial do High-Level Data Link Control (HDLC).

Esta seção descreve como usar o comando show interfaces serial diagnosticar problemas da conectividade de linha serial em um ambiente do Wide Area Network (WAN). As seguintes seções descrevem alguns dos campos importantes da saída do comando.

Outros campos mostrados no indicador são descritos em detalhe na seção “informação detalhada no comando show interfaces serial,” mais tarde neste capítulo.

Linhas de série: mostre condições de linha de status da série das relações

Você pode identificar cinco estados de problema possível na linha de status da interface do indicador de série das relações da mostra (veja figura 15-1):

  • X de série está para baixo, protocolo de linha está inativo

  • X de série está acima, protocolo de linha está inativo

  • X de série está acima, o protocolo de linha está acima de (dado laços)

  • X de série está acima, o protocolo de linha está inativo (desabilitado)

  • X de série está administrativamente para baixo, protocolo de linha está inativo

Figura saída de 15-1 do comando show interface serial HDLC

15_1.gif

Tabela 15-1: Linhas de série: mostre a relações condições de linha de status de série - Esta tabela mostra as condições, os problemas possíveis associados com as condições, e as soluções de status da interface 2 aqueles problemas.

Condição de linha de status Possível problema Solução
X de série está acima, protocolo de linha está acima   Essa é a condição de linha de status correta. Nenhuma ação é necessária.
X de série está para baixo, protocolo de linha está inativo (o modo DTE)
  • Indica tipicamente que o roteador não está detectando um sinal do CD (isto é, o CD não é ativo).
  • A problema-linha da companhia telefônica está para baixo ou a linha não é conectada ao CSU/DSU
  • Defeituoso ou cabeamento incorreto
  • Falha do hardware (CSU/DSU)
  1. Verifique o diodo emissor de luz no CSU/DSU para ver se o CD é ativo, ou para introduzir uma caixa breakout na linha para verificar para ver se há o sinal do CD.
  2. Verifique que você está usando o cabo adequado e a relação (veja sua documentação de instalação de hardware).
  3. Introduza uma caixa breakout e verifique todas as ligações do controle.
  4. Contacte sua linha alugada ou o outro serviço de portadora para ver se há um problema.
  5. Troque peças defeituosas.
  6. Se você suspeita o hardware de roteador falho, mude a linha de série a uma outra porta. Se a conexão vem acima, previamente a interface conectada tem um problema.
X de série está acima, protocolo de linha está inativo (o modo DTE)
  • O roteador local ou remoto é desconfigurado
  • O Keepalives não está sendo enviado pelo roteador remoto
  • Linha alugada ou a outra linha problema-ruidosa do serviço de portadora, ou desconfigurado ou switch falho
  • O problema de cronometragem no cabo (SCTE não ajustado no CSU/DSU) falhou o CSU/DSU local ou remoto
  • CSU/DSU local ou remoto falhado
  • Falha de hardware de roteador (local ou remoto)
  1. Põe o modem, o CSU, ou o DSU no modo loopback local e use o comando show interfaces serial ver se o protocolo de linha vem acima. Se o protocolo de linha vem acima, um problema de companhia telefônica ou um roteador remoto falhado são o problema provável.
  2. Se o problema parece estar na extremidade remota, repita etapa 1 no modem remoto, no CSU, ou no DSU.
  3. Verifique tudo que cabografa. Certifique-se de que o cabo está anexado à relação correta, ao CSU/DSU correto, e ao ponto de terminação de rede de companhia telefônica correto. Use o comando show controllers exec determinar que cabo é anexado a que relação.
  4. Permita o comando debug serial interface exec.

    cuidado Cuidado: Porque resultado do debug é atribuído uma alta prioridade no processo de CPU, pode tornar o sistema inusá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 eliminação de erros durante estes períodos diminui a probabilidade que aumentou despesas gerais de processamento de comando debug afetará o uso do sistema.

  5. Se o protocolo de linha não vem acima no modo loopback local e se a saída do comando debug serial interface exec mostra que o contador de keepalive não está incrementando, um problema de hardware de roteador é provável. Hardware de interface de roteador da troca.
  6. Se o protocolo de linha vem acima e os incrementos do contador de keepalive, o problema não está no roteador local. Pesquise defeitos a linha de série como descrito nas seções “pesquisando defeitos problemas de relógio” e “testes CSU e de loopback de DSU,” mais tarde neste capítulo.
  7. Se você suspeita o hardware de roteador falho, mude a linha de série a uma porta não utilizada. Se a conexão vem acima, previamente a interface conectada tem um problema.
X de série está acima, protocolo de linha está inativo (o modo de DCE)
  • Comando missing clockrate interface configuration
  • O dispositivo DTE não apoia nem não se estabelece para o modo de SCTE
  • CSU ou DSU remoto falhado
  • Falhado ou cabo incorreto
  • Falha de hardware de roteador
  1. Adicionar o comando clockrate interface configuration na interface serial. Sintaxe: descrição da sintaxe do clock rate bps:
    • Clock Rate bps-desejado nos bit por segundo: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000, ou 8000000.
  2. Ajuste o dispositivo DTE ao modo de SCTE se possível. Se seu CSU/DSU não apoia o SCTE, você pode ter que desabilitar o SCTE na interface de roteador Cisco. Veja a seção “inverter o rtransmitir relógio,” mais tarde neste capítulo.
  3. Verifique que o cabo correto está sendo usado.
  4. Se o protocolo de linha é ainda para baixo, há uma falha ou um problema de cabeamento de hardware possível. Introduza uma caixa breakout e observe ligações.
  5. Substitua peças defeituosas como necessário.
X de série está acima, o protocolo de linha está acima de (dado laços) Um laço existe no circuito. O número de sequência no pacote keepalive muda a um número aleatório quando um laço é detectado inicialmente. Se o mesmo número aleatório é retornado sobre o link, um laço existe.
  1. Use o comando show running-config privileged exec procurar todas as entradas do comando loopback interface configuration.
  2. Se você encontra uma entrada do comando loopback interface configuration, use o comando no loopback interface configuration remover o laço.
  3. Se você não encontra o comando loopback interface configuration, examine o CSU/DSU para ver se são configurados no modo loopback manual. Se são, desabilite o loopback manual.
  4. Restaure o CSU ou o DSU, e inspecione a linha estado. Se o protocolo de linha vem acima, nenhuma outra ação está precisada.
  5. Se o CSU ou o DSU não são configurados no modo loopback manual, contacte a linha alugada ou o outro serviço de portadora para a linha assistência paraTroubleshooting.
X de série está acima, o protocolo de linha está inativo (desabilitado)
  • Alta taxa de erro devido ao problema do serviço da companhia telefônica
  • Problema de hardware CSU ou DSU
  • Hardware do roteador inválido (relação)
  1. Pesquise defeitos a linha com um analisador de série e uma caixa breakout. Look for sinais firmando CTS e DSR.
  2. Laço CSU/DSU (laço DTE). Se o problema continua, é provável que há um problema de hardware. Se o problema não continua, é provável que há um problema de companhia telefônica.
  3. Descargue o hardware ruim como necessário (CSU, DSU, interruptor, roteador local ou remoto).
X de série está administrativamente para baixo, protocolo de linha está inativo
  • A configuração de roteador inclui o comando shutdown interface configuration
  • Endereço de IP duplicado
  1. Verifique a configuração de roteador para ver se há o comando shutdown.
  2. Use o comando no shutdown interface configuration remover o comando shutdown.
  3. Verifique que não há nenhum endereço IP idêntico usando o comando show running-config privileged exec ou o comando show interfaces exec.
  4. Se há uns endereços duplicados, resolva o conflito mudando um dos endereços IP de Um ou Mais Servidores Cisco ICM NT.

Linhas de série: Quedas de emissor crescentes no enlace serial

As quedas de emissor aparecem na saída do comando show interfaces serial (veja figura 15-1) quando o sistema está tentando entregar fora de um pacote a um buffer transmitir mas os sem bufferes estão disponíveis.

Sintoma: Um número de aumento de quedas de emissor no enlace serial.

Linhas da série da tabela 15-2: Quedas de emissor crescentes no enlace serial - Esta tabela esboça o problema possível que pode causar este sintoma e sugere soluções.

Possível problema Solução
A taxa de entrada à interface serial excede a largura de banda disponível no enlace serial
  1. Minimize o tráfego de broadcast periódico (tal como o roteamento e CAVE atualizações) usando Listas de acesso ou por outros meios. Por exemplo, para aumentar o atraso entre atualizações de SAP, use o comando ipx sap-interval interface configuration.
  2. Aumente o tamanho da fila de contenção de emissor em incrementos pequenos (por exemplo, 25 por cento), usando o comando hold-queue out interface configuration.
  3. Em relações afetadas, gire fora rapidamente a comutação para pesadamente - protocolos usados. Por exemplo, para desligar o interruptor rápido IP, inscreva o comando no ip route-cache interface configuration. Para a sintaxe de comando para outros protocolos, consulte os guias e as referências de comandos de configuração do IOS da Cisco.
  4. Execute filas de prioridade em uns enlaces serial mais lentos configurando listas de prioridades. Para obter informações sobre de configurar listas de prioridades, veja os guias e as referências de comandos de configuração do IOS da Cisco.

Nota: As quedas de emissor são aceitáveis sob certas condições. Por exemplo, se um link está sabido para ser usado (sem a maneira de remediar a situação), é frequentemente preferível deixar cair pacotes do que para guardá-los. Isto é verdadeiro para os protocolos que apoiam o controle de fluxo e podem retransmitir dados (tais como TCP/IP e Novell IPX). Contudo, alguns protocolos, tais como o DECNet e o Local-Area Transport são sensíveis aos pacotes descartado e acomodam a retransmissão deficientemente, se de todo.

Linhas de série: Caídas de entrada crescentes no enlace serial

As caídas de entrada aparecem na saída do comando show interfaces serial exec (veja figura 15-1) quando pacotes demais dessa relação estão sendo processados ainda no sistema.

Sintoma: Um número de aumento de caídas de entrada no enlace serial.

Tabela 15-3: Linhas de série: Caídas de entrada crescentes no enlace serial - Esta tabela esboça o problema possível que pode causar este sintoma e sugere soluções.

Possível problema Solução
A taxa de entrada excede a capacidade do roteador ou as filas de entrada excedem o tamanho das filas de saída

Nota: Os problemas da caída de entrada são considerados tipicamente quando o tráfego está sendo distribuído entre umas relações mais rápidas (tais como Ethernet, Token Ring, e FDDI) e umas interfaces serial. Quando o tráfego é luz, não há nenhum problema. Enquanto as taxas de tráfego aumentam, os backup começam ocorrer. Pacotes da gota do Roteadores durante estes períodos congestionados.

  1. Aumente o tamanho da fila de saída em interfaces de destino comuns para a relação que está deixando cair pacotes. Use o comando hold-queue out interface configuration. Aumente estas filas por incrementos pequenos (por exemplo, 25percent) até que você já não ver gotas na saída das relações da mostra. O limite da fila de contenção de emissor do padrão é 100 pacotes.
  2. Reduza o tamanho da fila de entrada, usando o comando hold-queue in interface configuration, forçar caídas de entrada para transformar-se quedas de emissor. As quedas de emissor têm menos impacto no desempenho do roteador do que fazem as caídas de entrada. A fila de organização de entrada do padrão é 75 pacotes.

Linhas de série: Erros de entrada de aumento além de um por cento do tráfego de interface total

Se os erros de entrada aparecem na mostra conectam a saída de série (veja figura 15-1), lá são diversos origens possíveis daqueles erros. As fontes mais provável são resumidas na tabela 15-4.

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

Sintoma: Um número de aumento de erros de entrada além de um por cento do tráfego de interface total.

Tabela 15-4: Linhas de série: Erros de entrada de aumento além de um por cento do tráfego de interface total

Possível problema Solução
Os seguintes problemas podem conduzir a este sintoma:
  • Equipamento de companhia telefônica defeituoso
  • Linha de série com ruído
  • Configuração de medição de tempo incorreta (SCTE não ajustado)
  • Cabo incorreto ou cabo demasiado longo
  • Cabo ou conexão ruim
  • CSU ou DSU ruim
  • Hardware do roteador inválido
  • Conversor de dados ou outro dispositivo que estão sendo usados entre o roteador e o DSU

Nota: Cisco recomenda fortemente não usar conversores de dados quando você está conectando um roteador a WAN ou a uma rede serial.

  1. Use um analisador de série para isolar a fonte dos erros de entrada. Se você detecta erros, é provável que há um problema de hardware ou uma má combinação do pulso de disparo em um dispositivo que seja externo ao roteador.
  2. Use o laço de retorno e os testes de ping para isolar o origem de problema específico. Para mais informação, veja seções “usar o comando trace” e “testes CSU e de loopback de DSU,” mais tarde neste capítulo.
  3. Procure testes padrões. Por exemplo, se os erros ocorrem em um intervalo consistente, poderiam ser relacionados a uma função periódica tal como a emissão das atualizações de roteamento.

Linhas de série: Troubleshooting de Erros Linha de Entrada Serial

Tabela 15-5: Esta tabela descreve os vários tipos de erros de entrada indicados pelo comando show interfaces serial (veja figura 15-1), os problemas possíveis que podem causar os erros e as soluções 2 aqueles problemas.

Tipo de erro de entrada (nome do campo) Possível problema Solução
Erros CRC (CRC) Os erros CRC ocorrem quando o cálculo de CRC faz passagem-não indicando que os dados são corromper-para uma das seguintes razões:
  • Linha de série com ruído
  • O cabo serial é demasiado longo, ou o cabo do CSU/DSU ao roteador não é protegido
  • O modo de SCTE não é permitido no DSU
  • O relógio de linha CSU é configurado incorretamente
  • Problema de densidade no link T1 (enquadramento incorreto ou especificação de codificação)
  1. Assegure-se de que a linha esteja limpa bastante para requisições de transmissão. Proteja o cabo caso necessário.
  2. Certifique-se que o cabo dentro está recomendado do comprimento-nenhuns mais do que os pés dos 50 pés (15.24 medidores) ou os 25 pés (7.62 medidores) para o link T1.
  3. Assegure-se de que todos os dispositivos estejam configurados corretamente para um relógio de linha comum. Ajuste o SCTE no DSU local e remoto. Se seu CSU/DSU não apoia o SCTE, veja a seção “inverter o rtransmitir relógio,” mais tarde neste capítulo.
  4. Assegure que o CSU/DSU local e remoto esteja configurado para a mesmos moldação e esquema de codificação que aquele usado pela linha alugada ou pelo outro serviço de portadora (por exemplo, ESF/B8ZS).
  5. Contacte sua linha alugada ou o outro serviço de portadora e mande-o executar 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 para uma das seguintes razões:
  • Linha de série com ruído
  • Impropriamente cabo programado; o cabo serial é demasiado longo; o cabo do CSU ou do DSU ao roteador não é protegido
  • O modo de SCTE não é permitido no DSU; o relógio de linha CSU é configurado incorretamente; um dos pulsos de disparo é configurado para cronometrar local
  • Problema de densidade no link T1 (enquadramento incorreto ou especificação de codificação)
  1. Assegure-se de que a linha esteja limpa bastante para requisições de transmissão. Proteja o cabo caso necessário. Assegure você estão usando o cabo correto.
  2. Certifique-se que o cabo dentro está recomendado do comprimento-nenhuns mais do que os pés dos 50 pés (15.24 medidores) ou os 25 pés (7.62 medidores) para o link T1.
  3. Assegure-se de que todos os dispositivos estejam configurados corretamente para usar um relógio de linha comum. Ajuste o SCTE no DSU local e remoto. Se seu CSU/DSU não apoia o SCTE, veja a seção “inverter o rtransmitir relógio” mais tarde neste capítulo.
  4. Assegure que o CSU/DSU local e remoto esteja configurado para a mesmos moldação e esquema de codificação que aquele usado pela linha alugada ou pelo outro serviço de portadora (por exemplo, ESF/B8ZS).
  5. Contacte sua linha alugada ou o outro serviço de portadora e mande-o executar testes de integridade na linha.
Transmissão abortada (aborto) Os abortos indicam uma sequência ilegal dos bit um (mais de sete em seguido). Os seguintes são razões para essa ocorrência possíveis:
  • O modo de SCTE não é permitido no DSU
  • O relógio de linha CSU é configurado incorretamente
  • O cabo serial é demasiado longo ou o cabo do CSU ou do DSU ao roteador não é protegido
  • Problema de densidade no link T1 (enquadramento incorreto ou especificação de codificação)
  • O pacote terminou no meio da causa transmissão-típica que é uma restauração da relação ou um erro de enquadramento
  • Circuito problema-ruim do hardware, CSU/DSU ruim, ou relação de emissão ruim no roteador remoto
  1. Assegure-se de que todos os dispositivos estejam configurados corretamente para usar um relógio de linha comum. Ajuste o SCTE no DSU local e remoto. Se seu CSU/DSU não apoia o SCTE, veja a seção “inverter o rtransmitir relógio,” mais tarde neste capítulo.
  2. Proteja o cabo caso necessário. Assegure o cabo dentro é recomendado do comprimento-nenhuns mais do que os pés dos 50 pés (15.24 medidores) ou os 25 pés (7.62 medidores) para o link T1. Assegure-se de que todas as conexões sejam boas.
  3. Verifique o hardware no ambas as extremidades do link. Troque equipamentos defeituosos, conforme necessário.
  4. As taxas de dados mais baixa e consideram se os abortos diminuem.
  5. Use testes de loopback remoto e local para determinar onde os abortos estão ocorrendo. Veja a seção “testes de linha serial especiais,” mais tarde neste capítulo.
  6. Contacte sua linha alugada ou o outro serviço de portadora e mande-o executar testes de integridade na linha.

Linhas de série: Aumentos de reinicialização de interface no enlace serial

As restaurações da relação que aparecem na saída do comando show interfaces serial exec (consideram que figura 15-1) é o resultado de pacotes de manutenção de atividade faltados.

Sintoma: Um número de aumento de restaurações da relação no enlace serial.

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

Possível problema Solução
Os seguintes problemas podem conduzir a este sintoma:
  • Congestão no link (associado tipicamente com as quedas de emissor)
  • Linha ruim que causa transições do CD
  • Problema do hardware possível no CSU, no DSU, ou no interruptor
Quando as restaurações da relação estão ocorrendo, examine outros campos do mostre a saída do comando de série de interfaces para determinar a fonte do problema. Supondo que um aumento em restaurações da relação está sendo gravado, examine os seguintes campos:
  1. Se há um alto número de quedas de emissor na mostra conecta a saída de série, vê linhas de série da seção “: Quedas de emissor crescentes no enlace serial,” mais cedo neste capítulo.
  2. Verifique as transições de portadora colocam no indicador de série das relações da mostra. Se as transições de portadora são altas quando as restaurações da relação estiverem registradas, o problema é provável ser um link ruim ou um CSU ou um DSU ruim. Contacte seu equipamento com defeito da linha alugada ou do serviço de portadora e da troca como necessário.
  3. Examine os erros de entrada colocam no indicador de série das relações da mostra. Se os erros de entrada são altos quando as restaurações da relação aumentarem, o problema é provavelmente um link ruim ou um CSU/DSU ruim. Contacte sua linha alugada ou o outro equipamento com defeito do serviço de portadora e da troca como necessário.

Linhas de série: Contagem crescente das transições de portadora no enlace serial

As transições de portadora parecem na saída do comando show interfaces serial exec sempre que há uma interrupção no sinal de portadora (tal como uma restauração da relação na extremidade remota de um link).

Sintoma: Um número de aumento de contagem das transições de portadora no enlace serial.

A tabela 15-7 esboça os problemas possíveis que podem causar este sintoma e sugere soluções.

Tabela 15-7: Linhas de série: Contagem crescente das transições de portadora no enlace serial

Possível problema Solução
Os seguintes problemas podem conduzir a este sintoma:
  • Linha interrupções devido a um origem externa (tal como a separação física de expedição de cabogramas, alarmes T1 vermelhos ou amarelos, ou desencapamento de fio em algum lugar ao longo da rede)
  • Switch defeituoso, DSU, ou hardware de roteador
  1. Verifique o hardware no ambas as extremidades do link. Anexe uma caixa breakout ou um analisador de série e um teste para determinar o origem de problemas.
  2. Se um analisador ou uma caixa breakout são incapaz de identificar quaisquer problemas externos, verifique o hardware de roteador.
  3. Troque equipamentos defeituosos, conforme necessário.

Usando o comando show controllers

O comando show controllers exec é uma outra ferramenta de diagnóstico importante ao pesquisar defeitos linhas de série. A sintaxe de comando varia segundo a plataforma:

  • Para interfaces serial em Cisco 7000 Series Router, use o comando show controllers cbus exec.

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

  • Para o AGS, o CGS, e o MGS, usam o comando show controllers mci exec.

Figura 15-2 mostra a saída do comando show controllers cbus exec. Este comando é usado em Cisco 7000 Series Router com o cartão rápido do processador de interface serial (FSIP). Verifique a saída do comando para assegurar que o cabo à unidade de serviço de canal/unidade de serviço digital (CSU/DSU) esteja anexado à interface adequada. Você pode igualmente verificar a versão do microcódigo para ver se é atual.

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

/image/gif/paws/14149/15_2.gif

Em produtos de acesso tais como o Cisco 2000, Cisco2500, o Cisco 3000, e os servidores de acesso e o Roteadores do Cisco 4000 Series, usam o comando show controllers exec. Figura 15-3 mostra o comando show controllers output do Basic Rate Interface (BRI) e das interfaces serial em um servidor de acesso do Cisco 2503. (Nota que alguma saída não está mostrada.)

A saída de controladores da mostra indica o estado dos canais de interface e se um cabo está anexado à relação. Em figura 15-3, a interface serial 0 tem um cabo DTE RS-232 anexado. A interface serial 1 não tem nenhum cabo anexado.

Figura 15-4 mostra a saída do comando show controllers mci. Este comando é usado no AGS, no CGS, e nos roteadores MGS somente. Se a interface elétrica está indicada como o DESCONHECIDO (em vez do V.35, do EIA/TIA-449, ou do algum outro tipo de interface elétrica), impropriamente um cabo conectado é o problema provável. Uns circuitos auxiliares ruins ou um problema com o fiação interna do cartão são igualmente possíveis. Se a interface elétrica é desconhecida, o indicador correspondente para o comando show interfaces serial exec mostrará que a relação e o protocolo de linha estão para baixo.

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

/image/gif/paws/14149/15_3.gif

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

/image/gif/paws/14149/15_4.gif

Utilizando comandos debug

A saída dos vários comandos debug privileged exec fornece a informação de diagnóstico em relação ao status do protocolo e a atividade de rede para muitos eventos de comunicação inter-redes.

cuidado Cuidado:  Porque resultado do debug é atribuído uma alta prioridade no processo de CPU, pode tornar o sistema inusá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 eliminação de erros durante estes períodos diminui a probabilidade que aumentou despesas gerais de processamento de comando 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 ao pesquisar defeitos a série e os problemas WAN. Mais informação sobre a função e a saída de cada um destes comandos é fornecida na publicação da referência do comando Debug:

  • debugar a relação de série verifica se os pacotes keepalive HDLC estão incrementando. Se não, é provável que exista um problema de cronometragem na placa de interface ou na rede.

  • os eventos do debug x25 detectam os eventos X.25, tais como a abertura e o closing dos Circuitos Virtuais Comutados (SVC). A “causa resultante e” a informação diagnóstica são incluídas com os relatórios de evento.

  • debugar a informação X.25 do procedimento de acesso de enlace, equilibrado (LAPB) ou do nível 2 das saídas LAPB.

  • debugar o ARP indica se o roteador está enviando a informação sobre ou a está aprendendo sobre o Roteadores (com pacotes ARP) no outro lado do nuvem de WAN. Use este comando quando alguns Nós em uma rede TCP/IP estão respondendo mas outro não são.

  • debugar o Frame Relay LMI obtém a informação da interface de gerenciamento local (LMI) útil para determinar se um Frame Relay Switch e um roteador são de emissão e de recepção pacotes de LMI.

  • debugar eventos do Frame Relay determina se as trocas estão ocorrendo entre um roteador e um Frame Relay Switch.

  • debugar os pacotes do protocolo shows point-to-point da negociação ppp (PPP) transmitidos durante a inicialização de PPP, onde as opções de PPP são negociadas.

  • debugar os pacotes PPP das mostras do pacote ppp que estão sendo enviados e recebidos. Esse comando exibe os dumps de pacote de nível baixo.

  • debugar os erros de PPP das mostras dos erros ppp (tais como ilegal ou frames mal formados) associados com a negociação e a operação da conexão PPP.

  • debugar intercâmbios de pacotes do protocolo de autenticação de cumprimento (RACHADURA) e do protocolo password authentication do desafio das mostras PPP da rachadura ppp (PAP).

  • debugar os pacotes de série do Switched Multimegabit Data Service (SMDS) das mostras do pacote que estão sendo enviados e recebidos. Este indicador igualmente imprime Mensagens de Erro para indicar porque um pacote não foi enviado nem foi recebido erroneamente. Para o S DS, o comando despeja o cabeçalho SMDS inteiro e alguns dados de payload quando um pacote SMDS é transmitido ou recebido.

Usando testes ping extendido

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 (Protocolo de mensagem de controle da Internet).

Nota: O comando ping é particularmente útil quando os níveis altos dos erros de entrada estão sendo registrados no indicador de série das relações da mostra. Veja 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. Figura 15-5 ilustra o menu usado para especificar opções do ping estendido. Este exemplo especifica 20 sibilos sucessivos. Contudo, ao testar os componentes em sua linha de série, você deve especificar um número muito maior, tal como 1000 sibilos.

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

/image/gif/paws/14149/15_5.gif

Executando testes de ping

Geralmente, execute testes de ping de linha serial como segue:

  1. Põe o CSU ou o DSU no modo loopback local.

  2. Configurar o comando extended ping enviar padrões de dados e tamanhos do pacote diferentes. Figura 15-6 e figura 15-7 ilustram dois testes de ping úteis, o tudo zero (1500-byte) sibilam e um sibilo (1500-byte) todas em uma, respectivamente.

  3. Examine o mostre a saída do comando de série de interfaces (veja 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 esta sequência de teste esteve alertada pela aparência de um grande número CRC e erros de enquadramento, um problema de relógio é provável. Verifique o CSU ou o DSU para ver se há um problema de cronometragem. Veja a seção do “problemas de relógio Troubleshooting,” mais tarde neste capítulo.

  4. Se você determina que a configuração de medição de tempo está correta e se está operando corretamente, põe o CSU ou o DSU no modo de loopback remoto.

  5. Repita o teste de ping e procure mudanças nas estatísticas do erro de entrada.

  6. Se os erros de entrada aumentam, há um problema na linha de série ou no CSU/DSU. Contacte o provedor de serviços MACILENTO e troque o CSU ou o DSU. Se os problemas persistem, contacte seu representante de suporte técnico.

Figura 15-6: Teste de ping do tudo zero 1500-Byte

/image/gif/paws/14149/15_6.gif

Figura teste de ping 1500-Byte todas em uma de 15-7

/image/gif/paws/14149/15_7.gif

Pesquisando defeitos problemas de relógio

Os conflitos de relógio nas conexões serial podem conduzir ao serviço crônico da perda de conexão ou ao desempenho degradado. Esta seção discute os aspectos importantes dos problemas de relógio: causas do problema de relógio, detectando problemas de relógio, isolando problemas de relógio, e soluções de problema de relógio.

Visão geral de tempo

O CSU/DSU deriva o relógio de dados dos dados que passam através dele. A fim recuperar o pulso de disparo, o hardware CSU/DSU deve receber pelo menos um valor 1-bit para cada 8 bit dos dados que passam com ele; isto é sabido como densidade. Manter densidade permite que o hardware recupere o relógio de dados confiantemente.

Umas aplicações T1 mais novas usam geralmente o formato de superframe estendido (ESF) que molda com codificação da substituição oito-zero binária (B8ZS). O B8ZS fornece um esquema por que um código especial é substituído sempre que oito zero consecutivos são enviados através do enlace serial. Este código é interpretado então na extremidade remota da conexão. Esta técnica garante independente de densidade do fluxo de dados.

Umas aplicações T1 mais velhas usam D4-also conhecido como o Superframe Format (SF) moldação e codificação da inversão de marca alternada (AMI). O AMI não utiliza um esquema de codificação como o B8ZS. Isto restringe o tipo de dados que podem ser transmitidos porque uns densidade não são independente mantido do fluxo de dados.

Um outro elemento importante nas comunicações serial é cronometragem terminal da transmissão externa de relógio serial (SCTE). O SCTE é o pulso de disparo ecoado para trás do dispositivo do equipamento de terminal de dados (DTE) (por exemplo, um roteador) ao dispositivo da data communications equipment (DCE) (por exemplo, o CSU/DSU).

Quando o dispositivo DCE usa o SCTE em vez de seu relógio interno para provar dados do DTE, pode melhor provar os dados sem erro mesmo se há um deslocamento de fase no cabo entre o CSU/DSU e o roteador. Usar o SCTE é altamente recomendado para transmissões de série mais rapidamente de 64 kbps. Se seu CSU/DSU não apoia o SCTE, veja a seção “inverter o rtransmitir relógio,” mais tarde neste capítulo.

Causas do problema de relógio

Geralmente, os problemas de relógio em interconexões do WAN serial podem ser atribuídos a uma das seguintes causas:

  • Configuração incorreta de dsu

  • Configuração incorreta de CSU

  • Cabos fora de especificação-que é, mais por muito tempo do que os pés dos 50 pés (15.24 medidores) ou unshielded

  • Conexões ruidosas ou deficientes do painel de correção

  • Diversos cabos conectados junto em seguido

Detectando problemas de relógio

Para detectar conflitos de relógio em uma interface serial, procure erros de entrada como segue:

  1. Use o comando show interfaces serial exec no Roteadores no ambas as extremidades do link.

  2. Examine o comando output para o CRC, os erros de enquadramento, e os abortos.

  3. Se qualquer uma destas etapas indica os erros que excedem um intervalo aproximado de 0.5 por cento 2.0 por cento do tráfego na relação, os problemas de relógio são prováveis existir em algum lugar em WAN.

  4. Isole a fonte dos conflitos de relógio de acordo com a seguinte seção, “isolando problemas de relógio.”

  5. Contorneie ou repare todos os painéis de correção defeituosos.

Isolando problemas de relógio

Depois que você determina que os conflitos de relógio são a causa mais provável dos erros de entrada, o seguinte procedimento ajudá-lo-á a isolar a fonte daqueles erros:

  1. Execute uma série de testes de ping e de testes de loopback (local e remoto), como descrito na seção “testes CSU e de loopback de DSU,” mais cedo neste capítulo.

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

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

Se os erros de entrada estão acumulando no ambas as extremidades da conexão, cronometrar do CSU é o problema mais provável.

Se somente uma extremidade está experimentando erros de entrada, há provavelmente um relógio DSU ou um problema de cabeamento.

Os abortos em uma extremidade sugerem que a outra extremidade esteja enviando a informação ruim ou que há um problema de linha.

Nota: Sempre refira o mostre a saída do comando de série de interfaces (veja figura 15-1) e registre todas as mudanças nos contagens de erro ou na nota se o contagem de erro não muda.

Soluções de problema de relógio

Linhas da série da tabela 15-8: Problemas de relógio e soluções: Esta tabela esboça remédios sugeridos para problemas de relógio, com base na fonte do problema.

Possível problema Solução
Configuração incorreta de CSU
  1. Determine se os CSU no ambas as extremidades concordam com o origem do relógio (local ou linha).
  2. Se os CSU não concordam, configurar-los de modo que façam. Geralmente a linha é a fonte.
  3. Verifique o ajuste LBO no CSU para assegurar-se de que a impedância combine aquela da linha física. Para obter informações sobre de configurar seu CSU, consulte sua documentação de hardware CSU.
Configuração incorreta de dsu
  1. Determine se os DSU no ambas as extremidades têm o modo de SCTE permitido.
  2. Se o SCTE não é permitido no ambas as extremidades da conexão, permita-a.
  3. Certifique-se de que se densidade está mantido. Isto exige que o uso DSU a mesmos moldação e esquemas de codificação (por exemplo, ESF e B8ZS) usados pela linha alugada ou pelo outro serviço de portadora. Verifique com seu fornecedor da linha alugada para obter informações sobre de seus moldação e esquemas de codificação.
  4. Se seu serviço de portadora usa a codificação ami, ou inverta o rtransmitir relógio em ambos os lados do link ou execute o DSU no modo bit-stuff. Para obter informações sobre de configurar seu DSU, consulte sua documentação de hardware DSU.
O cabo ao roteador é fora da especificação Se o cabo é mais longo do que os pés dos 50 pés (15.24 medidores), use um cabo mais curto. Se o cabo é unshielded, substitua-o com o cabo protegido.

Invertendo o rtransmitir relógio

Se você está tentando conexões serial em maiores de 64 kbps das velocidades com um CSU/DSU que não apoie o SCTE, você pode ter que inverter o rtransmitir relógio no roteador. Inverter o rtransmitir relógio compensa deslocamentos de fase entre os dados e os sinais do relógio.

O comando específico usado para inverter o rtransmitir relógio varia entre Plataformas. Em um Cisco 7000 Series Router, inscreva o comando invert-transmit-clock interface configuration. Para Cisco 4000 Series Router, use o comando dte-invert-txc interface configuration.

Para assegurar-se de que você esteja usando a sintaxe de comando correto para seu roteador, refira ao Guia do Usuário para seu roteador ou servidor de acesso e os guias e as referências de comandos de configuração do IOS da Cisco.

Nota: Em umas Plataformas mais velhas, inverter o rtransmitir relógio pode exigir que você move um jumper físico.

Ajustando bufferes

Excessivamente - os resultados da utilização de largura de banda alta (sobre 70percent) no desempenho geral reduzido e podem causar falhas intermitentes. Por exemplo, as transmissões de arquivos DECnet podem ser falhar devido aos pacotes que estão sendo deixados cair em algum lugar na rede.

Se a situação é ruim bastante, você deve aumentar a largura de banda do link. Contudo, aumentar a largura de banda não pode ser necessário ou imediatamente prático. Uma maneira de resolver problemas de utilização em excesso de linha serial secundária é controlar como o roteador usa bufferes de dados.

cuidado Cuidado: Geralmente, não ajuste bufferes de sistema a menos que você estiver trabalhando proximamente com um representante de suporte técnico Cisco. Você pode severamente afetar o desempenho de seu hardware e de sua rede se você ajusta incorretamente os bufferes de sistema em seu roteador.

Use uma das seguintes três opções para controlar como os bufferes são usados:

  • Ajuste os parâmetros associados com os bufferes de sistema

  • Especifique o número de pacotes guardados na fila de entrada ou de saída (as filas de contenção)

  • Dê a prioridade a como o tráfego é enfileirado para a transmissão (Enfileiramento de saídas de prioridade)

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

A seguinte seção centra-se sobre a identificação das situações em que estas opções são prováveis se aplicar e definindo como você pode usar estas opções para ajudar a resolver a Conectividade e os problemas de desempenho em interconexões serial/WAN.

Bufferes de sistema de ajuste

Há dois tipos gerais do buffer em roteadores Cisco: bufferes de hardware e bufferes de sistema. Somente os bufferes de sistema são diretamente configuráveis por administradores de sistema. Os bufferes de hardware são usados especificamente como a recepção e transmitem os bufferes associados com cada relação e (na ausência de alguma configuração especial) são controlados dinamicamente pelo software do sistema próprio.

Os bufferes de sistema são associados com a memória de sistema principal e são blocos de memória atribuídos do diferente-tamanho. Um comando útil para determinar o estado de seus bufferes de sistema é o comando show buffers exec. Figura 15-8 mostra a saída do comando show buffers.

Figura saída do comando show buffers de 15-8

/image/gif/paws/14149/15_8.gif

Na saída de show buffers:

  • o total identifica o número total de bufferes no pool, em incluir usado e em bufferes não utilizados.

  • o permanent- identifica o número permanente de bufferes alocado no pool. Estes bufferes estão sempre no pool e não podem ser aparados afastado.

  • na lista livre identifica o número de buffer atualmente no pool que está disponível para o uso.

  • o minuto identifica o número mínimo de bufferes que o route processor (RP) deve tentar se 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 buffer na lista livre cai abaixo do valor mínimo, o RP tenta criar mais bufferes para esse pool.

  • máximo permitido identifica o número máximo de bufferes permitidos na lista livre:

    • O parâmetro permitido máximo impede um pool dos bufferes de monopolização que não precisa anymore e livra esta memória de volta ao sistema para um uso mais adicional.

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

  • as batidas identificam o número de buffer que foram pedidas do pool. Esse contador de acertos fornece um mecanismo para determinar qual pool deve atender a demanda mais alta para buffers.

  • as faltas identificam o número de vezes que um buffer foi pedido e o RP detectou que os bufferes adicionais estiveram exigidos. (Ou seja o número de buffer na lista livre deixou cair abaixo do Min.) as faltas representam contra o número de vezes que o RP foi forçado para criar bufferes adicionais.

  • as guarnições identificam o número de buffer que o RP aparou do pool quando o número de buffer na lista livre excedeu o número de bufferes permitidos máximos.

  • criado identifica o número de buffer que foi criado no pool. O RP cria bufferes quando a procura para bufferes aumentou até que o número de buffer na lista livre esteja menos do que bufferes mínimos e/ou uma falta ocorre devido aos bufferes zero na lista livre.

  • as falhas identificam o número de falhas conceder um buffer a um solicitador mesmo depois a tentativa criar um buffer adicional. O número de falhas representa o número de pacotes que foram deixado cair devido à falha de buffer.

  • nenhuma memória identifica o número de falhas causadas pela memória insuficiente criar bufferes adicionais.

A saída do comando show buffers em figura 15-8 indica altos números nas guarnições e campos criados para grandes bufferes. Se você está recebendo altos números nestes campos, você pode aumentar seu desempenho de link serial aumentando o valor livre máximo configurado para seus bufferes de sistema. as guarnições identificam o número de buffer que o RP aparou do pool quando o número de buffer na lista livre excedeu o número de bufferes permitidos máximos.

Use o comando buffers max free number global configuration aumentar o número de bufferes do sistema gratuito. O valor que você configura deve ser aproximadamente 150 por cento da figura indicada no o campo total da saída do comando show buffers. Repita este processo até que a saída de bufferes da mostra já não indique guarnições e bufferes criados.

Se a saída do comando show buffers mostra um grande número falhas (no campo de nenhuma memória) (veja a última linha de saída em figura 15-8), você deve reduzir o uso dos bufferes de sistema ou aumentar a quantidade de compartilhado ou memória principal (RAM físico) no roteador. Chame seu representante de suporte técnico para o auxílio.

Executando limites da fila de contenção

As filas de contenção são bufferes usados por cada interface do roteador para armazenar pacotes de entrada e de saída. Use o comando hold-queue interface configuration aumentar o número de pacotes de dados enfileirados antes que o roteador deixar cair pacotes. Aumente estas filas por incrementos pequenos (por exemplo, 25 por cento) até que você já não ver gotas na saída das relações da mostra. O limite da fila de contenção de emissor do padrão é 100 pacotes.

Nota: O comando hold-queue é usado para os pacotes comutados por processamento e as atualizações periódicas gerados pelo roteador.

Use o comando hold-queue impedir que os pacotes estejam deixados cair e melhorar o desempenho de link serial sob as seguintes circunstâncias:

  • Você tem um aplicativo que não possa tolerar gotas e o protocolo possa tolerar uns atrasos mais longos. O DECNet é um exemplo de um protocolo que encontre ambos os critérios. O Local Area Transport (LAT) não faz porque não tolera atrasos.

  • A relação é muito lenta. A largura de banda é baixa ou a utilização antecipada é provável exceder esporadicamente a largura de banda disponível.

Nota: Quando você aumenta o número especificado para uma fila de contenção de emissor, você pode precisar de aumentar o número de bufferes de sistema. O valor usado depende do tamanho dos pacotes associados com o tráfego antecipado para a rede.

Usando filas de prioridade para reduzir gargalos

As filas de prioridade são um mecanismo de controle lista-baseado que permita que o tráfego seja dado a prioridade em uma base da relação-por-relação. As filas de prioridade envolvem duas etapas:

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

  2. Atribua a lista de prioridades a uma relação específica.

Both of these etapas usam versões do comando priority-list global configuration. Além, um controle de tráfego mais adicional pode ser aplicado por comandos referencing access-list global configuration das especificações da prioridade-lista. Para exemplos de definir listas de prioridades e para detalhes sobre a sintaxe de comando associada com as filas de prioridade, refira os guias e as referências de comandos de configuração do IOS da Cisco.

Nota: As filas de prioridade criam automaticamente quatro filas de contenção do tamanho de variação. Isto cancela toda a especificação da fila de contenção incluída em sua configuração.

Use filas de prioridade para impedir que os pacotes estejam deixados cair e para melhorar o desempenho de link serial sob as seguintes circunstâncias:

  • Quando a relação é lenta, há uma variedade de tipos de tráfego que estão sendo transmitidos, e você quer melhorar o desempenho do tráfego de terminal.

  • Se você tem um enlace serial que esteja experimentando intermitentemente muito filas de prioridade das cargas pesadas (tais como transferências de arquivo que ocorrem em horas específicas) ajudará seleciona que tipos de tráfego devem ser rejeitados em períodos do tráfego elevado.

Geralmente, começo com o número padrão de filas ao executar filas de prioridade. Após ter permitido filas de prioridade, monitore quedas de emissor com o comando show interfaces serial exec. Se você o observa que as quedas de emissor estão ocorrendo na fila de tráfego especificou para ser prioritário, aumente o número de pacotes que podem ser enfileirados (usando a opção das palavras-chave de limite de fila do comando priority-list global configuration). Os argumentos do limite de fila padrão são 20 pacotes para a fila de alta prioridade, 40 para o media, 60 para o normal, e 80 para o ponto baixo.

Nota: Ao construir uma ponte sobre o tráfego de LAT de Digital Equipment Corporation (DEC), o roteador deve deixar cair muito poucos pacotes, ou as sessões LAT podem terminar inesperadamente. Uma profundidade da fila de alta prioridade de aproximadamente 100 (especificado com as palavras-chave de limite de fila) é um valor de trabalho típico quando seu roteador está deixando cair pacotes de saída e as linhas de série é sujeitada aproximadamente à utilização da largura de banda dos por cento dos 50 pés. Se o roteador está deixando cair pacotes e está no porcentagem de utilização 100, você precisa uma outra linha.

Uma outra ferramenta para aliviar a congestão ao construir uma ponte sobre o LAT DEC é compactação de LAT. Você pode executar o compactação de LAT com a lat-compressão do grupo do ponte-grupo do comando interface configuration.

Testes de linha serial especiais

Além do que as capacidades de diagnóstico básicas disponíveis no Roteadores, uma variedade de ferramentas complementares e técnicas podem ser usadas para determinar as condições dos cabos, do equipamento de switching, do Modems, dos anfitriões, e do hardware Inter-rede remoto. Para mais informação, consulte a documentação para seu CSU, DSU, analisador de série, ou o outro equipamento.

Testes CSU e de loopback de DSU

Se a saída do comando show interfaces serial exec indica que a linha de série está acima mas o protocolo de linha está inativo, use os testes de loopback CSU/DSU para determinar a fonte do problema. Execute o teste de loop local primeiramente, e então o teste remoto. Figura 15-9 ilustra a topologia básica dos testes de loopback remoto e local CSU/DSU.

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

/image/gif/paws/14149/15_9.gif

Nota: Estes testes são genéricos na natureza e supõem o acessório do sistema inter-rede a um CSU ou a um DSU. Contudo, os testes são essencialmente os mesmos para o acessório a um multiplexer com funcionalidade incorporado CSU/DSU. Porque não há nenhum conceito de um laço de retorno ambientes na rede de pacote comutado X.25 ou de Frame Relay (PSN), os testes de loopback não se aplicam ao X.25 e às redes do Frame Relay.

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

É alistado abaixo um procedimento geral para executar testes de loopback conjuntamente com capacidades incorporados do Diagnóstico do Sistema:

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

  2. Use o comando show interfaces serial exec determinar se a linha alterações de status do “protocolo de linha está inativo” ao “protocolo de linha está acima (dado laços),” ou se permanece para baixo.

  3. Se o protocolo de linha vem acima de quando o CSU ou o DSU reagem do modo loopback local, este sugere que o problema esteja ocorrendo na extremidade remota da conexão serial. Se a linha de status não muda o estado, há um problema possível no roteador, no cabo de conexão, ou no CSU/DSU.

  4. Se o problema parece ser local, use o comando debug serial interface privileged exec.

  5. Tome o CSU/DSU fora 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 incrementando.

  6. Coloque o CSU/DSU no modo de loop local outra vez. Isto deve fazer com que os pacotes keepalive comecem a incrementar. Especificamente, os valores para o mineseen e os yourseen keepalive incrementarão os segundos cada 10. Esta informação aparecerá na saída da interface serial debugar.

    Se o Keepalives não incrementa, pode haver um problema de cronometragem na placa de interface ou na rede. Para obter informações sobre de corrigir problemas de cronometragem, veja a seção do “problemas de relógio Troubleshooting,” mais cedo neste capítulo.

    Se o Keepalives não incrementa, pode haver um problema de cronometragem na placa de interface ou na rede. Para obter informações sobre de corrigir problemas de cronometragem, veja a seção do “problemas de relógio Troubleshooting,” mais cedo neste capítulo.

  7. Verifique o roteador local, o hardware CSU/DSU, e os todos os cabos conectados. Assegure que os cabos dentro estejam recomendados do comprimento-nenhuns mais do que os pés dos 50 pés (15.24 medidores) ou os 25 pés (7.62 medidores) para um link T1. Assegure os cabos são anexados às portas adequadas. Troque equipamentos defeituosos, conforme necessário.

Figura 15-10 mostra a saída do comando debug serial interface para uma conexão serial HDLC, com o Keepalives faltado que faz com que a linha vá para baixo e a relação restaure.

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

/image/gif/paws/14149/15_10.gif

Testes de loopback remotos CSU e DSU para o HDLC ou os links de PPP

Se você determina que o hardware local está funcionando corretamente mas você ainda encontra problemas ao tentar estabelecer conexões sobre o enlace serial, tenta usar o teste de loopback remoto para isolar a causa do problema.

Nota: Este teste de loopback remoto supõe que o encapsulamento de HDLC está sendo usado e que o teste de loop local precedente esteve executado imediatamente antes deste teste.

Os seguintes passos são necessários para executar o teste de circuito de retorno: Os seguintes passos são necessários para executar o teste de circuito de retorno:

  1. Põe o CSU ou o DSU remoto no modo de loopback remoto (refira a documentação de fornecedor).

  2. Usar o comando show interfaces serial exec, determina se o protocolo de linha permanece acima com a linha de status que indica que “x de série está acima, protocolo de linha está acima (dado laços),” ou se vai para baixo com a linha de status que indica o “protocolo de linha está inativo.”

  3. Se o protocolo de linha permanece acima (dado laços), o problema está provavelmente na extremidade remota da conexão serial (entre o CSU/DSU remoto e o roteador remoto). Realize testes locais e remotos na extremidade remota para isolar a fonte do problema.

  4. Se a linha alterações de status ao “protocolo de linha está inativo” quando o modo de loopback remoto estiver ativado, se certifica de que se densidade está sendo mantido corretamente. O CSU/DSU deve ser configurado para usar a mesmos moldação e esquemas de codificação usados pela linha alugada ou pelo outro serviço de portadora (por exemplo, ESF e B8ZS).

  5. Se os problemas persistem, contacte seu gerente de rede de WAN ou a organização de serviço MACILENTO.

Informação detalhada no comando show interfaces serial

As seguintes subseções cobrem os parâmetros, a descrição da sintaxe, o exemplo de exibição de saída, e as descrições de campo de comando show interfaces serial.

mostre parâmetros da série das relações

Ao Exibir informação sobre uma interface serial, use o comando show interfaces serial privileged exec:

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

  • Número-opcional. Número de porta.

  • Contabilidade-opcional. Indica o número de pacotes de cada tipo de protocolo que foram enviados através da relação.

  • : canal-grupo - Opcional. No Cisco 4000 Series com um NPM ou em um Cisco 7500 Series com um MIP, especifica o número de grupo de canaleta T1 na escala de 0 a 23, definida com o comando channel-group controller configuration.

  • entalhe - Refere o manual do hardware apropriado para a informação do entalhe.

  • porta - Refere o manual do hardware apropriado para a informação de porta.

  • adaptador de porta - Refere o manual do hardware apropriado para obter informações sobre da compatibilidade de 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 1 a 28 um pouco do que o esquema zero-baseado mais tradicional (0 27) usado com outros produtos Cisco. Este é assegurar a consistência com esquemas de numeração do telco para os canais T1 dentro do equipamento T3 separado.

  • CRB-opcional. Roteamento da relação das mostras e informação da construção de uma ponte sobre.

Modo de comando

EXEC Privilegiado

Diretrizes de uso

Este comando apareceu primeiramente no Cisco IOS Release 10.0 para o Cisco 4000 Series. Apareceu primeiramente no Cisco IOS Release 11.0 para o Cisco 7000 Series, e foi alterado no Cisco IOS Release 11.3 para incluir o CT3IP.

Exibições de exemplo

O seguinte é 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 de campo

Tabela 15-9: mostre a relações descrições de campo de série - esta tabela descreve os campos significativos mostrados na saída.

Campo Descrição
A série… é {acima de | para baixo}… está administrativamente para baixo Indica se o hardware da relação é atualmente ativo (a revelação do sinal de comunicação esta presente) ou se esteve tomada para baixo por um administrador.
o protocolo de linha é {acima de | para baixo} Indica se os processos de software que seguram o protocolo de linha consideram a linha útil (isto é, o Keepalives é bem sucedido) ou se ele esteve tomado para baixo por um administrador.
o protocolo de linha é {acima de | para baixo} Indica se os processos de software que seguram o protocolo de linha consideram a linha útil (isto é, o Keepalives é bem sucedido) ou se ele esteve tomado para baixo por um administrador.
O hardware é Especifica o tipo de hardware.
O endereço do Internet é Especifica o internet address e a máscara de sub-rede.
MTU Unidade de transmissão máxima da relação.
BW Indica o valor do parâmetro de largura de banda que foi configurado para a relação (nos kilobits por segundo). O parâmetro de largura de banda é usado para computar métricas de IGRP somente. Se a relação é anexada a uma linha de série com uma velocidade de linha que não combine o padrão (1536 ou 1544 para o T1 e 56 para uma linha serial síncrona padrão), use o comando bandwidth especificar a velocidade de linha correta para esta linha de série.
DLY Atraso da relação nos microssegundos.
confie Confiança da relação como uma fração de 255 (255/255 são 100 por cento de confiança), calculada como uma média exponencial sobre cinco minutos.
carga Confiança da relação como uma fração de 255 (255/255 são 100 por cento de confiança), calculada como uma média exponencial sobre cinco minutos.
Encapsulamento Método de encapsulamento atribuído à relação.
loopback Indica se o laço de retorno está ajustado.
keepalive Indica se o Keepalives está ajustado.
Última entrada Número de horas, de minutos, e de segundos desde que o último pacote foi recebido com sucesso por uma relação. Útil para saber quando uma relação inoperante falhou.
Última saída Número de horas, de minutos, e de segundos desde que o último pacote foi transmitido com sucesso por uma relação. Número de horas, de minutos, e de segundos desde que o último pacote foi transmitido com sucesso por uma relação.
cair da saída Número de horas, de minutos, e de segundos (ou nunca) desde que a relação era última restauração devido a uma transmissão que tomasse demasiado por muito tempo. Quando o número de horas em alguns dos últimos campos excede 24, o número de dias e de horas está imprimido. Se esse campo transborda, os asteriscos estão imprimidos.
Fila de saída, fila de entrada das gotas, gotas Número de pacotes em filas de saídas e entrada. Cada número é seguido por um corte, pelo tamanho máximo da fila, e pelo número de pacotes porque a fila está completa.
taxa de saídas por minuto da taxa de entrada 5 do minuto 5 Número médio de bit e de pacotes transmitidos por segundo nos cinco minutos passados. As taxas de entrada e de saída do cinco minutos devem ser usadas somente como uma aproximação do tráfego por segundo durante um período de cinco minutos dado. Estas taxas são exponencialmente médias pesadas com um período constante de cinco minutos. Um período de quatro períodos constantes deve passar antes que a média estiver dentro de 2 por cento da taxa instantânea de um córrego uniforme do tráfego durante esse 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 rejeitados porque havia um espaço de sem buffer no sistema principal. Compare com a contagem ignorada. As tempestades de transmissão em redes Ethernet e em explosões do ruído em linhas de série são frequentemente responsáveis para nenhuns eventos do buffer de entrada.
… Transmissões recebidas Número total de transmissão ou de pacotes de transmissão múltipla recebida pela relação.
runts Número de pacotes que são rejeitados porque são menores do que o tamanho de pacote mínimo do media.
giants Número de pacotes que são rejeitados porque excedem o tamanho máximo do pacote do media.
erros de entrada Número total de sem buffer, de runts, de gigantes, de CRC, de quadro, de overrun, ignorado, e de contagens do aborto. Outros erros entrada-relacionados podem igualmente incrementar a contagem, assim que esta soma não pode equilibrar com o outro conta.
CRC A verificação de redundância cíclica gerada pela estação de origem ou pelo dispositivo de extremidade oposta não combina a soma de verificação calculada dos dados recebidos. Em um enlace serial, os CRC indicam geralmente o ruído, as batidas do ganho, ou os outros problemas de transmissão no link de dados.
quadro O número de pacotes recebeu incorretamente ter um erro CRC e um número não inteiro de octetos. Em uma linha de série, este é geralmente o resultado do ruído ou dos outros problemas de transmissão.
sobrecarga O número de vezes o hardware do receptor de série era incapaz de entregar dados recebidos a um buffer de hardware porque a taxa de entrada excedeu a capacidade do receptor para segurar os dados.
ignorado Número de pacotes recebidos ignorados pela relação porque o hardware da relação foi executado baixo em bufferes internos. Sobrecargas e surtos de ruído de broadcast podem provocar aumento na contagem ignorada.
abortar Sequência ilegal dos bit um em uma interface serial. Isto indica geralmente um problema de relógio entre a interface serial e o equipamento de link de dados.
transições de portadora O número de vezes a revelação do sinal de comunicação de uma interface serial mudou o estado. Por exemplo, se o Data Carrier Detect (DCD) vai para baixo e vem acima, o contador da transição de portadora incrementará duas vezes. Indicar o modem ou problemas de linha se a linha da revelação do sinal de comunicação está mudando o estado frequentemente.
saída dos pacotes Número total de mensagens transmitidas pelo sistema.
saída dos bytes Número total de bytes, incluindo os dados e o encapsulamento MAC, transmitidos pelo sistema.
subutilizações de capacidade O número de vezes que o transmissor tem sido executado mais rapidamente do que o roteador pode segurar. Isto pode nunca ser relatado em algumas relações.
erros de saída Soma de todos os erros que impediram a transmissão final das datagramas fora da relação que está sendo examinada. Note que isto não pode equilibrar com a soma dos erros de saída enumerados porque algumas datagramas podem ter mais de um erro, e outro podem ter os erros que não caem em algumas das categorias especificamente tabuladas.
colisões O número de mensagens retransmitiu devido a um colisão Ethernet. Este é geralmente o resultado de um LAN overextended (isto é, Ethernet ou cabo de transceiver demasiado por muito tempo, mais de dois repetidores entre estações, ou demasiados transceptores conectados do multiport). Algumas colisões são normais. Contudo, se sua taxa de colisão escala a ao redor 4 por cento ou a por cento 5, você deve considerar verificar que não há nenhum equipamento com defeito no segmento e/ou em mover algumas estações existentes para um segmento novo. Um pacote que colida é contado somente uma vez em uns pacotes de saída.
restaurações da relação O número de vezes uma relação foi restaurado completamente. Isto pode acontecer se os pacotes enfileirados para a transmissão não foram enviados dentro do tempo de diversos segundos. Em uma linha de série, isto pode ser causado por um modem funcionando mal que não esteja fornecendo o sinal de relógio de transmissão, ou por um problema de cabo. Se as advertências do sistema que a linha da revelação do sinal de comunicação de uma interface serial está acima mas o protocolo de linha está inativo, ele restauram periodicamente a relação em um esforço para o reiniciar. Também pode ocorrer a reinicialização da interface quando uma interface tiver o circuito fechado ou for fechada.
reinícios O número de vezes o controlador foi reiniciado devido aos erros.
indicações de alarme, alarmes remotos, RX LOF, RX LOS O número de alarmes CSU/DSU, e o número de ocorrências de recebem a perda do frame e recebem a perda de sinal.
BER inativo, NELR inativo, FELR inativo O estado do G.703-E1 opõe-se para o alarme da taxa de erros de bits (BER), o telecontrole do laço da extremidade próxima (NELR), e o telecontrole do laço da ponta oposta (FELR). Note que você não pode ajustar o NELR ou o FELR.

Pesquisando defeitos o T1

Esta seção descreve as técnicas e os procedimentos para pesquisar defeitos os circuitos T1 para clientes de discagem de entrada.

Pesquisa de defeitos usando o comando show controller t1

Este comando indica o status de controle que é específico ao hardware de controle. A informação indicada é geralmente útil para as tarefas de diagnóstico executadas por pessoais de suporte técnico somente.

O NMP (processador de gerenciamento de rede) ou o MIP (processador multichannel de interface) podem perguntar os adaptadores de porta para determinar seu status atual. Emita um comando show controller t1 indicar estatísticas sobre o link T1.

Se você especifica um entalhe e um número de porta, as estatísticas para o cada período de 15 minutos estarão indicadas. O comando show controller t1 exec fornece a informação para pesquisar defeitos logicamente problemas da camada física e da camada de link de dados. Esta seção descreve como pesquisar defeitos logicamente usando o comando show controller t1.

A maioria de erros T1 são causados por linhas desconfigurada. Assegure-se de que a codificação de linha, a moldação e o origem do relógio estejam configurados de acordo com o que o provedor de serviços recomenda.

mostre condições T1 do controlador

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

  • Administrativamente fora do ar

  • Down

  • Para cima

Está o controlador T1 administrativamente para baixo?

O controlador fica administrativamente desativado quando é encerrado manualmente. Você deve reiniciar o controlador para corrigir este 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 formação?

Se o controlador T1 e a linha não estão acima, verifique para ver se um dos seguintes mensagens aparece no T1 EXEC do controlador da mostra output:

  • O receptor tem a perda do frame

  • O receptor tem a perda de sinal

Se o receptor T1 tem a perda do frame:

Siga estas etapas se o receptor T1 tem a perda do frame:

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Você pode verificar o formato do quadro do controlador da configuração running ou da saída do comando show controller t1.

    Para mudar o formato do quadro use a moldação {SF | Comando ESF} no modo de configuração de controle como 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. Mude a configuração exterior de linha usando o cablelength {por muito tempo | } comando curto.

O Line Build Out (LBO) compensa a perda nos decibéis baseados 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 seu provedor de serviços e a referência de comandos do ½ do ¿  de Cisco IOSï para detalhes em ajustes do buildout.

Se isto não fixa o problema, continue “se o receptor T1 tem à seção da perda de sinal” abaixo.

Se o receptor T1 tem a perda de sinal:

Siga estas etapas se o receptor T1 tem a perda de sinal:

  1. Certifique-se de que o cabo entre a porta da relação e o equipamento de fornecedor de serviço T1 (ou o equipamento de terminal T1) está conectado corretamente. Verifique para ver se o cabo é enganchado até as portas corretas. Corrija as conexões de cabo, se necessário.

  2. Verifique a integridade de cabo. Procure rupturas ou outras anormalidades físicas no cabo. Assegure-se de que os pinouts estejam ajustados corretamente. Caso 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. Ajuste o par de fios de recepção às linhas 1 & o grupo 2. o par transmissor às linhas 4 & 5.

    Os pinos em um jaque RJ-45 são numerados de 1 a 8. que o Pin 1 é o pino leftmost ao olhar o jaque com os pinos de metal que enfrentam o. Refira a figura abaixo.

    Figura 15-10: Cabo RJ-45

    /image/gif/paws/14149/h2936.gif

  4. Tentativa usando um cabo de rollover.

Execute o comando show controller t1 exec após cada etapa verificar se o controlador exibe quaisquer erros.

Verifique para ver se a linha reage do modo loopback da saída T1 do controlador da mostra. Uma linha deve reagir do modo loopback somente para propósitos testando.

Para desligar o laço de retorno, use o comando no loopback no modo de configuração de controle como mostrado abaixo:

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

Se o controlador indica quaisquer alarmes:

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

Nós discutiremos agora vários alarmes e o procedimento necessário corrigi-los.

Receba o sinal de indicação do alarme (AIS) (RX) (azul):

Um sinal de indicação do alarme (AIS) recebido significa que há um alarme que ocorre na linha a montante do equipamento conectado à porta.

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Se não, mude o formato do quadro no controlador para combinar isso da linha.

  2. Contacte seu provedor de serviços para verificar para ver se há a configuração incorreta dentro do telco.

Receba a indicação de alarme remoto (RX) (RAI) (amarelo):

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

  1. Insira um cabo de circuito fechado externo na porta. Para criar um plugue de loopback refira a seção “que cria um plugue de loopback,” mais tarde no capítulo.

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

    1. Verifique o cabeamento. Veja a seção “se o receptor T1 tem a perda de sinal” para mais informação.

    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. Veja a seção “se o receptor T1 tem a perda de sinal” para mais informação.

  5. Desligue e religue o roteador.

  6. Conecte a linha T1 a uma porta diferente. Configurar a porta com os mesmos ajustes que aquela da linha. Se o problema não persiste, a seguir a falha encontra-se com a uma porta:

    1. Reconecte a linha T1 para a porta original.

    2. Continuam “pesquisar defeitos à seção dos eventos do erro T1”.

      Se o problema persiste, então:

  7. Execute um teste de loop de hardware como descrito na seção “que executa o teste de plugue de loop de hardware.”

  8. Substitua a placa de controle T1.

  9. Continuam “pesquisar defeitos à seção dos eventos do erro T1”.

Transmissor que envia o alarme remoto (vermelho):

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

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Se não mude o formato do quadro no controlador para combinar isso 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. Contacte seu provedor de serviços.

Indicação de alarme remoto de Transmit(Tx) (RAI) (amarelo):

Um RAI transmitido na relação indica que a relação tem um problema com o sinal que esteja recebendo do equipamento 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. Transmitir RAI deve ser acompanhado de algum outro alarme que indica que a natureza do problema a porta T1/cartão está tendo com o sinal do equipamento extremidade oposta.

Pesquise defeitos essa circunstância para resolver transmitir RAI.

Transmit(Tx) AIS (azul):

Siga as etapas abaixo para corrigir transmitir (Tx) AIS (azul).

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Se não, corrija a má combinação.

  2. Desligue e religue o roteador.

  3. Conecte a linha T1 a uma porta diferente. Configurar a porta com os mesmos ajustes que aquela da linha.

  4. Execute um teste de loop de hardware como descrito na seção “que executa o teste de plugue de loop de hardware.”

  5. Substitua a placa de controle T1.

  6. Continuam “pesquisar defeitos à seção dos eventos do erro T1”.

Pesquisando defeitos os eventos do erro T1

O comando show controller t1 exec fornece os Mensagens de Erro que podem ser usados para pesquisar defeitos problemas. Nós discutiremos agora diversos Mensagens de Erro e como corrigir os erros.

Para ver se os contadores de erros 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 ajustes da moldação e da codificação de linha. Um bom princípio básico é usar a codificação de linha B8ZS com enquadramento ESF e a codificação de linha AMI com moldação do SF.

O contador de Seg de Lapso está aumentando:

A presença de deslizamentos em uma linha T1 indica um problema de relógio. O fornecedor T1 (telco) fornecerá cronometrar a qual o Customer Premises Equipment (CPE) deve ser sincronizado.

  1. Verifique que o origem do relógio está derivado da rede. Isto pode ser verificado procurando o origem do relógio é linha preliminar.

    Nota: Se há T1s múltiplo em um servidor de acesso, simplesmente um pode ser o preliminar, quando o outro T1s derivar o pulso de disparo do preliminar. Nesse caso verifique que a linha T1 designada como o origem de tempo principal está configurada corretamente.

  2. Ajuste o origem do relógio T1 corretamente do modo de configuração de controle.

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

Os segundos de perda de quadro contrários estão aumentando:

Siga estas etapas quando os segundos de perda de quadro contrários estão aumentando.

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Você pode verificar este procurando o quadro é {ESF|SF} na saída T1 do controlador da mostra.

  2. Para mudar o formato do quadro use a moldação {SF | Comando ESF} no modo de configuração de controle como mostrado abaixo:

    maui-nas-03(config-controlle)#framing esf
    
  3. Mude a linha buildout usando o cablelength {por muito tempo | } comando curto.

Consulte seu provedor de serviços e a referência de comandos do ½ do ¿  de Cisco IOSï para detalhes em ajustes 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 estão aumentando.

  1. Verifique para ver se a codificação de linha configurada na porta combina o formato do quadro da linha. Você pode verificar este procurando o código de linha é {B8ZS|AMI} na saída T1 do controlador da mostra.

  2. Para mudar a codificação de linha, use o linecode {ami | comando b8zs} no modo de configuração de controle como mostrado abaixo:

    maui-nas-03(config-controlle)#linecode b8zs
    
  3. Mude a linha buildout usando o cablelength {por muito tempo | } comando curto.

Consulte seu provedor de serviços e a referência de comandos do ½ do ¿  de Cisco IOSï para detalhes em ajustes do buildout.

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

Use o comando show running-config ver se o tipo de switch ISDN e o pri-group timeslots são configurados corretamente. Contacte seu provedor de serviços para valores corretos.

Para mudar o tipo de switch ISDN e o PRI-grupo:

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 erros não aumentam mas o problema persiste, verifique que o canal de sinalização é ascendente e configurado corretamente.

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

  2. Verifique para ver se a relação está acima. 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. Assegure-se de que o encapsulamento seja PPP. Se a relação não está usando o PPP a seguir usa o comando encapsulation ppp no modo de configuração da interface corrigi-lo.

    maui-nas-03(config-if)#encapsulation ppp
    
  4. Verifique para ver se o laço de retorno é ajustado. 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 persiste, contacte seu provedor de serviços ou tac Cisco

Pesquisando defeitos um PRI

Sempre que pesquisando defeitos um PRI, você precisa de verificar para ver se o T1 está sendo executado limpamente no ambas as extremidades. Se os problemas do Layer 1 foram resolvidos, como descrito acima, considere a camada 2 e a camada 3 problemas.

Pesquisa de defeitos usando o comando show isdn status

O comando show isdn status é usado indicar um instantâneo de todas as interfaces. Indica o estado das camadas 1, 2 e 3.

  1. Verifique que o Layer 1 é ativo.

    O estado do Layer 1 deve sempre dizer o ACTIVE a menos que o T1 estiver para baixo. Se o status de ISDN da mostra indica que o Layer 1 ESTÁ DESATIVADO, a seguir há um problema com a conectividade física na linha T1. Veja que a seção “é o T1 do controlador T1 para baixo?”

    Igualmente verifique que o T1 não está administrativamente para baixo. Use o comando no shutdown trazer acima o controlador T1.

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

O estado desejado da camada 2 é Multiple_Frame_Established, que indica que nós somos quadros da camada de troca 2 e terminamos a iniciação da camada 2.

Se a camada 2 não é Multiple_Frame_Established, use o comando show controller t1 exec diagnosticar o problema. Refira o Troubleshooting usando a seção de comando show controller t1 neste capítulo.

Desde que o status de ISDN da mostra é um instantâneo do status atual, é possível que a camada 2 está saltando para cima e para baixo apesar de indicar Mulitple_Frame_Established. O uso debuga isdn q921 para verificar que a camada 2 é estável.

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

Assegure-se de que você esteja configurado para ver debugue mensagens usando o comando logging console or terminal monitor como necessário.

Nota: Em um ambiente de produção, verifique que o logging de console está desabilitado. Inscreva o comando show logging. Se registrar é permitido, o servidor de acesso pode intermitentemente congelar-se acima assim que a porta de Console obtiver sobrecarregada com os mensagens de registro. Inscreva o comando no logging console.

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

  1. Verifique que a camada 2 é estável.

    Você deve observar os resultados do debug para as mensagens que indicam que o serviço não está saltando para cima e para baixo. Se você vê os seguintes tipos de resultados do debug, 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 parece ser estável, veja “pesquisando defeitos os eventos do erro T1,” mais cedo neste capítulo.

  2. Verifique que você está vendo que somente os mensagens sapi em transmitem (TX) e receba os lados (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 que você não está vendo mensagens SABME, que indica que a camada 2 está tentando reinitialize. Isto é visto geralmente quando nós estamos transmitindo as solicitações de apuração (RRp) e não estamos obtendo uma resposta do interruptor (RRf) ou vice-versa. Está abaixo o exemplo de mensagens de 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ê está vendo mensagens SABME, use o comando show running-config ver se o tipo de switch ISDN e o pri-group timeslots são configurados corretamente. Contacte seu provedor de serviços para valores corretos.

    Para mudar o tipo de switch ISDN e o PRI-grupo:

    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 que o canal D é acima de usar o comando show interfaces serial x:23.

    Se o canal D não está acima, a seguir comando no shutdown do uso trazê-lo acima:

    maui-nas-03(config)#interface serial 0:23
    maui-nas-03(config-if)#no shutdown
    
  5. Verifique para ver 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 para ver se a relação reage do modo loopback. Para a operação normal, a relação não deve reagir do modo loopback.

    maui-nas-03(config-if)#no loopback
    
  7. Desligue e religue o roteador.

  8. Se o problema persiste, contacte seu provedor de serviços ou o tac Cisco.

Executando o teste de plugue de loop de hardware

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

Crie um plugue de loopback:

Siga estas etapas para criar um plugue de loopback.

  1. Use cortadores de fio para cortar um cabo RJ-45 ou RJ-48 de trabalho de modo que haja cinco polegadas do cabo e o conector lhe seja anexado.

  2. Retire os fios.

  3. Torça junto os fios dos pinos 1 e 4.

  4. Torça junto os fios dos pinos 2 e 5.

Os pinos em um jaque RJ-45/48 são numerados de 1 a 8. que o Pin 1 é o pino leftmost ao olhar o jaque com os pinos de metal que enfrentam o.

Executando o teste de plugue de loopback

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

  1. Introduza a tomada na porta T1 na pergunta.

  2. Salvar sua configuração de roteador usando o comando write memory.

    maui-nas-03#write memory
    Building configuration...
    [OK]
  3. Ajuste o encapsulamento ao 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 ver se a relação tem um endereço IP de Um ou Mais Servidores Cisco ICM NT.

    Se a relação não tem um endereço IP de Um ou Mais Servidores Cisco ICM NT, obtenha um endereço único e atribua-o à relação com uma máscara de sub-rede de 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 ping extendido como descrito na seção " usando testes de ping extenso, " mais cedo neste capítulo.

Pesquisando defeitos o E1

Esta seção descreve as técnicas e os procedimentos para pesquisar defeitos os circuitos E1 para clientes de discagem de entrada.

Pesquisa de defeitos usando o comando show controller e1

Este comando indica o status de controle que é específico ao hardware de controle. A informação indicada é geralmente útil para as tarefas de diagnóstico executadas por pessoais de suporte técnico somente.

O NMP ou o MIP podem perguntar os adaptadores de porta para determinar seu status atual. Emita um comando show controller e1 indicar estatísticas sobre o link E1. Se você especifica um entalhe e um número de porta, as estatísticas para cada período 15 minuto estarão indicadas.

O comando show controller e1 exec fornece a informação para pesquisar defeitos logicamente problemas da camada física e da camada de link de dados. Esta seção descreve como pesquisar defeitos logicamente usando o comando show controller e1.

A maioria de erros E1 são causados por linhas desconfigurada. Assegure-se de que a codificação de linha, a moldação, o origem do relógio e a terminação de linha (equilibrados ou desequilibrados) estejam configurados de acordo com o que o provedor de serviços recomenda.

mostre condições do E1 do controlador

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

  • Administrativamente fora do ar

  • Down

  • Para cima

Está o controlador E1 administrativamente para baixo?

O controlador fica administrativamente desativado quando é encerrado manualmente. Você deve reiniciar o controlador para corrigir este 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 formação?

Se a linha E1 não está acima, verifique para ver que a configuração de linha está correta e combina os ajustes da extremidade remota.

  1. Verifique a moldação da linha e da extremidade remota. Para as linhas E1, a moldação é 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 para ver se a terminação de linha é ajustada para equilibrado ou desequilibrado (75-ohm ou 120-ohm).

Consulte seu provedor de serviços para obter mais informações sobre das configurações correta. Faça todas as mudanças como necessário aos dispositivos finais locais ou remotos.

Se o controlador E1 e a linha não estão acima, verifique para ver se um dos seguintes mensagens aparece no E1 EXEC do controlador da mostra output:

  • O receptor tem a perda do frame

  • O receptor tem a perda de sinal

Se o receptor E1 tem a perda do frame:

Siga estas etapas se o receptor E1 tem a perda do frame.

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Você pode verificar o formato do quadro do controlador da configuração running ou da saída do comando show controller e1.

    Para mudar o formato do quadro, use o {CRC4 de moldação | nenhum comando CRC4} no modo de configuração de controle 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 isto não fixa o problema, continue “se o receptor E1 tem à seção da perda de sinal” abaixo.

  3. Verifique o formato do quadro na extremidade remota.

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

Se o receptor E1 tem a perda de sinal:

Siga estas etapas se o receptor E1 tem a perda de sinal

  1. Certifique-se de que o cabo entre a porta da relação e o equipamento do provedor de serviços E1 (ou o equipamento de terminal E1) está conectado corretamente. Verifique para ver se o cabo é enganchado até as portas corretas. Corrija as conexões de cabo, se necessário.

  2. Verifique a integridade de cabo. Procure rupturas ou outras anormalidades físicas no cabo. Assegure-se de que os pinouts estejam ajustados corretamente. Caso 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. Ajuste o par de fios de recepção às linhas 1 & o grupo 2. o par transmissor às linhas 4 & 5.

    Os pinos em um jaque RJ-48 são numerados de 1 a 8. que o Pin 1 é o pino leftmost ao olhar o jaque com os pinos de metal que enfrentam o. Refira a seguinte figura para mais informação.

    Figura 15-11: Cabo RJ-45

    /image/gif/paws/14149/h2936.gif

  4. Tentativa usando um cabo de rollover.

  5. Verifique para ver se há uns erros do bloco à distância. Em caso afirmativo, o problema existe com a ligação da recepção na extremidade local. Contacte o TAC para mais auxílio.

Execute o comando show controller e1 exec após cada etapa verificar se o controlador exibe quaisquer erros.

Se a linha reage do modo loopback:

Verifique para ver se a linha reage do modo loopback da saída do E1 do controlador da mostra. Uma linha deve reagir do modo loopback somente para propósitos testando.

Para desligar o laço de retorno, use o comando no loopback no modo de configuração de controle como mostrado abaixo:

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

Se o controlador indica quaisquer alarmes:

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

Nós discutiremos agora vários alarmes e o procedimento necessário corrigi-los.

O receptor (RX) tem o alarme remoto:

Um alarme remoto recebido significa que há um alarme que ocorre na linha a montante do equipamento conectado à porta.

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Se não, mude o formato do quadro no controlador para combinar isso da linha.

  2. Verifique o ajuste da codificação de linha no equipamento remoto-final. Contacte seu provedor de serviços para as configurações correta. Corrija todas as configurações incorretas como necessário.

  3. Insira um cabo de circuito fechado externo na porta. Para criar um plugue de loopback, veja a seção “executar o teste de plugue de loop de hardware,” mais cedo no capítulo.

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

    1. Verifique o cabeamento. Refira a seção “se o receptor E1 tem a perda de sinal” para mais informação.

    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. Veja a seção “se o receptor E1 tem a perda de sinal” para mais informação.

  7. Desligue e religue o roteador.

  8. Conecte a linha E1 a uma porta diferente. Configurar a porta com os mesmos ajustes que aquela da linha. Se o problema não persiste, a seguir a falha encontra-se com a uma porta:

    1. Reconecte a linha E1 à porta original.

    2. Continuam “pesquisar defeitos à seção dos eventos do erro E1”.

      Se o problema persiste, então:

  9. Execute um teste de loop de hardware como descrito na seção “que executa o teste de plugue de loop de hardware”

  10. Substitua o cartão de controlador E1.

  11. Continuam “pesquisar defeitos à seção dos eventos do erro E1”.

Transmissor que envia o alarme remoto (vermelho):

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

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Se não mude o formato do quadro no controlador para combinar isso 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, veja a seção “executar o teste de plugue de loop de hardware,” mais cedo no capítulo.

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

    1. Verifique o cabeamento. Refira a seção “se o receptor E1 tem a perda de sinal” para mais informação.

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

  5. Conecte a linha E1 a uma porta diferente. Configurar a porta com os mesmos ajustes que aquela da linha. Se o problema não persiste, a seguir a falha encontra-se com a uma porta.

    1. Reconecte a linha E1 à porta original.

    2. Continuam “pesquisar defeitos à seção dos eventos do erro E1”.

      Se o problema persiste, então:

  6. Execute um teste de loop de hardware como descrito na seção “que executa o teste de plugue de loop de hardware.”

  7. Substitua o cartão de controlador E1.

  8. Continuam “pesquisar defeitos à seção dos eventos do erro E1”.

  9. Contacte seu provedor de serviços.

Pesquisando defeitos os eventos do erro E1

O comando show controller e1 exec fornece os Mensagens de Erro que podem ser usados para pesquisar defeitos problemas. Nós discutiremos agora diversos Mensagens de Erro e como corrigir os erros.

Para ver se os contadores de erros 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 ajustes da moldação e da codificação de linha.

O contador de Seg de Lapso está aumentando:

A presença de deslizamentos nas linhas E1 indica um problema de relógio. O fornecedor E1 (telco) fornecerá cronometrar a qual o Customer Premises Equipment (CPE) deve ser sincronizado.

  1. Verifique que o origem do relógio está derivado da rede. Isto pode ser verificado procurando o origem do relógio é linha preliminar.

    Nota: Se há E1 múltiplos em um servidor de acesso, simplesmente um pode ser o preliminar, quando os outros E1 derivarem o pulso de disparo do preliminar. Nesse caso, verifique que a linha E1 designada como o origem de tempo principal está configurada corretamente.

  2. Ajuste o origem do relógio E1 corretamente do modo de configuração de controle.

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

Os segundos de perda de quadro contrários estão aumentando:

Siga estas etapas quando os segundos de perda de quadro contrários estão aumentando:

  1. Verifique para ver se o formato do quadro configurado na porta combina o formato do quadro da linha. Você pode verificar este procurando o quadro é {CRC4|no CRC4} na saída do E1 do controlador da mostra.

  2. Para mudar o formato do quadro use a moldação {CRC4 | nenhum comando CRC4} no modo de configuração de controle 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 estão aumentando.

  1. Verifique para ver se a codificação de linha configurada na porta combina o formato do quadro da linha. Você pode verificar este procurando o código de linha é {AMI/HDB3} na saída do E1 do controlador da mostra.

  2. Para mudar a codificação de linha, use o linecode {ami | comando hdb3} no modo de configuração de controle como mostrado abaixo:

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

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

Use o comando show running-config verificar se o tipo de switch ISDN e o pri-group timeslots são configurados corretamente. Contacte seu provedor de serviços para valores corretos.

Para mudar o tipo de switch ISDN e o PRI-grupo:

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 erros não aumentam mas o problema persiste, verifique que o canal de sinalização é ascendente e configurado corretamente.

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

  2. Verifique para ver se a relação está acima. 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. Assegure-se de que o encapsulamento seja PPP. Se a relação não está usando o PPP, a seguir use o comando encapsulation ppp no modo de configuração da interface corrigi-lo.

    maui-nas-03(config-if)#encapsulation ppp
    
  4. Verifique para ver se o laço de retorno é ajustado. 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 persiste, contacte seu provedor de serviços ou o tac Cisco.

Pesquisando defeitos um PRI

Ao pesquisar defeitos um PRI, você precisa de determinar se o E1 está sendo executado limpamente no ambas as extremidades. Se os problemas do Layer 1 foram resolvidos como descrito acima, considere a camada 2 e a camada 3 problemas.

Pesquisa de defeitos usando o comando show isdn status

O comando show isdn status é usado indicar um instantâneo de todas as interfaces. Indica o estado das camadas 1, 2 e 3.

  1. Verifique que o Layer 1 é ativo.

    O estado do Layer 1 deve sempre dizer o ACTIVE a menos que o E1 estiver para baixo.

    Se o status de ISDN da mostra indica que o Layer 1 ESTÁ DESATIVADO, a seguir há um problema com a conectividade física na linha E1. Veja que a seção “é o controlador E1 administrativamente para baixo?”

    Igualmente verifique que o E1 não está administrativamente para baixo. Use o comando no shutdown trazer acima o controlador E1.

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

O estado desejado da camada 2 é Multiple_Frame_Established, que indica que o protocolo de inicialização entre o switch ISDN e o dispositivo final esteve estabelecido e nós somos quadros da camada de troca 2.

Se a camada 2 não é Multiple_Frame_Established, use o comando show controller e1 exec diagnosticar o problema. Veja “Troubleshooting usando a seção do comando show controller e1” neste capítulo e “pesquisando defeitos na seção dos eventos do erro E1”.

Porque o status de ISDN da mostra é um instantâneo do status atual, é possível que a camada 2 está saltando para cima e para baixo apesar de indicar Mulitple_Frame_Established. Use o comando debug isdn q921 para verificar se a Camada 2 está estável.

Usar-se debuga q921

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

Assegure-se de que você esteja configurado para ver debugue mensagens usando o comando logging console or terminal monitor como necessário.

Nota: Em um ambiente de produção, verifique que o logging de console está desabilitado. Inscreva o comando show logging. Se registrar é permitido, o servidor de acesso pode intermitentemente congelar-se acima assim que a porta de Console obtiver sobrecarregada com os mensagens de registro. Inscreva o comando no logging console.

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

  1. Verifique que a camada 2 é estável. Você deve observar os resultados do debug para as mensagens que indicam que o serviço não está saltando para cima e para baixo. Se você vê os seguintes tipos de resultados do debug, 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 parece ser estável, veja “pesquisando defeitos os eventos do erro E1,” mais cedo neste capítulo.

  2. Verifique que você está vendo que somente os mensagens sapi em transmitem (TX) e receba os lados (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 que você não está vendo mensagens SABME, que indica que a camada 2 está tentando reinitialize. Isto é visto geralmente quando nós estamos transmitindo as solicitações de apuração (RRp) e não estamos obtendo uma resposta do interruptor (RRf) ou vice-versa. Está abaixo o exemplo de mensagens de SABME. Nós devemos obter uma resposta do switch ISDN para nossos 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ê está vendo mensagens SABME, use o comando show running-config verificar se o tipo de switch ISDN e o pri-group timeslots são configurados corretamente. Contacte seu provedor de serviços para valores corretos.

    Para mudar o tipo de switch ISDN e o PRI-grupo:

    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 que o canal D é acima de usar o comando show interfaces serial x:15.

    Se o canal D não está acima, a seguir use o comando no shutdown trazê-lo acima:

    maui-nas-03(config)#interface serial 0:15
    maui-nas-03(config-if)#no shutdown
    
  5. Verifique para ver se o encapsulamento é PPP. Se não use o comando encapsulation ppp ajustar o encapsulamento.

    maui-nas-03(config-if)#encapsulation ppp
    
  6. Verifique para ver se a relação reage do modo loopback. Para a operação normal, a relação não deve reagir do modo loopback.

    maui-nas-03(config-if)#no loopback
    
  7. Desligue e religue o roteador.

  8. Se o problema persiste, contacte seu provedor de serviços ou o tac Cisco.


Informações Relacionadas


Document ID: 14149