Discar e acessar : Dial-on-Demand Routing (DDR)

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

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


Índice


Introdução

Este documento fornece métodos de pesquisar defeitos tipos de conexões de discagem diferentes e não é pretendido ser lido do início ao fim. A estrutura é projetada permitir que o leitor salte para a frente às seções do interesse, cada qual são variações no tema geral de Troubleshooting para um caso específico.

Pré-requisitos

Requisitos

Este capas de documento três cenários principais; antes que você comece a pesquisar defeitos, determine que tipo de atendimento está sendo tentado e vá a 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. 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.

Histórico

O Dialup é simplesmente o aplicativo da rede telefônica pública comutada (PSTN) que leva dados em nome do utilizador final. Envolve um dispositivo do Customer Premises Equipment (CPE) que envia ao switch de telefones um número de telefone a que para dirigir uma conexão. O AS3600, o AS5200, o AS5300, e o AS5800 são todos os exemplos de roteadores que têm a capacidade para executar uma relação da taxa principal (PRI) junto com bancos dos modens digitais. O AS2511, por outro lado, é um exemplo de um roteador que se comunique com os Modens externos.

O mercado de portadora cresceu significativamente, e o mercado exige agora umas densidades de modem mais altas. A resposta a esta necessidade é um grau de interoperation mais alto com o equipamento de companhia telefônica e o desenvolvimento do modem digital. Este é um modem que seja capaz do acesso digital direto ao PSTN. Em consequência, uns modens de CPE mais rápidos têm sido desenvolvidos agora que se aproveitassem da clareza de sinal que os modens digitais apreciam. O fato de que os modens digitais que conectam no PSTN com um PRI ou o Basic Rate Interface (BRI) podem transmitir dados em 53k excedente usando o padrão de comunicação V.90, atesta ao sucesso da ideia.

Os primeiros servidores de acesso eram o AS2509 e o AS2511. O AS2509 poderia apoiar 8 conexões recebidas usando Modens externos, e o AS2511 poderia apoiar 16. O AS5200 foi introduzido com 2 PRI e poderia apoiar 48 usuários que usam modens digitais, e representou um salto principal para a frente na tecnologia. As densidades de modem aumentaram firmemente com o AS5300 que apoiam 4 e então os 8 PRI. Finalmente, o AS5800 foi introduzido para encher as necessidades de instalações de classe de portadora que precisam de segurar o T1s das dezenas de entradas e as centenas de conexões do usuário.

Um par tecnologias ultrapassadas carregam mencionar em uma discussão histórica da tecnologia de discador. 56Kflex é (pre-V.90) um padrão de modem 56K mais velho que seja proposto por Rockwell. A Cisco suporta versão 1.1 do padrão 56Kflex em seus modens internos, mas recomenda migrar os modens de CPE ao V.90 o mais cedo possível. Uma outra tecnologia ultrapassada é o AS5100. O AS5100 era um junção temporária entre Cisco e um fabricante do modem. O AS5100 foi criado como uma maneira de aumentar a densidade de modem com o uso de placas de modem do quadrilátero. Envolveu um grupo de AS2511 construído como os cartões que introduziram em um backplane compartilhado por placas de modem do quadrilátero, e um cartão T1 duplo.

Convenções

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

Quando o abordagem de Troubleshooting para chamadas recebidas começar na parte inferior, pesquisando defeitos começos de uma conexão externa na parte superior.

O fluxo geral do raciocínio assemelha-se ao seguinte:

  1. O roteamento por encomenda do seletor (DDR) inicia um atendimento? (A resposta A sim avança à pergunta seguinte.)

  2. Se este é um modem assíncrono, os scripts do bate-papo emitem os comandos expected?

  3. O atendimento fá-lo para fora ao PSTN?

  4. A extremidade remota responde ao atendimento?

  5. O atendimento termina?

  6. Está a passagem dos dados sobre o link?

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

Para ver se o discador está tentando fazer um atendimento a seu destino remoto, use o comando debug dialer events. Mais informação detalhada pode ser ganhada do pacote do debug dialer, mas o comando debug dialer packet é recursos intensivos e não deve ser usado em um sistema ocupado que tenha o funcionamento das interfaces do discador múltiplo.

A seguinte linha de eventos do debug dialer output para um pacote IP alista o nome da interface DDR e os endereços de rementente e destinatário do pacote:

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

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

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

Possíveis causas Ações sugeridas
Definições faltantes ou incorretas do “tráfego interessante”
  1. Usar o comando show running-config, assegura-se de que a relação esteja configurada com um discador-grupo e que há uma discador-lista nivelada global configurada com um número correspondente.
  2. Assegure-se de que o comando dialer-list esteja configurado para permitir um protocolo completo ou permitir o tráfego que combina uma lista de acessos
  3. Verifique que a lista de acesso declara os pacotes que vão através do link ser interessante. Um teste útil é usar o comando privileged exec debuga o [list number] do pacote IP usando o número da lista de acesso pertinente. Então tentativa de sibilar, ou de enviar de outra maneira o tráfego, através do link. Se os filtros de tráfego interessante foram definidos corretamente, você verá os pacotes no resultado do debug. Se não há nenhum resultado do debug deste teste, a lista de acesso não está combinando os pacotes.
Estado da relação Use o comando show interfaces <interface name> assegurar-se de que a relação esteja no estado “up/up (spoofing).”
  • Conecte no modo " standby "
Uma outra relação (preliminar) no roteador foi configurada para usar a interface do discador como uma Interface de backup. Além disso, a interface principal não está em um estado de “para baixo/para baixo”, que seja exigido para trazer a interface do discador fora do modo standby. Também, um retardo de backup deve ser configurado na interface principal, ou o comando backup interface será reforçado nunca. Para certificar-se da interface do discador mude do “apoio” ao “up/up (spoofing),” é geralmente necessário puxar o cabo da interface principal. Simplesmente fechar a interface principal com o configuration command shutdown não porá a interface principal em “para baixo/para baixo,” mas pelo contrário po-la-á em “administrativamente abaixo de”? não a mesma coisa. Além, se a conexão principal é através do Frame Relay, a configuração do Frame Relay deve ser feita em uma subinterface serial de Point-to-Point, e a companhia telefônica deve passar o bit “ativo”. Esta prática é sabida igualmente como “a interface de gerenciamento local (LMI) fim-a-fim.”
  • A relação está “administrativamente abaixo de”
A interface do discador foi configurada com o comando shutdown. Este é igualmente o estado padrão de toda a relação quando um roteador Cisco é carreg pela primeira vez mesma. Use o comando interface configuration nenhuma parada programada remover este impedimento.
Roteamento incorreto Emita o [a.b.c.d] da rota do exec command show IP, onde a.b.c.d é o endereço da interface do discador do roteador remoto. Se os unnumberedis IP usados no roteador remoto, usam o endereço da relação alistada no unnumberedcommand IP. A saída deve mostrar uma rota ao endereço remoto através da interface do discador. Se não há nenhuma rota, assegure-se de que a estática ou as Rotas estáticas flutuantes estejam configuradas examinando a saída da executar-configuração da mostra. Se há uma rota através de uma relação a não ser a interface do discador, a implicação é que o DDR está sendo usado como um backup. Examine a configuração de roteador para certificar-se de que a estática ou as Rotas estáticas flutuantes estiveram configuradas. A maneira mais certa testar o roteamento, neste caso, é desabilitar a conexão principal e para executar o commandto do [a.b.c.d] da rota da mostra IP verifique que a rota apropriada esteve instalada na tabela de roteamento.

Nota: Se você tenta este durante operações da rede viva, um evento do seletor pode ser provocado. Este teste é realizado meio melhor durante ciclos de manutenção agendada.

Estabelecendo a chamada

Se o roteamento e os filtros de tráfego interessante estão corretos, um atendimento deve ser iniciado. Isto pode ser visto usando eventos do debug dialer:

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 é considerada mas nenhuma tentativa está feita para discar, a razão comum é um mapa de discadores mal configurado ou um perfil do discador.

Tabela 2: Atendimento não colocado

Problema possível Ações sugeridas
Mapa de discadores mal configurado Use o comando show running-config assegurar-se de que a interface de discagem esteja configurada com pelo menos a uma instrução de mapa de discador que pontos ao endereço de protocolo e ao número chamado do local remoto.
Perfil de discador mal configurado Use o comando show running-config assegurar-se de que a interface do discador esteja configurada com um comando dialer pool X e que uma interface do discador no roteador está configurada com um dialer membro-pool de harmonização X. Se os Perfis de discagem não são configurados corretamente, você pode ver uma mensagem debugar como:
Dialer1: Can't place call, no dialer pool set
Certifique-se de que uma corda do dialer está configurada.

Em seguida, identifique o tipo de media que está sendo usado:

DDR de modem assíncrono externo

  1. Para identificar um modem assíncrono externo DDR, use os comandos seguintes, a seguir tente-os fazer um atendimento:

    router# debug modem
    router# debug chat line <n>
    
    
  2. Para chamadas de modem, chat script deve executar para que o atendimento continue. Para o discador DDR com base no mapa, é invocado chat script pelo parâmetro de script de modem em um comando dialer map. Se o DDR é discador perfil-baseado, este está realizado pelo comando script dialer, configurado na linha TTY. Ambos os métodos confiam chat script em uma existência na configuração global do roteador, por exemplo:

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

    Em um ou outro evento, o comando ver chat script a atividade é debuga o bate-papo. Se a série de discagem (isto é, número de telefone) usada no comando dialer map ou dialer string era 5551212, o resultado do debug olharia como o 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. Assegure-se de que tente chat script a chamada esperada (isto é o número correto) baseada em “enviar a corda.” Se chat script não tenta fazer a chamada esperada, verifique a configuração do chat script. Use o comando start-chat no prompt de exec iniciar chat script manualmente.

  4. Vendo do “a espera intervalo: CONECTE” pode descrever diversas possibilidades diferentes:

    • Possibilidade 1: O modem local não está colocando realmente o atendimento. Verifique que o modem pode colocar um atendimento executando um telnet reverso ao modem e manualmente iniciando um seletor. Se a extremidade remota não parece responder, verifique que o atendimento está sendo colocado pelo modem de origem chamando um número local manualmente com o comando ATDT <number> e escutando o anel.

    • Possibilidade 2: O modem remoto não está respondendo. Teste isto discando o modem remoto com um telefone ordinário dos POTENCIÔMETROS. Tente isto:

      1. Assegure-se de que o número de telefone chamado esteja correto. Use um monofone para chamar o número de recepção. Seja certo usar o mesmo cabo à parede que o modem usava. Se uma chamada manual pode alcançar o modem assíncrono de recepção, o modem de origem não pode trabalhar corretamente. Verifique o modem e substitua-o como necessário.

      2. Se uma chamada manual não pode alcançar o modem assíncrono de resposta, mude os cabos de telefone no modem de recepção e tente um telefone regular na linha de modem de recepção. Se o atendimento pode ser recebido pelo telefone regular, há provável um problema com o modem de recepção.

      3. Se a chamada manual não pode ainda alcançar o telefone regular na linha na pergunta, tente uma outra (linha bom conhecido) na facilidade de recepção. Se isso conecta ESTÁ BEM, tenha a verificação do telco a linha telefônica que vai ao modem de recepção.

      4. Se esta é uma chamada interurbana, mande o lado de origem tentar um outro (número interurbano bom conhecido). Se isso trabalha, a facilidade ou a linha de recepção não podem ser fornecida receber chamadas interurbanas. Se a linha de origem não pode alcançar nenhuns outros números interurbanos, não pode ter a longa distância permitida. Códigos da tentativa 1010 para empresas interurbanas diferentes.

      5. Finalmente, tente um outro (número local bom conhecido) da linha de origem. Se a conexão ainda falha, tenha a verificação do telco a linha de origem.

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

    • Possibilidade 4: O trainup de modem está tomando demasiado por muito tempo ou o valor de timeout é demasiado baixo. Tentativa que aumenta o valor de timeout no comando chat-script. Se o INTERVALO é já 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE a que é anexado. As falhas de trainup podem igualmente indicar um problema de circuito ou uma incompatibilidade de modem.

      Para obter à parte inferior de um problema individual de modem, vá ao na alerta no modem de origem com telnet reverso. Se possível, obtenha ao na alerta do modem de recepção também. A maioria de Modems indicará um anel à sessão terminal anexada a sua conexão de DTE. Uso ATM1 mandar o modem enviar sons a seu orador de modo que os povos em cada extremidade possam se ouvir o que está acontecendo na linha.

      A música tem o ruído nela? Em caso afirmativo, limpe o circuito. Se os modens assíncronos não treinam acima, chame o número e escute a estática. Pode haver outros fatores que interferem com o trem acima. Inverta o telnet ao modem assíncrono e debugar-lo.

  5. Se tudo está trabalhando muito bem e você ainda não pode conectar em seu DDR de modem assíncrono de CAS, tente o PPP debugging. Use os comandos:

    router# debug ppp negotiation
         router# debug ppp authentication
    

    Se termina chat script com sucesso, o Modems está conectado. Consulte “pesquisando defeitos a seção PPP” no capítulo 17 do guia de Troubleshooting da rede interna para a próxima etapa em pesquisar defeitos a conexão.

DDR de modem assíncrono CAS T1/E1

  1. Para identificar um DDR de modem assíncrono de CAS T1/E1, use os comandos seguintes, a seguir tente-os fazer um atendimento:

    aviso aviso:  Ser executado debuga em um sistema ocupado poderia causar um crash o roteador sobrecarregando o CPU ou passando o buffer de console!

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

    Nota: O comando debug cas está disponível nas Plataformas do Cisco AS5200 and AS5300 que executam o Cisco IOS?? Software Release 12.0(7)T e Mais Recente. Nas versões anterior dos IO, o comando service internal teria que ser inscrito no nível principal da configuração do roteador e modem-Mgmt csm debugar-RBS precisaria de ser entrado no prompt de exec. A eliminação de erros no Cisco AS5800 exige a conexão à placa de tronco. (No-debug-rbs de modem-Mgmt csm do uso para desligar debugar.)

  2. Para chamadas de modem, chat script deve executar para que o atendimento continue. Para o discador DDR com base no mapa, é invocado chat script pelo parâmetro de script de modem em um comando dialer map. Se o DDR é discador perfil-baseado, este está realizado pelo comando script dialer, configurado na linha TTY. Ambos os usos confiam chat script em uma existência na configuração global do roteador, como:

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

    Em um ou outro evento, o comando ver chat script a atividade é debuga o bate-papo. Se a série de discagem (isto é, número de telefone) usada no comando dialer map ou dialer string era 5551212, o resultado do debug olharia como o 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. Assegure-se de que tente chat script a chamada esperada (isto é o número correto) baseada em “enviar a corda”. Se chat script não tenta fazer a chamada esperada, verifique a configuração do chat script. Use o comando start-chat no prompt de exec iniciar chat script manualmente.

  4. Vendo do “a espera intervalo: CONECTE” pode descrever diversas possibilidades diferentes:

    • Possibilidade 1: O modem local não está colocando realmente o atendimento. Verifique que o modem pode colocar um atendimento executando um telnet reverso ao modem e manualmente iniciando um seletor. Se a extremidade remota não parece responder, verifique que o atendimento está sendo colocado pelo modem chamando um número local manualmente com o comando ATDT <number> e escutando o anel.

      Para a chamada de saída através do T1 ou E1 de CAS e dos modens digitais integrados, muito do Troubleshooting é similar ao outro Troubleshooting de DDR. O mesmo guarda verdadeiro, também, para atendimentos de partida do modem integrado sobre uma linha PRI. Os recursos exclusivos envolvidos em fazer um atendimento exigem desse modo a eliminação de erros especial no caso de uma falha de chamada.

      Quanto para a outras situações DDR, você deve assegurar-se de que uma tentativa de chamada esteja exigida. Use eventos do debug dialer por esse motivo. Refira IO DDR, mais cedo neste artigo.

      Antes que um atendimento possa ser colocado, um modem deve ser atribuído para o atendimento. Para ver este processo e a chamada subsequente, use os seguintes comandos debug:

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

      Nota: O comando debug cas apareceu primeiramente na Versão do IOS 12.0(7)T para o AS5200 e o AS5300. As versões anterior dos IO usam um system-level configuration command service internal junto com o exec command modem-mgmt debug rbs:

      Girar sobre debuga:

      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 
      

      Desligar debuga:

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

      Debugar esta informação em um AS5800 exige a conexão à placa de tronco. O seguinte é um exemplo de uma chamada externa normal sobre um T1 de CAS que seja fornecida e configurado para o FXS-Terra-início:

      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
      

      Debuga para o T1s e os E1 com outros tipos de sinalização são similares.

      Obter a este ponto na eliminação de erros indica que a chamada e os modens de resposta treinaram e conectaram e que os protocolos de camada mais elevada podem começar a negociar. Se um modem está atribuído corretamente para a chamada externa mas a conexão não obtém esta distante, o T1 deve ser examinado. Use o comando show controller t1/e1 verificar que o T1/E1 está trabalhando. Veja pesquisando defeitos linhas de série para uma explicação de saídas do controlador da mostra. Se o T1/E1 não está trabalhando corretamente, o Troubleshooting de T1/E1 é necessário.

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

      1. Assegure-se de que o número de telefone chamado esteja correto. Use um monofone para chamar o número de recepção.

      2. Assegure-se de que uma chamada manual possa alcançar o modem assíncrono de resposta. Se uma chamada manual pode alcançar o modem assíncrono de resposta, a linha de CAS não pode ser fornecida permitir chamadas de voz externa.

      3. Se uma chamada manual não pode alcançar o modem assíncrono de resposta, mude os cabos de telefone no modem de recepção e tente um telefone regular na linha de modem de recepção. Se o atendimento pode ser recebido pelo telefone regular, há provável um problema com o modem de recepção.

      4. Se a chamada manual não pode ainda alcançar o telefone regular na linha na pergunta, tente uma outra (linha bom conhecido) na facilidade de recepção. Se isso conecta, tenha a verificação do telco a linha telefônica que vai ao modem de recepção.

      5. Se esta é uma chamada interurbana, mande o lado de origem tentar um outro (número interurbano bom conhecido). Se isso trabalha a facilidade ou a linha de recepção não podem ser fornecida receber chamadas interurbanas. Se a linha de origem (de CAS) não pode alcançar nenhuns outros números interurbanos, não pode ter a longa distância permitida. Códigos da tentativa 10-10 para empresas interurbanas diferentes.

      6. Finalmente, tente um outro (número local bom conhecido) da linha de origem de CAS. Se a conexão ainda falha, tenha a verificação do telco CAS.

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

    • Possibilidade 4: O trainup de modem está tomando demasiado por muito tempo, ou o valor de timeout é demasiado baixo. Tentativa que aumenta o valor de timeout no comando chat-script. Se o INTERVALO é já 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE a que é anexado. As falhas de trainup podem igualmente indicar um problema de circuito ou uma incompatibilidade de modem.

      Para obter à parte inferior de um problema individual de modem, vá ao na alerta no modem de origem com telnet reverso. Se possível, use o telnet reverso para obter também ao na alerta do modem de recepção. Uso ATM1 mandar o modem enviar sons a seu orador de modo que os povos em cada extremidade possam se ouvir o que está acontecendo na linha.

      A música tem o ruído nela? Em caso afirmativo, limpe o circuito. Se os modens assíncronos não treinam acima, chame o número e escute a estática. Pode haver outros fatores que interferem com o trem acima. Inverta o telnet ao modem assíncrono e debugar-lo.

  5. Se tudo está trabalhando muito bem e você ainda não pode conectar em seu DDR de modem assíncrono de CAS, tente o PPP debugging. Se termina chat script com sucesso e o PPP debuga indica uma falha, consulte “pesquisando defeitos a seção PPP” no capítulo 17 do guia de Troubleshooting da rede interna.

DDR de modem assíncrono de PRI, DDR

  1. Para identificar um DDR de modem assíncrono PRI, use os comandos seguintes, a seguir tente-os fazer um atendimento:

    aviso aviso:  Ser executado debuga em um sistema ocupado poderia causar um crash o roteador sobrecarregando o CPU ou passando o buffer de 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, chat script deve executar para que o atendimento continue. Para o discador DDR com base no mapa, é invocado chat script pelo parâmetro de script de modem em um comando dialer map. Se o DDR é discador perfil-baseado, este está realizado pelo comando script dialer, configurado na linha TTY. Ambos os métodos confiam chat script em uma existência na configuração global do roteador, como:

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

    Em um ou outro evento, o comando ver chat script a atividade é debuga o bate-papo. Se a série de discagem (número de telefone) usada no comando dialer map ou dialer string era 5551212, o resultado do debug olharia como o 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. Assegure-se de que tente chat script a chamada esperada (o número correto) baseada em “enviar a corda.” Se chat script não tenta fazer a chamada esperada, verifique a configuração do chat script. Use o comando start-chat no prompt de exec iniciar chat script manualmente.

  4. Vendo do “a espera intervalo: CONECTE” pode descrever diversas possibilidades diferentes:

    • Possibilidade 1: O modem local não está colocando realmente o atendimento. Verifique que o modem pode colocar um atendimento executando um telnet reverso ao modem e manualmente iniciando um seletor. Se a extremidade remota não parece responder, verifique que o atendimento está sendo colocado pelo modem chamando um número local manualmente com o comando ATDT <number> e escutando o anel. Se nenhum atendimento sai, gire sobre o ISDN debuga. Após a primeira suspeita de uma falha de ISDN em um BRI, verifique sempre a saída do status de ISDN da mostra. As coisas chaves a notar são que o Layer 1 deve ser ativo e a camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED. Veja o capítulo do Guia de Troubleshooting 16 da rede interna, “interpretando exibição de status de ISDN” para obter informações sobre de ler esta saída, assim como para medidas corretiva.

      Para chamadas de ISDN externo, debugar o q931 de ISDN e o debug isdn events é as melhores ferramentas a usar-se. Felizmente, debugar chamadas externas é muito similar a debugar chamadas recebidas. Uma chamada bem sucedida normal pôde olhar como 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
      

      Note que o mensagem CONNECT é o indicador de sucesso chave. Se CONNECT não é recebida, você pode ver uma DISCONEXÃO ou uma mensagem RELEASE_COMP (liberação completa) seguida por 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 de causa indica duas coisas:

      • O segundo byte dos 4 ou do valor 6-byte indica o ponto no caminho de chamada de ponta a ponta de que a DISCONEXÃO ou o RELEASE_COMP foram recebidos. Isto pode ajudá-lo a localizar o problema.

      • O terço e os quartos bytes indicam a razão real para a falha. Veja a tabela 9 para os significados dos valores diferentes.

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

      1. Assegure-se de que o número de telefone chamado esteja correto. Use um monofone para chamar o número de recepção.

      2. Assegure-se de que uma chamada manual possa alcançar o modem assíncrono de resposta. Se uma chamada manual pode alcançar o modem assíncrono de resposta, a linha BRI não pode ser fornecida permitir chamadas de voz externa.

      3. Se uma chamada manual não pode alcançar o modem assíncrono de resposta, mude os cabos de telefone no modem de recepção e tente um telefone regular na linha de modem de recepção. Se o atendimento pode ser recebido pelo telefone regular, há provável um problema com o modem de recepção.

      4. Se a chamada manual não pode ainda alcançar o telefone regular na linha na pergunta, tente uma outra (linha bom conhecido) na facilidade de recepção. Se isso conecta, tenha a verificação do telco a linha telefônica que vai ao modem de recepção.

      5. Se esta é uma chamada interurbana, mande o lado de origem tentar um outro (número interurbano bom conhecido). Se isso trabalha, a facilidade ou a linha de recepção não podem ser fornecida receber chamadas interurbanas. Se a linha (BRI) de origem não pode alcançar nenhuns outros números interurbanos, não pode ter a longa distância permitida. Códigos da tentativa 1010 para empresas interurbanas diferentes.

      6. Finalmente, tente um outro (número local bom conhecido) da linha de origem BRI. Se a conexão ainda falha, tenha a verificação do telco o BRI.

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

    • Possibilidade 4: O trainup de modem está tomando demasiado por muito tempo ou o valor de timeout é demasiado baixo. Tentativa que aumenta o valor de timeout no comando chat-script. Se o INTERVALO é já 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE é anexado a. As falhas de trainup podem igualmente indicar um problema de circuito ou uma incompatibilidade de modem.

      Para obter à parte inferior de um problema individual de modem, vá ao na alerta no modem de origem com telnet reverso. Se possível, use o telnet reverso para obter também ao na alerta do modem de recepção. Uso ATM1 mandar o modem enviar sons a seu orador de modo que os povos em cada extremidade possam se ouvir o que está acontecendo na linha.

      A música tem o ruído nela? Em caso afirmativo, limpe o circuito. Se os modens assíncronos não treinam acima, chame o número e escute a estática. Pode haver outros fatores que interferem com o trem acima. Inverta o telnet ao modem assíncrono e debugar-lo.

  5. Se tudo está trabalhando muito bem e você ainda não pode conectar em seu modem assíncrono BRI DDR, tente o PPP debugging. Se termina chat script com sucesso e o PPP debuga indica uma falha, consulte “pesquisando defeitos a seção PPP” no capítulo 17 do guia de Troubleshooting da rede interna.

BRI Modem assíncrono DDR

Esta característica trabalha somente na plataforma do Cisco 3640 usando o Cisco IOS Software Release 12.0(3)T ou Mais Recente. Exige uma revisão de hardware mais atrasada do módulo de rede BRI. Isto não trabalhará com um WAN Interface Card (WIC).

  1. Assegure-se de que o código de país esteja correto com o comando show modem. Use os comandos seguintes, a seguir tente-os fazer um atendimento:

    aviso aviso:  Ser executado debuga em um sistema ocupado poderia causar um crash o roteador sobrecarregando o CPU ou passando o buffer de 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, chat script deve executar para que o atendimento continue. Para o discador DDR com base no mapa, é invocado chat script pelo parâmetro de script de modem em um comando dialer map. Se o DDR é discador perfil-baseado, este está realizado pelo comando script dialer, configurado na linha TTY. Ambos os usos confiam chat script em uma existência na configuração global do roteador, como:

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

    Em um ou outro evento, o comando ver chat script a atividade é debuga o bate-papo. Se a série de discagem (número de telefone) usada no comando dialer map ou dialer string era 5551212, o resultado do debug olharia como o 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. Assegure-se de que tente chat script a chamada esperada (o número correto) baseada em “enviar a corda.” Se chat script não tenta fazer a chamada esperada, verifique a configuração do chat script. Use o comando start-chat no prompt de exec iniciar chat script manualmente.

  4. Vendo do “a espera intervalo: CONECTE” pode descrever diversas possibilidades diferentes:

    • Possibilidade 1: O modem local não está colocando realmente o atendimento. Verifique que o modem pode colocar um atendimento executando um telnet reverso ao modem e manualmente iniciando um seletor. Se a extremidade remota não parece responder, verifique que o atendimento está sendo colocado pelo modem chamando um número local manualmente com o comando ATDT <number> e escutando o anel. Se nenhum atendimento sai, gire sobre o ISDN debuga. Após a primeira suspeita de uma falha de ISDN em um BRI, verifique sempre a saída do status de ISDN da mostra. As coisas chaves a notar são que o Layer 1 deve ser ativo e a camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED. Veja o capítulo do Guia de Troubleshooting 16 da rede interna, “interpretando exibição de status de ISDN” para obter informações sobre de ler estas saída e medidas corretiva.

      Para chamadas de ISDN externo, debugar o q931 de ISDN e o debug isdn events é as melhores ferramentas a usar-se. Felizmente, debugar chamadas externas é muito similar a debugar chamadas recebidas. Uma chamada bem sucedida normal pôde olhar como 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
      

      Note que o mensagem CONNECT é o indicador de sucesso chave. Se CONNECT não é recebida, você pode ver uma DISCONEXÃO ou uma mensagem RELEASE_COMP (liberação completa) seguida por 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 de causa indica duas coisas.

      • O segundo byte dos 4 ou do valor 6-byte indica o ponto no caminho de chamada de ponta a ponta de que a DISCONEXÃO ou o RELEASE_COMP foram recebidos. Isto pode ajudá-lo a localizar o problema.

      • O terço e os quartos bytes indicam a razão real para a falha. Veja a tabela 9 para os significados dos valores diferentes.

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

      1. Assegure-se de que o número de telefone chamado esteja correto. Use um monofone para chamar o número de recepção.

      2. Assegure-se de que uma chamada manual possa alcançar o modem assíncrono de resposta. Se uma chamada manual pode alcançar o modem assíncrono de resposta, a linha BRI não pode ser fornecida permitir chamadas de voz externa.

      3. Se uma chamada manual não pode alcançar o modem assíncrono de resposta, mude os cabos de telefone no modem de recepção e tente um telefone regular na linha de modem de recepção. Se o atendimento pode ser recebido pelo telefone regular, há provável um problema com o modem de recepção.

      4. Se a chamada manual não pode ainda alcançar o telefone regular na linha na pergunta, tente uma outra (linha bom conhecido) na facilidade de recepção. Se isso conecta, tenha a verificação do telco a linha telefônica que vai ao modem de recepção.

      5. Se esta é uma chamada interurbana, mande o lado de origem tentar um outro (número interurbano bom conhecido). Se isso trabalha, a facilidade ou a linha de recepção não podem ser fornecida receber chamadas interurbanas. Se a linha (BRI) de origem não pode alcançar nenhuns outros números interurbanos, não pode ter a longa distância permitida. Códigos da tentativa 10-10 para empresas interurbanas diferentes.

      6. Finalmente, tente um outro (número local bom conhecido) da linha de origem BRI. Se a conexão ainda falha, tenha a verificação do telco o BRI.

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

    • Possibilidade 4: O trainup de modem está tomando demasiado por muito tempo, ou o valor de timeout é demasiado baixo. Tentativa que aumenta o valor de timeout no comando chat-script. Se o INTERVALO é já 60 segundos ou mais, pode haver um problema de cabo entre o modem e o DTE é anexado a. As falhas de trainup podem igualmente indicar um problema de circuito ou uma incompatibilidade de modem.

      Para obter à parte inferior de um problema individual de modem, vá ao na alerta no modem de origem com telnet reverso. Se possível, use o telnet reverso para obter também ao na alerta do modem de recepção. Uso ATM1 mandar o modem enviar sons a seu orador de modo que os povos em cada extremidade possam se ouvir o que está acontecendo na linha.

      A música tem o ruído nela? Em caso afirmativo, limpe o circuito. Se os modens assíncronos não treinam acima, chame o número e escute a estática. Pode haver outros fatores que interferem com o trem acima. Inverta o telnet ao modem assíncrono e debugar-lo.

  5. Se tudo está trabalhando muito bem e você ainda não pode conectar em seu modem assíncrono BRI DDR, tente o PPP debugging. Se termina chat script com sucesso e o PPP debuga indica uma falha, consulte “pesquisando defeitos a seção PPP” no capítulo 17 do guia de Troubleshooting da rede interna.

PRI ISDN DDR

  1. Após a primeira suspeita de uma falha de ISDN em um PRI, verifique sempre a saída do status de ISDN da mostra. As coisas chaves a notar são que o Layer 1 deve ser ativo e a camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED. Veja o capítulo do Guia de Troubleshooting 16 da rede interna, “interpretando exibição de status de ISDN” para obter informações sobre de ler estas saída e medidas corretiva.

    Para chamadas de ISDN externo, debugar o q931 de ISDN e o debug isdn events é as melhores ferramentas a usar-se. Felizmente, debugar chamadas externas é muito similar a debugar chamadas recebidas. Uma chamada bem sucedida normal pôde olhar como 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
    

    Note que o mensagem CONNECT é o indicador de sucesso chave. Se CONNECT não é recebida, você pode ver uma DISCONEXÃO ou uma mensagem RELEASE_COMP (liberação completa) seguida por 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 de causa indica duas coisas.

    • O segundo byte dos 4 ou do valor 6-byte indica o ponto no caminho de chamada de ponta a ponta de que a DISCONEXÃO ou o RELEASE_COMP foram recebidos. Isto pode ajudá-lo a localizar o problema.

    • O terço e os quartos bytes indicam a razão real para a falha. Veja a tabela 9 para os significados dos valores diferentes.

    Nota: O seguinte impresso indica uma falha de protocolo mais alto:

    Cause i = 0x8090 - Normal call clearing

    A falha de autenticação de PPP é um motivo típico. Gire sobre debugam a negociação ppp e debugam a autenticação de PPP antes de supor que a falha de conexão é necessariamente um problema de ISDN.

  2. Se o mensagem ISDN CONNECT é considerado e o PPP debuga indica uma falha, consulte “pesquisando defeitos a seção PPP” no capítulo 17 do guia de Troubleshooting da rede interna.

BRI ISDN DDR

  1. Após a primeira suspeita de uma falha de ISDN em um BRI, verifique sempre a saída do status de ISDN da mostra. As coisas chaves a notar são que o Layer 1 deve ser ativo e a camada 2 deve estar em um estado de MULTIPLE_FRAME_ESTABLISHED. Veja o capítulo do Guia de Troubleshooting 16 da rede interna, “interpretando exibição de status de ISDN” para obter informações sobre de ler estas saída e medidas corretiva.

    Para chamadas de ISDN externo, debugar o q931 de ISDN e o debug isdn events é as melhores ferramentas a usar-se. Felizmente, debugar chamadas externas é muito similar a debugar chamadas recebidas. Uma chamada bem sucedida normal pôde olhar como 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
    

    Note que o mensagem CONNECT é o indicador de sucesso chave. Se CONNECT não é recebida, você pode ver uma DISCONEXÃO ou uma mensagem RELEASE_COMP (liberação completa) seguida por 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 de causa indica duas coisas.

    • O segundo byte dos 4 ou do valor 6-byte indica o ponto no caminho de chamada de ponta a ponta de que a DISCONEXÃO ou o RELEASE_COMP foram recebidos. Isto pode ajudá-lo a localizar o problema.

    • O terço e os quartos bytes indicam a razão real para a falha. Veja a tabela 9 para os significados dos valores diferentes.

      Nota: O seguinte impresso indica uma falha de protocolo mais alto:

      Cause i = 0x8090 - Normal call clearing

      A falha de autenticação de PPP é um motivo típico. Gire sobre debugam a negociação ppp e debugam a autenticação de PPP antes de supor que a falha de conexão é necessariamente um problema de ISDN.

  2. Se o mensagem ISDN CONNECT é considerado e o PPP debuga indica uma falha, consulte “pesquisando defeitos a seção PPP” no capítulo 17 do guia de Troubleshooting da rede interna.


Informações Relacionadas


Document ID: 14954