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 sus características soportadas en el Cisco IOS® Software, refiérase a Cisco Learning Connection (sólo clientes registrados) y busque usando la palabra clave ppp en el campo Buscar formación.
Para obtener una explicación detallada de las diferentes fases de la negociación PPP y el resultado de la negociación debug ppp, consulte Configuración y resolución de problemas del protocolo de autenticación de contraseña PPP (PAP).
Asegúrese de cumplir estos requisitos previos:
Active debug ppp negotiation y debug ppp authentication.
Debe leer y comprender el resultado de debug ppp negotiation. Refiérase a Cómo Comprender la Salida de debug ppp negotiation para obtener más información.
La fase de autenticación PPP no comienza hasta que la fase del protocolo de control de enlaces (LCP) se complete y se encuentre en estado "abierto". Si debug ppp negotiation no indica que el LCP está abierto, resuelva este problema antes de continuar.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
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.
Este documento comprende algunos diagramas de flujo de utilidad en la resolución de problemas.
Nota: Para resolver problemas correctamente, no omita ninguno de los pasos que se muestran en estos diagramas de flujo.
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 resolución de problemas del módem, consulte Resolución de problemas de módems.
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.
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).
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).
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
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.
El resultado a continuación muestra la salida del comando show caller user y show ip interface brief cuando una llamada se termina correctamente y los paquetes IP se pueden enviar 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 <- 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
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
18-Dec-2007 |
Versión inicial |