WAN : Protocolo punto a punto (PPP)

Diagrama de Flujo de Solución de Problemas de PPP

10 Abril 2009 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (18 Diciembre 2007) | Comentarios

Contenidos


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:

    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
       <- 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 IP Pool

    Otros Problemas de Estabilidad del Enlace PP

    Fallas de Enlazado en la Capa 2 de IP


    Discusiones relacionadas de la comunidad de soporte de Cisco

    La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


    Document ID: 42887