Discar e acessar : """Integrated Services Digital Networks (ISDN), Channel-Associated Signaling (CAS)"""

Tecnologia dialup: Técnicas para Troubleshooting

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


Esta informação do guia de Troubleshooting da rede interna foi afixada primeiramente no CCO. Como um serviço oferecido para os nossos clientes, capítulos selecionados têm sido atualizados com as informações mais atuais e precisas. A atualização completa do Manual de Troubleshooting de Problemas Inter-Redes estará em breve disponível em versão impressa e on-line.


Índice


Introdução

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. Os Cisco3600, o AS5200, o AS5300, e o AS5800 são todos os exemplos de roteadores que têm a capacidade para executar um PRI junto com bancos dos modens digitais. O AS2511, por outro lado, é um exemplo de um roteador que se comunique com os Modens externos.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes da seguinte informação:

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 um 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 os Cisco2509 e os Cisco2511. 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.

Componentes Utilizados

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

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Convenções

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

Pesquisando defeitos chamadas recebidas

Pesquisar defeitos uma chamada recebida começa na parte inferior e trabalha sua maneira acima. O fluxo geral do raciocínio procura o seguinte:

  1. Nós vemos o atendimento chegar? (A resposta A sim avança à pergunta seguinte)

  2. A extremidade de recepção responde ao atendimento?

  3. O atendimento termina?

  4. É a passagem dos dados através do link?

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

Para conexões de modem, uma chamada de dados olha o mesmos que uma sessão terminal que vem em até o final onde a chamada de dados vai negociar o PPP.

Para as chamadas recebidas que envolvem modens digitais, certifique-se primeiramente que o ISDN subjacente ou CAS estão recebendo o atendimento. Se usando um Modem externo, o ISDN e as seções de grupo de CAS podem ser saltados.

Troubleshooting da chamada de ISDN recebido

Use o comando debug isdn q931. Estão aqui umas saídas de exemplo de uma conexão bem sucedida:

Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

O mensagem setup indica que uma conexão está sendo iniciada pela extremidade remota. Os números de referência da chamada são mantidos como um par. Neste caso o número de referência da chamada para o lado de entrada da conexão é 0x06, e o número de referência da chamada do lado externo da conexão é 0x86. A capacidade do portador (referida frequentemente como o bearercap) diz ao roteador que tipo do atendimento está vindo. Neste caso a conexão é o tipo 0x8890. Esse valor indica “a velocidade 64 Kb/s ISDN”. Se o bearercap tinha sido 0x8090A2, indicaria o “chamada de voz/discurso u-law”.

Se nenhum mensagem setup entrou, você deve verificar o número correto chamando o manualmente, se é Voz fornecida. Você deve igualmente verificar o estado da interface (refira a utilização do comando show isdn status para o Troubleshooting de BRI). Se esse tudo verifica para fora, certifique-se de que o originador de chamada está fazendo o atendimento correto. Isto pode ser feito contactando a companhia telefônica. O originador de chamada pode seguir o atendimento para ver onde ele? s que está sendo enviado. Se a conexão é interurbana, tente uma portadora interurbana diferente usando um código interurbano 1010.

Se o atendimento que entra é uma chamada de modem assíncrono, certifique-se que a linha é fornecida permitir chamadas de voz.

Nota: A chamada do modem assíncrono BRI é uma característica dos 3600 Router que executam 12.0(3)T, ou mais tarde. Exige uma revisão recente de hardware do módulo de rede da interface BRI. Os módulos WIC não apoiam a chamada modem ASYNC.

Se o atendimento chegou mas não terminou, procure um código de causa (veja a tabela 17-10). Uma conclusão bem sucedida é indicada pelo conectar-ACK.

Se esta é uma chamada de modem assíncrono, mova-se para a frente para da “a seção do Troubleshooting chamada de modem entrante”.

A chamada ISDN é conectada neste momento, mas nenhum dados foi vinda considerada através do link. Use o comando debug ppp negotiate ver se algum tráfego PPP está vindo através da linha. Se você não vê o tráfego, pode haver uma má combinação da velocidade. Para determinar se este é o caso, use o comando show running-config privileged exec ver a configuração de roteador. Verifique as entradas do comando dialer map interface configuration no roteador local e remoto. Estas entradas devem olhar similares ao seguinte:

dialer map ip 131.108.2.5 speed 56 name C4000

Para Perfis de discagem, uma classe de mapas precisa de ser definida a fim ajustar a velocidade. Note que, à revelia, as interfaces tentam usar velocidades das comunicações 64K em cada canal.

Para informações detalhadas sobre de configurar Mapas de discagem e perfis, refira o manual de configuração das soluções de discagem IOS Cisco, o Dial Solutions Command Reference, e o manual de configuração rápida das soluções do seletor.

Se você recebe pacotes PPP válidos, o link é ascendente e trabalhar. Você deve continuar “pesquisar defeitos à seção PPP” neste tempo.

Troubleshooting entrante do atendimento de CAS

Para pesquisar defeitos a Conectividade do serviço do grupo de CAS ao Modems, use os comandos debug modem, debug modem csm, e debug cas.

Nota: O comando debug cas apareceu primeiramente em 12.0(7)T para o AS5200 e o AS5300. As versões anterior dos IO usam o serviço do comando system level configuration interno junto com o exec command modem-mgmt debug rbs. Debugar esta informação em um AS5800 exige a conexão à placa de tronco própria.

Primeiramente, determine se o switch de companhia telefônica foi “fora do gancho” para sinalizar a chamada recebida. Se não fez, para verificar o número que está sendo chamado. Faça isto anexando um telefone à linha telefônica do lado de origem e chamando o número. Se o atendimento entra corretamente, o problema está no CPE de origem. Se o atendimento ainda não aparece em CAS, verifique o T1 (o capítulo 15).In este exemplo, usa o comando debug serial interfaces.

As seguintes mostras uma boa conexão usando o debug modem csm:

Router# debug modem csm
CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.
MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0
CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
CSM_RING_INDICATION_PROC: RI is on
CSM_RING_INDICATION_PROC: RI is off
CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0
CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0

Neste exemplo, o atendimento foi dirigido a um modem. Se seu atendimento foi dirigido a um modem, continue da “à seção do Troubleshooting chamada de modem entrante”, abaixo.

Troubleshooting da chamada de modem entrante

Use os seguintes comandos debug ao pesquisar defeitos chamadas de modem entrante:

  • debugar o modem

  • debug modem csm (para modens digitais integrados)

Use os seguintes comandos debug na junção indicar o atendimento novo que vem em:

  • debug isdn q931

  • debugar o cas

Supor o atendimento alcança o modem, o modem precisa de pegarar o atendimento.

Pontas para debugging external modem

Para facilitar debugar em um Modem externo conectou a uma linha TTY, aumenta o volume de altofalante. Isto ajuda a fazer alguns problemas mais aparentes.

Quando o modem de origem chama, o modem receber soa? Se não, verifique o número e tente uma chamada manual do local remoto. Tente usar um telefone regular na extremidade de recepção também. Substitua cabos e hardware como necessário.

Coletor de chamada de modem assíncrono

Se um Modem externo não está respondendo, verifique a expedição de cabogramas entre o modem e o servidor de acesso ou o roteador. Confirme que o modem está conectado ao TTY ou ao porto auxiliar no roteador com um cabo RJ-45 rolado e um adaptador MMOD DB-25. Cisco recomenda e apoia esta configuração de cabo para as portas RJ-45. Note que estes conectores estão etiquetados tipicamente: Modem.

Cabografar RJ-45 vem em alguns tipos: em linha reta, rolado, e cruzamento. Você pode determinar o tipo de cabeamento guardando as duas extremidades de um cabo RJ-45 de lado a lado. Você verá oito tiras coloridas, ou pinos, em cada extremidade.

  • Se a ordem dos pinos coloridos é a mesma em cada extremidade, o cabo é reto.

  • Se a ordem das cores é invertida em cada extremidade, o cabo está rolado.

  • O cabo é um cabo crossover se as cores indicam o seguinte:

RJ45 ao cabo crossover RJ45:

RJ45                  RJ45 
         5 ------------------ 2
         2 ------------------ 5
         4 ------------------ 1 
         1 ------------------ 4

Para certificar-se da sinalização é APROVAÇÃO, usa o comando show line esboçado no capítulo 16.

As questões de cabeamento de lado, um Modem externo precisam de ser inicializadas à resposta automática. Verifique o modem remoto para ver se está ajustado à resposta automática. Geralmente, uma luz indicadora AA está em quando a resposta automática é ajustada. Ajuste o modem remoto à resposta automática se não é ajustada já. Para obter informações sobre de verificar e de mudar os ajustes do modem, refira sua documentação de modem. Use um telnet reverso para inicializar o modem (refira o capítulo 16).

Coletor de chamada de modem digital (INTEGRADO)

Em um Modem externo é claro se o atendimento está sendo respondido, mas os modens internos exigem uma chamada manual ao número de recepção. Escute o Answer Back Tone (ABT). Se você não ouve um ABT, verifique a configuração para ver se há as seguintes duas coisas:

  1. Certifique-se que o comando isdn incoming-voice modem existe sob todas as interfaces que seguram conexões de modem recebido.

  2. Sob a configuração de linha para o TTY do modem, certifique-se que o comando modem inout existe.

É igualmente possível que o módulo de switching de chamadas (CS) não atribuiu um modem interno para segurar a chamada recebida. Este problema pode ser causado pelo modem ou pelos conjuntos de recurso que estão sendo configurados para demasiado poucas conexões recebidas. Pode-se igualmente significar que o servidor de acesso pode simplesmente ser fora do Modems. Verifique a disponibilidade de modems e ajuste o conjunto de modem ou as configurações do gerenciador do conjunto de recurso apropriadamente. Se um modem foi atribuído e o recolhimento do modem inout, das mostras da configuração debuga e contato Cisco para o auxílio.

Trainup de modem

Se o modem de recepção aumenta o DSR, o trainup era bem sucedido. As falhas de trainup podem 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 quando anexar aos POTENCIÔMETROS a linha de interesse. Se chamar em um modem digital em um Cisco access server, seja preparada para gravar um arquivo do .WAV da música de trainup, ou da sequência de aprendizagem de defeito digital (DIL). O DIL é a pontuação musical (sequência PCM) que o modem analógico V.90 de origem diz o modem digital de recepção para jogar para trás. A sequência permite que o modem analógico distinga todo o defeito digital no circuito; como conversões múltiplas de D/A, um law/u-law, bit roubado, ou almofadas digital. Se você não ouve o DIL, o Modems não negociou o V.90 em V.8/V.8bis (que é., uma questão de compatibilidade de modem). Se você ouve o DIL e um retreinamento no V.34, o modem analógico decidiu (com base na reprodução de DIL) que o V.90 era inexequível.

A música tem o ruído nela? Em caso afirmativo, limpe então o circuito.

O cliente dá acima rapidamente, sem executar o treinamento V.34? Por exemplo, talvez não conhece o que fazer quando ouve V.8bis. Neste caso você deve tentar desabilitar V.8bis (daqui K56Flex) no server (se aceitável). Você deve obter o firmware de cliente novo ou trocar para fora o modem do cliente. Alternadamente, a extremidade discando podia introduzir cinco vírgulas na extremidade da série de discagem. Isto atrasa a audição do modem de chamada e causará o tom de V.8bis do server de recepção ao intervalo sem afetar o modem do cliente. Cinco vírgulas na série de discagem são uma diretriz geral e puderam precisar de ajustar para permitir condições local.

Estabelecimento de sessão

Neste momento na sequência, o Modems é conectado e treinado acima. Agora é hora de encontrar se algum tráfego está vindo transversalmente corretamente.

Se a linha que recebe o atendimento está configurada com autoselect ppp e a interface assíncrona está configurada com o modo assíncrono interativo, use o comando debug modem verificar o processo de autoseleção. Porque o tráfego vem dentro sobre o link assíncrono, o servidor de acesso examinará o tráfego para determinar se o tráfego é caráter-baseado ou com base em pacotes. Segundo a determinação, o servidor de acesso então começará uma sessão de PPP ou irá não mais distante do que tendo uma sessão de exec na linha.

Uma sequência de autoseleção normal com pacotes PPP LCP de entrada:

*Mar  1 21:34:56.958: TTY1: DSR came up
*Mar  1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar  1 21:34:56.970: TTY1: EXEC creation
*Mar  1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar  1 21:34:59.722: TTY1: Autoselect(2) sample 7E 

!--- The inbound traffic is displayed in hexadecimal format. This is based on the
!--- bits coming in over the line, regardless of whether the bits are ASCII
!--- characters or elements of a packet. The bits represented in this example are
!--- correct for a LCP packet. Anything different would be either a malformed packet
!--- or character traffic.

*Mar  1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar  1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate 

!--- Having determined that the inbound traffic is actually an LCP packet, the access
!--- server triggers the PPP negotiation process.

*Mar  1 21:34:59.746: TTY1: EXEC creation
*Mar  1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar  1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar  1 21:34:59.794: TTY1: destroy timer type 0
*Mar  1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up 

!--- The async interface changes state to up, and the PPP negotiation (not shown)
!--- commences.

Se o atendimento é uma sessão de PPP e se o modo assíncrono dedicado está configurado na interface assíncrona, use o comando debug ppp negotiation ver se algum pacote de requisição de configuração está vindo da extremidade remota. Debuga a mostra estes como o CONFREQ. Se você observa de entrada e pacotes PPP de saída, continuam “pesquisar defeitos ao PPP”. Se não, conecte da extremidade origem de chamada com uma sessão do modo de caractere (ou o “executivo”) (isto é, uma sessão diferente de PPP).

Nota: Se a extremidade de recepção indica o modem assíncrono dedicado sob a interface assíncrona, mostras do discagem de exec somente o que parece ser lixo de ASCII aleatório. Para permitir uma sessão terminal e ainda ter a potencialidade de PPP, use o modo assíncrono do comando async interface configuration interativo. Sob a configuração de linha associada, use o comando autoselect ppp.

O modem não pode enviar ou receber dados

Se o Modems conecta com uma sessão terminal e nenhum dados vem transversalmente, verifique as seguintes causas possíveis e os cursos de ação sugeridos:

  • A configuração de velocidade de modem não é travada

    1. Use o comando show line exec no servidor de acesso ou no roteador. A saída para o porto auxiliar deve indicar as velocidades atualmente configuradas de Tx e RX.

      Para uma explicação da saída do comando show line, veja “usando a seção dos comandos Debug” no capítulo 15.

    2. Se a linha não é configurada à velocidade correta, use o comando speed line configuration ajustar a velocidade de linha no servidor de acesso ou na linha de roteador. Ajuste o valor à velocidade a mais alta na terra comum entre o modem e o servidor de acesso ou a porta de roteador. Para ajustar a taxa de baud terminal, use o comando speed line configuration. Este os conjuntos de comandos transmitir (ao terminal) e recebem (do terminal) velocidades.

      Sintaxe:

      velocidade bps

      Descrição da sintaxe:

      bps - Taxa de baud nos bit por segundo (bps). O padrão é 9600 bps.

      O exemplo seguinte ajusta as linhas 1 e 2 em um servidor de acesso Cisco 2509 a 115200 bps:

      line 1 2
      speed 115200

      Nota: Se, por qualquer motivo, você não pode usar o controle de fluxo, limite a velocidade de linha a 9600 bps. Umas velocidades mais rápidas são prováveis conduzir aos dados perdidos.

    3. Use o comando show line exec outra vez e confirme que a velocidade de linha está ajustada ao valor desejado.

    4. Quando você está certo que o servidor de acesso ou a linha de roteador estão configurados para a velocidade desejada, inicie uma sessão de Telnet reversa ao modem através dessa linha. Para mais informação, veja a seção “estabelecer uma sessão de Telnet reversa a um modem” no capítulo 16.

    5. Use uma série de comando do modem que inclua o comando " lock dte speed " para seu modem. Veja sua documentação de modem para a sintaxe exata do comando de configuração.

    Nota: O comando lock dte speed, que pôde igualmente ser referido enquanto a taxa de porta ajusta ou modo colocado em buffer, é relacionado frequentemente à maneira em que o modem segura a correção de erros. Este comando varia extensamente de um modem a outro.

    Travar a velocidade do modem assegura-se de que o modem se comunique sempre com o Cisco access server ou o roteador na velocidade configurada na porta auxiliar Cisco. Se este comando não é usado, o modem reverte à velocidade do link de dados (linha de telefone), em vez da comunicação na velocidade configurada no servidor de acesso.

  • Controle de fluxo de hardware não configurado no modem ou roteador local ou remoto

    1. Use o comando show line aux-line-number exec e procure o seguinte no campo das capacidades:

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      Para mais informação, refira a interpretação da linha da mostra Output no capítulo 16.

      Se não há nenhuma menção do controle de fluxo de hardware neste campo, o controle de fluxo de hardware não está permitido na linha. O controle de fluxo de hardware para conexões de acesso servidor para modem é recomendado.

      Para uma explicação da saída do comando show line, veja a seção “usar comandos Debug” no capítulo 15.

    2. Configurar o controle de fluxo de hardware na linha usando o comando flowcontrol hardware line configuration.

      Para ajustar o método de controle do fluxo de dados entre o terminal ou o outro dispositivo serial e o roteador, use o comando flowcontrol line configuration. Não use nenhum formulário deste comando desabilitar o controle de fluxo.

      Sintaxe:

      controlo de fluxo {nenhum | [lock] do software [em | para fora] | hardware [em | para fora]}

      Descrição da sintaxe:

      • nenhuns - Desliga o controle de fluxo.

      • software - Ajusta o controle de fluxo de software. Umas palavras-chave opcionais especificam o sentido: no faz com o Cisco IOS Software escute o controle de fluxo do dispositivo anexo, e faz com para fora que o software envie a informação de controle de fluxo ao dispositivo anexo. Se você não especifica um sentido, ambos estão supostos.

      • fechamento - Faz impossível desligar o controle de fluxo do host remoto quando o dispositivo conectado precisa o controle de fluxo de software. Esta opção aplica-se às conexões usando o telnet ou os protocolos rlogin.

      • hardware - Ajusta o controle de fluxo de hardware. Umas palavras-chave opcionais especificam o sentido: no faz com o software escute o controle de fluxo do dispositivo anexo, e faz com para fora que o software envie a informação de controle de fluxo ao dispositivo anexo. Se você não especifica um sentido, ambos estão supostos. Para obter mais informações sobre do controle de fluxo de hardware, veja o manual do hardware que foi enviado com seu roteador.

      Exemplo:

      O exemplo seguinte ajusta o controle de fluxo de hardware na linha 7:

      line 7
      flowcontrol hardware

      Nota: Se por qualquer motivo você não pode usar o controle de fluxo, limite a velocidade de linha a 9600 bps. Umas velocidades mais rápidas são prováveis conduzir aos dados perdidos.

    3. Após ter permitido o controle de fluxo de hardware no servidor de acesso ou na linha de roteador, inicie uma sessão de Telnet reversa ao modem através dessa linha. Para mais informação, veja a seção “estabelecer uma sessão de Telnet reversa a um modem” no capítulo 16.

    4. Use uma série de comando do modem que inclua o comando RTS/CTS Flow para seu modem. Este comando assegura-se de que o modem esteja usando o mesmo método de controle de fluxo (isto é, controle de fluxo de hardware) que o Cisco access server ou o roteador. Veja sua documentação de modem para a sintaxe exata do comando de configuração.

  • Comandos do mapa de discadores mal configurado

    1. Use o comando show running-config privileged exec ver a configuração de roteador. Verifique o dialer map command entries para ver se a palavra-chave da transmissão está especificada.

    2. Se a palavra-chave falta, adicionar-la à configuração.

      Sintaxe:

      [dial-string] do [broadcast] do [name hostname] do dialer map protocol next-hop-address

      Descrição da sintaxe:

      • protocolo - O assunto do protocolo ao traço. As opções incluem o IP, o IPX, a ponte, e o instantâneo.

      • endereço de próximo salto - O endereço de protocolo da interface assíncrona do local oposto.

      • hostname do nome - Um parâmetro requerido usado na autenticação de PPP. É o nome do local remoto para que o mapa de discadores é criado. O nome é diferenciando maiúsculas e minúsculas e deve combinar o hostname do roteador remoto.

      • transmissão - Umas palavras-chave opcionais que pacotes de transmissão (por exemplo, atualizações do RASGO IP ou IPX RIP/SAP) que é enviado ao destino remoto. Nas configurações de exemplo de roteamento estático, as atualizações de roteamento não são desejadas e a palavra-chave da transmissão é omitida.

      • série de discagem - O número de telefone do local remoto. Todos os códigos de acesso (por exemplo, 9 a sair de um escritório, de códigos de discagem internacionais, de códigos de área) devem ser incluídos.

    3. Certifique-se de que os comandos dialer map especificam os endereços de próximo salto corretos.

    4. Se o endereço de próximo salto está incorreto, mude-o que usa o comando dialer map.

    5. Certifique-se que todas as outras opções nos comandos dialer map estão especificadas corretamente para o protocolo que você se está usando.

    Para informações detalhadas sobre de configurar Mapas de discagem, refira a referência do Guia de Configuração de Rede e Área Ampla do IOS Cisco e do comando wide-area networking.

  • Problema com modem de discagem

    • Certifique-se de que o modem de discagem é operacional e está conectado firmemente à porta correta. Determine se um outro modem funciona quando conectado à mesma porta.

Debugar uma sessão de exec recebido cai geralmente em algumas categorias principal:

O cliente dialup não recebe nenhum prompt de exec

  • O Autoselect é permitido na linha

    A tentativa de alcançar o modo exec pressionando entra.

  • A linha é configurada com o comando no exec

    1. Use o comando show line exec ver o estado da linha apropriada.

      Verifique as capacidades colocam para ver se diz o “executivo suprimido.” Se este é o caso, o comando no exec line configuration está permitido.

    2. Configurar o comando exec line configuration na linha permitir que as sessões de exec sejam iniciadas. Este comando não tem nenhuma argumento ou palavra-chave.

    O exemplo seguinte gira sobre o executivo na linha 7:

    line 7 
    exec
  • O controle de fluxo não é permitido.

    ou

    O controle de fluxo é permitido somente em um dispositivo (DTE ou DCE).

    ou

    O controle de fluxo é desconfigurado.

    1. Use o comando show line aux-line-number exec e procure o seguinte no campo das capacidades:

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
      

      Para mais informação, refira a interpretação da linha da mostra Output no capítulo 16.

      Se não há nenhuma menção do controle de fluxo de hardware neste campo, o controle de fluxo de hardware não está permitido na linha. O controle de fluxo de hardware para conexões de acesso servidor para modem é recomendado.

      Para uma explicação da saída do comando show line, veja “usando a seção dos comandos Debug” no capítulo 15.

    2. Configurar o controle de fluxo de hardware na linha usando o comando flowcontrol hardware line configuration. O exemplo seguinte ajusta o controle de fluxo de hardware na linha 7:

      line 7
      flowcontrol hardware

      Nota: Se por qualquer motivo você não pode usar o controle de fluxo, limite a velocidade de linha a 9600 bps. Umas velocidades mais rápidas são prováveis conduzir aos dados perdidos.

    3. Após ter permitido o controle de fluxo de hardware no servidor de acesso ou na linha de roteador, inicie uma sessão de Telnet reversa ao modem através dessa linha. Para mais informação, veja a seção “estabelecer uma sessão de Telnet reversa a um modem” no capítulo 16.

    4. Use uma série de comando do modem que inclua o comando RTS/CTS Flow para seu modem. Este comando assegura-se de que o modem esteja usando o mesmo método de controle de fluxo (isto é, controle de fluxo de hardware) que o Cisco access server ou o roteador. Veja sua documentação de modem para a sintaxe exata do comando de configuração.

  • A configuração de velocidade de modem não é travada

    1. Use o comando show line exec no servidor de acesso ou no roteador. A saída para o porto auxiliar deve indicar as velocidades atualmente configuradas de Tx e RX.

      Para uma explicação da saída do comando show line, veja “usando a seção dos comandos Debug” no capítulo 15.

    2. Se a linha não é configurada à velocidade correta, use o comando speed line configuration ajustar a velocidade de linha no servidor de acesso ou na linha de roteador. Ajuste o valor à velocidade a mais alta na terra comum entre o modem e o servidor de acesso ou a porta de roteador. Para ajustar a taxa de baud terminal, use o comando speed line configuration. Este os conjuntos de comandos transmitir (ao terminal) e recebem (do terminal) velocidades.

      Sintaxe:

      velocidade bps

      Descrição da sintaxe:

      bps - Taxa de baud nos bit por segundo (bps). O padrão é 9600 bps.

      Exemplo:

      O exemplo seguinte ajusta as linhas 1 e 2 em um servidor de acesso Cisco 2509 a 115200 bps:

      line 1 2
      speed 115200

      Nota: Se por qualquer motivo você não pode usar o controle de fluxo, limite a velocidade de linha a 9600 bps. Umas velocidades mais rápidas são prováveis conduzir aos dados perdidos.

    3. Use o comando show line exec outra vez e confirme que a velocidade de linha está ajustada ao valor desejado.

    4. Quando você está certo que o servidor de acesso ou a linha de roteador estão configurados para a velocidade desejada, inicie uma sessão de Telnet reversa ao modem através dessa linha. Para mais informação, veja a seção “estabelecer uma sessão de Telnet reversa a um modem” no capítulo 16.

    5. Use uma série de comando do modem que inclua o comando lock dte speed para seu modem. Veja sua documentação de modem para a sintaxe exata do comando de configuração.

    Nota: O comando lock dte speed, que pôde igualmente ser referido enquanto a taxa de porta ajusta ou modo colocado em buffer, é relacionado frequentemente à maneira em que o modem segura a correção de erros. Este comando varia extensamente de um modem a outro.

    Travar a velocidade do modem assegura-se de que o modem se comunique sempre com o Cisco access server ou o roteador na velocidade configurada na porta auxiliar Cisco. Se este comando não é usado, o modem reverte à velocidade do link de dados (linha de telefone) em vez da comunicação na velocidade configurada no servidor de acesso.

As sessões dialup consideram o “lixo”

  • A configuração de velocidade de modem não é travada

    1. Use o comando show line exec no servidor de acesso ou no roteador. A saída para o porto auxiliar deve indicar as velocidades atualmente configuradas de Tx e RX.

      Para uma explicação da saída do comando show line, veja “usando a seção dos comandos Debug” no capítulo 15.

    2. Se a linha não é configurada à velocidade correta, use o comando speed line configuration ajustar a velocidade de linha no servidor de acesso ou na linha de roteador. Ajuste o valor à velocidade a mais alta na terra comum entre o modem e o servidor de acesso ou a porta de roteador.

      Para ajustar a taxa de baud terminal, use o comando speed line configuration. Este os conjuntos de comandos transmitir (ao terminal) e recebem (do terminal) velocidades.

      Sintaxe:

      velocidade bps

      Descrição da sintaxe:

      bps da taxa de baud nos bit por segundo (bps). O padrão é 9600 bps.

      Exemplo:

      O exemplo seguinte ajusta as linhas 1 e 2 em um servidor de acesso Cisco 2509 a 115200 bps:

      linha 1 2

      velocidade 115200

      Nota: Se por qualquer motivo você não pode usar o controle de fluxo, limite a velocidade de linha a 9600 bps. Umas velocidades mais rápidas são prováveis conduzir aos dados perdidos.

    3. Use o comando show line exec outra vez e confirme que a velocidade de linha está ajustada ao valor desejado.

    4. Quando você está certo que o servidor de acesso ou a linha de roteador estão configurados para a velocidade desejada, inicie uma sessão de Telnet reversa ao modem através dessa linha. Para mais informação, veja a seção “estabelecer uma sessão de Telnet reversa a um modem” no capítulo 16.

    5. Use uma série de comando do modem que inclua o comando lock dte speed para seu modem. Veja sua documentação de modem para a sintaxe exata do comando de configuração.

    Nota: O comando lock dte speed, que pôde igualmente ser referido enquanto a taxa de porta ajusta ou modo colocado em buffer, é relacionado frequentemente à maneira em que o modem segura a correção de erros. Este comando varia extensamente de um modem a outro.

    Travar a velocidade do modem assegura-se de que o modem se comunique sempre com o Cisco access server ou o roteador na velocidade configurada na porta auxiliar Cisco. Se este comando não é usado, o modem reverte à velocidade do link de dados (linha de telefone) em vez da comunicação na velocidade configurada no servidor de acesso.

Sintoma: A sessão de discagem remota abre em uma sessão já existente iniciada por um outro usuário. Isto é, em vez de obter uma alerta de login, um usuário da discagem vê uma sessão estabelecida por um outro usuário (que possa ser uma alerta de comando unix, uma sessão de editor de texto, e assim por diante).

A sessão dialup abre na sessão existente

  • Modem configurado para o DCD sempre altamente

    1. O modem deve ser reconfigurado para ter o DCD alto somente no CD. Isto é realizado geralmente usando a série de comando do modem &C1, mas verifica sua documentação de modem para ver se há a sintaxe exata para seu modem.

    2. Você pôde ter que configurar a linha de servidor de acesso a que o modem é conectado com o comando no exec line configuration. Cancele a linha com o comando clear line privileged exec, inicie uma sessão de Telnet reversa com o modem, e reconfigure o modem de modo que o DCD seja alto somente no CD.

    3. Termine a sessão de Telnet incorporando a disconexão e reconfigure a linha de servidor de acesso com o comando exec line configuration

  • O controle do modem não é permitido no servidor de acesso ou no roteador

    1. Use o comando show line exec no servidor de acesso ou no roteador. A saída para o porto auxiliar deve ser inout ou RIisCD da mostra na coluna de modem. Isto indica que o controle do modem está permitido na linha do servidor de acesso ou do roteador.

      Para uma explicação da linha saída da mostra, veja “usando a seção dos comandos Debug” no capítulo 15.

    2. Configurar a linha para o controle do modem usando o comando modem inout line configuration. O controle do modem é permitido agora no servidor de acesso.

    Nota: É certo que usarão o comando modem inout em vez do comando modem dialin quando a Conectividade do modem estiver na pergunta. O último comando permite que a linha aceite chamadas recebidas somente. As chamadas feitas serão recusadas, fazendo o impossível estabelecer uma sessão de Telnet com o modem para configurar-lo. Se você quer permitir o comando modem dialin, faça assim somente depois que você está certo que o modem está funcionando corretamente.

  • Cabeamento incorreto

    1. Verifique a expedição de cabogramas entre o modem e o servidor de acesso ou o roteador. Confirme que o modem está conectado ao porto auxiliar no servidor de acesso ou no roteador com um cabo RJ-45 rolado e um adaptador MMOD DB-25. Esta configuração de cabeamento é recomendada e apoiada por Cisco para as portas RJ-45. Estes conectores são etiquetados tipicamente: Modem.

      Há dois tipos da expedição de cabogramas RJ-45: em linha reta e rolado. Se você guarda os dois fins de um RJ-45 cabografam de lado a lado, você verá oito tiras coloridas, ou pinos, em cada extremidade. Se a ordem dos pinos coloridos for a mesma em cada extremidade, o cabo será reto. Se a ordem das cores estiver invertida em cada extremidade, o cabo estará enrolado.

      O cabo enrolado (CAB-500RJ) é padrão com 2500/CS500 de Cisco.

    2. Use o comando show line exec verificar que a expedição de cabogramas está correta. Veja a explicação do comando show line output na seção “que usa comandos Debug” neste capítulo 15.

O Modem de Discagem Receptor não desliga corretamente

  • O modem não está detectando o DTR

    Entre na corda de comando Hangup DTR modem. Este comando diz o modem para deixar cair o portador quando o sinal DTR está sendo recebido já não.

    Em um modem hayes-compatível a corda &D3 é de uso geral configurar o Hangup DTR no modem. Para a sintaxe exata deste comando, veja a documentação para seu modem.

  • O controle do modem não é permitido no roteador ou no servidor de acesso

    1. Use o comando show line exec no servidor de acesso ou no roteador. A saída para o porto auxiliar deve mostrar o inout ou o RIisCD na coluna de modem. Isto indica que o controle do modem está permitido na linha do servidor de acesso ou do roteador.

      Para uma explicação da linha saída da mostra, veja “usando a seção dos comandos Debug” no capítulo 15.

    2. Configurar a linha para o controle do modem usando o comando modem inout line configuration. O controle do modem é permitido agora no servidor de acesso.

    Nota: É certo que usarão o comando modem inout em vez do comando modem dialin quando a Conectividade do modem estiver na pergunta. O último comando permite que a linha aceite chamadas recebidas somente. As chamadas feitas serão recusadas, fazendo o impossível estabelecer uma sessão de Telnet com o modem para configurar-lo. Se você quer permitir o comando modem dialin, faça assim somente depois que você está certo que o modem está funcionando corretamente.

Pesquisando defeitos chamadas externas

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 procura o 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)

Verificando a operação de discador

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 é repleto de recursos 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).

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

  • 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 seguir 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” - não da 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 “o 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 endereço do isthe a.b.c.d 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 executar o comando show ip route [a.b.c.d] verificar 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.

Atendimento não colocado

Alguns problemas possíveis e ações sugeridas estão listados abaixo:

  • 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 aponta 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.

Chamada de saída de Assíncrono - Verifique chat script a operação

Se a chamada externa é uma chamada 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, 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

Chat script os problemas podem quebrar-se em três categorias:

  • Erro de configuração

  • Falha de modem

  • Falha de conexão

Chat script falha

Esta lista mostra que as saídas possíveis de debugam mostras e ações sugeridas de bate-papo:

  • nenhuma harmonização chat script encontrada para o [number]

    A não foi configurado chat script. Adicionar um.

  • Chat script discagem terminada, estado = conexão cronometrada para fora; o host remoto não está respondendo

    O modem não está respondendo ao chat script. Verifique uma comunicação com o modem (refira a tabela 16-2 no capítulo 16).

  • Espera do intervalo: CONNECT

    • 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.

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

    • 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. Se o modem local é externo, gire acima do volume de alto-falante de modem e escute os tons do trainup. Se o trainup é eliminado abruptamente, tente aumentar o valor de timeout no comando chat-script. Se o INTERVALO é já 60 segundos ou mais, veja a seção do trainup de modem.

Chamada de saída ISDN

Após a primeira suspeita de uma falha de ISDN, em um BRI ou 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 a seção Output “interpretando exibição de status de ISDN” no capítulo 16 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 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

!--- The CONNECT message is the key indicator of success. If a CONNECT is not received,
!--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by
!--- a cause code (see below)

*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 de onde no caminho de chamada de ponta a ponta 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 as tabelas que seguem para os significados dos valores diferentes.

Nota: O seguinte impresso indica geralmente 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

Campos de código de causa

A tabela 17-9 alista os campos código causa ISDN que indicam no seguinte formato dentro dos comandos debug:

i=0x y1 y2 z1 z2 [a1 a2]

Campos código causa ISDN

Campo Descrição do valor
0x Os valores que seguem estão no hexadecimal.
y1 Codificação 8--ITU-T padrão.
y2 rede A do usuário remoto 7--International do serviço da rede do usuário remoto 5--Private do serviço da rede da rede 4--Public do usuário local 3--Transit do serviço da rede do usuário local 2--Public do serviço da rede 0--User 1--Private--Ponto de comunicação inter-rede do além da rede
z1 Classe (mais o número hexadecimal significativo) de valor de causa. Refira a tabela seguinte para informações detalhadas sobre dos valores possíveis.
z2 Valor (menos o número hexadecimal significativo) do valor de causa. Refira a tabela seguinte para informações detalhadas sobre dos valores possíveis.
a1 Campo de diagnóstico (opcional) que é sempre 8.
a2 Campo de diagnóstico (opcional) que é um dos seguintes valores: 0--Unknown 1--Permanent 2--Transient

Valores de causa de ISDN

A tabela a seguir alista descrições de alguns da maioria de valores de causa comumente visto do elemento de informação da causa - o terço e os quartos bytes do código de causa. Para informações mais completas sobre dos códigos ISDN e dos valores, refira a compreensão debugam códigos da causa da desconexão do q931 de ISDN.

Valor hexadecimal Causa Explicação
81 Número (unassigned) Unallocated O número ISDN foi enviado ao interruptor no formato correto; contudo, o número não é atribuído a nenhum equipamento de destino.
90 Limpeza normal de chamada O esclarecimento de chamada normal ocorreu.
91 Usuário ocupado O sistema chamado reconhece o pedido de conexão mas é incapaz de aceitar o atendimento porque todos os canais B estão no uso.
92 Nenhum usuário está respondendo A conexão não pode ser terminada porque o destino não responde ao atendimento.
93 Sem resposta do usuário (usuário alertado) O destino responde à solicitação de conexão, mas não completa a conexão dentro do tempo determinado. O problema está na ponta remota da conexão.
95 Chamada rejeitada O destino é capaz de aceitar o atendimento mas rejeitado lhe para uma razão desconhecida.
9C Formato de número inválido A conexão poderia não ser estabelecida porque o endereço de destino foi apresentado em um formato irreconhecível ou porque o endereço de destino estava incompleto.
9F Normal, não especificado Informa a ocorrência de um evento normal quando nenhuma causa padrão se aplica. Nenhuma ação é necessária.
A2 Nenhuns circuito/canal disponível A conexão não pode ser estabelecida porque nenhum canal apropriado está disponível para tomar o atendimento.
A6 A rede não está funcionando O destino não pode ser alcançado porque a rede não está funcionando corretamente, e a circunstância pôde durar por um período de tempo prolongado. Uma tentativa de reconexão imediata será provavelmente mal sucedida.
AC Circuitos /canal solicitado não disponíveis O equipamento remoto não pode oferecer o canal requisitado por uma razão desconhecida. Este pôde ser um problema temporário.
B2 Recurso solicitado não inscrito O equipamento remoto suporta o serviço suplementar requisitado somente por assinatura. Esta é frequentemente uma referência ao serviço interurbano.
B9 Capacidade do portador não autorizada O usuário pediu uma capacidade do portador que a rede fornecesse, mas o usuário não é autorizado a usar. Este pôde ser um problema de assinatura.
D8 Destino incompatível Indica que uma tentativa esteve feita para conectar ao equipamento não-ISDN. Por exemplo, a uma linha analógica.
E0 O elemento de informação obrigatório falta O equipamento de recepção recebeu uma mensagem que não incluísse um dos elementos de informação obrigatórios. Isso geralmente ocorre devido a um erro de canal D. Se este erro ocorre sistematicamente, relate-o a seu fornecedor de serviço de ISDN.
E4 Conteúdos inválidos do elemento de informação O equipamento remoto recebeu uma mensagem que incluísse a informação inválida no elemento de informação. Isso geralmente ocorre devido a um erro de canal D.

Chamada de saída de CAS

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 a verificação da operação de discador.

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:

  • debugar o modem

  • debug modem csm

  • debugar o 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# 
router#modem-mgmt csm no-debug-rbs 
neat msg at slot 0: debug-rbs is off 

Nota: 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. Refira o capítulo 15 para a informação de Troubleshooting T1.

Pesquisando defeitos o PPP

Pesquisar defeitos a parcela PPP de uma conexão começa quando você sabe que a conexão de discagem, o ISDN ou o async, estabelecem com sucesso.

É importante compreender o que um bem sucedido debuga olhares da sequência PPP como antes que você pesquise defeitos a negociação de PPP. Desta maneira, comparando um PPP defeituoso debugar a sessão contra bem sucedido-terminado debugam a sequência PPP salvar o tempo e esforço.

Seguir é um exemplo de uma sequência bem sucedida PPP. Veja detalhes da negociação de PPP LCP para uma descrição detalhada dos campos de saída.

Montecito# 
Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up
Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25
Mar 13 10:57:15.415: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.415: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.415: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.415: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.415: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25
Mar 13 10:57:15.543: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.543: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.543: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.543: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.547: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23
Mar 13 10:57:16.919: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:16.919: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:16.919: As1 LCP:    PFC (0x0702)
Mar 13 10:57:16.919: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: State is Open
Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end
Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4
Mar 13 10:57:17.191: As1 PPP: Phase is UP
Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10
Mar 13 10:57:17.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15
Mar 13 10:57:17.319: As1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
Mar 13 10:57:17.319: As1 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
Mar 13 10:57:17.319: As1 LCP:  (0x80FD0101000F12060000000111050001)
Mar 13 10:57:17.319: As1 LCP:  (0x04)
Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10
Mar 13 10:57:17.319: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1,
 changed state to up
Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd
Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10
Mar 13 10:57:19.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10
Mar 13 10:57:19.315: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34
Mar 13 10:57:20.307: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22
Mar 13 10:57:20.543: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22
Mar 13 10:57:20.547: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: State is Open
Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1

Nota: Seu debuga pode aparecer em um formato diferente. Este exemplo mostra ao formato de emissor mais novo do PPP debugging qual foi alterado na Versão do IOS 11.2(8). Veja o capítulo 16 para um exemplo do PPP debugging com as versões mais velhas dos IO.

Detalhes da negociação de PPP LCP

Selo de tempo Descrição
10:57:15.415 Solicitação de configuração de saída (O CONFREQ). O NAS envia um pacote de requisição da configuração de PPP de saída ao cliente.
10:57:15.543 Reconhecimento entrante da configuração (I CONFACK). O cliente reconhece o pedido PPP do montecito.
10:57:16.919 Solicitação de configuração recebida (I CONFREQ). O cliente quer negociar o protocolo de chamada de volta.
10:57:16.919 Rejeição da configuração de saída (O CONFREJ). O NAS rejeita a opção de chamada de volta.
10:57:17.047 Solicitação de configuração recebida (I CONFREQ). Os pedidos do cliente um conjunto de opções novo. Observe que a rechamada Microsoft não está pedida esta vez.
10:57:17.047 Reconhecimento da configuração de saída (O CONFACK). O NAS aceita o conjunto de opções novo.
10:57:17.047 A negociação de PPP LCP é terminada com sucesso. O estado LCP é “abre”. Os ambos os lados reconheceram (CONFACK) o outro pedido de configuração de lado (CONFREQ).
10:57:17.047 até 10:57:17.191 A autenticação de PPP é terminada com sucesso. Depois que o LCP negocia, a autenticação começa. A autenticação deve ocorrer antes que todos os protocolos de rede, tais como o IP, estejam entregados. Os ambos os lados autenticam com o método negociado durante o LCP. O montecito está autenticando o cliente que usa a RACHADURA.
10:57:20.551 O estado está aberto para o protocolo de controle de IP (IPCP). Uma rota é negociada e instalada para o par IPCP, que é endereço IP atribuído 1.1.1.1.

Link control protocol

Dois tipos de problema são encontrados tipicamente durante a negociação de LCP.

O primeiro ocorre quando um par faz os pedidos de configuração que o outro par não pode nem não reconhecerá. Quando esta for uma ocorrência frequente, pode ser um problema se o solicitador insiste no parâmetro. Um exemplo típico é ao negociar o AUTHTYPE (igualmente conhecido como o “AuthProto”). Por exemplo, muitos servidores de acesso são configurados para aceitar somente a RACHADURA para a autenticação. Se o chamador é configurado para fazer somente a autenticação pap, os CONFREQ e os CONFNAK estarão trocados até um par ou os outro deixam cair a conexão.

BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
...
...

O segundo tipo de problema no LCP é quando somente os CONFREQ de partida são vistos em um ou ambo o par como no exemplo abaixo. Este é geralmente o resultado do que é referido como uma má combinação da velocidade na camada mais baixa. Esta circunstância pode ocorrer no async ou no ISDN DDR.

Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open  
Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25  
Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:57:59.768: As5 LCP: PFC (0x0702)
Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) 
Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 
Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:01.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). 
Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 
Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:03.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) 
Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 

!--- This repeats every two seconds until:

Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 
Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:19.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802)  
Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR

Se a conexão é async, a causa provável é uma má combinação da velocidade entre o roteador e seu modem. Isto é geralmente em consequência da não trava a velocidade DTE do modem à velocidade configurada da linha TTY. O problema pode ser encontrado em qualquer um ou em ambos os pares, assim que verifique ambos. Refira o modem não pode enviar ou receber dados mais cedo neste capítulo.

Se os sintomas são considerados quando a conexão está sobre o ISDN, o problema é provável ser que um par está conectando no 56K quando o outro estiver em 64K. Quando esta circunstância for rara, acontece. O problema podia ser um ou ambo o par, ou possivelmente a companhia telefônica. O uso debuga o q931 de ISDN e examina os mensagens setup em cada um dos pares. A capacidade do portador enviada de um par deve combinar a capacidade do portador considerada no mensagem setup recebido no outro par. Como um remédio possível, configurar a velocidade, o 56K ou o 64K discando, no mapa de discadores do comando interface level ou no comando dialer isdn speed configurado sob uma classe de mapas.

*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

Esta situação é uma que pode justificar um atendimento ao tac Cisco. Recolha as seguintes saídas de ambos os pares antes de chamar o TAC:

  • show running-config

  • show version

  • debug isdn q931

  • debug isdn events

  • negociação de debug ppp

Autenticação

A autenticação falha é a única a maioria de motivo comum para uma falha de PPP. Os nomes de usuário e senha desconfigurados ou combinados mal criam Mensagens de Erro no resultado do debug.

O exemplo seguinte mostra que o username Goleta não tem a permissão discar dentro ao NAS, que não tem um nome de usuário local configurado para este usuário. Para fixar o problema, use o comando username name password password adicionar o username “Goleta” ao banco de dados AAA local do NAS:

Mar 13 11:01:42.399: As2 LCP: State is Open
Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response.  Username Goleta not found
Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure"
Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING

O exemplo seguinte mostra que o username “Goleta” está configurado no NAS. Contudo, a comparação de senha falhada. Para fixar este problema, use o comando username name password password especificar a senha de login correta para Goleta:

Mar 13 11:04:06.843: As3 LCP: State is Open
Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed"
Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING

Para obter mais informações sobre da autenticação pap refira configurar e pesquisando defeitos o protocolo ppp password authentication (PAP).

Protocolo network control

Depois que os pares executaram com sucesso a autenticação requerida, a negociação move-se na fase NCP. Se ambos os pares são configurados corretamente, a negociação de NCP pôde olhar como o exemplo seguinte em que mostra um PC cliente que disca e que negocia com um NAS:

solvang# show debug
Generic IP:
IP peer address activity debugging is on
PPP:
PPP protocol negotiation debugging is on

*Mar  1 21:35:04.186: As4 PPP: Phase is UP
*Mar  1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
*Mar  1 21:35:04.194: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28
*Mar  1 21:35:04.282: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.286: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:04.290: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:04.298: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar  1 21:35:04.310: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15
*Mar  1 21:35:04.318: As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
*Mar  1 21:35:04.318: As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
*Mar  1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
*Mar  1 21:35:04.326: As4 LCP:  (0x80FD0101000F12060000000111050001)
*Mar  1 21:35:04.330: As4 LCP:  (0x04)
*Mar  1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 21:35:04.338: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4,
 changed state to up
*Mar  1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.278: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:07.282: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:07.286: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.298: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.302: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.310: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.430: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.434: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.442: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2
*Mar  1 21:35:07.450: ip_get_pool: As4: using pool default
*Mar  1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2
*Mar  1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
*Mar  1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.462: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.466: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.474: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.478: As4 IPCP: State is Open
*Mar  1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2

Detalhes da negociação de PPP NCP

Selo de tempo Descrição
21:35:04.190 Solicitação de configuração de saída (O CONFREQ). O NAS envia um pacote de requisição da configuração de PPP de saída que contém seu endereço IP de Um ou Mais Servidores Cisco ICM NT ao par.
21:35:04.282 CONFREQ entrante. As solicitações de peer fazer a compressão de cabeçalhos VJ. Precisa um endereço IP de Um ou Mais Servidores Cisco ICM NT para se, assim como endereços dos servidores de DNS principais e secundários.
21:35:04.306 Outbound Config-Reject (CONFREJ). A compressão de cabeçalhos VJ é rejeitada.
21:35:04.314 até 21:35:04.330 O par envia um pedido fazer o protocolo compression control; o protocolo completo é rejeitado pelo NAS por meio de um mensagem protrej. O par não deve (e não faz) tentar experimentar de novo o CCP.
21:35:04.334 O par reconhece o endereço IP de Um ou Mais Servidores Cisco ICM NT do NAS com um CONFACK.
21:35:07.274 CONFREQ entrante. Do par os pedidos já não fazer a compressão de cabeçalhos VJ, mas ainda precisam um endereço IP de Um ou Mais Servidores Cisco ICM NT para se, assim como endereços dos servidores de DNS principais e secundários.
21:35:07.294 O NAS envia um CONFNAK que contêm o endereço que queira o par se usar, e endereços dos servidores de DNS principais e secundários.
21:35:07.426 O par envia os endereços de volta ao NAS; uma tentativa de confirmar que os endereços estiveram recebidos corretamente.
21:35:07.458 O NAS reconhece os endereços com um CONFACK.
21:35:07.478 Cada lado da conexão que emite um CONFACK, negociação termina. O comando show interfaces Async4 no NAS mostra o “IPCP: Abra”.
21:35:07.490 Uma rota do host ao peer remoto é instalada na tabela de roteamento do NAS.

É possível para os pares negociar simultaneamente mais de um protocolo da camada 3. Não é raro, por exemplo, ver o IP e o IPX que estão sendo negociados. É igualmente possível para um protocolo negociar com sucesso quando o outro não faz assim.

Pesquisando defeitos o NCP

Todos os problemas que ocorrerem durante a negociação de NCP podem tipicamente ser seguidos às configurações dos pares de negócio. Se a negociação de PPP falha durante a fase NCP, refira as seguintes etapas:

  1. Verifique a configuração de protocolo da relação

    Examine a saída do privileged exec command show running-config. Verifique que a relação está configurada para apoiar o protocolo que você deseja executar sobre a conexão.

  2. Verifique o endereço da relação

    Confirme que a relação na pergunta tem um endereço configurado. Se usando o [interface-name] unnumbered IP ou o [number] do laço de retorno do PPP-cliente IPX, assegure-se de que a interface referenciada esteja configurada com um endereço.

  3. Verifique a disponibilidade de endereço de cliente

    Se o NAS é suposto para emitir um endereço IP de Um ou Mais Servidores Cisco ICM NT ao chamador, assegure-se de que tal endereço esteja disponível. O endereço IP de Um ou Mais Servidores Cisco ICM NT a ser distribuído ao chamador pode ser obtido com um dos seguintes métodos:

    • Configurar localmente na relação. Verifique a configuração da interface para ver se há o comando peer default ip address a.b.c.d. na prática, este método deve somente ser usado nas relações que aceitam conexões de um único chamador, tal como sobre uma relação do async (não um grupo assíncrono).

    • Conjunto de endereços configurado localmente no NAS. A relação deve ter o comando peer default ip address pool [pool-name]. Além, o pool deve ser definido no nível de sistema com o comando ip local pool [pool-name] [first-address] [last-address]. O intervalo de endereço definido no pool deve ser grande bastante acomodar tantos como chamadores simultâneo-conectados porque o NAS é capaz.

    • Servidor DHCP. A relação NAS deve ser configurada com o comando peer default ip address dhcp. Além disso, o NAS deve ser configurado para apontar a um servidor DHCP com o [address] do DHCP-server do global configuration command ip.

    • AAA. Se usando o TACACS+ ou o RADIUS de autorização, o servidor AAA pode ser configurado para entregar todas as vezes um endereço IP de Um ou Mais Servidores Cisco ICM NT específico a um chamador dado que o chamador conecte. Veja o capítulo 16 para mais informação.

  4. Verifique a configuração de endereço de servidor

    Para retornar os endereços configurados de server do Domain Name Servers ou de Windows NT em resposta aos pedidos do BOOTP, assegure-se de que o [address] do global-level commands async-bootp DNS-server e o [address] do async-bootp nbns-server estejam configurados.

    Nota: Quando o comando async-bootp subnet-mask [mask] puder ser configurado no NAS, a máscara de sub-rede não estará negociada entre o NAS e um cliente de discagem de entrada PC PPP. Devido à natureza das conexões Point-to-Point, o cliente usa automaticamente o endereço IP de Um ou Mais Servidores Cisco ICM NT do NAS (aprendido durante a negociação de IPCP) como o gateway padrão. A máscara de sub-rede não é precisada nesse ambiente Point-to-Point. O PC sabe que se o endereço de destino não combina o endereço local, o pacote deve ser enviado ao gateway padrão (NAS) que é alcançado sempre através do link de PPP.

Antes de chamar o equipe tac do Cisco Systems

Antes de chamar o centro de assistência técnica (TAC) do Cisco Systems, certifique-se de você ter lido com este capítulo e ter terminado as ações sugeridas para seu problema de sistema.

Além disso, faça o seguinte e documente os resultados para que possamos auxiliá-lo melhor:

Para todos os problemas, recolha a saída da executar-configuração da mostra e mostre a versão. Assegure-se de que o comando service timestamps debug datetime msec esteja na configuração.

Para problemas com DDR, recolha o seguinte:

  • mostre o mapa de discadores

  • debug dialer

  • negociação de debug ppp

  • debug ppp authentication

Se o ISDN é involvido, recolha:

  • show isdn status

  • debug isdn q931

  • debug isdn events

Se o Modems é involvido, recolha:

  • mostre linhas

  • mostre a linha [x]

  • mostre o modem (se os modens integrados são involvidos)

  • mostre a versão de modem (se os modens integrados são involvidos)

  • debugar o modem

  • debug modem csm (se os modens integrados são involvidos)

  • debugar o bate-papo (se um cenário DDR)

Se o T1s ou os PRI são involvido, recolha:

  • mostre o T1 do controlador

Discussões relacionadas da comunidade de suporte da Cisco

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


Informações Relacionadas


Document ID: 10203