Es un valor de 32 bits en formato ip. Este valor es único en todo el dominio OSPF. Se transmite dentro de cada LSA y se usa en el cálculo SPF. No puede haber dos equipos con el mismo RID, pues esto causa comportamientos impredecibles en la red.
Cuando el proceso de routing de Junos (rpd) se inicia elige una interface para su RID. Si la interface loopback (lo0) tiene configuradas direcciones ip, escogerá la dirección más baja siempre que no sea una "martian route" (non-127/8). Si no tiene, elegirá la primera dirección ip disponible en el rotuer.
Por supuesto que podemos configurar la dirección que nosotros queramos:
- set routing-options router-id X.X.X.X
Cuando configuramos una loopback y la propagamos en OSPF, la propagamos en esa área solamente. En el resto de áreas irá dentro del LSA Summary.
PROPAGACIÓN DE LSAs
La propagación de rutas en OSPF es un poco complicada. Vamos a intentar darle claridad a este tema:
- LSA Tipo 1 y 2 no salen de su área.
- LSA Tipo 3 salen de su área a través del ABR para propagar los LSA Tipo 1 y 2 de cada área. Se puede decir que todas los LSA de tipo 3 de todas la áreas suman todas las rutas que hay en el dominio OSPF, tanto de la 0 como de las demás. Por ejemplo, en el área 1 tendremos los LSA de tipo 3 de las áreas 0, 2 y 3.
- LSA Tipo 4 los genera el ABR para propagar entre todas la áreas la ruta para llegar al ASBR que está propagando rutas externas. El LSA Tipo 4 del área 0 se propagará por la 1,2 y 3 y, el LSA Tipo 4 del área 3 se propagará por la 0, 1 y 2.
- LSA Tipo 5 los genera el ASBR y se propagan por todas las áreas (menos en las que son STUB). Los equipos usa un Router LSA o un ASBR Summary LSA para llegar a esas rutas externas.
 |
| show ospf database en vMX-1 |
- Del Área 0: 1, 2 y 5
- Del Área 1: 3, 4 y 5
- Del Área 2: 3, 4 y 5
- Del Área 3: 3
En el área 1 tenemos los siguientes Tipos de LSAs:
- Del Área 0: 3, 4 y 5
- Del Área 1: 1, 2 y 5
- Del Área 2: 3, 4 y 5
- Del Área 3: 3
 |
| show ospf database en vMX-3 |
- Del Área 0: 3, 4 y 5
- Del Área 1: 3, 4 y 5
- Del Área 2: 1, 2 y 5
- Del Área 3: 3
 |
| show ospf database area 3 en vMX-3 |
- Del Área 0: 3, 4 y 5
- Del Área 1: 3, 4 y 5
- Del Área 2: 3, 4 y 5
- Del Área 3: 1, 2 y 5
Ahora vamos a hacer al área 2 que sea una NSSA y los enlaces del área 0 (backbone) lo vamos a configurar como P2P:
- set protocols ospf area 0 interface X interface-type p2p ( en vMX-1, 2 y 3)
- set protocols ospf area 2 nssa ( en vMX-3 y 6)
 |
| show ospf database en vMX-1 |
Como veis, en el área 0 no hay LSA de Tipo 2 (network). Al haber hecho que las interfaces sean P2P, estas no se reflejan en la LSDB y así reducimos su tamaño.
También, la haber hecho que área 2 sea NSSA, no se ha generado el ASBRSummary del 172.16.6.1.
PROTECCIÓN DE LA LSDB
Podemos proteger la "database" para que reciba un número limitado de LSA. Afecta a los LSA recibidos de otros vecinos, no a los que genera el propio equipo. Esto puede ser muy útil, por ejemplo, cuando tenemos configuradas VRF entre los PE y los CE, para poder evitar que una mala configuración del cliente haga que nos inunde la LSDB y pueda crear fallos de comunicación:
- set protocols ospf database-protection maximum-lsa
- set protocols ospf database-protection warning-only
ALGORITMO SPF
Esta basado en el algoritmo Dijkstra. Usa tres base de datos para el cálculo:
- Link-state database
- Candidate database
- Tree database
Como ya sabemos la LSDB tiene los datos de todo el routing de la red. Por decirlo así, se refleja como "datos en grupos de tres" que contienen: router-id, neighbor id y el coste. Y esto describe cada uno de los enlaces de la red.
Vemos un ejemplo de cómo funcional el algoritmo. La red acaba de converger, es decir, la LSDB es igual en todos los equipos.
Tabla Link-State del Router A
(A, A, 0)
(A, B, 1)
(A, C, 2)
(B, A, 3)
(B, D, 3)
(C, A, 4)
(C, D, 4)
(D, B, 1)
(D, C, 2)
|
Ahora el Router A ejecuta el cálculo SPF para determinar el camino más corto a cada equipo de la red:
- Evalua cada grupo de 3 en la "candidate database" y elimina aquellos grupos donde el "neighbor id" ya esté en la "tree database" y su coste sea mayor que el actual de la "tree database". Y esto lo repite hasta que no haya más grupos de 3 para poder borrar.
 |
| SPF ejecutándose en el Router A |
El Router A empieza moviendo su propio grupo e 3, el que hace referencia a él mismo, a la "candidate". Se calcula el coste desde el "neighbor", que es 0 porque es él mismo. Esto quiere decir para OSPF que está directamente conectado. Y después se mueve esa entrada, que es la de más bajo coste, a la "Tree". Y continua así con todos los grupos de 3 que hay en la "Link-State"
- Por cada nueva entrada en la "candidate", el router determina el coste para llegar a cada "neighbor". La entrada con menos coste a ese vecino es la elegida. Si hay más de una entrada con el mismo coste, elige una aleatoriamente. Si aparece un nuevo vecino en la Tabla Tree (porque llegado una actualización de otro router), mueve todos los grupos de 3 con el Router-ID igual al de la nueva entrada, desde la LSDB a la "candidate".
 |
Cuando llega a la (C, A, 4), esta entrada no la pasa a la tabla del Tree ya que tiene una con mejor coste para llegar a C (A, C, 2).
Hasta que la "candidate database" no esté vacía, seguirá ejecutando el algoritmo.
Nota: Recordad que el algoritmo Disjktra se ejecuta localmente. Importante también recordar que hay un base de datos (LSDB) por cada área, por lo tanto, tienen tablas de rutas diferentes.
Una vez ejecutada la tabla entera, el mapa de red que le queda al Router A sería así:
Este resultado se pasa directamente a la tabla de rutas de la RE. De aquí podemos deducir que si quisieramos filtar rutas en OSPF, lo mejor es hacer que no se instalen en la "database", y así el router no cuenta con ella para los cálculos de algoritmo SPF.
Nota: OSPF provee de una opción de "import" parea bloquear que LSA de Tipo 5 y 7 se instalen en la tabla de rutas. Sin embargo, este import no previene que los LSA sean propagados, por lo que Juniper no recomienda el usa de este atrinuto por las posibles consecuencias de descarte de tráfico no deseado.
CONTROL DE CÁLCULOS SPF
Para mejorar la convergencia ante cambios de topología, Junos permite que haya 3 cálculos seguidos de SPF. Después aplica un tiempo de parada obligatoria (hold-down timer) para evitar que el proceso de enrutamiento cargue a la CPU y nos tire el equipo. Esto se hace para situaciones de inestabilidad y muchos cambios en la red, ya que el algoritmo SPF estaría todo el tiempo ejecutándose.
Se puede configurar tanto a nivel global como a nivel de "routing-instance". El tiempo por defecto de "hold-down" es de 5 segundos (5000 ms), pero se puede configurar entre un rango que va de 2000 a 20000 ms:
También podemos configurar este tiempo a nuestro gusto el retardo o delay que hay entre un cálculo SPF y el siguiente:
Aunque configuremos este parámetro, el tiempo de parada obligatoria después de 3 cálculos seguidos de SPF se seguirá ejecutando.
Una práctica común en las redes grandes con OSPF es configurar el spf-options delay un poco más grande que el delay que tiene la red para propagar las rutas. Es decir, si nuesrta red tarde en converger unos 300 ms, podemos configurar el spf-options delay a 350 ms. Con ello damos tiempo para que todas las entradas duplicadas lleguen a todos los routers antes de que el cálculo SPF se ejecutado.
COSTE DE OSPF
Antes de propagar una red en OSPF a través de los LSAs, el equipo tiene que determinar el coste de las interfaces. Como todos los equipos envían el coste de las interfaces, cada equipo puede calcular el coste total para llegar a los otros.
Para determinar el coste de las interfaces dividimos 100.000.000 entre el ancho de banda de la interface. Si el resultado es menor de 1, se redondea a 1.
Se puede configurar manualmente el coste individual de las interfaces con el siguiente comando:
Si tenemos muchas interfaces o interfaces Ethernet (10mb), la configuración manual de cada interface se puede volver tediosa. Para ello, podemos cambiar la referencia que tienen del coste el protocolo OSPF. En vez de ser 100.000.000, que sería justamente el ancho de banda de una Fast Ethernet, le asignamos otra:
Recordad que el coste es el de la interface de salida, por lo que al configurar las métricas manualmente, podemos encontrarnos con routing asimétrico, ya que un router puede estar declarando en la salida de su interface un coste de 10 y el vecino que tiene conectado puede haber configurado ese mismo enlace con un coste de 5. Para el cálculo local de SPF no afecta, pero podemos entrar en un escenario de routing asimétrico. Hay que andarse con mucho ojo.
OVERLOAD
Es el mismo concepto que usa IS-IS. Se usa para que el protocolo siga ejecutándose pero advierte en su área que no está disponible para procesar tráfico. Hay dos escenarios especialmente en los que nos puede ser de gran ayuda.
Se puede configurar de forma permanente o solo por un tiempo:
Si lo configuramos normal, la métrica de las interfaces seguirá alta hasta que no lo eliminemos de la configuración y hagamos "commit".
Si configuramos un tiempo, este tiempo no se pondrá en marcha hasta que no se inicie el proceso de routing (rpd). Cuando el tiempo que hemos configurado finaliza, la métrica de las interfaces vuelven al estado normal. Pero ojo, la opción "overload" seguirá en la configuración.
Reiniciamos el proceso de routing y tras un momento se ve la métrica de 65535. Como hemos configurado 60 segundos de overload, transcurrido este tiempo la métrica vuelve a 1.
Recordad que el comando "overload" sigue configurado y si se reiniciara el proceso de routing otra vez, por el motivo que sea, se activaría entonces el "overload" por otros 60 segundos.
Nota: cualquier tráfico que vaya directo al equipo, que termine en el equipo, como la gestión por ejemplo, llegará a este.
Hasta que la "candidate database" no esté vacía, seguirá ejecutando el algoritmo.
Nota: Recordad que el algoritmo Disjktra se ejecuta localmente. Importante también recordar que hay un base de datos (LSDB) por cada área, por lo tanto, tienen tablas de rutas diferentes.
Una vez ejecutada la tabla entera, el mapa de red que le queda al Router A sería así:
Este resultado se pasa directamente a la tabla de rutas de la RE. De aquí podemos deducir que si quisieramos filtar rutas en OSPF, lo mejor es hacer que no se instalen en la "database", y así el router no cuenta con ella para los cálculos de algoritmo SPF.
Nota: OSPF provee de una opción de "import" parea bloquear que LSA de Tipo 5 y 7 se instalen en la tabla de rutas. Sin embargo, este import no previene que los LSA sean propagados, por lo que Juniper no recomienda el usa de este atrinuto por las posibles consecuencias de descarte de tráfico no deseado.
CONTROL DE CÁLCULOS SPF
Para mejorar la convergencia ante cambios de topología, Junos permite que haya 3 cálculos seguidos de SPF. Después aplica un tiempo de parada obligatoria (hold-down timer) para evitar que el proceso de enrutamiento cargue a la CPU y nos tire el equipo. Esto se hace para situaciones de inestabilidad y muchos cambios en la red, ya que el algoritmo SPF estaría todo el tiempo ejecutándose.
Se puede configurar tanto a nivel global como a nivel de "routing-instance". El tiempo por defecto de "hold-down" es de 5 segundos (5000 ms), pero se puede configurar entre un rango que va de 2000 a 20000 ms:
- set protocols ospf spf-options holddown X
También podemos configurar este tiempo a nuestro gusto el retardo o delay que hay entre un cálculo SPF y el siguiente:
- set protocols ospf spf-options delay X
Aunque configuremos este parámetro, el tiempo de parada obligatoria después de 3 cálculos seguidos de SPF se seguirá ejecutando.
Una práctica común en las redes grandes con OSPF es configurar el spf-options delay un poco más grande que el delay que tiene la red para propagar las rutas. Es decir, si nuesrta red tarde en converger unos 300 ms, podemos configurar el spf-options delay a 350 ms. Con ello damos tiempo para que todas las entradas duplicadas lleguen a todos los routers antes de que el cálculo SPF se ejecutado.
COSTE DE OSPF
Antes de propagar una red en OSPF a través de los LSAs, el equipo tiene que determinar el coste de las interfaces. Como todos los equipos envían el coste de las interfaces, cada equipo puede calcular el coste total para llegar a los otros.
Para determinar el coste de las interfaces dividimos 100.000.000 entre el ancho de banda de la interface. Si el resultado es menor de 1, se redondea a 1.
- Fast Ethernet (100mb) - 1
- Giga Ethernet (1000mb) - 10
Se puede configurar manualmente el coste individual de las interfaces con el siguiente comando:
- set protocols ospf interface X metric X
Si tenemos muchas interfaces o interfaces Ethernet (10mb), la configuración manual de cada interface se puede volver tediosa. Para ello, podemos cambiar la referencia que tienen del coste el protocolo OSPF. En vez de ser 100.000.000, que sería justamente el ancho de banda de una Fast Ethernet, le asignamos otra:
- set protocols ospf reference-bandwidth 10g
Recordad que el coste es el de la interface de salida, por lo que al configurar las métricas manualmente, podemos encontrarnos con routing asimétrico, ya que un router puede estar declarando en la salida de su interface un coste de 10 y el vecino que tiene conectado puede haber configurado ese mismo enlace con un coste de 5. Para el cálculo local de SPF no afecta, pero podemos entrar en un escenario de routing asimétrico. Hay que andarse con mucho ojo.
OVERLOAD
Es el mismo concepto que usa IS-IS. Se usa para que el protocolo siga ejecutándose pero advierte en su área que no está disponible para procesar tráfico. Hay dos escenarios especialmente en los que nos puede ser de gran ayuda.
- Cuando por mantenimiento le sacamos de la red y no queremos que llegue tráfico a este equipo
- Cuando queremos que se establezcan antes todas las vecindades de BGP antes de procesar tráfico a través de OSPF.
Se puede configurar de forma permanente o solo por un tiempo:
- set protocols ospf overload
- set protocols ospf overload timeout X - entre 60 y 1800 segundos
Si lo configuramos normal, la métrica de las interfaces seguirá alta hasta que no lo eliminemos de la configuración y hagamos "commit".
Si configuramos un tiempo, este tiempo no se pondrá en marcha hasta que no se inicie el proceso de routing (rpd). Cuando el tiempo que hemos configurado finaliza, la métrica de las interfaces vuelven al estado normal. Pero ojo, la opción "overload" seguirá en la configuración.
 |
| Se configura Overload y las métricas siguen igual |
Reiniciamos el proceso de routing y tras un momento se ve la métrica de 65535. Como hemos configurado 60 segundos de overload, transcurrido este tiempo la métrica vuelve a 1.
Recordad que el comando "overload" sigue configurado y si se reiniciara el proceso de routing otra vez, por el motivo que sea, se activaría entonces el "overload" por otros 60 segundos.
Nota: cualquier tráfico que vaya directo al equipo, que termine en el equipo, como la gestión por ejemplo, llegará a este.
No hay comentarios:
Publicar un comentario