WAN : Point-to-Point Protocol (PPP)

Fluxograma de Solução de Problemas de PPP

22 Maio 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (18 Dezembro 2007) | Feedback


Índice


Introdução

Este fluxograma ajuda a Solucionar problemas de Point-to-Point Protocol (PPP), amplamente utilizado por soluções de tecnologia de Acesso múltiplas.

Neste fluxograma e saída de exemplo exibidos abaixo, definimos uma conexão PPP de interface de taxa básica (BRI) de Rede Digital de serviços Integrados (ISDN) para outra utilização do Roteamento de Discagem por Demanda Antigo (DDR). Entretanto, as mesmas etapas de solução de problemas aplicam-se às conexões com outros roteadores (como filiais) com conexões PPP quando utilizam o Grupo Giratório do Discador, Perfil do Discador ou PPP através de links seriais.

Para mais informações sobre o Protocolo de Ponto-a-Ponto e seus recursos suportados no Cisco IOS Software, consulte Conexão de Aprendizagem do Cisco (você deve ser um cliente registrado e conectado), e pesquisar utilizando a palavra-chave ppp no campo Pesquisa para treinamento.

Para uma explicação detalhada das diferentes fases da negociação PPP e da saída de debug ppp negotiation, consulte o documento Entendendo a Saída do Comando debug ppp negotiation.

Antes de Começar

Convenções

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

Pré-requisitos

Certifique-se de que você atende aos seguintes pré-requisitos:

  • Habilitar debug ppp negotiation e debug ppp authentication.

  • Você deve estar apto a ler e entender a saída debug ppp negotiation. Consulte o documento Entendendo a Saída do Comando debug ppp negotiation para mais informações.

  • A fase de autenticação de PPP não começa até que a fase de LCP (Protocolo de Controle de Link) esteja concluída e esteja em um estado “aberto”. Se o comando debug ppp negotiation não indicar que o LCP está aberto, solucione este problema antes de continuar.

Componentes Usados

Este documento não está restrito a versões específicas de software e de hardware.

    Terminologia

    Máquina local (ou roteador local): Este é o sistema em que a sessão de depuração está sendo executada atualmente. Conforme você move a sessão de depuração de um roteador para o outro, aplique o termo "máquina local" ao outro roteador.

    Correspondente: A outra extremidade do link de ponto-a-ponto. Portanto, este dispositivo não está na máquina local.

    Por exemplo, se você executar o comando debug ppp negotiation no RoteadorA, está é a máquina local, e o RoteadorB é o correspondente. Entretanto, se você deslocar a depuração pelo RoteadorB, este se torna a máquina local e o RoteadorA se torna o correspondente.

    Observação: Os termos máquina local e correspondente não implicam em um relacionamento cliente-servidor. Dependendo de onde seja executada a sessão de depuração, o cliente de discagem poderia ser a máquina local ou o correspondente.

    Fluxograma de Solução de Problemas

    Este documento inclui alguns fluxogramas para ajudar na solução de problemas. Vá para o próximo fluxograma, clicando nos círculos numerados.

    Observação: Para que a solução de problemas seja bem-sucedida, não pule nenhuma das etapas exibidas nesses fluxogramas.

    Fase LCP (Protocolo de Controle de Link) PPP

    Modems Assíncronos utilizados para Conectividade de PPP

    Esta seção explica como os Modems Assíncronos podem utilizar a conectividade de PPP. Os quadros LCP enviados são visualizados no roteador local, mas não há quadros LCP recebidos.

    Neste caso, o problema poderia ser devido a uma de duas possibilidades:

    • Os modems do roteador local e do roteador remoto são treinados, mas o PPP não inicializa no roteador remoto. Para solucionar este problema, consulte a seção Modems são bem treinados, mas o PPP não inicializa no documento Solucionando Problemas de Modems.

    • Os modems do roteador local e do roteador remoto são bem treinados, e o PPP inicializa em ambos os roteadores, mas a chamada cai imediatamente. Isto destrói qualquer chance de recebimento de quadros LCP de roteadores remotos. Para solucionar este problema, consulte a seção Modems são bem treinados, o PPP inicializa, mas a chamada cai posteriormente no documento Solucionando Problemas de Modems.

    Para mais informações detalhadas sobre Solução de problemas de modem, consulte o documento Solucionando Problemas de Modems.

    Opções LCP de Saída PPP

    O fluxograma abaixo destaca vários dos parâmetros LCP mais comuns de PPP que podem ser negociados durante a fase LCP. Este fluxograma auxilia a localizar quais parâmetros LCP a sua máquina local de PPP não está negociando com o correspondente remoto de PPP.

    Fase de autenticação de PPP

    O Protocolo de Ponto-a-Ponto fornece uma fase opcional que garante que ao usuário de rede uma transmissão segura de dados para aprimorar a segurança de rede. Em alguns links, pode ser desejável solicitar um correspondente PPP para autenticá-lo antes de permitir que os pacotes de protocolo de camada de rede sejam trocados. Para qualquer implementação de PPP, a fase de autenticação é opcional por padrão. Se um administrador de rede PPP desejar que o correspondente PPP utilize um protocolo de autenticação específico, ele deve solicitar a utilização daquele protocolo de autenticação durante a fase LCP PPP. Ou seja, o protocolo de autenticação utilizado deve ser uma das opções LCP PPP negociadas entre os correspondentes de PPP.

    Neste estágio, apenas o LCP PPP, o protocolo de autenticação e os pacotes de monitoramento de qualidade de link são permitidos durante a fase de autenticação. Certifique-se de que não há problemas neste estágio com quaisquer parâmetros de LCP PPP negociados antes de seguir as etapas para a solução de problemas nesta seção.

    Para informações detalhadas de solução de problemas sobre problemas na fase de autenticação de PPP, consulte Solucionando PPP (CHAP ou PAP) fluxograma de Autenticação.

    Negociações de PPP NCP

    Enquanto diferentes Protocolos de Controle de Rede (NCPs) apresentam uma grande variação nos dados que estão sendo negociados, a estrutura geral da conversação é semelhante, independente dos protocolos que estão sendo utilizados. Esta seção aborda apenas a negociação do protocolo NCP (IPCP) IP.

    A seguinte saída mostra a saída de depuração de uma negociação de IP bem-sucedida durante a negociação NCP PPP.

     As4 PPP: A fase está ATIVADA
    As4 IPCP: O CONFREQ [Não negociado] id 1 len 10
    As4 IPCP: Endereço 10.1.2.1 (0x03060A010201)
    As4 IPCP: I CONFREQ [REQsent] id 1 len 28
    As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
    As4 IPCP: Endereço 0.0.0.0 (0x030600000000)
    As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
    As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
    As4 IPCP: O CONFREJ [REQsent] id 1 len 10
    As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
    As4 CCP: I CONFREQ [Não negociado] id 1 len 15
    As4 CCP: Bits suportados MS-PPC 0x00000001 (0x120600000001)
    As4 CCP: Histórico do empilhador 1 modo de verificação ESTENDIDO (0x1105000104)
    As4 LCP: O PROTREJ [Aberto] id 3 len 21 protocol CCP
    As4 LCP: (0x80FD0101000F12060000000111050001)
    As4 LCP: (0x04)
    As4 IPCP: I CONFACK [REQsent] id 1 len 10
    As4 IPCP: Endereço 10.1.2.1 (0x03060A010201)
    %LINEPROTO-5-UPDOWN: Protocolo de linha na Interface Async4, alterou o estado para ativado
    As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
    As4 IPCP: Endereço 0.0.0.0 (0x030600000000)
    As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
    As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
    As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
    As4 IPCP: Endereço 10.1.2.2 (0x03060A010202)
    As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203)
    As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301)
    As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
    As4 IPCP: Endereço 10.1.2.2 (0x03060A010202)
    As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203)
    As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301)
    ip_get_pool: As4: endereço validado = 10.1.2.2
    ip_get_pool: As4: utilizando pool padrão
    ip_get_pool: As4: endereço de retorno = 10.1.2.2
    set_ip_peer_addr: As4: endereço = 10.1.2.2 (3) é redundante
    As4 IPCP: O CONFNAK [ACKrcvd] id 3 len 22
    As4 IPCP: Endereço 10.1.2.2 (0x03060A010202)
    As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203)
    As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301)
    As4 IPCP: O estado é Aberto
    As4 IPCP: Instalar a rota no 10.1.2.2

    O IPCP Não Entra no Estado Aberto na Fase de Negociação de NCP

    Problemas de Estabilidade de Link PPP

    Conforme mostrado no fluxograma abaixo, neste ponto, o link está ativado e enviando pacotes, mas não está se comportando como deveria.

    Não Pode Rotear Pacotes Por um Link PPP IP

    A saída abaixo exibe os comandos show caller user e show ip interface brief quando uma chamada é terminada de forma bem-sucedida e os pacotes IP podem ser enviados para o correspondente remoto pela conexão de PPP.

       maui-soho-01#show caller user maui-soho-02 detail
       Usuário: maui-soho-02, linha BR0:1, serviço PPP
    
       Tempo ativo 00:02:21, Tempo ociosos 00:00:57
    
       Intervalos: Ociosidade Absoluta
    
       Limites: - 00:02:00 
    
       Desconexão em: - 00:01:02 
    
       PPP: LCP Aberto, CHAP (local <--> local), IPCP
    
       LCP: -> peer, AuthProto, MagicNumber
    
       <- peer, AuthProto, MagicNumber
    
       NCP: IPCP Aberto
    
       IPCP: <- correspondente, Endereço
    
       <- correspondente, Endereço
    
       Discador Conectado a #, entrada
    
       Temporizador de ociosidade 120 seg, ocioso 57 seg
    
       O tipo é ISDN, grupo BRI0
    
       IP: Local 10.0.1.1/24, remoto 10.0.1.2
    
       Contas: 123 pacotes de entrada, 3246 bytes, 0 sem buffer
    
       0 erros de entrada, 0 CRC, 0 quadros, 0 excessivos, 0 ignorados
    
       Saída de 119 pacotes, 2940 bytes, 0 perdas por ausência de execução
    
       0 erros de saída, 0 colisões, 0 reinicializações de interface
       maui-soho-01#show ip interface brief
    
       Endereço de IP de Interface IP-OK? Protocolos de Status de Métodos
    
       BRI0 10.0.1.1 YES NVRAM up up 
    
       BRI0:1 não atribuído YES up up não definido 
    
       BRI0:2 não atribuído YES down down não definido 
    
       Ethernet0 172.22.53.160 YES NVRAM up up 
    
       Serial0 não atribuído YES NVRAM administrativamente down down 
    
        
    
        
    
        
    
      
    
    

    Erros de Pool de IP

    Outros Problemas de Estabilidade de Link PP

    Falhas de Vinculação de Camada 2 de IP


    Discussões relacionadas da comunidade de suporte da Cisco

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


    Document ID: 42887