CiscoOSPFRouting

Mensajes OSPF

Al igual que los otros protocolos de enrutamiento dinámicos, OSPF utiliza mensajes para poder transportar información de su funcionamiento.

Los paquetes de los mensajes que utiliza OSPF son:

  • Tipo 1: Hello
  • Tipo 2: Database Description (DBD)
  • Tipo 3: Link-State Request (LSR)
  • Tipo 4: Link-State Update (LSU)
  • Tipo 5: Link-State Acknowledgement (LSAck)

Todos los paquetes de OSPF comparten el mismo encabezado, donde en IPv4 posee 24 bytes, mientras que en IPv6 tiene 16 bytes.

A continuación, se detalla el encabezado de OSPFv2:

  • Version (1 byte): indica la versión de OSPF, que en este caso es 2.
  • Type (1 byte): indica el tipo de paquete OSPF, donde el valor varía entre 1 y 5.
  • Packet length (2 bytes): longitud del paquete OSPF (en bytes), incluyendo el header.
  • Router ID (4 bytes): RID del router que crea el paquete OSPF.
  • Area ID (4 bytes): área a la cual pertenece la interfaz del router OSPF.
  • Checksum (2 bytes): es utilizado para determinar la integridad del paquete OSPF. Es necesario tener en cuenta que este campo es utilizado siempre y cuando no se tenga habilitado la autenticación, si se encuentra habilitado, su valor es 0 (none).
  • Auth type (2 bytes): especifica el tipo de autenticación del protocolo, donde este puede ser: 0 = Null, 1 = Simple password, 2 = Cryptographic authentication.
  • Authentication (8 bytes): campo usado por el esquema de autenticación.

Encabezado de OSPFv3:

  • Version (1 byte): indica la versión de OSPF, que en este caso es 3.
  • Type (1 byte): indica el tipo de paquete OSPF, donde el valor varía entre 1 y 5.
  • Packet length (2 bytes): longitud del paquete OSPF (en bytes), incluyendo el header.
  • Router ID (4 bytes): RID del router que crea el paquete OSPF.
  • Area ID (4 bytes): área a la cual pertenece la interfaz del router OSPF.
  • Checksum (2 bytes): es utilizado para determinar la integridad del paquete OSPF.
  • Instance ID (1 byte): valor que tiene significado local, el cual identifica las múltiples instancias de OSPF que corren por el enlace.
  • 0 (reservado, 1 byte): campo ignorado cuando es recibido en paquete OSPF, y está compuesto de puros 0’s.

Paquetes Hello

Los paquetes Hello son los primeros mensajes enviados por cada router que trabaja con OSPF, el cual es utilizado para formar adyacencias y como un mecanismo de keepalive.

El intercambio de estos paquetes esta supervisado por el protocolo Hello, el cual indica que cuando un router recibe un mensaje Hello de su vecino, y contiene el nombre del router local en la sección Neighbor, se posee una comunicación bidireccional entre ambos equipos (comunicación o estado two-way).

Dentro del paquete Hello de OSPFv2 se encuentran los siguientes parámetros:

  • Network mask (4 bytes): corresponde a la máscara de la red configurada en la interfaz en donde se origina el paquete Hello.
  • Hello interval (2 bytes): número de segundos que el router debe esperar para enviar un mensaje Hello.
  • Options (1 byte): campo utilizado para habilitar capacidades opcionales de OSPF. Este campo se encuentra en todos los paquetes OSPF.
  • Router priority (1 byte): usado para elegir al DR/BDR del segmento, si este es configurado en 0, no se participa de esta elección.
  • Router dead interval (4 bytes): la cantidad de segundos antes de declarar a un router OSPF abajo.
  • Designated Router (4 bytes): identifica al router designado de la red. Si el valor es 0.0.0.0, significa que no se tiene DR.
  • Backup Designated Router (4 bytes): identifica al router designado de respaldo de la red. Si el valor es 0.0.0.0, significa que no se tiene BDR.
  • Neighbor (campo variable): identifica cada router vecino, del cual se recibió un mensaje Hello.

Con respecto al mensaje Hello en OSPFv3, se cambia el campo Network mask por el de Interface ID, el cual es utilizado para identificar la interfaz del router. también cambia la cantidad de bytes asignados al campo Option, que ahora es de 3 bytes, y el Router dead interval es de 2 bytes.

Es necesario tener en cuenta que el TTL de los paquetes Hello es de 1, y según la versión del protocolo, cambia su dirección MAC e IP de destino (estos valores pueden cambiar según el tipo de red de OSPF y la configuración que se aplique):

  • IPv4 de destino: 224.0.0.5 (identifica a todos los routers OSPF)
  • IPv6 de destino: FF02::5 (identifica a todos los routers OSPF)
  • MAC de destino en IPv4: 01:00:5E:00:00:05
  • MAC de destino en IPv6: 33:33:00:00:00:05

A continuación, se deja un mensaje Hello de IPv4 y de IPv6, donde se puede ver el vecino de dicha comunicación:

IPv4:

IPv6:

Cuando se empieza el proceso de vecindad entre dos routers OSPF, es muy importante que los siguientes parámetros coincidan:

  • Intervalo de Hello/Dead
  • Área (valor encontrado en el header de OSPF)
  • Máscara de subred (este valor no se toma en cuenta en redes Point-to-Point)
  • Autenticación
  • Stub tag

Para poder detectar problemas en el intercambio de paquetes Hello, se puede usar el comando debug ip ospf hello:

R1#debug ip ospf hello
OSPF hello debugging is on
R1#
*May 16 14:32:28.475: OSPF-1 HELLO Fa0/0: Send hello to 224.0.0.5 area 0 from 192.168.10.1
R1#
*May 16 14:32:34.071: OSPF-1 HELLO Fa0/0: Rcv hello from 192.168.10.2 area 0 192.168.10.2
R1#
*May 16 14:32:37.583: OSPF-1 HELLO Fa0/0: Send hello to 224.0.0.5 area 0 from 192.168.10.1
R1#
*May 16 14:32:43.623: OSPF-1 HELLO Fa0/0: Rcv hello from 192.168.10.2 area 0 192.168.10.2

----# Parámetros desiguales #----

R1#debug ip ospf hello
OSPF hello debugging is on
R1#
*May 16 14:38:00.591: OSPF-1 HELLO Fa0/0: Send hello to 224.0.0.5 area 0 from 192.168.10.1
*May 16 14:38:00.967: OSPF-1 HELLO Fa0/0: Rcv hello from 192.168.10.2 area 0 192.168.10.2
*May 16 14:38:00.971: OSPF-1 HELLO Fa0/0: Mismatched hello parameters from 192.168.10.2
*May 16 14:38:00.971: OSPF-1 HELLO Fa0/0: Dead R 36 C 40, Hello R 9 C 10 Mask R 255.255.255.0 C 255.255.255.0

Es necesario tener en cuenta que los intervalos Hello/Dead varían según el tipo de red de OSPF, al igual que las direcciones de destino.

Paquetes Database Description (DBD)

Los paquetes DBD son intercambiados una vez se tenga una comunicación bidireccional entre routers OSPF, donde estos mensajes transportan las cabeceras de los LSA, por lo tanto, se puede decir que estos paquetes transportan un resumen de lo que sabe el router en OSPF.

Al momento de intercambiar mensajes DBD, los routers definen quien será el Master de la comunicación, con el fin de que este inicie la comunicación definiendo un número de secuencia, el cual solo puede ser cambiado por el.

El número de secuencia es utilizado como acuse de recibo, debido que el equipo que queda como Slave, utiliza el mismo número de secuencia para responder con su propio mensaje DBD, y este lo cambia cuando el Master lo hace.

En un principio, ambos routers se consideran el Master de la comunicación, pero al final, el que tiene el Router ID más alto, es el que se elige como Master.

NOTA: es necesario tener en cuenta, que no siempre el DR corresponde al Master en este proceso.

El paquete DBD contiene los siguientes campos:

  • Interface MTU (2 bytes): corresponde al tamaño en bytes del paquete IP (es necesario que este parámetro coincida en ambos extremos, o de lo contrario la vecindad OSPF queda en estado EXCHANGE, para luego pasar a DOWN)
  • Options (1 byte): son los mismos valores enviados en los paquetes hello.
  • DBD bits:
    • R (1 bit): OOBResync (resincronización fuera de banda, definida en la RFC 4811)
    • I (1 bit): init bit, cuando es 1, corresponde al primer paquete DBD.
    • M (1 bit): More bit, cuando es 1, indica que vienen más mensajes DBD.
    • MS (1 bit): Master bit, cuando es 1, establece que es el Master en el proceso de intercambio de la base de datos.
  • DD sequence number (4 bytes): es usado para secuenciar los paquetes DBD. El valor inicial (indicado por el Init-bit con valor 1) debe ser único. El número de secuencia se va incrementando hasta que se haya enviado por completo el resumen de la base de datos.
  • LSA header (campo variable): contiene las cabeceras de los LSA, los cuales describen los LSA que conoce el router.

Los DBD bit trabajan en pares, y dependiendo de como estén configurados, significa lo siguiente:

  • I-bit = 1, M-bit = 0: un único paquete DBD describe todas las cabeceras de los LSA
  • I-bit = 1, M-bit = 1: más de un paquete DBD se necesita para enseñar todas las cabeceras de los LSA
  • I-bit = 0, M-bit = 0: corresponde al último paquete DBD
  • I-bit = 0, M-bit = 1: valor asignado a los paquetes DBD que son enviados entre el primero y el último

Paquete DBD en red IPv4:

Paquete DBD en red IPv6:

Ejemplo de LSA Header:

R1#show ip ospf database router

            OSPF Router with ID (192.168.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 26
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 192.168.1.1
  Advertising Router: 192.168.1.1
  LS Seq Number: 80000002
  Checksum: 0x77B
  Length: 36
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.1.3
     (Link Data) Router Interface address: 192.168.1.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1


  LS age: 22
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 192.168.1.2
  Advertising Router: 192.168.1.2
  LS Seq Number: 80000002
  Checksum: 0x57A
  Length: 36
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.1.3
     (Link Data) Router Interface address: 192.168.1.2
      Number of MTID metrics: 0
       TOS 0 Metrics: 1


  LS age: 27
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 192.168.1.3
  Advertising Router: 192.168.1.3
  LS Seq Number: 80000002
  Checksum: 0x379
  Length: 36
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.1.3
     (Link Data) Router Interface address: 192.168.1.3
      Number of MTID metrics: 0
       TOS 0 Metrics: 1


R1#

Lo que está en rojo corresponde a la cabecera del LSA, enviado en el paquete DBD.

Para poder validar los mensajes OSPF enviados y recibidos en un router Cisco, se utiliza el comando debug ip ospf adj, donde nuestra la secuencia completa del establecimiento de adyacencia entre dos equipos:

R1#debug ip ospf adj
OSPF adjacency debugging is on
R1#
*May 17 12:20:05.039: OSPF-1 ADJ   Fa0/0: 2 Way Communication to 192.168.1.2, state 2WAY
*May 17 12:20:05.423: OSPF-1 ADJ   Fa0/0: 2 Way Communication to 192.168.1.3, state 2WAY
R1#
*May 17 12:20:28.403: OSPF-1 ADJ   Fa0/0: end of Wait on interface
*May 17 12:20:28.403: OSPF-1 ADJ   Fa0/0: DR/BDR election
*May 17 12:20:28.407: OSPF-1 ADJ   Fa0/0: Elect BDR 192.168.1.3
*May 17 12:20:28.407: OSPF-1 ADJ   Fa0/0: Elect DR 192.168.1.3
*May 17 12:20:28.407: OSPF-1 ADJ   Fa0/0: DR: 192.168.1.3 (Id)   BDR: 192.168.1.3 (Id)
*May 17 12:20:28.411: OSPF-1 ADJ   Fa0/0: Nbr 192.168.1.3: Prepare dbase exchange
*May 17 12:20:28.415: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.3 seq 0xFEA opt 0x52 flag 0x7 len 32
R1#
*May 17 12:20:33.359: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.3 seq 0xFEA opt 0x52 flag 0x7 len 32
*May 17 12:20:33.359: OSPF-1 ADJ   Fa0/0: Retransmitting DBD to 192.168.1.3 [1]
R1#
*May 17 12:20:35.919: OSPF-1 ADJ   Fa0/0: Rcv DBD from 192.168.1.3 seq 0x18E opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART
*May 17 12:20:35.919: OSPF-1 ADJ   Fa0/0: NBR Negotiation Done. We are the SLAVE
*May 17 12:20:35.923: OSPF-1 ADJ   Fa0/0: Nbr 192.168.1.3: Summary list built, size 1
*May 17 12:20:35.923: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.3 seq 0x18E opt 0x52 flag 0x2 len 52
*May 17 12:20:35.955: OSPF-1 ADJ   Fa0/0: Rcv DBD from 192.168.1.3 seq 0x18F opt 0x52 flag 0x1 len 52  mtu 1500 state EXCHANGE
*May 17 12:20:35.955: OSPF-1 ADJ   Fa0/0: Exchange Done with 192.168.1.3
*May 17 12:20:35.955: OSPF-1 ADJ   Fa0/0: Send LS REQ to 192.168.1.3 length 36 LSA count 1
*May 17 12:20:35.955: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.3 seq 0x18F opt 0x52 flag 0x0 len 32
*May 17 12:20:35.967: OSPF-1 ADJ   Fa0/0: Rcv LS UPD from 192.168.1.3 length 64 LSA count 1
*May 17 12:20:35.967: OSPF-1 ADJ   Fa0/0: Synchronized with 192.168.1.3, state FULL
*May 17 12:20:35.967: %OS
R1#PF-5-ADJCHG: Process 1, Nbr 192.168.1.3 on FastEthernet0/0 from LOADING to FULL, Loading Done
*May 17 12:20:35.971: OSPF-1 ADJ   Fa0/0: Rcv LS REQ from 192.168.1.3 length 36 LSA count 1
R1#
*May 17 12:20:42.687: OSPF-1 ADJ   Fa0/0: Neighbor change event
*May 17 12:20:42.691: OSPF-1 ADJ   Fa0/0: DR/BDR election
*May 17 12:20:42.691: OSPF-1 ADJ   Fa0/0: Elect BDR 192.168.1.2
*May 17 12:20:42.691: OSPF-1 ADJ   Fa0/0: Elect DR 192.168.1.3
*May 17 12:20:42.695: OSPF-1 ADJ   Fa0/0: DR: 192.168.1.3 (Id)   BDR: 192.168.1.2 (Id)
*May 17 12:20:42.699: OSPF-1 ADJ   Fa0/0: Nbr 192.168.1.2: Prepare dbase exchange
*May 17 12:20:42.699: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.2 seq 0xDA2 opt 0x52 flag 0x7 len 32
*May 17 12:20:42.703: OSPF-1 ADJ   Fa0/0: Neighbor change event
*May 17 12:20:42.703: OSPF-1 ADJ   Fa0/0: DR/BDR election
*May 17 12:20:42.703: OSPF-1 ADJ   Fa0/0: Elect BDR 192.168.1.2
*May 17 12:20:42.707: OSPF-1 ADJ   Fa0/0: Elect DR 192.168.1.3
*May 17 12:20:42.707: OSPF-1 ADJ   Fa0/0: DR: 192.168.1.3 (Id)   BDR: 192.168.1.2 (Id)
*May 17 12:20:42.715: OSPF-1 ADJ   Fa0/0: Rcv DBD from 192.168.1.2 seq 0xF4D opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART
*Ma
R1#y 17 12:20:42.715: OSPF-1 ADJ   Fa0/0: NBR Negotiation Done. We are the SLAVE
*May 17 12:20:42.715: OSPF-1 ADJ   Fa0/0: Nbr 192.168.1.2: Summary list built, size 4
*May 17 12:20:42.715: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.2 seq 0xF4D opt 0x52 flag 0x2 len 112
*May 17 12:20:42.735: OSPF-1 ADJ   Fa0/0: Rcv DBD from 192.168.1.2 seq 0xF4E opt 0x52 flag 0x1 len 112  mtu 1500 state EXCHANGE
*May 17 12:20:42.735: OSPF-1 ADJ   Fa0/0: Exchange Done with 192.168.1.2
*May 17 12:20:42.735: OSPF-1 ADJ   Fa0/0: Send LS REQ to 192.168.1.2 length 36 LSA count 1
*May 17 12:20:42.735: OSPF-1 ADJ   Fa0/0: Send DBD to 192.168.1.2 seq 0xF4E opt 0x52 flag 0x0 len 32
*May 17 12:20:42.747: OSPF-1 ADJ   Fa0/0: Rcv LS UPD from 192.168.1.2 length 64 LSA count 1
*May 17 12:20:42.747: OSPF-1 ADJ   Fa0/0: Synchronized with 192.168.1.2, state FULL
*May 17 12:20:42.747: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
R1#
*May 17 12:20:43.463: OSPF-1 ADJ   Fa0/0: Neighbor change event
*May 17 12:20:43.467: OSPF-1 ADJ   Fa0/0: DR/BDR election
*May 17 12:20:43.467: OSPF-1 ADJ   Fa0/0: Elect BDR 192.168.1.2
*May 17 12:20:43.471: OSPF-1 ADJ   Fa0/0: Elect DR 192.168.1.3
*May 17 12:20:43.471: OSPF-1 ADJ   Fa0/0: DR: 192.168.1.3 (Id)   BDR: 192.168.1.2 (Id)
*May 17 12:20:43.475: OSPF-1 ADJ   Fa0/0: Neighbor change event
*May 17 12:20:43.475: OSPF-1 ADJ   Fa0/0: DR/BDR election
*May 17 12:20:43.475: OSPF-1 ADJ   Fa0/0: Elect BDR 192.168.1.2
*May 17 12:20:43.479: OSPF-1 ADJ   Fa0/0: Elect DR 192.168.1.3
*May 17 12:20:43.479: OSPF-1 ADJ   Fa0/0: DR: 192.168.1.3 (Id)   BDR: 192.168.1.2 (Id)
R1#undebug all
All possible debugging has been turned off
R1

Si queremos validar que la MTU es idéntica en ambos extremos, usamos el comando show ip interface, el cual nos solo muestra este parámetro, si no que también al grupo multicast al que esta unida la interfaz (en este caso es a OSPF):

R1#show ip interface f0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 192.168.1.1/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.5 224.0.0.6
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled
  ICMP redirects are always sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  IP fast switching is enabled
  IP fast switching on the same interface is disabled
  IP Flow switching is disabled
  IP CEF switching is enabled
  IP CEF switching turbo vector
  IP CEF turbo switching turbo vector
  IP multicast fast switching is enabled
  IP multicast distributed fast switching is disabled
  IP route-cache flags are Fast, CEF
  Router Discovery is disabled
  IP output packet accounting is disabled
  IP access violation accounting is disabled
  TCP/IP header compression is disabled
  RTP/IP header compression is disabled
  Policy routing is disabled
  Network address translation is disabled
  BGP Policy Mapping is disabled
  Input features: MCI Check
  IPv4 WCCP Redirect outbound is disabled
  IPv4 WCCP Redirect inbound is disabled
  IPv4 WCCP Redirect exclude is disabled
R1#

Paquete Link-State Request (LSR)

Los paquetes LSR son usados para consultar la información completa de un LSA que no se conozca o que se encuentre desactualizado. Los LSAs a consultar son los aprendidos en el intercambio de los paquetes DBD.

Los LSAs consultados son especificados por los siguientes parámetros:

  • LS type (4 bytes en OSPFv2 y 2 bytes en OSPFv3): indica el tipo de LSA por el cual se está consultando.
  • Link state ID (4 bytes para OSPFv2 y v3): identifica la parte del dominio de enrutamiento que está describiendo el LSA, el cual depende del tipo de LSA, donde puede tomar los siguientes valores:
    • LS type 1: el Link state ID corresponde al RID del router que origina el LSA.
    • LS type 2: el Link state ID es la IP de la interfaz del DR.
    • LS type 3: el Link state ID es la IP de la red de destino.
    • LS type 4: el Link state ID es el RID del ASBR descrito en el LSA.
    • LS type 5: el Link state ID es la IP de la red de destino.
  • Advertising Router (4 bytes para OSPFv2 y v3): este campo se establece con el RID del router que origina la LSA:
    • Router LSA (LSA tipo 1): se usa el mismo valor que el Link state ID.
    • Netowork LSA (LSA tipo 2): es el valor del DR.
    • Summary LSA (LSA tipo 3): corresponde al ABR que origina el LSA.
    • Summary ASB LSA (LSA tipo 4): corresponde al ABR que origina el LSA.
    • AS-external LSA (LSA tipo5): RID del ASBR que importa las rutas.

LSR OSPFv2:

LSR OSPFv3:

Paquete Link-State Update (LSU)

Estos paquetes inundan con los LSAs consultados por el vecino OSPF, donde un solo LSU puede contener múltiples LSAs.

Las redes que soportan multicast, utilizan dicha dirección para enviar los LSUs.

Todos los LSUs deben ser respondidos por un LSAck, los cuales corresponden a un acuse de recibo de estos.

En el cuerpo de los LSUs, solo se encuentran las LSAs transportadas (campo variable):

Paquete Link-State Acknowledgement (LSAck)

Es necesario que la inundación de LSAs sea confiable, por lo mismo, se necesita un mecanismo de acuse de recibo para saber si los LSAs llegaron al destino. En este punto aparecen los LSAck, los cuales son respuestas a los LSUs (paquete contenedor de LSAs).

Al igual que con los LSUs, se pueden responder a todos los LSAs intercambiados con un único LSAck (dependiendo de la cantidad de LSAs intercambiados), y estos pueden usar la dirección multicast o unicast como destino, según la configuración de OSPF.

En esta respuesta, los LSAck responde con los headers de los LSAs enviados por el vecino (campo variable):

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *