Diagrama de Flujo de Solución de Problemas de PPP Contenidos Introducción Antes de Comenzar Convenciones Prerrequisitos Componentes Utilizados Terminología Diagramas de Flujo de Solución de Problemas Fase de Link Control Protocol (LCP) de PPP Opciones de Salida del LCP de PPP Fase de Autenticación de PPP Negociaciones NCP de PPP El IPCP No Pasa a Estado Abierto en la Fase de Negociación NCP Problemas de Estabilidad del Enlace PPP Imposibilidad de Rutear Paquetes a Través de un Enlace PPP de IP Errores de IP Pool Otros Problemas de Estabilidad del Enlace PP Fallas de Enlazado en la Capa 2 de IP

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 obtener más información sobre el Point-to-Point Protocol y las características soportadas por el software Cisco IOS®, consulte Conexión de Aprendizaje de Cisco (debe ser un cliente registrado y haber iniciado sesión), y realice una búsqueda utilizando la palabra clave ppp en el campo Search for training (Buscar capacitación). Para obtener una explicación detallada de las diferentes fases de negociación de PPP y la salida del comando debug ppp negotiation, consulte el documento Introducción a la Salida del Comando debug ppp negotiation.

Antes de Comenzar Convenciones Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Prerrequisitos Asegúrese de cumplir con los siguientes prerrequisitos: Active debug ppp negotiation y debug ppp authentication. Es necesario que pueda leer y entender la salida del comando debug ppp negotiation. Consulte el documento Introducción a la Salida del Comando debug ppp negotiation para más información. La fase de autenticación de PPP no comienza hasta que la fase de Link Control Protocol (LCP) esté completa y en estado "abierto". Si debug ppp negotiation no indica que el LCP está abierto, solucione este problema antes de continuar.

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

Terminología Máquina local (o router local): Sistema donde actualmente se está ejecutando la sesión de debugging. Al trasladar la sesión de debug de un router a otro, utilice el término "máquina local" para el otro router. Peer: El otro extremo del enlace 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 peer. Sin embargo, si cambia el debugging al RouterB, entonces éste pasará a ser la máquina local y el RouterA, el peer. Nota: Los términos máquina local y peer no implican una relación cliente-servidor. Según dónde se ejecute la sesión de debug, el cliente dialin puede ser la máquina local o el peer.

Diagramas de Flujo de Solución de Problemas Este documento comprende algunos diagramas de flujo de utilidad en la solución de problemas. Haga clic en los círculos numerados para continuar con el siguiente diagrama de flujo. Nota: Para resolver los problemas con éxito, no saltee ninguno de los pasos indicados en estos diagramas de flujo.

Fase de Link Control Protocol (LCP) de PPP

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: Los módems del router local y el router remoto se activan, pero el PPP no comienza en el router remoto. Para resolver este problema, consulte la sección Los módems se activan correctamente, pero el PPP no comienza en el documento Solución de Problemas de Módems. Los módems de los routers local y remoto se activan correctamente y el PPP comienza en ambos, pero la llamada se pierde inmediatamente. Esto imposibilita la recepción de tramas de entrada del LCP de routers remotos. Para resolver este problema, consulte la sección Los módems se activan correctamente y el PPP comienza, pero luego se pierde la llamada en el documento Solución de Problemas de Módems.

Para obtener información más detallada sobre la solución de problemas de módems, consulte el documento Solución de Problemas de Módems.

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 peer remoto PPP.

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 peer 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 peer 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 peers 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 (NCPs) 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).

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

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.

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

El siguiente ejemplo muestra la salida de los comandos show caller user y show ip interface brief cuando una llamada finaliza con éxito y los paquetes IP pueden enviarse al par remoto a través de 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