Point-to-Point Protocol – Part. 2
W0lf_F4ng W0lf_F4ng /assets/img/point-to-point-protocol-part-2/ppp.jpeg
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:
- Callback: es una característica que se configura para restablecer llamadas.
- PPP Multilink Protocol (MP): es una agregación de enlaces en PPP.
- Autenticación: LCP define si se va a autenticar o no, y si se autentica, cual protocolo usar (PAP o CHAP).
- Magic Number: este número es utilizado para detectar loops en el enlace, además de otras anomalías del enlace.
- Compression: define si se va a comprimir el campo protocol o los campos de dirección y control.
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 qué tipo de paquete LCP se está enviando. Estos valores son definidos por números:
- Configure-Request
- Configure-Ack
- Configure-Nak
- Configure-Reject
- Terminate-Request
- Terminate-Ack
- Code-Reject
- Protocol-Reject
- Echo-Request
- Echo-Reply
- 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:
- 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.
- 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.
- 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.
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:
- Callback: es una característica que se configura para restablecer llamadas.
- PPP Multilink Protocol (MP): es una agregación de enlaces en PPP.
- Autenticación: LCP define si se va a autenticar o no, y si se autentica, cual protocolo usar (PAP o CHAP).
- Magic Number: este número es utilizado para detectar loops en el enlace, además de otras anomalías del enlace.
- Compression: define si se va a comprimir el campo protocol o los campos de dirección y control.
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 qué tipo de paquete LCP se está enviando. Estos valores son definidos por números:
- Configure-Request
- Configure-Ack
- Configure-Nak
- Configure-Reject
- Terminate-Request
- Terminate-Ack
- Code-Reject
- Protocol-Reject
- Echo-Request
- Echo-Reply
- 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:
- 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.
- 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.
- 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.