Fluxograma de Troubleshooting de PPP

Introduction

Este fluxograma auxilia no troubleshooting de Point-to-Point Protocol (PPP), que é amplamente usado para soluções de tecnologia de múltiplo Acesso.

Nos fluxogramas e na saída de exemplo mostrados abaixo, configuramos uma conexão PPP de Interface de Taxa Básica (BRI - Basic Rate Interface) de Rede Digital de Serviços Integrados (ISDN - Integrated Services Digital Network) para outra usando o Roteamento de Discador sob Demanda (DDR - Legacy Dialer-on-Demand Routing). No entanto, as mesmas etapas de Troubleshooting se aplicam a conexões com outros roteadores (como filiais) com conexões PPP ao usar o Dialer Rotary-Group, o Dialer Profile ou o PPP em links seriais.

Para obter mais informações sobre o Point-to-Point Protocol e seus recursos suportados no software Cisco IOS®, consulte Cisco Learning Connection (somente clientes registrados) e pesquise usando a palavra-chave ppp no campo Pesquisar treinamento.

Para obter uma explicação detalhada das diferentes fases da negociação PPP e a saída da negociação debug ppp, consulte Configuração e Troubleshooting do PPP Password Authentication Protocol (PAP).

Prerequisites

Requirements

Certifique-se de atender a estes pré-requisitos:

• Ative debug ppp negotiation e debug ppp authentication.

• Você deve ler e entender a saída da negociação debug ppp. Consulte Como Entender a Saída do Comando debug ppp negotiation para obter mais informações.

• A fase de autenticação do PPP não é iniciada até que a fase do LCP (Link Control Protocol) seja concluída e esteja em estado "aberto". Se debug ppp negotiation não indicar que o LCP está aberto, solucione esse problema antes de continuar.

Componentes Utilizados

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

Terminology

Máquina local (ou roteador local): Esse é o sistema no qual a sessão de depuração está em execução no momento. À medida que você move a sessão de depuração de um roteador para outro, aplique o termo "máquina local" ao outro roteador.

Correspondente: A outra extremidade do enlace ponto-a-ponto. Portanto, este dispositivo não é a máquina local.

Por exemplo, se você executar o comando debug ppp negotiation no RouterA, esta é a máquina local e RouterB é o peer. No entanto, se você transferir a depuração para RouterB, ela se tornará a máquina local e o RouterA se tornará o peer.

Observação: os termos máquina local e peer não implicam uma relação cliente-servidor. Dependendo de onde a sessão de debugação é executada, o cliente de discagem pode ser a máquina local ou o peer.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Fluxogramas de solução de problemas

Este documento inclui alguns fluxogramas para ajudar no Troubleshooting.

Observação: para solucionar problemas com êxito, não ignore nenhuma das etapas mostradas nesses fluxogramas.

Fase do Protocolo de Controle de Enlace (LCP - Link Control Protocol) PPP

Modems assíncronos usados para conectividade PPP

Esta seção explica como os modems assíncronos podem ser usados para conectividade PPP. Os quadros LCP de saída são vistos no roteador local, mas não há quadros LCP de entrada.

Nesse caso, o problema pode ser devido a uma de duas possibilidades:

• Os modems do roteador local e do roteador remoto são acionados, mas o PPP não é iniciado no roteador remoto. Para solucionar esse problema, consulte os modems que fazem o treinamento correto, mas o PPP não inicia na seção Troubleshooting de modems.

• Os modems dos roteadores local e remoto treinam corretamente, e o PPP inicia em ambos os roteadores, mas a chamada cai imediatamente. Isso destrói qualquer chance de receber quadros LCP de entrada de roteadores remotos. Para solucionar esse problema, consulte os modems que fazem o treinamento correto, o PPP inicia, mas a chamada mais tarde cai na seção Troubleshooting de modems.

Para obter informações mais detalhadas sobre a solução de problemas de modem, consulte Troubleshooting de Modems.

Opções de LCP de saída PPP

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

Fase de autenticação PPP

O Point-to-Point Protocol fornece uma fase opcional que garante ao usuário da rede uma transmissão de dados segura para melhorar a segurança da rede. Em alguns links, pode ser desejável exigir que um peer PPP se autentique antes de permitir a troca de pacotes de protocolo da camada de rede. Para qualquer implementação de PPP, a fase de autenticação é opcional por padrão. Se um administrador de rede PPP desejar que o peer PPP use um protocolo de autenticação específico, ele deverá solicitar o uso desse protocolo de autenticação durante a fase PPP LCP. Ou seja, o protocolo de autenticação usado deve ser uma das opções de LCP PPP negociado entre os dois pares PPP.

Neste estágio, somente o LCP do PPP, o protocolo de autenticação e os pacotes de monitoramento da qualidade do enlace são permitidos durante a fase de autenticação. Certifique-se de que não haja problemas neste estágio com nenhum parâmetro negociado por LCP do PPP antes de seguir as etapas de solução de problemas nesta seção.

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

Negociações de PPP NCP

Embora diferentes NCPs (Network Control Protocols, Protocolos de controle de rede) variem muito nos dados sendo negociados, a estrutura geral da conversação é semelhante independentemente dos protocolos que estão sendo usados. Esta seção cobre somente a negociação do protocolo NCP IP (IPCP).

A saída abaixo mostra a saída de depuração para uma negociação de IP bem-sucedida durante a negociação de NCP do PPP:

As4 PPP: Phase is UP
 As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
 As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
 As4 IPCP: I CONFREQ [REQsent] id 1 len 28
 As4 IPCP:    CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
 As4 IPCP:    Address 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 [Not negotiated] id 1 len 15
 As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
 As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
 As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
 As4 LCP:  (0x80FD0101000F12060000000111050001)
 As4 LCP:  (0x04)
 As4 IPCP: I CONFACK [REQsent] id 1 len 10
 As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
 %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up
 As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
 As4 IPCP:    Address 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:    Address 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:    Address 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: validate address = 10.1.2.2
 ip_get_pool: As4: using pool default
 ip_get_pool: As4: returning address = 10.1.2.2
 set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
 As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
 As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
 As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
 As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
 As4 IPCP: State is Open
 As4 IPCP: Install route to 10.1.2.2

O IPCP não entra no estado aberto na fase de negociação do NCP

Problemas de estabilidade de link do PPP

Como indicado no fluxograma abaixo, neste ponto, o link está ativo e passando pacotes, mas não está se comportando como deveria.

Não é possível rotear pacotes sobre um link IP PPP

A saída abaixo mostra a saída do comando show caller user e show ip interface brief quando uma chamada é terminada com êxito e os pacotes IP podem ser enviados ao peer remoto através da conexão PPP.

maui-soho-01#show caller user maui-soho-02 detail
   User: maui-soho-02, line BR0:1, service PPP
   Active time 00:02:21, Idle time 00:00:57
   Timeouts: Absolute Idle
   Limits: - 00:02:00 
   Disconnect in: - 00:01:02 
   PPP: LCP Open, CHAP (local <--> local), IPCP
   LCP: -> peer, AuthProto, MagicNumber
   <- peer, AuthProto, MagicNumber
   NCP: Open IPCP
   IPCP: <- peer, Address
   -> peer, Address
   Dialer: Connected to #, inbound
   Idle timer 120 secs, idle 57 secs
   Type is ISDN, group BRI0
   IP: Local 10.0.1.1/24, remote 10.0.1.2
   Counts: 123 packets input, 3246 bytes, 0 no buffer
   0 input errors, 0 CRC, 0 frame, 0 overrun
   119 packets output, 2940 bytes, 0 underruns
   0 output errors, 0 collisions, 0 interface resets
   maui-soho-01#show ip interface brief
   Interface IP-Address OK? Method Status Protocol
   BRI0 10.0.1.1 YES NVRAM up up 
   BRI0:1 unassigned YES unset up up 
   BRI0:2 unassigned YES unset down down 
   Ethernet0 172.22.53.160 YES NVRAM up up 
   Serial0 unassigned YES NVRAM administratively down down

Erros do pool de IP

Outros problemas de estabilidade de link da PP

Falhas de vinculação da Camada 2 de IP

Informações Relacionadas

• Suporte à tecnologia de discagem e acesso
• Entendendo a saída de negociação de debug ppp
• 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)
• Troubleshooting de Autenticação de PPP (CHAP ou PAP)
• Suporte Técnico e Documentação - Cisco Systems