Fluxograma de Solução de Problemas de PPP

Fluxograma de Solução de Problemas de PPP
Índice
Introdução Antes de Começar
Convenções Pré-requisitos Componentes Utilizados Terminologia
Fluxogramas de Solução de Problemas
Fase do Protocolo de Controle de Link PPP (LCP) Opções LCP de Saída PPP Fase de Autenticação de PPP Negociações NCP de
PPP IPCP Não Entra em Estado Aberto na Fase de Negociação NCP Problemas de Estabilidade de Link PPP Não Pode Rotear
Pacotes Por um Link PPP IP Erros de Pool de IP Outros Problemas de Estabilidade de Link PP Falhas de Vinculação da Camada 2
de IP
Informações Relacionadas
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
© 1992-2014 Cisco Systems Inc. Todos os direitos reservados.
Data da Geração do PDF: 22 Maio 2008
http://www.cisco.com/cisco/web/support/BR/8/86/86099_ppp_tshoot_gen.html