Troubleshooting da Conectividade de Tecnologia de Discagem – o DDR IOS Inicia a Chamada

Opções de download

  • PDF     (217.8 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (98.6 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (106.5 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:9 de julho de 2007
ID do documento:14954

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Este documento fornece métodos de identificação e solução de problemas de diferentes tipos de conexões de discagem e não se destina a ser lido do início ao fim. A estrutura é projetada para permitir que o leitor passe para as seções de interesse, cada uma delas variações no tema geral de solução de problemas de um caso específico.

Prerequisites

Requirements

Este documento abrange três cenários principais: antes de começar a solucionar o problema, determine que tipo de chamada está sendo tentada e vá para essa seção:

Componentes Utilizados

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

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

Histórico

A discagem é simplesmente a aplicação da rede telefônica pública comutada (PSTN) que transporta dados em nome do usuário final. Ele envolve um dispositivo CPE (Customer Premises Equipment, equipamento das instalações do cliente) que envia ao switch telefônico um número de telefone para o qual direcionar uma conexão. O AS3600, AS5200, AS5300 e AS5800 são exemplos de roteadores que têm a capacidade de executar uma PRI (Primary Rate Interface Interface Interface de Taxa Primária) junto com bancos de modems digitais. O AS2511, por outro lado, é um exemplo de um roteador que se comunica com modems externos.

O mercado de operadoras cresceu significativamente, e o mercado agora exige maiores densidades de modem. A resposta para essa necessidade é um grau maior de interoperação com o equipamento da companhia telefônica e o desenvolvimento do modem digital. Esse é um modem capaz de acessar diretamente a PSTN. Como resultado, já foram desenvolvidos modems CPE mais rápidos que aproveitam a clareza do sinal que os modems digitais desfrutam. O fato de que os modems digitais que se conectam à PSTN através de uma PRI ou BRI (Basic Rate Interface, Interface de Taxa Básica) podem transmitir dados a mais de 53k usando o padrão de comunicação V.90 atesta o sucesso da ideia.

Os primeiros servidores de acesso foram o AS2509 e o AS2511. O AS2509 poderia suportar 8 conexões de entrada usando modems externos, e o AS2511 poderia suportar 16. O AS5200 foi introduzido com 2 PRIs e poderia suportar 48 usuários usando modems digitais, e representou um grande salto em tecnologia. As densidades do modem aumentaram continuamente com o AS5300 suportando 4 e depois 8 PRIs. Finalmente, o AS5800 foi introduzido para atender às necessidades das instalações de classe de operadora que precisam lidar com dezenas de T1s de entrada e centenas de conexões de usuário.

Algumas tecnologias desatualizadas têm sido mencionadas em uma discussão histórica sobre a tecnologia do discador. 56Kflex é um padrão de modem de 56k mais antigo (pré-V.90) proposto pela Rockwell. A Cisco suporta a versão 1.1 do padrão 56Kflex em seus modems internos, mas recomenda a migração dos modems CPE para V.90 o mais rápido possível. Outra tecnologia desatualizada é o AS5100. O AS5100 era uma joint venture entre a Cisco e um fabricante de modem. O AS5100 foi criado como uma forma de aumentar a densidade do modem através do uso de placas de modem quádruplo. Ele envolveu um grupo de AS2511s construídos como placas inseridas em um backplane compartilhado por placas de modem quádruplo e uma placa T1 dupla.

Conventions

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

O DDR do Cisco IOS inicia a chamada

Enquanto a abordagem de solução de problemas para chamadas recebidas começa na parte inferior, a solução de problemas de uma conexão de saída começa na parte superior.

O fluxo geral de raciocínio se assemelha ao seguinte:

  1. O Roteamento de discagem por demanda (DDR) inicia uma chamada? (Uma resposta sim avança para a próxima pergunta.)

  2. Se for um modem assíncrono, os scripts de bate-papo emitem os comandos esperados?

  3. A chamada chega ao PSTN?

  4. A extremidade remota atende a chamada?

  5. A chamada é concluída?

  6. Os dados estão passando pelo link?

  7. A sessão está estabelecida? (PPP ou terminal)

Para ver se o discador está tentando fazer uma chamada para seu destino remoto, use o comando debug dialer events. Informações mais detalhadas podem ser obtidas do debug dialer packet, mas o comando debug dialer packet é intensivo em recursos e não deve ser usado em um sistema ocupado que tenha várias interfaces de discador operando.

A linha a seguir da saída debug dialer events para um pacote IP lista o nome da interface DDR e os endereços de origem e de destino do pacote: 

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

Se o tráfego não iniciar uma tentativa de discagem, o motivo mais comum é a configuração incorreta (uma das definições de tráfego interessante, o estado da interface do discador ou o roteamento).

Tabela 1: O tráfego não inicia uma tentativa de discagem

Possíveis causas Ações sugeridas
Faltam ou incorretas definições de "tráfego interessante"
  1. Usando o comando show running-config, verifique se a interface está configurada com um dialer-group e se há uma lista de discadores de nível global configurada com um número correspondente.
  2. Certifique-se de que o comando dialer-list esteja configurado para permitir um protocolo inteiro ou para permitir o tráfego correspondente a uma lista de acesso
  3. Verifique se a lista de acesso declara que os pacotes que passam pelo link são interessantes. Um teste útil é usar o comando exec privilegiado debug ip packet [list number] usando o número da lista de acesso pertinente. Em seguida, tente fazer ping ou enviar tráfego pelo link. Se os filtros de tráfego interessante tiverem sido definidos corretamente, você verá os pacotes na saída de depuração. Se não houver saída de depuração deste teste, a lista de acesso não corresponde aos pacotes.
Estado da interface Use o comando show interfaces <nome da interface> para garantir que a interface esteja no estado "up/up (spoofing)".
  • Interface no modo "standby"
Outra interface (primária) no roteador foi configurada para usar a interface do discador como uma interface de backup. Além disso, a interface primária não está em um estado de "down/down", que é necessário para retirar a interface do discador do modo de espera. Além disso, um atraso de backup deve ser configurado na interface primária, ou o comando backup interface nunca será executado. Para verificar se a interface do discador mudará de "standby" para "up/up (spoofing)", geralmente é necessário puxar o cabo da interface primária. Simplesmente desligar a interface primária com o comando de configuração shutdown não colocará a interface primária em "down/down", mas a colocará em "administratively down"? não é a mesma coisa. Além disso, se a conexão principal for via Frame Relay, a configuração do Frame Relay deverá ser feita em uma subinterface serial ponto-a-ponto, e a companhia telefônica deverá estar passando o bit "Ativo". Essa prática também é conhecida como "LMI (Local Management Interface, interface de gerenciamento local) de ponta a ponta".
  • A interface está "administrativamente inativa"
A interface do discador foi configurada com o comando shutdown. Esse também é o estado padrão de qualquer interface quando um roteador Cisco é inicializado pela primeira vez. Use o comando de configuração de interface no shutdown para remover esse impedimento.
Roteamento incorreto Emita o comando exec show ip route [a.b.c.d], onde a.b.c.d é o endereço da interface do discador do roteador remoto. Se ip unnumbered for usado no roteador remoto, use o endereço da interface listada no comando ip unnumbered. A saída deve mostrar uma rota para o endereço remoto através da interface do discador. Se não houver rota, verifique se as rotas estáticas ou estáticas flutuantes foram configuradas examinando a saída de show running-config. Se houver uma rota através de uma interface diferente da interface do discador, a implicação é que o DDR está sendo usado como um backup. Examine a configuração do roteador para verificar se as rotas estáticas ou flutuantes foram configuradas. A maneira mais segura de testar o roteamento, nesse caso, é desabilitar a conexão primária e executar o comando show ip route [a.b.c.d] para verificar se a rota apropriada foi instalada na tabela de roteamento.

Observação: se você tentar isso durante as operações da rede ao vivo, um evento de discagem poderá ser acionado. Esse tipo de teste é mais bem realizado durante os ciclos de manutenção programados.

Estabelecendo a chamada

Se o roteamento e os filtros de tráfego interessante estiverem corretos, uma chamada deve ser iniciada. Isso pode ser visto usando debug dialer events: 

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

Se a causa de discagem for vista, mas não for feita nenhuma tentativa de discagem, o motivo normal é um mapa de discador ou perfil de discador mal configurado.

Tabela 2: Chamada não efetuada

Possível problema Ações sugeridas
Mapa de discador mal configurado Use o comando show running-config para garantir que a interface de discagem esteja configurada com pelo menos uma instrução dialer map que aponte para o endereço do protocolo e o número chamado do local remoto.
Perfil de discador configurado incorretamente Use o comando show running-config para garantir que a interface do Discador esteja configurada com um comando dialer pool X e que uma interface do discador no roteador esteja configurada com um dialer pool-member X correspondente . Se os perfis de discador não estiverem configurados corretamente, você poderá ver uma mensagem de depuração como: 
Dialer1: Can't place call, no dialer pool set
Verifique se uma string de discador está configurada.

Em seguida, identifique o tipo de mídia que está sendo usada:

DDR de modem assíncrono externo

  1. Para identificar um DDR de modem assíncrono externo, use os seguintes comandos e tente fazer uma chamada: 

    router# debug modem
router# debug chat line

  2. Para chamadas de modem, um script de bate-papo deve ser executado para que a chamada continue. Para o DDR baseado em mapa de discador, o script de bate-papo é chamado pelo parâmetro modem-script em um comando dialer map. Se o DDR for baseado no perfil do discador, isso será feito pelo comando script dialer, configurado na linha TTY. Ambos os métodos dependem de um script de bate-papo existente na configuração global do roteador, por exemplo: 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Em ambos os eventos, o comando para exibir a atividade do script de bate-papo é debug chat. Se a sequência de discagem (ou seja, o número do telefone) usada no dialer map ou dialer string fosse 5551212, a saída de depuração pareceria com a seguinte: 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Certifique-se de que o script de bate-papo tente a chamada esperada (ou seja, o número certo) com base na "string de envio". Se o script de bate-papo não tentar fazer a chamada esperada, verifique a configuração do script de bate-papo. Use o comando start-chat no prompt exec para iniciar o script de bate-papo manualmente.

  4. Vendo "Timeout expecting: CONNECT" pode descrever várias possibilidades diferentes:

    • Possibilidade 1: O modem local não está realmente fazendo a chamada. Verifique se o modem pode fazer uma chamada executando um telnet reverso para o modem e iniciando manualmente uma discagem. Se a extremidade remota não parecer estar respondendo, verifique se a chamada está sendo feita pelo modem de origem, ligando manualmente para um número local com o comando ATDT <number> e ouvindo o toque.

    • Possibilidade 2: O modem remoto não está respondendo. Teste isso discando o modem remoto com um telefone POTS comum. Tente isto:

      1. Verifique se o número de telefone chamado está correto. Utilize um monofone para ligar para o número receptor. Certifique-se de usar o mesmo cabo na parede que o modem estava usando. Se uma chamada manual puder acessar o modem assíncrono receptor, o modem de origem pode não estar funcionando corretamente. Verifique o modem e substitua-o conforme necessário.

      2. Se uma chamada manual não puder acessar o modem assíncrono de resposta, altere os cabos do telefone no modem receptor e tente um telefone regular na linha do modem receptor. Se a chamada puder ser recebida pelo telefone comum, é provável que haja um problema com o modem receptor.

      3. Se a chamada manual ainda não puder acessar o telefone regular na linha em questão, tente outra linha (em boas condições) na instalação de recebimento. Se isso se conectar OK, faça com que a telco verifique a linha telefônica indo para o modem receptor.

      4. Se esta for uma chamada de longa distância, faça com que o lado de origem tente outro número de longa distância (em boas condições). Se isso funcionar, a linha ou o recurso de recebimento podem não ser provisionados para receber chamadas de longa distância. Se a linha de origem não puder alcançar nenhum outro número de longa distância, ela pode não ter a longa distância habilitada. Tente os códigos 1010 para diferentes empresas de longa distância.

      5. Finalmente, tente outro número local (em boas condições) da linha de origem. Se a conexão ainda falhar, peça para a telco verificar a linha de origem.

    • Possibilidade 3: O número discado está incorreto. Verifique o número discando-o manualmente. Corrija a configuração, se necessário.

    • Possibilidade 4: O treinamento do modem está demorando muito ou o valor TIMEOUT está muito baixo. Tente aumentar o valor TIMEOUT no comando chat-script. Se o TIMEOUT já for de 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE ao qual ele está conectado. Falhas de treinamento também podem indicar um problema de circuito ou incompatibilidade de modem.

      Para chegar à parte inferior de um problema de modem individual, vá para o prompt AT no modem de origem com telnet reverso. Se possível, acesse o prompt AT do modem receptor também. A maioria dos modems indicará um toque para a sessão do terminal conectada à conexão DTE. Use ATM1 para que o modem envie sons para seu alto-falante para que as pessoas em cada extremidade possam ouvir o que está acontecendo na linha.

      A música tem barulho? Em caso afirmativo, limpe o circuito. Se os modems assíncronos não estiverem sendo treinados, ligue para o número e ouça a mensagem estática. Pode haver outros fatores interferindo no treinamento. Reverta o telnet para o modem assíncrono e debug.

  5. Se tudo estiver funcionando bem e você ainda não conseguir se conectar ao DDR do modem assíncrono CAS, tente a depuração do PPP. Use os comandos: 

    router# debug ppp negotiation
     router# debug ppp authentication

    Se o script de bate-papo for concluído com êxito, os modems serão conectados. Consulte a seção "Solução de problemas de PPP" no Capítulo 17 do Guia de Troubleshooting de Internetwork para saber o próximo passo na solução de problemas da conexão.

DDR de modem assíncrono CAS T1/E1

  1. Para identificar um DDR de modem assíncrono CAS T1/E1, use os seguintes comandos e tente fazer uma chamada:

    warning aviso:  A execução de depurações em um sistema ocupado pode travar o roteador sobrecarregando a CPU ou executando demais o buffer do console! 

    router# debug modem
router# debug chat or debug chat line n

router# debug modem csm
router# debug cas

    Observação: o comando debug cas está disponível nas plataformas Cisco AS5200 e AS5300 executando o Cisco IOS? Software versão 12.0(7)T e posterior. Em versões anteriores do IOS, o serviço de comando interno teria que ser inserido no nível principal da configuração do roteador e o modem-mgmt csm debug-rbs precisaria ser inserido no prompt exec. A depuração no Cisco AS5800 exige a conexão com a placa de tronco. (Use modem-mgmt csm no-debug-rbs para desativar a depuração.)

  2. Para chamadas de modem, um script de bate-papo deve ser executado para que a chamada continue. Para o DDR baseado em mapa de discador, o script de bate-papo é chamado pelo parâmetro modem-script em um comando dialer map. Se o DDR for baseado no perfil do discador, isso será feito pelo comando script dialer, configurado na linha TTY. Ambos os usos dependem de um script de bate-papo existente na configuração global do roteador, como: 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Em ambos os eventos, o comando para exibir a atividade do script de bate-papo é debug chat. Se a sequência de discagem (ou seja, o número do telefone) usada no dialer map ou dialer string fosse 5551212, a saída de depuração pareceria com a seguinte: 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Certifique-se de que o script de bate-papo tente a chamada esperada (ou seja, o número certo) com base na "string de envio". Se o script de bate-papo não tentar fazer a chamada esperada, verifique a configuração do script de bate-papo. Use o comando start-chat no prompt exec para iniciar o script de bate-papo manualmente.

  4. Vendo "Timeout expecting: CONNECT" pode descrever várias possibilidades diferentes:

    • Possibilidade 1: O modem local não está realmente fazendo a chamada. Verifique se o modem pode fazer uma chamada executando um telnet reverso para o modem e iniciando manualmente uma discagem. Se a extremidade remota não parecer estar respondendo, verifique se a chamada está sendo feita pelo modem chamando manualmente um número local com o comando ATDT<number> e ouvindo o toque.

      Para chamadas de saída via CAS T1 ou E1 e modems digitais integrados, grande parte da solução de problemas é semelhante a outra solução de problemas DDR. O mesmo se aplica a chamadas de modem integradas de saída por uma linha PRI. Os recursos exclusivos envolvidos em fazer uma chamada desta maneira exigem depuração especial no caso de uma falha de chamada.

      Quanto a outras situações de DDR, você deve garantir que uma tentativa de chamada seja solicitada. Use debug dialer events para esse fim. Consulte o IOS DDR neste artigo.

      Para que uma chamada possa ser feita, um modem deve ser alocado para a chamada. Para visualizar esse processo e a chamada subsequente, use os seguintes comandos debug: 

      router# debug modem
router# debug modem csm
router# debug cas

      Observação: o comando debug cas apareceu primeiro no IOS versão 12.0(7)T para AS5200 e AS5300. As versões anteriores do IOS usam um serviço interno de comando de configuração no nível do sistema junto com o comando exec modem-mgmt debug rbs:

      Ativando as depurações: 

      router#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#service internal 
router(config)#^Z 
router#modem-mgmt csm ? 
  debug-rbs     enable rbs debugging 
  no-debug-rbs  disable rbs debugging 
router#modem-mgmt csm debug-rbs 
router# 
neat msg at slot 0: debug-rbs is on 
neat msg at slot 0: special debug-rbs is on

      Desativando as depurações:

      router#modem-mgmt csm no-debug-rbs 
neat msg at slot 0: debug-rbs is off

      A depuração dessas informações em um AS5800 exige a conexão com a placa de tronco. A seguir está um exemplo de uma chamada de saída normal sobre um CAS T1 que é provisionado e configurado para FXS-Ground-Start: 

      Mica Modem(1/0): Rcvd Dial String(5551111) 
[Modem receives digits from chat script]

CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_CHANNEL_LOCK at slot 1 and port 0 

CSM_PROC_OC4_DIALING: 
CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 

Mica Modem(1/0): Configure(0x1) 

Mica Modem(1/0): Configure(0x2) 

Mica Modem(1/0): Configure(0x5) 

Mica Modem(1/0): Call Setup 

neat msg at slot 0: (0/2): Tx RING_GROUND 

Mica Modem(1/0): State Transition to Call Setup 

neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
[Telco switch goes OFFHOOK]

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_START_TX_TONE at slot 1 and port 0 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 

neat msg at slot 0: (0/2): 
Tx LOOP_CLOSURE [Now the router goes OFFHOOK]

Mica Modem(1/0): Rcvd Tone detected(2) 

Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 

Mica Modem(1/0): Rcvd Digits Generated 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
EVENT_CHANNEL_CONNECTED at slot 1 and port 0 

CSM_PROC_OC5_WAIT_FOR_CARRIER: 
CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 

Mica Modem(1/0): Link Initiate 

Mica Modem(1/0): State Transition to Connect 

Mica Modem(1/0): State Transition to Link 

Mica Modem(1/0): State Transition to Trainup 

Mica Modem(1/0): State Transition to EC Negotiating 

Mica Modem(1/0): State Transition to Steady State 

Mica Modem(1/0): State Transition to Steady State Speedshifting 

Mica Modem(1/0): State Transition to Steady State

      As depurações para T1s e E1s com outros tipos de sinalização são semelhantes.

      Chegar a este ponto na depuração indica que os modems de chamada e resposta treinaram e conectaram e que os protocolos de camada superior podem começar a negociar. Se um modem for alocado corretamente para a chamada de saída, mas a conexão não chegar até aqui, a T1 deverá ser examinada. Use o comando show controller t1/e1 para verificar se T1/E1 está funcionando. Consulte Troubleshooting de Linhas Seriais para obter uma explicação da saída show controller. Se T1/E1 não estiver funcionando corretamente, a solução de problemas T1/E1 é necessária.

    • Possibilidade 2: O modem remoto não está respondendo. Teste isso discando o modem remoto com um telefone comum. Tente isto:

      1. Verifique se o número de telefone chamado está correto. Utilize um monofone para ligar para o número receptor.

      2. Verifique se uma chamada manual consegue acessar o modem assíncrono de resposta. Se uma chamada manual puder acessar o modem assíncrono de resposta, a linha CAS pode não ser provisionada para permitir chamadas de voz de saída.

      3. Se uma chamada manual não puder acessar o modem assíncrono de resposta, altere os cabos do telefone no modem receptor e tente um telefone regular na linha do modem receptor. Se a chamada puder ser recebida pelo telefone comum, é provável que haja um problema com o modem receptor.

      4. Se a chamada manual ainda não puder acessar o telefone regular na linha em questão, tente outra linha (em boas condições) na instalação de recebimento. Se isso se conectar, faça com que a telco verifique se a linha telefônica está indo para o modem receptor.

      5. Se esta for uma chamada de longa distância, faça com que o lado de origem tente outro número de longa distância (em boas condições). Se isso funcionar, a linha ou o recurso de recebimento pode não ser provisionado para receber chamadas de longa distância. Se a linha de origem (CAS) não puder alcançar nenhum outro número de longa distância, ela pode não ter a longa distância habilitada. Tente os códigos 10-10 para diferentes empresas de longa distância.

      6. Finalmente, tente outro número local (em boas condições) da linha CAS de origem. Se a conexão ainda falhar, peça para a telco verificar o CAS.

    • Possibilidade 3: O número discado está incorreto. Verifique o número discando-o manualmente. Corrija a configuração, se necessário.

    • Possibilidade 4: O treinamento do modem está demorando muito ou o valor TIMEOUT está muito baixo. Tente aumentar o valor TIMEOUT no comando chat-script. Se o TIMEOUT já for de 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE ao qual ele está conectado. Falhas de treinamento também podem indicar um problema de circuito ou incompatibilidade de modem.

      Para chegar à parte inferior de um problema de modem individual, vá para o prompt AT no modem de origem com telnet reverso. Se possível, use reverse telnet para chegar ao prompt AT do modem receptor também. Use ATM1 para que o modem envie sons para seu alto-falante para que as pessoas em cada extremidade possam ouvir o que está acontecendo na linha.

      A música tem barulho? Em caso afirmativo, limpe o circuito. Se os modems assíncronos não estiverem sendo treinados, ligue para o número e ouça a mensagem estática. Pode haver outros fatores interferindo no treinamento. Reverta o telnet para o modem assíncrono e debug.

  5. Se tudo estiver funcionando bem e você ainda não conseguir se conectar ao DDR do modem assíncrono CAS, tente a depuração do PPP. Se o script de bate-papo for concluído com êxito e as depurações de PPP indicarem uma falha, consulte a seção "Troubleshooting de PPP" no Capítulo 17 do Internetwork Troubleshooting Guide.

DDR de modem assíncrono de PRI, DDR

  1. Para identificar um DDR de modem assíncrono PRI, use os seguintes comandos e tente fazer uma chamada:

    warning aviso:  A execução de depurações em um sistema ocupado pode travar o roteador sobrecarregando a CPU ou executando demais o buffer do console! 

    router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug isdn
router# debug ppp negotiate
router# debug ppp authenticate

  2. Para chamadas de modem, um script de bate-papo deve ser executado para que a chamada continue. Para o DDR baseado em mapa de discador, o script de bate-papo é chamado pelo parâmetro modem-script em um comando dialer map. Se o DDR for baseado no perfil do discador, isso será feito pelo comando script dialer, configurado na linha TTY. Ambos os métodos dependem de um script de bate-papo existente na configuração global do roteador, como: 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Em ambos os eventos, o comando para exibir a atividade do script de bate-papo é debug chat. Se a string de discagem (número de telefone) usada no dialer map ou dialer string fosse 5551212, a saída de depuração pareceria com a seguinte: 

    CHAT1: Attempting async line dialer script


CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Certifique-se de que o script de bate-papo tente a chamada esperada (o número correto) com base na "string de envio". Se o script de bate-papo não tentar fazer a chamada esperada, verifique a configuração do script de bate-papo. Use o comando start-chat no prompt exec para iniciar o script de bate-papo manualmente.

  4. Vendo "Timeout expecting: CONNECT" pode descrever várias possibilidades diferentes:

    • Possibilidade 1: O modem local não está realmente fazendo a chamada. Verifique se o modem pode fazer uma chamada executando um telnet reverso para o modem e iniciando manualmente uma discagem. Se a extremidade remota não parecer estar respondendo, verifique se a chamada está sendo feita pelo modem, ligando manualmente para um número local com o comando ATDT<number> e ouvindo o toque. Se nenhuma chamada sair, ative as depurações de ISDN. Após a primeira suspeita de uma falha de ISDN em uma BRI, sempre verifique a saída de show isdn status. Os principais aspectos a serem observados são que a Camada 1 deve ser Ativa e a Camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED. Consulte o Capítulo 16 do Guia de Troubleshooting de Internetwork, "Interpreting Show ISDN Status" para obter informações sobre como ler essa saída, bem como para obter medidas corretivas.

      Para chamadas ISDN de saída, debug isdn q931 e debug isdn events são as melhores ferramentas a serem usadas. Felizmente, a depuração de chamadas de saída é muito semelhante à depuração de chamadas de entrada. Uma chamada bem-sucedida normal pode ser semelhante a esta: 

      *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

      Observe que a mensagem CONNECT é o principal indicador de sucesso. Se um CONNECT não for recebido, você poderá ver uma mensagem DISCONNECT ou RELEASE_COMP (versão completa) seguida de um código de causa: 

      *Mar 20 22:11:03.212: ISDN SE0:23: 
RX <-RELEASE_COMP pd = 8 callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

      O valor da causa indica duas coisas:

      • O segundo byte do valor de 4 ou 6 bytes indica o ponto no caminho de chamada fim-a-fim do qual o DISCONNECT ou RELEASE_COMP foi recebido. Isso pode ajudá-lo a localizar o problema.

      • O terceiro e o quarto bytes indicam o motivo real da falha. Consulte a Tabela 9 para obter os significados dos diferentes valores.

    • Possibilidade 2: O modem remoto não está respondendo. Teste isso discando o modem remoto com um telefone comum. Tente isto:

      1. Verifique se o número de telefone chamado está correto. Utilize um monofone para ligar para o número receptor.

      2. Verifique se uma chamada manual consegue acessar o modem assíncrono de resposta. Se uma chamada manual puder acessar o modem assíncrono de resposta, a linha BRI pode não ser provisionada para permitir chamadas de voz de saída.

      3. Se uma chamada manual não puder acessar o modem assíncrono de resposta, altere os cabos do telefone no modem receptor e tente um telefone regular na linha do modem receptor. Se a chamada puder ser recebida pelo telefone comum, é provável que haja um problema com o modem receptor.

      4. Se a chamada manual ainda não puder acessar o telefone regular na linha em questão, tente outra linha (em boas condições) na instalação de recebimento. Se isso se conectar, faça com que a telco verifique se a linha telefônica está indo para o modem receptor.

      5. Se esta for uma chamada de longa distância, faça com que o lado de origem tente outro número de longa distância (em boas condições). Se isso funcionar, a linha ou o recurso de recebimento podem não ser provisionados para receber chamadas de longa distância. Se a linha de origem (BRI) não puder alcançar nenhum outro número de longa distância, ela pode não ter a longa distância habilitada. Tente os códigos 1010 para diferentes empresas de longa distância.

      6. Finalmente, tente outro número local (em boas condições) da linha BRI de origem. Se a conexão ainda falhar, peça para a telco verificar a BRI.

    • Possibilidade 3: O número discado está incorreto. Verifique o número discando-o manualmente. Corrija a configuração, se necessário.

    • Possibilidade 4: O treinamento do modem está demorando muito ou o valor TIMEOUT está muito baixo. Tente aumentar o valor TIMEOUT no comando chat-script. Se o TIMEOUT já for de 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE ao qual ele está conectado. Falhas de treinamento também podem indicar um problema de circuito ou incompatibilidade de modem.

      Para chegar à parte inferior de um problema de modem individual, vá para o prompt AT no modem de origem com telnet reverso. Se possível, use reverse telnet para chegar ao prompt AT do modem receptor também. Use ATM1 para que o modem envie sons para seu alto-falante para que as pessoas em cada extremidade possam ouvir o que está acontecendo na linha.

      A música tem barulho? Em caso afirmativo, limpe o circuito. Se os modems assíncronos não estiverem sendo treinados, ligue para o número e ouça a mensagem estática. Pode haver outros fatores interferindo no treinamento. Reverta o telnet para o modem assíncrono e debug.

  5. Se tudo estiver funcionando bem e você ainda não conseguir se conectar ao DDR do modem assíncrono BRI, tente a depuração do PPP. Se o script de bate-papo for concluído com êxito e as depurações de PPP indicarem uma falha, consulte a seção "Troubleshooting de PPP" no Capítulo 17 do Guia de Identificação e Solução de Problemas de Redes Interconectadas.

BRI Modem assíncrono DDR

Esse recurso funciona somente na plataforma Cisco 3640 usando o software Cisco IOS versão 12.0(3)T ou posterior. Requer uma revisão posterior do hardware do módulo de rede BRI. Isso não funcionará com uma placa de interface WAN (WIC).

  1. Verifique se o código do país está correto com o comando show modem. Utilize os seguintes comandos e tente fazer uma chamada:

    warning aviso:  A execução de depurações em um sistema ocupado pode travar o roteador sobrecarregando a CPU ou executando demais o buffer do console! 

    router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug bri
router# debug ppp negotiate
router# debug ppp authenticate

  2. Para chamadas de modem, um script de bate-papo deve ser executado para que a chamada continue. Para o DDR baseado em mapa de discador, o script de bate-papo é chamado pelo parâmetro modem-script em um comando dialer map. Se o DDR for baseado no perfil do discador, isso será feito pelo comando script dialer, configurado na linha TTY. Ambos os usos dependem de um script de bate-papo existente na configuração global do roteador, como: 

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

    Em ambos os eventos, o comando para exibir a atividade do script de bate-papo é debug chat. Se a string de discagem (número de telefone) usada no dialer map ou dialer string fosse 5551212, a saída de depuração pareceria com a seguinte: 

    CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none
CHAT1: process started
CHAT1: Asserting DTR
CHAT1: Chat script callout started
CHAT1: Sending string: AT
CHAT1: Expecting string: OK
CHAT1: Completed match for expect: OK
CHAT1: Sending string: atdt5551212
CHAT1: Expecting string: CONNECT
CHAT1: Completed match for expect: CONNECT
CHAT1: Chat script callout finished, status = Success

  3. Certifique-se de que o script de bate-papo tente a chamada esperada (o número correto) com base na "string de envio". Se o script de bate-papo não tentar fazer a chamada esperada, verifique a configuração do script de bate-papo. Use o comando start-chat no prompt exec para iniciar o script de bate-papo manualmente.

  4. Vendo "Timeout expecting: CONNECT" pode descrever várias possibilidades diferentes:

    • Possibilidade 1: O modem local não está realmente fazendo a chamada. Verifique se o modem pode fazer uma chamada executando um telnet reverso para o modem e iniciando manualmente uma discagem. Se a extremidade remota não parecer estar respondendo, verifique se a chamada está sendo feita pelo modem, ligando manualmente para um número local com o comando ATDT<number> e ouvindo o toque. Se nenhuma chamada sair, ative as depurações de ISDN. Após a primeira suspeita de uma falha de ISDN em uma BRI, sempre verifique a saída de show isdn status. Os principais aspectos a serem observados são que a Camada 1 deve ser Ativa e a Camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED . Consulte o Capítulo 16 do Internetwork Troubleshooting Guide, "Interpreting Show ISDN Status" para obter informações sobre como ler essa saída e as medidas corretivas.

      Para chamadas ISDN de saída, debug isdn q931 e debug isdn events são as melhores ferramentas a serem usadas. Felizmente, a depuração de chamadas de saída é muito semelhante à depuração de chamadas de entrada. Uma chamada bem-sucedida normal pode ser semelhante a esta: 

      *Mar 20 21:07:45.025: ISDN BR0: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

      Observe que a mensagem CONNECT é o principal indicador de sucesso. Se um CONNECT não for recebido, você poderá ver uma mensagem DISCONNECT ou RELEASE_COMP (versão completa) seguida de um código de causa: 

      *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

      O valor da causa indica duas coisas.

      • O segundo byte do valor de 4 ou 6 bytes indica o ponto no caminho de chamada fim-a-fim do qual o DISCONNECT ou RELEASE_COMP foi recebido. Isso pode ajudá-lo a localizar o problema.

      • O terceiro e o quarto bytes indicam o motivo real da falha. Consulte a Tabela 9 para obter os significados dos diferentes valores.

    • Possibilidade 2: O modem remoto não está respondendo. Teste isso discando o modem remoto com um telefone comum. Tente isto:

      1. Verifique se o número de telefone chamado está correto. Utilize um monofone para ligar para o número receptor.

      2. Verifique se uma chamada manual consegue acessar o modem assíncrono de resposta. Se uma chamada manual puder acessar o modem assíncrono de resposta, a linha BRI pode não ser provisionada para permitir chamadas de voz de saída.

      3. Se uma chamada manual não puder acessar o modem assíncrono de resposta, altere os cabos do telefone no modem receptor e tente um telefone regular na linha do modem receptor. Se a chamada puder ser recebida pelo telefone comum, é provável que haja um problema com o modem receptor.

      4. Se a chamada manual ainda não puder acessar o telefone regular na linha em questão, tente outra linha (em boas condições) na instalação de recebimento. Se isso se conectar, faça com que a telco verifique se a linha telefônica está indo para o modem receptor.

      5. Se esta for uma chamada de longa distância, faça com que o lado de origem tente outro número de longa distância (em boas condições). Se isso funcionar, a linha ou o recurso de recebimento podem não ser provisionados para receber chamadas de longa distância. Se a linha de origem (BRI) não puder alcançar nenhum outro número de longa distância, ela pode não ter a longa distância habilitada. Tente os códigos 10-10 para diferentes empresas de longa distância.

      6. Finalmente, tente outro número local (em boas condições) da linha BRI de origem. Se a conexão ainda falhar, peça para a telco verificar a BRI.

    • Possibilidade 3: O número discado está incorreto. Verifique o número discando-o manualmente. Corrija a configuração, se necessário.

    • Possibilidade 4: O treinamento do modem está demorando muito ou o valor TIMEOUT está muito baixo. Tente aumentar o valor TIMEOUT no comando chat-script. Se o TIMEOUT já for de 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE ao qual ele está conectado. Falhas de treinamento também podem indicar um problema de circuito ou incompatibilidade de modem.

      Para chegar à parte inferior de um problema de modem individual, vá para o prompt AT no modem de origem com telnet reverso. Se possível, use reverse telnet para chegar ao prompt AT do modem receptor também. Use ATM1 para que o modem envie sons para seu alto-falante para que as pessoas em cada extremidade possam ouvir o que está acontecendo na linha.

      A música tem barulho? Em caso afirmativo, limpe o circuito. Se os modems assíncronos não estiverem sendo treinados, ligue para o número e ouça a mensagem estática. Pode haver outros fatores interferindo no treinamento. Reverta o telnet para o modem assíncrono e debug.

  5. Se tudo estiver funcionando bem e você ainda não conseguir se conectar ao DDR do modem assíncrono BRI, tente a depuração do PPP. Se o script de bate-papo for concluído com êxito e as depurações de PPP indicarem uma falha, consulte a seção "Troubleshooting de PPP" no Capítulo 17 do Guia de Identificação e Solução de Problemas de Redes Interconectadas.

PRI ISDN DDR

  1. Após a primeira suspeita de uma falha de ISDN em uma PRI, sempre verifique a saída de show isdn status. Os principais aspectos a serem observados são que a Camada 1 deve estar Ativa e a Camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED. Consulte o Capítulo 16 do Internetwork Troubleshooting Guide, "Interpreting Show ISDN Status" para obter informações sobre como ler essa saída e as medidas corretivas.

    Para chamadas ISDN de saída, debug isdn q931 e debug isdn events são as melhores ferramentas a serem usadas. Felizmente, a depuração de chamadas de saída é muito semelhante à depuração de chamadas de entrada. Uma chamada bem-sucedida normal pode ser semelhante a esta: 

    *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
callref = 0xAC
*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

    Observe que a mensagem CONNECT é o principal indicador de sucesso. Se um CONNECT não for recebido, você poderá ver uma mensagem DISCONNECT ou RELEASE_COMP (versão completa) seguida de um código de causa: 

    *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    O valor da causa indica duas coisas.

    • O segundo byte do valor de 4 ou 6 bytes indica o ponto no caminho de chamada fim-a-fim do qual o DISCONNECT ou RELEASE_COMP foi recebido. Isso pode ajudá-lo a localizar o problema.

    • O terceiro e o quarto bytes indicam o motivo real da falha. Consulte a Tabela 9 para obter os significados dos diferentes valores.

    Observação: a impressão a seguir indica uma falha no protocolo mais alto:

    Cause i = 0x8090 - Normal call clearing

    A falha de autenticação PPP é um motivo típico. Ative debug ppp negotiation e debug ppp authentication antes de supor que a falha de conexão é necessariamente um problema ISDN.

  2. Se a mensagem ISDN CONNECT for exibida e as depurações PPP indicarem uma falha, consulte a seção "Troubleshooting PPP" no Capítulo 17 do Internetwork Troubleshooting Guide.

BRI ISDN DDR

  1. Após a primeira suspeita de uma falha de ISDN em uma BRI, sempre verifique a saída de show isdn status. Os principais aspectos a serem observados são que a Camada 1 deve estar Ativa e a Camada 2 deve estar em um estado MULTIPLE_FRAME_ESTABLISHED. Consulte o Capítulo 16 do Internetwork Troubleshooting Guide, "Interpreting Show ISDN Status" para obter informações sobre como ler essa saída e as medidas corretivas.

    Para chamadas ISDN de saída, debug isdn q931 e debug isdn events são as melhores ferramentas a serem usadas. Felizmente, a depuração de chamadas de saída é muito semelhante à depuração de chamadas de entrada. Uma chamada bem-sucedida normal pode ser semelhante a esta: 

    *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
*Mar 20 21:07:45.041:         Channel ID i = 0x83
*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
*Mar 20 21:07:45.145:         Channel ID i = 0x89
*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
        Channel ID i = 0x0101
*Mar 20 21:07:45.161:   -------------------
        Channel ID i = 0x89
*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

    Observe que a mensagem CONNECT é o principal indicador de sucesso. Se um CONNECT não for recebido, você poderá ver uma mensagem DISCONNECT ou RELEASE_COMP (versão completa) seguida de um código de causa: 

    *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
callref = 0x8F
*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

    O valor da causa indica duas coisas.

    • O segundo byte do valor de 4 ou 6 bytes indica o ponto no caminho de chamada fim-a-fim do qual o DISCONNECT ou RELEASE_COMP foi recebido. Isso pode ajudá-lo a localizar o problema.

    • O terceiro e o quarto bytes indicam o motivo real da falha. Consulte a Tabela 9 para obter os significados dos diferentes valores.

      Observação: a impressão a seguir indica uma falha no protocolo mais alto: 

      Cause i = 0x8090 - Normal call clearing

      A falha de autenticação PPP é um motivo típico. Ative debug ppp negotiation e debug ppp authentication antes de supor que a falha de conexão é necessariamente um problema ISDN.

  2. Se a mensagem ISDN CONNECT for exibida e as depurações PPP indicarem uma falha, consulte a seção "Troubleshooting PPP" no Capítulo 17 do Internetwork Troubleshooting Guide.

Informações Relacionadas

Histórico de revisões

Revisão Data de publicação Comentários
1.0
09-Jul-2007
Versão inicial

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco

Este documento se refere a estes produtos