PPP antes de levantar la interfaz que va hacia el dispositivo vecino, este negocia opciones del enlace mediante el protocolo LCP. Dentro de las especificaciones encontramos lo siguiente:

LCP posee 3 variedades de paquetes, los cuales son:

  • Link Configuration Packets: usados para establecer y configurar un enlace, donde se encuentran los siguientes mensajes:
  • Configure-Request: utilizado para abrir una conexión con el vecino, donde se indican las opciones que se van a usar: un tipo de autenticación, MP, Callback, entro otros.
  • Configure-Ack: enviado para aceptar todos los valores de las opciones enviadas en un Configure-Request. Cuando ambos peer aceptan las configuraciones de cada uno (reciben un paquete Configure-Ack), finaliza la negociación de LCP.
  • Configure-Nak: utilizado cuando no se soporta una característica definida en un Configure-Request, pero se ofrece una característica que puede reemplazar las anteriores (se realiza una negociación).
  • Configure-Reject: similar al Configure-Nak, pero esta en este caso no se ofrece nada para reemplazar la característica rechazada.
  • Link Termination Packets: utilizados para finalizar la sesión del enlace, y se pueden encontrar los siguientes mensajes:
  • Terminate-Request: utilizado para indicar que se quiere cerrar la conexión con el peer. Este mensaje es enviado hasta recibir un Terminate-Ack.
  • Terminate-Ack: mensaje enviado para responder a un Termite-Request.
  • Link Maintenance Packets: usados para administrar y depurar el enlace. Podemos encontrar los siguientes mensajes:
  • Code-Reject: utilizado para indicar que se recibió un código desconocido, lo cual puede deberse a que el peer utiliza otra versión del protocolo.
  • Protocol-Reject: enviado cuando se recibe un paquete PPP con un valor del campo Protocol desconocido, indicando que el peer está intentando utilizar un protocolo que no es compatible con PPP.
  • Echo-Request: enviado para proveer un mecanismo anti-loop en el enlace de datos.
  • Echo-Reply: usado para responder el mensaje Echo-Request.
  • Discard-Request: mensaje utilizado para hacer pruebas de salida.

De los mensajes indicados, los Link Configuration Packets corresponden a los utilizados para establecer el enlace con el peer.

Formato LCP

A continuación, se deja el formato de un mensaje LCP:

Como podemos ver en la imagen anterior, los mensajes LCP posee los siguientes campos:

  • Code: campo de un 1 byte y que representa que tipo de paquete LCP se está enviando. Estos valores son definidos por números:
  1. Configure-Request
  2. Configure-Ack
  3. Configure-Nak
  4. Configure-Reject
  5. Terminate-Request
  6. Terminate-Ack
  7. Code-Reject
  8. Protocol-Reject
  9. Echo-Request
  10. Echo-Reply
  11. Discard-Request
  • Identifier: 1 byte que permite hacer coincidir los requests con los replies. Si se recibe un valor no valido, el mensaje es descartado.
  • Length: 2 bytes que indican la longitud del mensaje LCP.
  • Data: dependiendo del valor del código, es como se encuentra estructurado este campo.

Establecimiento de sesión PPP

El establecimiento de sesión PPP se encuentra dividido en 3 fases, las cuales son:

  1. Establecimiento de enlace y negociación de configuración: lo primero que se hace antes de enviar algún datagrama (como un paquete IP), es abrir una conexión y negociar las opciones de configuración mediante LCP. Una vez se reciba un Configure-Ack esta fase finaliza.
  2. Determinar la calidad del enlace (opcional): LCP tiene la capacidad de validar la calidad del enlace para enviar tráfico de la capa de red.
  3. Negociación de la configuración del protocolo de la capa de red: cuando LCP termina su función de la negociación con el peer y de verificar la calidad del enlace es tiempo de que NCP cumpla su función. NCP configura los protocolos de capa de red que se utilizarán, donde este puede activarlos y desactivarlos en cualquier momento.

Verificación de negociación LCP

En los equipos Cisco, para poder validar la negociación del protocolo PPP, se utiliza el comando debug ppp negotiation:

R1#debug ppp negotiation 
PPP protocol negotiation debugging is on
R1#
*Jun 25 01:05:08.367: PPP: Alloc Context [68AD348C]
*Jun 25 01:05:08.371: ppp2 PPP: Phase is ESTABLISHING
*Jun 25 01:05:08.371: Se1/0 PPP: Using default call direction
*Jun 25 01:05:08.371: Se1/0 PPP: Treating connection as a dedicated line
*Jun 25 01:05:08.371: Se1/0 PPP: Session handle[91000002] Session id[2]
*Jun 25 01:05:08.371: Se1/0 LCP: Event[OPEN] State[Initial to Starting]
*Jun 25 01:05:08.375: Se1/0 LCP: O CONFREQ [Starting] id 1 len 10
*Jun 25 01:05:08.375: Se1/0 LCP:    MagicNumber 0x011CF58C (0x0506011CF58C)
*Jun 25 01:05:08.379: Se1/0 LCP: Event[UP] State[Starting to REQsent]
R1#
*Jun 25 01:05:10.355: Se1/0 LCP: O CONFREQ [REQsent] id 2 len 10
*Jun 25 01:05:10.359: Se1/0 LCP:    MagicNumber 0x011CF58C (0x0506011CF58C)
*Jun 25 01:05:10.359: Se1/0 LCP: Event[Timeout+] State[REQsent to REQsent]
*Jun 25 01:05:10.491: Se1/0 LCP: I CONFREQ [REQsent] id 1 len 10
*Jun 25 01:05:10.491: Se1/0 LCP:    MagicNumber 0x021CFEBF (0x0506021CFEBF)
*Jun 25 01:05:10.495: Se1/0 LCP: O CONFACK [REQsent] id 1 len 10
*Jun 25 01:05:10.495: Se1/0 LCP:    MagicNumber 0x021CFEBF (0x0506021CFEBF)
*Jun 25 01:05:10.495: Se1/0 LCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
*Jun 25 01:05:10.499: Se1/0 LCP: I CONFACK [ACKsent] id 2 len 10
*Jun 25 01:05:10.503: Se1/0 LCP:    MagicNumber 0x011CF58C (0x0506011CF58C)
*Jun 25 01:05:10.503: Se1/0 LCP: Event[Receive ConfAck] State[ACKsent to Open]
*Jun 25 01:05:10.515: Se1/0 PPP: Phase is FORWARDING, Attempting Forward
*Jun 25 01:05:10.519: Se1/0 LCP: State is Open
*Jun 25 01:05:10.567: Se1/0 PPP: Phase is ESTABLISHING, Finish 
R1#LCP
*Jun 25 01:05:10.567: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up
*Jun 25 01:05:10.567: Se1/0 PPP: Outbound cdp packet dropped, line protocol not up
*Jun 25 01:05:10.583: Se1/0 PPP: Phase is UP
*Jun 25 01:05:10.591: Se1/0 CDPCP: Protocol configured, start CP. state[Initial]
*Jun 25 01:05:10.599: Se1/0 CDPCP: Event[OPEN] State[Initial to Starting]
*Jun 25 01:05:10.603: Se1/0 CDPCP: O CONFREQ [Starting] id 1 len 4
*Jun 25 01:05:10.607: Se1/0 CDPCP: Event[UP] State[Starting to REQsent]
*Jun 25 01:05:10.615: Se1/0 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Jun 25 01:05:10.619: Se1/0 CDPCP: O CONFACK [REQsent] id 1 len 4
*Jun 25 01:05:10.619: Se1/0 CDPCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
*Jun 25 01:05:10.643: Se1/0 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Jun 25 01:05:10.643: Se1/0 CDPCP: Event[Receive ConfAck] State[ACKsent to Open]
*Jun 25 01:05:10.647: Se1/0 CDPCP: State is Open

En color azul podemos ver un Configure-Request enviado por R1 y respondido por un Configure-Ack (esto validado por el Magic Number), y viceversa se puede ver en rosado, donde R1 recibe un Configure-Request y este responde un Configure-Ack.