WAN : T1/E1 e T3/E3

Troubleshooting de PRIs de T1

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (28 Julho 2013) | Inglês (5 Junho 2005) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Uso do Comando show isdn status
Uso do Comando debug isdn q921
      Troubleshooting Adicional
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Ao fazer o troubleshooting de uma Primary Rate Interface (PRI), certifique-se de que a T1 está funcionando adequadamente em ambas as extremidades. O motivo para isso é que a sinalização da PRI da ISDN ocorre sobre a camada física T1. Para verificar se a Camada 1 da T1 está funcionando corretamente, utilize o comando show controller t1. Certifique-se de que não haja erros em nenhum dos contadores. Certifique-se de que o framing, a codificação de linha e a fonte do relógio estejam configurados corretamente. Consulte o fluxograma Troubleshooting de T1 para obter mais informações. Entre em contato com seu provedor de serviços para obter as configurações corretas.

Quando os problemas da Camada 1 estiverem resolvidos e os contadores show controller t1 estiverem zerados, você poderá se concentrar nas Camadas 2 e 3 da sinalização da PRI da ISDN.

Dica: Você pode usar o comando clear counters para redefinir os contadores da T1. Quando os contadores forem zerados, você poderá observar facilmente se a linha T1 está apresentando erros. Contudo, lembre-se que esse comando limpa todos os outros contadores de show interface também. Exemplo:

maui-nas-03#clear counters
Clear "show interface" counters on all interfaces [confirm]
maui-nas-03#
*Apr 12 03:34:12.143: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

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. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documentos, consulte as Convenções de Dicas Técnicas da Cisco.

Uso do Comando show isdn status

O comando show isdn status é muito útil no troubleshooting de problemas de sinalização da ISDN. O comando show isdn status exibe um resumo do status atual de todas as interfaces da ISDN, além do status das Camadas 1, 2 e 3. Aqui está um exemplo de saída do comando show isdn status:

maui-nas-03#show isdn status
Global ISDN Switchtype = primary-5ess
ISDN Serial0:23 interface
        dsl 0, interface ISDN Switchtype = primary-5ess
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        5 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 5
        CCB:callid=7D5, sapi=0, ces=0, B-chan=9, calltype=DATA
        CCB:callid=7D6, sapi=0, ces=0, B-chan=10, calltype=DATA
        CCB:callid=7DA, sapi=0, ces=0, B-chan=11, calltype=DATA
        CCB:callid=7DE, sapi=0, ces=0, B-chan=1, calltype=DATA
        CCB:callid=7DF, sapi=0, ces=0, B-chan=2, calltype=DATA
    The Free Channel Mask:  0x807FF8FC
ISDN Serial1:23 interface
        dsl 1, interface ISDN Switchtype = primary-5ess
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Activated dsl 1 CCBs = 0
    The Free Channel Mask:  0x807FFFFF
    Total Allocated ISDN CCBs = 5

Execute estes passos para verificar o status das camadas:

  1. Verifique se a Camada 1 está no estado ACTIVE. O status da Camada 1 deve sempre ser ACTIVE, a menos que a T1 esteja inoperante.

    Se a saída do comando show isdn status indicar que a Camada 1 está DEACTIVATED, então existe um problema na conectividade física da linha T1. Caso a linha esteja fora do ar por motivos administrativos, use o comando no shutdown para reiniciar a interface.

  2. Verifique se a Camada 2 está no estado MULTIPLE_FRAME_ESTABLISHED. Esse é o estado necessário da Camada 2. Esse estado indica que o roteador recebeu uma mensagem ISDN SABME (Set Asynchronous Balanced Mode Extended) e respondeu com um frame UA (Unnumbered Acknowledge) para a sincronização com o switch da operadora. Além disso, deve haver uma troca constante de frames da Camada 2 (Receiver Ready, RR) entre os dois dispositivos. Uma vez que isto ocorra, o roteador e o switch ISDN terão inicializado totalmente o protocolo ISDN da Camada 2. Para obter informações sobre como identificar as mensagens SABME e RR, consulte a seção Usando o Comando debug q921.

    Se a Camada 2 não estiver no estado MULTIPLE_FRAME_ESTABLISHED, use o comando debug isdn q921 para diagnosticar o problema.

    Adicionalmente, o comando show isdn status exibe um resumo dos status atuais. Assim, a Camada 2 pode oscilar entre ativa e inativa mesmo quando o estado MULTIPLE_FRAME_ESTABLISHED está indicado. Use o comando debug isdn q921 para garantir que a Camada 2 esteja estável.

    Nessa ocasião, use o comando show controllers t1 para verificar a T1 novamente, e certifique-se de que não haja erros. Se houver erros, consulte o fluxograma Troubleshooting de T1.

    No exemplo de saída de show isdn status, observe que a T1 0 (cujo canal D é o Serial 0:23) possui a Camada 1 como ACTIVE e a Camada 2 como MULTIPLE_FRAME_ESTABLISHED, indicando que o canal de sinalização está funcionando corretamente e está trocando frames da Camada 2 com o switch da operadora. O canal D (Serial1:23) da T1 1 possui a Camada 1 ACTIVE, mas a Camada 2 está TEI_ASSIGNED, indicando que a PRI não está trocando frames da Camada 2 com o switch. Use o comando show controller t1 x para verificar primeiro o circuito t1 da controladora, e veja se ele está limpo (ou seja, se não apresenta erros), antes de fazer o troubleshooting do problema da Camada 2 da ISDN com o comando debug isdn q921. Consulte o fluxograma Troubleshooting de T1 para obter mais informações.

Uso do Comando debug isdn q921

O comando debug é útil no troubleshooting de problemas de sinalização da Camada 2 da ISDN. O comando debug isdn q921 exibe procedimentos de acesso à Camada de enlace de dados (Camada 2) que estão ocorrendo no roteador no canal D. Esse comando pode indicar se o problema está no NAS, no switch da operadora ou na linha.

Use o comando logging console ou terminal monitor para garantir que você esteja preparado para ver as mensagens de depuração.

Nota: Em um ambiente de produção, use o comando show logging para garantir que o log do console esteja desabilitado. Se o log do console estiver habilitado, o servidor de acesso poderá interromper o trabalho de forma intermitente quando a porta do console estiver sobrecarregada de mensagens de log. Insira o comando no logging console para desabilitar o log na porta do console. Consulte Informações Importantes sobre Comandos de Depuração para obter mais informações.

Nota: Caso debug isdn q921 esteja ativo e você não receba nenhuma saída de depuração, verifique primeiro e certifique-se de ter ativado terminal monitor. Em seguida, tente redefinir a controladora ou o canal D para obter saídas de depuração. Você pode usar o comando clear controller t1 x ou clear interface serial x:23 para redefinir a linha.

Execute estes passos para garantir que os procedimentos de acesso à Camada de enlace de dados estejam sendo realizados no roteador no canal D:

  1. Verifique se a Camada 2 está estável. Para isso, observe as mensagens na saída de debug. Aqui está a saída do debug isdn q921 quando a controladora T1 sofre shutdown e no shutdown:

    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 linha oscilar entre ativa e inativa, uma saída similar a esta será exibida:

    %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
    %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
    %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed to up
    %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
    %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
    %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
  2. Se a Camada 2 estiver estável, o roteador e o switch devem iniciar a sincronização mútua. A mensagem Set Asynchronous Balanced Mode Extended (SABME) será exibida no visor. Essa mensagem indica que a Camada 2 está tentando inicializar com o outro lado. Ambos os lados podem enviar mensagens e tentar inicializar um ao outro. Se o roteador receber a mensagem SABME, ele deverá enviar de volta um frame Unnumbered Acknowledge (UAf). O roteador então altera o status da Camada 2 para MULTIPLE_FRAME_ESTABLISHED. Exemplo:

    *Apr 12 04:14:43.967: ISDN Se0:23: RX <- SABMEp c/r=1 sapi=0 tei=0
    
    *Apr 12 04:14:43.971: ISDN Se0:23: TX -> UAf c/r=1 sapi=0 tei=0
    
    

    Se o switch receber e reconhecer o frame UAf, os dois dispositivos serão sincronizados e keepalives periódicos de atividade serão trocados entre o roteador e o switch ISDN. Essas mensagens são da forma Receiver Ready (RRf e RRp). Esses keepalives de atividade são observados a cada dez segundos e garantem que os dois lados podem se comunicar. Por exemplo:

    *Apr 12 05:19:56.183: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
    
    *Apr 12 05:19:56.183: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
    *Apr 12 05:20:06.247: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
    
    *Apr 12 05:20:06.247: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
    *Apr 12 05:20:16.311: ISDN Se0:23: RX <- RRp sapi=0 tei=0 nr=18
    
    *Apr 12 05:20:16.311: ISDN Se0:23: TX -> RRf sapi=0 tei=0 nr=18
    
    

    Observe o TX e RX e a seta. TX indica que o roteador está transmitindo o sinal na direção do switch. RX significa que o roteador está recebendo o sinal do switch.

  3. Em algumas ocasiões, o canal D não é ativado corretamente e permanece no estado TEI_ASSIGNED, ou a Camada 2 oscila entre ativa e inativa. Isso pode ser causado por uma transmissão unidirecional ou pela perda de pacotes de keepalive. Assim que cada lado perde quatro keepalives consecutivos, ele tenta reinicializar o enlace da Camada 2. Para fazer isso, o lado reenvia a mensagem SABME e inicia todo o processo novamente. Nessa situação, você precisa descobrir se esses keepalives estão sendo efetivamente enviados pelo cabo e se um dos lados não responde aos keepalives ao recebê-los.

    Para isolar o problema, use os comandos debug isdn q921 e show interface serial x:23 e execute estes passos no roteador e junto ao provedor do serviço de T1 (operadora):

    1. Execute o comando show interface serial x:23 várias vezes e certifique-se de que o contador de saídas não incremente e que não haja perdas ou erros de entrada/saída.

    2. Crie um plugue de loopback T1 e conecte-o à porta T1 em que você deseja fazer o troubleshooting. A saída de debug isdn q921 deve indicar que o SABME foi enviado e que essa mensagem foi recebida.

      RX <- BAD FRAME(0x00017F)Line may be looped!

      Se nenhuma mensagem de depuração por exibida, execute um shutdown e um no shutdown na controladora T1 correspondente.

      A mensagem BAD FRAME indica que o roteador está operando corretamente. O roteador envia o pacote SABME. A mensagem é reenviada por loopback de volta ao roteador, pois o roteador recebe a mesma mensagem SABME que enviou. O roteador o marca como BAD FRAME e exibe a mensagem de erro. A mensagem de erro indica que a linha está provavelmente em loop. Esse é o comportamento esperado para o circuito em loop. Dessa forma, o problema é no switch ISDN da operadora ou no cabeamento do demarc até o switch da operadora.

      No entanto, caso a linha esteja em loopback e o roteador envie SABMEs mas não os receba de volta, isso pode significar que existe um problema com o plugue físico de loopback ou com a própria interface do roteador. Consulte Testes de Loopback de Plugues Físicos para Linhas T1/56K e verifique se você pode fazer um ping até o roteador a partir do mesmo roteador com o auxílio do teste de loopback de cabo físico. Se você não puder fazer o ping no roteador, pode haver um problema de hardware na controladora T1. Nesse caso, contate o TAC para obter assistência. Se você for capaz de fazer o ping no roteador, prossiga para o passo c.

    3. Após isolar e testar o roteador e as portas T1 e verificar se eles funcionam corretamente, contate a operadora para obter troubleshooting adicional.

      • Entre em contato com a operadora e pergunte por que o switch não responde aos keepalives. Peça também à operadora para verificar se eles enxergam as mensagens de keepalive ou qualquer mensagem da Camada 2 da ISDN proveniente do roteador.

      • Execute novamente o teste de loopback, mas, dessa vez, estenda o teste de loopback ao switch da operadora. Esse procedimento é descrito no documento Testes de Loopback de Plugues Físicos para Linhas T1/56K.

      • Consulte o técnico da operadora a fim de estabelecer um loop na linha e testar se o roteador ainda pode executar um ping em si mesmo.

      • Se o roteador não puder executar um ping em si mesmo, então deve haver um problema com o cabeamento do circuito em direção ao switch ISDN da operadora. Consulte Testes de Loopback de Plugues Físicos para Linhas T1/56K para obter mais informações.

      • Se o roteador conseguir efetuar um ping em si mesmo, o teste de loopback terá sido bem-sucedido. Desfaça a configuração de loopback e altere a configuração da controladora de channel-group para pri-group.

        maui-nas-03(config)#controller t1 0
        maui-nas-0(config-controller)#no channel-group 0
        maui-nas-0(config-controller)#pri-group timeslots 1-24
        
      • Execute um shutdown e um no shutdown na controladora e verifique se o roteador envia isto:

        ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0

        e recebe isto:

        RX <- BAD FRAME(0x00017F)Line may be looped!

        Se isso ocorrer, o roteador estará operando adequadamente e o caminho de transmissão e recepção até a operadora estará bom. O problema estará relacionado ao switch ISDN ou à rede ISDN. No entanto, se o roteador enviar:

        ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0

        e não receber:

        RX <- BAD FRAME(0x00017F)Line may be looped!

        entre em contato com o TAC para obter assistência adicional.

Troubleshooting Adicional

Após resolver todos os problemas da Camada 2 associados à PRI e confirmar que o hardware está operando corretamente, você deverá fazer o troubleshooting da Camada 3 da ISDN. Consulte Troubleshooting da Camada 3 da BRI ISDN Usando o Comando debug isdn q931 para obter mais informações.

Nota: Mesmo que o documento aborde o troubleshooting da Camada 3 das BRIs, você pode aplicar os mesmos conceitos ao troubleshooting da PRI da Camada 3. Você também pode consultar o documento Entendendo os Códigos de Causa de Desconexão de debug isdn q931 para interpretar a razão da desconexão da Camada 3.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 8131