Capítulo 12: Open Shortest Path First

OSPF es un protocolo de enrutamiento del tipo "link-state" (estado de link) para usarlo conjuntamente con un Sistema Autónomo (AS). Está considerado como un IGP, tiene un convergencia muy rápida y es capaz de soportar grandes estructuras de red.

OSPF utiliza LSA's para el intercambio de información con los otros routers OSPF.

Cada router crea y mantiene una base de datos específica de "link-state". El router usa esta base de datos junto con el algoritmo SPF para calcular la mejor ruta hacia destino.

La Base de Datos de Link-State

A parte de descubrir vecino e inundar con LSA's la red, otra tarea fundamental de OSPF es crear y mantener la base de datos (LSDB). La info que almacena incluye los Router ID de los otros, sus propias redes conectadas, sus vecinos y el coste para llegar a los destinos. Todos los routers dentro de una misma área, deberán tener la misma LSDB para asegurar un enrutamiento preciso. Por lo tanto, un equipo que pertenezca a 2 áreas diferentes (como un ABR) tendrá una LSDB para cada área.

Por lo tanto, OSPF usa la LSDB para calcular el camino más corto usando el algoritmo SPF o Disjktra. Este cálculo lo hace creando árboles de caminos más cortos y elige el mejor para el enrutamiento. El resultado de este cálculo se lo pasa a la tabla de rutas para enviar los paquetes por ahí.

Tipos de paquetes OSPF

Paquete Hello



Todos los routers envían periódicamente paquetes "hello" cada 10 segundos por defecto. Se mandan a la dirección multicast 224.0.0.5, es decir, a todos los routers.  Cuando la comunicación es con el DR/BDR la dirección multicast es la 224.0.0.6. OSPF utiliza el "Ip Protocol 89". El dead interval es el tiempo que tiene que esperar para que si no ha recibido un hello, elimine la vecindad. El campo opciones, que tiene 8-bit es donde se representa la configuración de las áreas "stub".

Paquete de Descripción de Base de Datos



OSPF usa los paquetes DD (database description) solo durante el proceso de formación de vecindad de dos routers. El propósito del paquete DD es: determinar quién se encarga de la sincronización de la base de datos y transferir las cabeceras de los LSA entre dos sistemas autónomos.

El router con el "router-id" más alto será el encargado de sincronizar la base de datos y este, es conocido como "master" y el otro router como "slave" (esclavo). Una vez traspasada toda la información, la relación master-slave no se usa más.

OSPF solo usa paquetes DD para pasar la info entre 2 AS y al menos, sirve para sincronizar las bases de datos.

Los detalles del paquete son:

• Cabecera OSPF: tiene 24 bytes
• Número de secuencia: para asegurar que toda la secuencia ha llegado al equipo. Los números de la secuencia los establece el master.
• Cabecera LSA: muestra cabeceras de LSA de la base de datos original. Contiene información única para poder identificar el LSA concreto.

Paquete de Petición de Link-State (Link-state request)

Después de recibir un número X de paquetes DD, el router puede encontrar que el vecino le está enviando una cabecera de LSA que él no tiene. Entonces hace una "petición de link-state" que lleva el LSA que no tiene.

Los detalles del paquete son:

• Cabecera OSPF: tiene 24 bytes
• Tipo de Link-State
• ID de Link-State
• Router que lo pide: contiene el Router ID del equipo que origina el LSA.

Paquete de Actualización de Link-State (Link-state-update)

Es dentro de los LSUs donde van los LSAs. Los LSUs son enviados en respuesta a un "paquete de petición de link-state" cuando se forma la vecindad y se sincronizan. Y también son enviados una vez formada la vecindad cuando hay cambios de los enlaces.





Los detalles del paquete son:

• Cabecera OSPF: tiene 24 bytes (20+4)
• Número de anuncios: 4 bytes. Contiene el número de LSAs que lleva dentro.
• Anuncios Link-State: contiene los LSAs. El número máximo de LSAs que puede contener depende del tamaño máximo de paquete que es permitido en el enlace.

Variable = Anuncios Link-State

Paquete de Reconocimiento de Link-State (link-state-acknowledgement)

Después de recibir un LSU se envía este paquete de reconocimiento. Este paquete de reconocimiento se envía a través de "unicast" al equipo que nos mandó el LSU. Este proceso es la base de la inundación fiable de OSPF.

Formación de la Vecindad

La vecindad (adjency) entre dos rouers OSPF es la relación que se forma entre ellos. Esto asegura que cada uno sepa del otro y además llegar a un acuerdo sobre ciertos parámetros del enlace.

Existen 7 estados de posible vecindad OSPF:

1. Down: Estado incial que indica que OSPF está esperando un evento de inicio
2. Init: un paquete hello se ha enviado pero la comunicación bidireccional no se ha establecido
3. 2Way: un paquete hello con el "router-id" se ha recibido. La comunicación bidireccional no se ha establecido.
4. ExStart: los routers negocian entre sí para determinar cuál se encarga de la sincronización de la base de datos de OSPF.
5. Exchange: los routers intercambian cabeceras de LSA de su propia base de datos. Si el router no conoce ese LSA, puede enviar un "paquete de petición de link-state".
6. Loading: el router ha finalizado de enviar su base de datos al vecino pero está esperando recibir la información del vecino.
7. Full: las bases de datos de ambos equipos están sincronizadas. Ahora se pueden propagar las rutas de OSPF.

Optimización de la Vecindad

Los routers OSFP forman la vecindad con los equipos de los que recibe paquetes hello. Cuando están en un entorno "broadcast", como ethernet, se puede dar un problema y es que cuántos más routers metamos en el mismo broadcast, más vecindades se formarán, creando un "mallado-completo" (full-mesh), donde todos se conectan con todos añadiendo más carga a los equipos. Además, todos están propagando la misma red.

 Para evitar este problema, OSPF elige un equipo que será el que represente al "broadcast" al resto de la red. Este router es el DR (designated router). Es el DR el que forma la vecindad con todos los routers y el que propaga la információn al AS. En un entorno ethernet se reduce bastante el tráfico.

También se elige un BDR (backup designated router) para cubrir el rol por si se cae el DR. El BDR también forma vecindad con todos los otros routers del segmento. Sin embargo no propaga nada de información al AS a no ser que se dé un fallo del DR.



Si le añadimos el comando "interface-type p2p" le decimos a OSPF que no haga la elección del DR/BDR en ese enlace. Con esto podemos ahorrar hasta 40 segundos en la espera para formar la vecindad. Además, tampoco genera el LSA de tipo 2 (lo veremos más adelante) y esto hace que la LSDB reduzca el tamaño.

Elección de DR (Designated Router)

OSPF basa la elección del DR en dos criterios: la prioridad y el RID (Router ID).

La prioridad por defecto es 128. Se puede configurar de 0 a 255.

El router elegido es el que tenga mayor prioridad. Si le configuramos 0 nunca participará en la elección del DR. Si existe emparte en la prioridad entre dos o más routers, será el equipo con mayor RID el que sea el elegido para ese segmento. Una detalle importante es que si el DR falla, cuando vuelva a estar en línea y vea que es otro equipo el que se ha establecido como DR, no intentará volver a ser el DR aunque tenga mayor prioridad. Esto se hace para asegurar la estabilidad de la red.

La primera elección del DR se hace dentro de los 40 primeros segundos. Se transmiten los paquetes hello. Después de elegir el DR, se sigue el mismo procedimiento para la elección del BDR, cuya función es monitorizar al DR. Si el BDR nota que el DR se ha caído, asume el rol automáticamente y un nuevo BDR es elegido.





Relación de Vecindad OSPF

show ospf neighbor

En cuanto a un router OSPF le llega un paquete hello, almacena esa información sobre el vecino. En el "show ospf neighbor" podemos ver las relaciones que se forman.

Todos los routers están en el mismo segmento. Cuando un router OSPF no es ni el DR ni el BDR, el rol que asume es el de DROther. Entre DROthers, la relación que se forma es 2Way. La relación de estos con el DR/BDR será la de FULL.

Escalabilidad de OSPF

Cuando se ejecuta el algoritmo SPF se consumen muchos recursos, y como todas las LSDB tienen que estar sincronizadas, si la red es muy grande y se producen cambios, esto puede afectar al rendimiento de los routers y ocupar su procesamiento en el SPF y no ser capaz de mandar tráfico.

La solución a este problema (y a todos los protocolos de link-state) es reducir el tamaño de la LSDB. Para ello creamos múltiples áreas de OSPF dentro del AS, en vez de una sola muy grande. 



Para restringir la inundación de LSA en las áreas, configuramos una "sumarización" de rutas en los bordes entre áreas. De esta manera reducimos la LSDB y además no nos llegarían los posibles cambios que se suceden en otras áreas.

ÁREAS OSPF

También facilitamos la escalabilidad

El área "backbone" es siempre el área 0. Según OSPF, todas las demás áreas tendrán que estar conectadas al área 0. Por defecto, todo el tráfico de datos entre áreas OSPF debe transitar por el backbone. Se puede alterar este comportamiento configurando una "vecindad multiárea" en el mismo interface lógico (RFC 5185 - No entra en el temario de JNCIS)

TIPOS DE ROUTER OSPF  



En OSPF tenemos varios roles para los routers:

•  ABR (Area Border Router): es un router OSPF conectado al "backbone y a otra área. Se encarga de pasar la información de enrutamiento entre el backbone y las otras áreas
• ASBR (Autonomous System Boundaring Router): mete la información de fuera de OSPF al dominio OSPF.
• Backbone Router: al menos una interface está conectado al área 0. Puede ser un ABR o un router interno que tenga todas sus interfaces conectadas al área 0.
• Internal Router: tiene todas sus interfaces conectadas a la misma área. Si está dentro del área 0, es conocido también como "backbone router".

 TIPOS DE ÁREA OSPF

Como vemos todas las áreas están conectadas al backbone. Hay escenarios en los que un área no colinde con el backbone y entonces tendremos que configurar un virtual-link (fuera del estudio del JNCIS).

Para OSPF tenemos 3 tipos de información de enrutamiento (rutas):

• Intra-area o internal routes: rutas generadas dentro de un área y con destino dentro del propio área
• Inter-area o summary routes: rutas originadas en otra área
• External routes: el origen de las rutas es de otro protocolo y es redistribuido en OSPF





Un "área stub" no inundan con LSA (tipo 4 y 5) en sus áreas. Esto se hace para reducir las propagaciones de rutas y mantener una LSDB pequeña.

Cuando configuramos un ABR para crear un área stub, normalmente se propaga una ruta por defecto (0.0.0.0./0) para los equipos de dentro del área y las rutas externas no se propegan dentro, se quedan en el ABR. Para propagar esta ruta por defecto tendremos que configurar el ABR.

Un "totally stub area" es una stub area que recibe una ruta por defecto desde el backbone.

Luego tenemos la "NSSA" (not so stubby area). En este tipo de área, el ABR no inunda con LSA de tipo 3, 4 y 5. Sin emabrgo, deja pasar las tipo 6 y 7 (externas a OSPF).

NOTA: si tenemos un área stub no podremos crear un virtual link.

TIPOS DE PAQUETES DE LSA

• Router (Tipo 1): describe las interfaces y vecinos de cada router OSFP a los otros routers OSPF de dentro del mismo área
• Network (Tipo 2): describe un segmento ethernet. Estos LSA son enviados por el DR  a los otros routers OSPF del mismo área.
• Summary (Tipo 3): describe las rutas aprendidas por el router y los LSAs. Estos LSAs son aprendidos por el ABR conectado al área donde se aprendieron esas rutas (inter-area). Estas rutas no cambian el tipo al pasarse de un área a otra, pero sí cambia el coste, claro.
• ASBR Summary (Tipo 4): describe el Router-ID (RID) de los routers de las otras áreas. Estos LSAs son aprendidos por el ASBR conectado al área donde se aprendieron esas rutas (inter-area). Estas rutas no cambian el tipo al pasarse de un área a otra, pero sí cambia el coste, claro.
• External (Tipo 5): describen los LSAs redistribuidos por otros protocolos, incluidas las rutas estáticas. Las inyecta el ASBR. Por defecto, Junos las etiqueta como LSA de Tipo 2, pero no modifica su coste. Se puede modificar este comportamiento para que las etiquete como LSA de Tipo 1 y que sí añada el coste del camino. Estas Tipo 5 son inyectadas en todas las áreas except en las que son STUB.
• NSSA External (Tipo 7): son similares a las Tipo 5. Describen los LSAs redistribuidos por otros protocolos, incluidas las rutas estáticas. Las inyecta también el ASBR pero esta vez en las áreas que son NSSA. Cuando llegan al ABR, estos LSAs son traducidos como LSA de Tipo 5.

En OSPF también nos podremos encontrar otros tipos que son menos comunes:

• Tipo 6: Multicast OSPF LSA
• Tipo 8: External Attributes LSA (para tunelizar atributos de otros protocolos a través de OSPF)
• Tipo 9: Opaque LSA
• Tipo 10: Opaque LSA
• Tipo 11: Opaque LSA

Los Opaque LSA no están soportados por los otros LSA, como por ejemplo cuando se hace un Graceful Restart o para transmitir información de "traffic engineering".

Los LSA están asociados como máximo durante 1 hora. Para asegurarse de que los LSA están actualizados, OSPF refresca estos datos anes de que expiren. En Junos se hace a los 50 minutos (3000 sec)


OPCIONES DE JUNOS EN OSPF

OSPF en Junos soporta tanto la versión 2 (IPv4) como la versión 3 (Ipv4 e IPv6).

Opciones de configuración:

• Autenticación: por defecto deshabilitada. Autenticación simple, con MD5o IPSEC.
• Sumarización: capacidad para sumarizar rutas.
• Límite de redes externas: por defecto no limita. Podemos configurar un límite con el comando prefix-export-limit
• Graceful Restart (GR): no habilitada por defecto. Esta opción hace que cuando un router va a reiniciarse, informe a los demás routers para que estos consideren al equipo todavía dentro de la topología cuando se está reiniciando y siguen enviando tráfico.
• Bidirectional Forwarding Detection (BFD): protocolo con mecanismo de "hello" para detectar fallos en los enlaces.  

CONFIGURACIÓN BÁSICA

Todos los routers que participen en OSPF tendrán un RID. Se usa para varias opciones como el identificador del origen de los LSA o en la elección del DR (designated router)

El RID se configura manualmente pero si no lo hacemos antes de que el proceso OSPF se inicie, si el equipo tiene una loopback configurada, escogerá la loopback como RID. Si no tiene loopback, elegirá la interface asociada a la "interface management". Recordad que las interfaces de management (de administración) no soportan el tráfico de tránsito por lo que no podríamos hacer ping al RID. Por lo tanto, lo más recomendable es configurar el RID.

Debemos configurar la loopback "Lo0" con una dirección ip. Si a esta dirección le cofiguramos una máscara menor de /32, OPSF anunciará 2 prefijos: 1 con la máscara /32 y otra con la máscara propia de la dirección que hayamos configurado. Es decir, si configuramos "lo0.0" con la dirección 10.0.0.1/24, OSPF anunciará las redes 10.0.0.1/24 y la 10.0.0.1/32.

Si no quisieramos propagar todas las direcciones ip que hay en una interface (como en la Lo0), en vez de configurar la interface física, directamente escribimos la dirección ip que queramos propagar.