WAN : Point-to-Point Protocol (PPP)

Fluxograma do Troubleshooting de PPP

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Tradução Manual (22 Maio 2008) | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

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 no exemplo de saída mostrados abaixo, nós estabelecemos uma conexão PPP do Basic Rate Interface (BRI) do Integrated Services Digital Network (ISDN) a um outro Dialer-on-Demand Routing (DDR) de utilização do legado (DDR). Contudo, os mesmos passos de Troubleshooting aplicam-se às conexões ao outro Roteadores (tal como escritórios filiais) com as conexões PPP ao usar o grupo giratório do dialer, o perfil do discador, ou o PPP sobre enlaces serial.

Para mais informações sobre do protocolo Point-to-Point, e das suas características suportadas no software do ½ do ¿  de Cisco IOSïÂ, refira a conexão de aprendizagem do Cisco (clientes registrados somente) e a busca usando as palavras-chave PPP na busca para o campo de treinamento.

Para uma explicação detalhada das fases diferentes de negociação de PPP e da saída de debugar a negociação ppp, refira configurar e pesquisando defeitos o protocolo ppp password authentication (PAP).

Pré-requisitos

Requisitos

Certifique-se que você encontra estas condições prévias:

  • Ative debug ppp negotiation e debug ppp authentication.

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

  • A fase da autenticação de PPP não começa até que a fase do protocolo de controle de link (LCP) esteja completa e esteja em “abrir” o estado. Se debugar a negociação ppp não indica que o LCP está aberto, pesquisa defeitos esta edição antes que você continue.

Componentes Utilizados

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

Terminologia

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

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

Por exemplo, se você executa o comando debug ppp negotiation no roteadorA, esta é a máquina local, e o roteadorB é o par. Contudo, se você desloca a eliminação de erros sobre ao roteadorB, a seguir assenta bem na máquina local e o roteadorA assenta bem no par.

Nota: Os termos máquina local e peer não implicam em 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.

Convenções

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

Fluxogramas de Troubleshooting

Este documento inclui alguns fluxogramas para ajudar no Troubleshooting.

Nota: A fim pesquisar defeitos com sucesso, não salte algumas das etapas mostradas nestes fluxogramas.

Fase do protocolo ppp link control (LCP)

/image/gif/paws/42887/ppp-tshoot-gen-01.gif

Modens assíncronos usados para a conectividade de PPP

Esta seção explica como os modens assíncronos podem ser usados para a conectividade de PPP. Os quadros que parte LCP são considerados no roteador local, mas não há nenhum quadro entrante LCP.

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

Para informações mais detalhadas sobre do Troubleshooting do modem, refira pesquisando defeitos o Modems.

Opções LCP de Saída PPP

O fluxograma abaixo destaca diversos da maioria de parâmetros PPP LCP comuns que podem ser negociados durante a fase LCP. Este fluxograma ajuda-o a localizar que os parâmetros LCP sua máquina local PPP não estão negociando com o peer remoto PPP.

ppp-tshoot-gen-02.gif

Fase da autenticação de PPP

O protocolo Point-to-Point fornece uma fase opcional que garanta o usuário de rede uma transmissão de dados fixada para aumentar a segurança de rede. Em alguns links pode ser desejável exigir um par PPP autenticar-se antes de permitir que os pacotes do protocolo de camada de rede sejam trocados. Para toda a implementação PPP, a fase de autenticação é opcional à revelia. Se um administrador de rede PPP quer o par PPP usar um protocolo de autenticação específico, deve pedir o uso desse protocolo de autenticação durante a fase PPP LCP. Isto é, o protocolo de autenticação usado deve ser uma das opções PPP LCP negociadas entre ambos os pares PPP.

Nesta fase, somente o PPP LCP, protocolo de autenticação, e pacotes do monitoramento de qualidade de link é permitido durante a fase de autenticação. Assegure-se de que não haja nenhum problema nesta fase com nenhuns parâmetros LCP-negociados PPP antes de seguir os passos de Troubleshooting nesta seção.

Para informação de Troubleshooting detalhada para problemas da fase da autenticação de PPP, refira pesquisando defeitos o fluxograma da autenticação PPP (RACHADURA ou PAP).

Negociações de PPP NCP

Quando os protocolos network control diferentes (NCP) variarem extremamente nos dados que estão sendo negociados, a estrutura total da conversação é similar não importa o que os protocolos estão sendo usados. Esta seção cobre somente a negociação de protocolo IP (IPCP) NCP.

ppp-tshoot-gen-03.gif

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

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 em aberto na fase da negociação de NCP

ppp-tshoot-gen-04.gif

Problemas de estabilidade do link de PPP

Como exposto no fluxograma abaixo, neste momento, o link é ascendente e passando pacotes, mas não se está comportando como ele deva.

ppp-tshoot-gen-05.gif

Não podem os pacotes de rota sobre um link de PPP IP

ppp-tshoot-gen-06.gif

A saída abaixo mostra que o caller user e o comando show ip interface brief da mostra output quando um atendimento está terminado com sucesso e os pacotes IP podem ser enviados ao peer remoto sobre a 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 IP pool

ppp-tshoot-gen-07.gif

Outros problemas de estabilidade do link PP

ppp-tshoot-gen-08.gif

Falhas do ligamento da camada IP 2

ppp-tshoot-gen-09.gif


Informações Relacionadas


Document ID: 42887