WAN : Protocolo punto a punto (PPP)

Diagrama de Flujo de Solución de Problemas de PPP

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (10 Abril 2009) | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este diagrama de flujo lo ayuda a resolver problemas del Point-to-Point Protocol (PPP), que es ampliamente utilizado para diversas soluciones de tecnología de Acceso.

En los diagramas de flujo y el ejemplo de salida que se muestran a continuación, hemos configurado una conexión PPP con interfaz de velocidad básica (BRI) de la Red Digital de Servicios Integrados (ISDN) a otra mediante Legacy Dialer-on-Demand Routing (DDR). Sin embargo, los mismos pasos de solución de problemas se aplican a conexiones a otros routers (como sucursales) con conexiones PPP, cuando se utiliza Dialer Rotary-Group, Dialer Profile o PPP en enlaces seriales.

Para más información sobre el protocolo Point-to-Point, y sus características admitidas en el software del ½ del ¿Â de Cisco IOSïÂ, refiera a la conexión de aprendizaje de Cisco (clientes registrados solamente) y a la búsqueda usando palabra clave ppp adentro la búsqueda para el campo de entrenamiento.

Para una explicación detallada de las diversas fases de negociación de PPP y de la salida de la negociación ppp del debug, refiera a configurar y a resolver problemas el protocolo ppp password authentication (PAP).

prerrequisitos

Requisitos

Aseegurese le resolver estos requisitos previos:

  • Active debug ppp negotiation y debug ppp authentication.

  • Usted debe leer y entender los resultados de la negociación ppp del debug. Refiérase a Cómo Comprender la Salida de debug ppp negotiation para obtener más información.

  • La fase de la autenticación PPP no comienza hasta que la fase del (LCP) del Link Control Protocol sea completa y esté en el estado “abierto”. Si la negociación ppp del debug no indica que el LCP está abierto, resuelva problemas este problema antes de que usted proceda.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Terminología

Máquina local (o router local): Sistema donde actualmente se está ejecutando la sesión de depuración. Al trasladar la sesión de debug de un router a otro, utilice el término "máquina local" para el otro router.

Entidad par: El otro extremo del link punto a punto. Por lo tanto, este dispositivo no es la máquina local.

Por ejemplo, si usted ejecuta el comando debug ppp negotiation en el RouterA, éste será la máquina local y el RouterB será el par. Sin embargo, si cambia el debugging al RouterB, entonces éste pasará a ser la máquina local y el RouterA, el par.

Nota: Los términos máquina local y par no implican una relación cliente-servidor. Según dónde se ejecute la sesión de debug, el cliente de marcado puede ser la máquina local o el par.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Diagramas de flujo de Troubleshooting

Este documento comprende algunos diagramas de flujo de utilidad en la resolución de problemas.

Nota: Para resolver problemas con éxito, no salte los pasos uces de los mostrados en estos organigramas.

Fase de Link Control Protocol (LCP) de PPP

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

Módems Asíncronos utilizados para una Conectividad PPP

Esta sesión explica cómo pueden utilizarse los Módems Asíncronos para una conectividad PPP. Las tramas de salida del LCP pueden verse en el router local, pero no hay tramas de entrada del LCP.

En este caso, el problema podría deberse a una de dos posibilidades:

Para información más detallada sobre el troubleshooting del módem, refiera a los módems del troubleshooting.

Opciones de Salida del LCP de PPP

El siguiente diagrama de flujo destaca varios de los parámetros LCP de PPP más comunes que pueden negociarse durante la fase de LCP. Este diagrama de flujo lo ayuda a localizar qué parámetros de LCP su máquina local PPP no está negociando con el par remoto PPP.

ppp-tshoot-gen-02.gif

Fase de Autenticación de PPP

El Point-to-Point Protocol proporciona una fase opcional que garantiza al usuario de red una transmisión de datos segura, para mejorar la seguridad de la red. En algunos enlaces puede ser conveniente requerir que un par PPP se autentique antes de permitir el intercambio de paquetes del protocolo de la capa de red. Para cualquier implementación PPP, la fase de autenticación es opcional, de forma predeterminada. Si un administrador de red PPP desea que el par PPP utilice un protocolo de autenticación específico, debe solicitar el uso de dicho protocolo durante la fase LCP de PPP. Es decir, el protocolo de autenticación utilizado debe ser una de las opciones LCP de PPP negociadas entre ambos pares PPP.

En esta etapa, durante la fase de autenticación, sólo se admiten los paquetes de control de calidad del enlace, del protocolo de autenticación y el LCP de PPP. Asegúrese de que en esta etapa no haya problemas con ninguno de los parámetros negociados de LCP de PPP antes de seguir los pasos de solución de problemas indicados en esta sección.

Para obtener información detallada sobre la solución de problemas en la fase de autenticación de PPP, consulte el diagrama de flujo de Solución de Problemas de Autenticación de PPP (CHAP o PAP).

Negociaciones NCP de PPP

Si bien los diferentes Network Control Protocols (NCP) varían considerablemente con respecto a los datos que se negocian, la estructura general de la conversación es similar, independientemente de los protocolos que se utilizan. Esta sección sólo abarca la negociación IP del protocolo NCP (IPCP).

ppp-tshoot-gen-03.gif

El siguiente ejemplo es la salida del comando debug de una negociación IP exitosa durante la negociación NCP de 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

El IPCP No Pasa a Estado Abierto en la Fase de Negociación NCP

ppp-tshoot-gen-04.gif

Problemas de Estabilidad del Enlace PPP

Como se indica en el diagrama de flujo a continuación, en esta instancia, el enlace está activo y transmitiendo paquetes, pero no se comporta como debería.

ppp-tshoot-gen-05.gif

Imposibilidad de Rutear Paquetes a Través de un Enlace PPP de IP

ppp-tshoot-gen-06.gif

La salida abajo muestra que el caller user y el comando show ip interface brief de la demostración hacen salir cuando una llamada se termina con éxito y los paquetes del IP se pueden enviar al peer remoto sobre la conexión 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

Errores de Agrupación IP

ppp-tshoot-gen-07.gif

Otros Problemas de Estabilidad del Enlace PP

ppp-tshoot-gen-08.gif

Fallas de Enlazado en la Capa 2 de IP

ppp-tshoot-gen-09.gif


Información Relacionada


Document ID: 42887