Fluxograma de Troubleshooting de ISDN BRI
Contents
Introduction
Este documento ajuda a fazer Troubleshooting de acesso dialup de BRI (Interface de Taxa Básica) de ISDN. Na saída de exemplo e no fluxograma mostrados abaixo, configuramos uma conexão ISDN BRI para outra conexão usando Perfis de Discador. Entretanto, as mesmas etapas de Troubleshooting aplicam-se às conexões com outros roteadores (como filiais) e ao usar o Legacy Dial-on-Demand Routing (DDR).
Note: Você também pode usar a Comunidade de Suporte da Cisco para ajudá-lo a resolver seu problema de ISDN.
Para obter informações introdutórias sobre ISDN e DDR, consulte o treinamento de áudio localizado na Cisco Learning Connection.
Fluxograma
Clique em um link a seguir para obter mais informações sobre o item. Utilize o botão de voltar do seu navegador para retornar a esse fluxograma.
Troubleshooting: Como Iniciar Sessão e Capturar Estas Debugações
Você pode se conectar ao roteador através do cabo de console conectado à porta serial do PC ou usando telnet.
Se necessitar conectar o switch usando o console, consulte Aplicando as definições corretas do simulador de terminal para conexões de console. Se o roteador já estiver configurado para conectividade na Ethernet e você quiser conectá-lo usando Telnet, basta usar um cliente Telnet para se conectar ao endereço IP de Ethernet do roteador.
Em qualquer um dos casos (console ou Telnet), é melhor usar um cliente que permita manter um histórico da saída recebida durante a sessão, já que talvez seja necessário rolar de volta a saída de depurações para procurar mensagens específicas.
Ative milissegundos na saída de debugação e mensagens de log. Quando solicitado, insira a senha configurada no roteador e insira o modo de ativação:
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Se você estiver conectado via telnet, digite o monitor de terminal da seguinte forma:
router#terminal monitor router#
Em seguida, digite os comandos debug abaixo:
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
Em seguida, inicie o ping no roteador que chama. Veja abaixo um exemplo de saída de depuração de uma chamada bem-sucedida. As fases diferentes, conforme identificado no fluxograma, estão destacadas.
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
Voltar ao fluxograma de Troubleshooting
Troubleshooting: O roteador tenta discar?
Para descobrir se o roteador tenta fazer uma chamada, verifique se você tem as seguintes linhas na saída de debugação do roteador de chamada:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
Na saída de debugação, 8134 é o número de diretório ISDN que o roteador está tentando discar. Este número foi especificado usando o comando dialer string ou dialer map.
Voltar ao fluxograma de Troubleshooting
Sintoma: O roteador não tenta discar
Se o roteador não estiver tentando discar, haverá várias possibilidades:
Nenhuma Saída de Debugação
Se não houver nenhuma saída de depuração, muito provavelmente o pacote IP que você está enviando ainda não está roteado para a interface do Discador. As causas mais comuns para isto são:
- Verifique se o IP está configurado na interface do discador. É necessário ter um endereço IP na interface do discador ou na interface de IP sem número (onde interface é uma interface up/up tal como Ethernet x, Loopback x, etc.) ou ter um endereço IP negociado (se o cliente obterá um endereço IP do NAS). Se usar o DDR de legado, o endereço IP deve ser configurado na interface física (exemplo, interface BRI 0).
- Verifique se o comando ip routing está configurado. Ao observar a configuração utilizando o comando show running-config, você não deve ver o comando no ip routing.
- Verifique se há uma rota estática apontando para a interface do discador ou o próximo salto (em caso de utilização dos mapas de discador).
O exemplo abaixo (de perfil de discador) é uma rota estática para 172.22.53.0/24 com Next Hop Dialer 1:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
O seguinte exemplo (para DDR anterior) é uma rota estática para 172.22.53.0/24 com próximo salto 172.16.1.1. O endereço do próximo salto deve corresponder ao endereço de IP na instrução de mapeamento de discador utilizada para a discagem:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- Verifique se o discador ou a interface física não está desativado administrativamente ou no estado de espera. Use o comando show interface dialer X ou show interface bri X para garantir que a interface está no estado up/up (falsificação).
Se a interface estiver administrativamente fora do ar, use o comando no shutdown no modo de configuração da interface.
Se a interface estiver em modo de espera, o discador ou a interface BRI será um backup para uma conexão ativa. É possível remover o comando backup interface da interface principal ou desconectar o cabo de tal interface.
Há saída de depuração, mas nenhuma mensagem Attempting to Dial
Nesse caso, provavelmente há um pacote IP roteado para a interface, mas o roteador o descarta e não inicia a chamada por algum motivo. Examine a saída do comando debug para descobrir por que não é feita a tentativa de chamada. Abaixo estão algumas saídas de debugação e suas possíveis razões:
Exemplo 1
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
O tráfego gerado não corresponde à definição de tráfego interessante. Para esse exemplo, modifique a lista de acesso 101.
Uma definição de tráfego interessante simples seria permitir todo o tráfego IP como em:
maui-soho-01(config)#dialer-list 1 protocol ip permit
aviso: A marcação de todo o tráfego IP como interessante pode causar a atividade indefinida do link ISDN, especialmente se você tiver um protocolo de roteamento ou outro tráfego periódico. Ajuste a definição de tráfego interessante de acordo com suas necessidades.
Para obter mais informação sobre o tráfego interessante, consulte o documento Tecnologia de Dial-up: Visões Gerais e Explicações.
Exemplo 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (no dialer-group defined).
Não existe um grupo de discagem configurado na interface do discador. Adicione um grupo de discadores como neste exemplo:
interface Dialer1 dialer-group X
Note: O valor de X deve ser o mesmo utilizado com o comando dialer-list.
Exemplo 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (dialer-list 1 not defined).
Há uma instrução dialer-group na interface do discador, mas a lista de discadores consultada não existe. Configure a lista de discador conforme o exemplo a seguir:
dialer-list X protocol ip permit
Note: O valor de X deve ser mesmo utilizado com o comando dialer-group na interface do discador.
Exemplo 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.
Neste caso, o pacote de saída deve ser considerado interessante o bastante para ativar o enlace, mas não há nenhuma interface física disponível para realizar a chamada. Certifique-se de que dialer pool-member X esteja configurado na interface física e o conjunto de discadores X esteja configurado na interface do discador. Exemplo:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
Além disso, verifique se a interface BRI não está no estado de desligamento.
Exemplo 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.
Nesse caso, nenhuma série do discador está configurada na interface do discador. O roteador deseja fazer uma chamada, mas não sabe qual número de diretório ISDN chamar. Defina uma série do discador:
interface Dialer1 dialer string 8134
Para obter mais informações sobre troubleshooting, consulte a seção "O Roteador de Chamada não envia uma mensagem SETUP" do documento Troubleshooting da Camada 3 BRI ISDN Utilizando o Comando debug isdn q931.
Voltar ao fluxograma de Troubleshooting
Troubleshooting: A chamada ISDN conecta-se com êxito?
A fim de identificar se a chamada ISDN está conectada, procure uma mensagem CONNECT_ACK e %LINK-3-UPDOWN nas depurações.
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
Se você vir esta mensagem, sua chamada ISDN foi conectada com sucesso e você pode prosseguir para a próxima etapa. Se você não visualizar uma mensagem como essa, leia a seguir para ver as possíveis causas.
Voltar ao fluxograma de Troubleshooting
Sintoma: A Conexão da Chamada ISDN Não Foi Bem-Sucedida
- Se você observar uma saída similar à seguinte, verifique se o cabo de ISDN está conectado no roteador e na tomada Telco.
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- Verifique se o circuito de ISDN está funcionando adequadamente. Use o comando show isdn status para verificar se a Camada 1 está ACTIVE, a Camada 2 está MULTIPLE_FRAME_ESTABLISHED e os SPIDs (se necessários) são válidos. Para obter mais informações, consulte o documento Utilização do Comando show isdn status em Troubleshooting BRI.
Se você tiver a saída de um comando show isdn status de seu dispositivo Cisco, poderá usar o Cisco CLI Analyzer para exibir possíveis problemas e correções. Para usar o Cisco CLI Analyzer, você deve ser um usuário registrado, estar conectado e ter o JavaScript habilitado. - Verifique se a string configurada do discador IDSDN está correta. Tenha sempre em mente que você pode ter que adicionar um zero, nove ou outros dígitos iniciais para obter uma linha externa ao estar conectado por meio de um PBX.
- Se a conexão utilizar uma portadora de longa distância, entre em contato com a empresa de telecomunicações local e o provedor de longa distância para verificar se o serviço está ativo. Geralmente, a Telco local tem o circuito ISDN configurado inadequadamente, de maneira que as chamadas ISDN externas de longa distância não são comutadas para a rede correta do provedor de longa distância. Você também deve verificar se a rede de provedores de longa distância está funcionando.
Nos EUA e em situações nas quais a Telco ou o provedor de longa distância não consegue corrigir o problema, você pode usar uma portadora Interexchange pré-assinada (PIC). Códigos PIC são prefixos de 7 dígitos que identificam companhias de longa distância dos Estados Unidos para as portadoras de intercâmbio locais (LEC). Isso permite que os clientes usem diferentes portadoras de longa distância para chamadas individuais. O código PIC está configurado como um prefixo para o número discado. A maioria dos PICs apresenta formato 1010xxx.
Não utilize nenhuma série xxxxx e nenhum mapa de discador para remover o número existente e, em seguida, configure o novo número.
Por exemplo, a série do discador 10103215125551111.
- Procure uma mensagem de desconexão ISDN.
O software Cisco IOS® decodifica o código de causa nesta mensagem de desconexão e fornece uma mensagem de texto sem formatação, que freqüentemente contém informações úteis que levam à causa do problema. As séries que você pode encontrar aqui incluem:
- Número não alocado ou não atribuído
- Destino incompatível (ambas indicam que o número discado talvez esteja incorreto)
- Número ocupado (que indica que o lado chamado está ocupado)
- Falha temporária (que indica uma falta temporária na rede Telco)
Para descobrir a possível causa de uma desconexão específica, consulte Códigos de Causa de Desconexão de debug isdn q931.
Por exemplo, uma desconexão devido a um número ISDN incorreto pode ser indicada com:
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
Consultando o documento Códigos de Causa de Desconexão mencionado anteriormente, podemos determinar se o código de desconexão foi causado por uma tentativa de conexão com um equipamento não ISDN (por exemplo, uma linha analógica).
Uma desconexão devido a um número formatado incorretamente pode ser indicada por:
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)Consultando o documento Noções Básicas Sobre Códigos de Causa de Desconexão debug isdn q931, podemos determinar se o código de desconexão foi causado por um formato inválido para o número ISDN remoto. Há falha na conexão porque o endereço de destino é apresentado (ao switch) em um formato irreconhecível, ou o endereço de destino está incompleto.
O seguinte exemplo mostra uma chamada rejeitada devido a um número ISDN incorreto:
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- Se a sua empresa de telecomunicações tiver fornecido identificadores de perfis de serviço (SPIDs) a serem usados, certifique-se de que esses SPIDs estejam configurados na interface BRI. Os SPIDs só costumam ser utilizados nos EUA e com tipos de switch NI e DMS (tipos de switch 5ess não precisam de SPIDs).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
É possível usar o comando show isdn status para verificar se os SPIDs estão corretos.
Para obter mais informações, consulte o documento Troubleshooting de SPIDs BRI ISDN.
Se você tiver a saída de um comando show isdn status de seu dispositivo Cisco, poderá usar o Cisco CLI Analyzer para exibir possíveis problemas e correções. Para usar o Cisco CLI Analyzer, você deve ser um usuário registrado, estar conectado e ter o JavaScript habilitado. - Se o procedimento acima não tiver resolvido o problema, use o documento Troubleshooting ISDN BRI Layer 3 using the debug isdn q931 Command.
Voltar ao fluxograma de Troubleshooting
Troubleshooting: A fase PPP LCP se realiza com sucesso?
Na saída da depuração, você deve ver uma linha de mensagem para o seguinte:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
Se você vir essa linha, isso indica que o protocolo de controle de enlace (LCP) foi negociado com êxito. Qualquer outro estado que não seja aberto indica falha de LCP.
Voltar ao fluxograma de Troubleshooting
Sintoma: Fase LCP PPP não obteve sucesso
Possível causa: O PPP não está configurado
Caso tenha uma saída de depuração similar às linhas a seguir, é uma indicação de que o PPP não foi iniciado.
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
Observe, pela saída de depuração, que o roteador não envia nenhuma mensagem PPP CONFREQ. Isso provavelmente ocorreu porque a interface não foi configurada para encapsulamento de PPP.
Nesse caso, verifique se você configurou o comando encapsulation ppp na interface do discador e na interface física. A seguir, estão alguns exemplos:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
Possível causa: Incompatibilidade de velocidade ISDN
Algumas vezes, você pode ver apenas mensagens LCP CONFREQ de saída, e nenhuma mensagem LCP de entrada. Um exemplo é mostrado abaixo:
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
Esse problema pode ter sido causado por:
- A extremidade remota não está configurada para PPP. Configure o comando encapsulation ppp no lado remoto
- Pacotes que não estão chegando aos meios de transmissão. A causa mais comum para isso é uma incompatibilidade de velocidade ISDN
A natureza do problema, em relação à ISDN, é que provavelmente um lado está conectado a 56k enquanto o outro lado está conectado a 64k. É possível que o circuito local ou remoto não ofereça suporte às conexões padrões de 64K. Tente configurar ambos os lados para execução em 56k.
Para perfis de discagem:
maui-soho-01(config)#interface Dialer1 maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
Para DDR existente (mapas de discador):
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
Possível causa: Os dois roteadores não concordam sobre o protocolo de autenticação (CHAP ou PAP) a ser usado
Caso haja saída de depuração similar às linhas a seguir, é uma indicação de que o roteador e o lado remoto não concordam sobre o protocolo de autenticação a ser usado:
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
Nesse caso, verifique se você configurou o seguinte:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
Para obter mais informações sobre CHAP (Protocolo de autenticação de handshake de desafio) ou PAP (Protocolo de autenticação de senha), consulte os documentos a seguir:
- Entendendo e configurando a autenticação de PPP CHAP
- Autenticação PPP Usando os Comandos ppp chap hostname e ppp authentication chap callin
- Configurando e Troubleshooting de PPP Password Authentication Protocol (PAP)
Você também pode usar a Comunidade de Suporte da Cisco para Troubleshooting adicional de PPP.
Voltar ao fluxograma de Troubleshooting
Troubleshooting: A Autenticação de PPP foi Bem-sucedida?
Verifique a saída da depuração para uma linha semelhante a esta:
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
Voltar ao fluxograma de Troubleshooting
Sintoma: Autenticação de PPP Mal-Sucedida
Verifique se configurou as seguintes linhas:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
No exemplo, XXXXX é o nome de usuário e YYYYY é a senha.
Note: Configure apenas o nome de usuário e a senha para o método de autenticação empregado por você e o peer. Por exemplo, se ambos não utilizarão o PAP, o comando ppp pap sent-username não é necessário. No entanto, se você não tiver certeza de que o peer oferece suporte a PAP ou CHAP, configure os dois.
Dependendo da versão do software Cisco IOS e da configuração, a senha pode ser mostrada criptografada na configuração. Se for esse o caso, ao executar um comando show running-configuration, você verá a palavra "password" seguida do dígito 7 e, em seguida, uma seqüência de números, como no exemplo a seguir:
interface Dialer1 ppp chap password 7 140005
Neste caso, não é possível verificar se a senha configurada está correta ou não analisando a configuração. Para verificar se a senha está correta, basta entrar no modo de configuração e remover e configurar novamente a senha. Para identificar uma falha de senha na depuração, compare sua saída de depuração com a saída de amostra abaixo.
Se este roteador autenticar o correspondente, assegure de configurar o comando username username password password, sendo que username é o nome fornecido pelo roteador do correspondente para autenticação.
Exemplo 1
Uma mensagem como esta abaixo significa que a senha CHAP é inválida.
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
Tip: An incoming CHAP failure (indicated by CHAP: I FAILURE) significa que o correspondente não foi capaz de autenticar o roteador. Utilize o comando debug ppp negotiation no roteador correspondente para determinar a causa exata da falha.
Para obter mais informações, consulte o documento Autenticação PPP Utilizando os Comandos ppp chap hostname e ppp authentication chap callin.
Exemplo 2
Uma mensagem como a exibida abaixo pode significar que o nome de usuário CHAP não é válido:
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
Tip: An incoming CHAP failure (indicated by CHAP: I FAILURE) significa que o correspondente não foi capaz de autenticar o roteador. Utilize o comando debug ppp negotiation no roteador correspondente para determinar a causa exata da falha.
Para obter mais informações, consulte o documento Autenticação PPP Usando os Comandos ppp chap hostname e ppp authentication chap callin.
Exemplo 3
Uma mensagem como a exibida abaixo significa que a senha PAP não é válida:
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
Para obter mais informações, consulte o documento Configurando e Troubleshooting de PPP Password Authentication Protocol (PAP).
Exemplo 4
Uma mensagem como a abaixo significa que o nome de usuário não é válido:
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
Para obter mais informações, consulte o documento Configurando e Troubleshooting de PPP Password Authentication Protocol (PAP).
Você também pode usar a Comunidade de Suporte da Cisco para obter mais troubleshooting de PPP.
Voltar ao fluxograma de Troubleshooting
Troubleshooting: A Fase PPP NCP (IPCP) É Concluída?
O elemento principal negociado no IPCP é cada endereço de peer. Before IPCP negotiation, each peer is in one of two possible states; tem um endereço IP ou não. Se o peer já possuir um endereço, tal endereço será enviado em um CONFREQ para o outro correspondente. Se o endereço for aceitável ao outro peer, uma mensagem CONFACKis é retornada. Se o endereço não for aceitável, a resposta será um CONFNAK contendo um endereço para o peer usar.
Essa é a única fase que não pode ser adequadamente identificada pela análise de apenas uma linha. Para assegurar que o IP Control Protocol (IPCP) esteja ativado corretamente, você precisa verificar se os endereços IP foram negociados em ambos os sentidos. Procure na sua depuração as seguintes linhas:
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
e
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
e
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
Esses três conjuntos de linhas podem não ser consecutivos. É importante que você verifique se há um Configure Acknowledge (O CONFACK) de saída que tenha, entre outras opções, um endereço abaixo dele.
Deve haver também um I CONFACK com outro endereço IP abaixo dele.
Finalmente, deve existir uma linha declarando que o IPCP está aberto. Depois disso, você deve ser capaz de executar ping em ambos os endereços IP diretamente do roteador.
Voltar ao fluxograma de Troubleshooting
Sintoma: Negociação PPP NCP (IPCP) Malsucedida
Problema: Falha na negociação de endereço IP
Uma das razões pelas quais IPCP pode falhar se deve a uma falha na negociação do endereço IP. Por exemplo, o NAS pode tentar atribuir um endereço ao cliente enquanto o roteador cliente tem um endereço IP diferente configurado ou outro problema comum é quando o cliente solicita um endereço e o NAS não tem nenhum endereço disponível para o cliente.
No roteador de chamada:
Se o roteador chamado atribuir dinamicamente um endereço IP ao roteador de chamada, verifique se você negociou o comando ip address na interface do discador.
Se o provedor de NAS/ISP forneceu um endereço IP estático, verifique se este endereço IP (e máscara de sub-rede) está configurado na interface do discador com o comando ip address address subnet_mask.
No roteador chamado:
Verifique se a interface que controla a conexão (por exemplo, Discador int. x) tem um endereço IP e se está atribuindo um endereço ao peer, usando o comando peer default ip address address.
Note: Se houver um endereço IP configurado para o roteador cliente, não será necessário atribuir um endereço utilizando o comando peer default ip address.
Para obter mais informações, consulte o documento Tecnologia de Dial-up: Técnicas para Troubleshooting.
Problema: O roteador chamado falha na ligação do perfil do discador
Se o nome de usuário autenticado não corresponder ao nome remoto do discador configurado na interface do discador, a chamada será desconectada pelo roteador chamado. O seguinte é um exemplo de saída do discador de depuração para tal erro:
No roteador de chamada:
A seguinte depuração mostra uma desconexão causada por uma associação de perfil de discador inválido no roteador chamado.
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
Note: As debugações no lado chamado não ajudam no troubleshooting desse problema, senão para indicar que o peer desconectou a chamada. Mova o troubleshooting para o roteador chamado.
No roteador chamado:
A depuração a seguir exibe uma falha na chamada devido a problemas de ligação com o perfil do discador:
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
Solução:
Configure o comando dialer pool number na interface do discador. O número do pool deve corresponder ao número do pool configurado na interface física.
Configure o comando de nome remoto do discador na interface do discador. O nome especificado deve corresponder exatamente ao nome de usuário fornecido pelo roteador remoto para autenticação. Nesse exemplo, o nome de usuário autenticado é maui-soho-03.
Para obter mais informações sobre Troubleshooting sobre problemas de vinculação, consulte o documento Configuração e Troubleshooting de Perfis de Discador.
Você também pode usar a Comunidade de Suporte da Cisco para Troubleshooting adicional de PPP.
Voltar ao fluxograma de Troubleshooting
Solução de problemas pós-conexão
Sintoma: A chamada foi desconectada prematuramente ou a chamada não foi totalmente desconectada
Se a chamada for desconectada inesperadamente ou a chamada jamais se desconectar, verifique o timeout de ociosidade do discador e a definição de tráfego interessante. Você pode usar o comando debug dialer packet para ver se um pacote em particular é interessante ou não. Por exemplo:
Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, outgoing uninteresting (list 101) Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes, outgoing interesting (list 101)
No exemplo acima, as saudações de OSPF são desinteressantes por lista de acesso 101, enquanto o segundo pacote é interessante por lista de acesso 101.
- Ajuste o dialer idle-timeout na configuração da interface do discador. O padrão é 120 segundos, mas você pode aumentar ou diminuir esse valor dependendo de suas necessidades.
- Alterar a definição de tráfego interessante (configurada com o comando dialer-list). Se a chamada desconectar antes do tempo, talvez você precise definir de forma mais livre o tráfego que seja de interesse. Se a chamada nunca desconectar, altere a definição do tráfego de interesse para ser mais restritivo. Por exemplo, você pode definir o tráfego do Routing Protocol como desinteressante. Aqui há um exemplo de definição interessante de tráfego:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1Para obter mais informações, consulte o documento Tecnologia de Dial-up: Visões Gerais e Explicações.
Sintoma: O Roteador Disca a Conexão Periodicamente
Em certas situações, você poderá observar que o roteador periodicamente disca a conexão, mesmo que não haja nenhum tráfego de usuário aparente requisitando que o enlace seja ativado. Isto pode resultar em altas cobranças de tarifas nas quais o serviço ISDN é cobrado por minuto.
A causa mais comum é que um processo que gera tráfego periódico (como Routing Protocol, NTP, SNMP, etc) pode ser designado inadvertidamente como interessante. O Troubleshooting deste problema requer duas etapas:
- Identificar o tráfego que está provocando a discagem do link.
- Designe esse tráfego como não interessante.
Identificar o tráfego que está provocando a discagem do link.
Para identificar o tráfego que faz o enlace discar, é necessário habilitar o comando debug dialer packet. Monitore o roteador enquanto o link ISDN estiver desativado e aguarde um tráfego interessante periódico que tenta ativar o link.
Tip: Exceto quando especificamente necessário, designe todos os protocolos de roteamento configurados no roteador como não interessantes.
O exemplo a seguir mostra as saudações OSPF periódicas que estão sendo marcadas como interessantes:
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
A única maneira de identificar que o pacote acima é um hello OSPF é a partir do endereço de destino (d=224.0.0.5) definido para OSPF. A tabela a seguir lista os endereços utilizados para alguns Routing Protocols comuns.
|
Routing Protocol
|
Endereço de Destino para Periódico Atualizações ou Keepalives |
|
RIPv1
|
255.255.255.255
|
|
RIPv2
|
224.0.0.9
|
|
EIGRP
|
224.0.0.10
|
|
OSPF
|
224.0.0.5
|
O tráfego que causa a discagem do roteador (procol de roteamento ou outro tráfego periódico) deve ser marcado como não interessante.
Designar o Tráfego Periódico como Não Interessante
Alterar a definição de tráfego interessante (configurada com o comando dialer-list). Neste exemplo, defina o tráfego OSPF e NTP como desinteressante. Aqui há um exemplo de definição interessante de tráfego:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
Para obter mais informações, consulte o documento Tecnologia de Dial-up: Visões Gerais e Explicações.
Note: O OSPF possui um recurso chamado circuito de demanda que também pode ser utilizado aqui. Consulte o documento Por que o Circuito de Demanda OSPF Continua Ativando o Link para obter mais informações
Sintoma: O canal Segundo B não se Conecta
Em diversas instâncias, o roteador pode se conectar somente em um canal B, enquanto o outro canal B permanece ocioso. Para obter mais informações sobre o troubleshooting desse problema, consulte o documento Troubleshooting de Falhas na Chamada do canal Segundo B em Links BRI ISDN.
Problemas de conectividade de IP
Se o link ISDN vier ativado mas você não puder passar o tráfego pelo link, o problema deverá ser um roteamento ou relacionado a NAT. Consulte a Comunidade de Suporte da Cisco para obter mais informações sobre solução de problemas.
Se você estiver utilizando o link ISDN como backup para uma conexão WAN, consulte o documento Configuração e Troubleshooting de Backup DDR.
Informações Relacionadas
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)