LABORATORIO OSPF - JCNIS

TOPOLOGÍA

1. Usar las métricas para asegurarnos que el camino que elige es a través del enlace e1 del área del backbone.
2. En JNCIS-OSPF1 redistribuir la red 192.168.1.0/24 y asegurarnos de que se instala como una ruta OSPF de tipo externa.
3. Hacer que la red 192.168.2.0/24 se propague como red OSPF de tipo interna pero además configurar el interface em1.0 de JNCIS-OSPF4 para que no admita vecindades OSPF.

CONFIGURACIÓN BÁSICA

root@JNCIS-OSPF1> show configuration | display set set system host-name JNCIS-OSPF1 set interfaces em0 unit 0 family inet address 172.16.12.1/30 set interfaces em1 unit 0 family inet address 192.168.1.1/24 set interfaces lo0 unit 0 family inet address 10.0.0.1/32 root@JNCIS-OSPF2> show configuration | display set set system host-name JNCIS-OSPF2 set interfaces em0 unit 0 family inet address 172.16.12.2/30 set interfaces em1 unit 0 family inet address 172.16.23.1/30 set interfaces em2 unit 0 family inet address 172.16.230.1/30 set interfaces lo0 unit 0 family inet address 10.0.0.2/32 root@JNCIS-OSPF3> show configuration | display set set system host-name JNCIS-OSPF3 set interfaces em0 unit 0 family inet address 172.16.34.2/30 set interfaces em1 unit 0 family inet address 172.16.23.2/30 set interfaces em2 unit 0 family inet address 172.16.230.2/30 set interfaces lo0 unit 0 family inet address 10.0.0.3/32 root@JNCIS-OSPF4> show configuration | display set set system host-name JNCIS-OSPF4 set interfaces em0 unit 0 family inet address 172.16.34.1/30 set interfaces em1 unit 0 family inet address 192.168.2.1/24 set interfaces lo0 unit 0 family inet address 10.0.0.4/32

-----------------------------------------------------------------------------------------------

1. Configuramos el OSPF básico

root@JNCIS-OSPF1# set protocols ospf area 0.0.0.1 interface em0.0

root@JNCIS-OSPF1# set protocols ospf area 0.0.0.1 interface lo0.0

root@JNCIS-OSPF2# set protocols ospf area 0.0.0.0 interface em1.0

root@JNCIS-OSPF2# set protocols ospf area 0.0.0.0 interface em2.0

root@JNCIS-OSPF2# set protocols ospf area 0.0.0.0 interface lo0.0

root@JNCIS-OSPF2# set protocols ospf area 1 interface em0.0

root@JNCIS-OSPF3# set protocols ospf area 0.0.0.0 interface em1.0

root@JNCIS-OSPF3# set protocols ospf area 0.0.0.0 interface em2.0

root@JNCIS-OSPF3# set protocols ospf area 0.0.0.0 interface lo0.0

root@JNCIS-OSPF3# set protocols ospf area 2 interface em0.0

root@JNCIS-OSPF4# set protocols ospf area 2 interface em0.0

root@JNCIS-OSPF4# set protocols ospf area 2 interface lo0.0

Nota: No hace falta configurar el área con el formato IP, Junos convierte la dirección.

Comprobamos si tenemos conectividad y si se han formado las vecindades:

Si miramos la tabla de rutas, podemos ver, por ejemplo, desde JNCIS-OSPF2 que para llegar a JNCIS-OSPF3 o 4 tenemos dos caminos para llegar. Al tener ambos la misma métrica, OSPF ha elegido uno de los caminos e instala ambas rutas.

Vamos a configurar métrica en OSPF para forzar que el tráfico vaya por la interface em1. Configuramos la métrica en las interfaces em2 para que sean más altas de 1 y así se elija la em1.

Para ello, vamos a JCNIS-OSPF2 Y JNCIS-OSPF3:

root@JNCIS-OSPF2# set protocols ospf area 0 interface em2.0 metric 50

root@JNCIS-OSPF3# set protocols ospf area 0 interface em2.0 metric 50

Comprobamos la tabla de rutas:

Vemos que para llegar ahora a JNCIS-OSPF3 y 4 se llega a través de la em1. También vemos que la métrica asignada al enlace em2 es de 50.

Todas las interfaces que participan en OSPF tienen un coste. que el la métrica de enrutamiento y que se usa para el cálculo del enlace. Las rutas con menor coste son las elegidas para enviar el tráfico. La fórmula para calcular el coste es.

Coste = referencia del ancho de banda / ancho de banda

El valor de la "referencia del ancho de banda" se puede modificar. Este ancho de banda se basa en la capacidad del interface físico. Para modificar este valor:

[edit protocols ospf] user@R1# set reference-bandwidth ? Possible completions: Bandwidth for calculating metric defaults

El valor por defecto del ancho de banda es 100 mbps (que se especifica con una configuracion de 100.000.000 bits )y esto ofrece una métrica de 1 a las interfaces que son FastEthernet (100mbps). Se puede configurar un valor desde 9600 a 1.000.000.000.000 bits.

 Si por ejemplo, establecemos una referencia de 1gbps (1.000.000.000) entonces una interfaces de 1gbps de capacidad tendrá una métrica de 1 y una interface FastEthernet de 100mbs tendría una métrica de 10.

 Por defecto la métrica de la loopback Lo0 es de 0. No hay ancho de banda asociado a la loopback pero podemos establecerle una métrica desde 1 a 65535.

2. Configuramos un política para la redistribución

[edit] root@JNCIS-OSPF1# run show configuration policy-options policy-statement REDIS-EM1 {     term tipo-externa {         from {             protocol direct;             route-filter 192.168.1.0/24 exact;         }         then accept;     } } [edit] root@JNCIS-OSPF1#

Le decimos que la red es la 192.168.1.0/24  exactamente y que además está directamente conectada con el comando "protocol direct"

Ahora aplicamos la política en JNCIS-OSPF1:

root@JNCIS-OSPF1# set protocols ospf export REDIS-EM1

Vemos ahora que se configura con 150, lo que quiere decir que es externa

show ospf route también nos muestra el tipo de ruta externa

3. Por cuestiones de seguridad, se suele configurar las interfaces que no tienen que admitir vecindades OSPF. Además redsitribuimos la red como tipo interna. Para ello, en JNCIS-OSPF4:

root@JNCIS-OSPF4# set protocols ospf area 2 interface em1.0 passive

El atributo pasive cierra la puerta a la formación de vecindades OSPF en ese interface

Vemos en JCNIS-OSPF1 la red con 10 (tipo interna)

Ahora vamos a ver en detalle la vecindad OSPF:

Detalle del show:

• Address: la ip del vecino
• Intf: interface por la que conocemos al vecino
• State: estado del vecino. Este estado puede ser: Attempt, Down, Exchange, ExStart, Full, Init, Loading o 2way
• ID: el RID del vecino
• Pri: prioridad del vecino para convertirse en DR (Designated Router)
• Dead: número de segundos que faltan para que el vecino sea declarado "inalcanzable"
• Area: área a la que pertenece el vecino
• Opt: muestra la opciónes de bits del vecino
• DR: muestra la dirección ip del DR
• BDR: muestra la dirección ip del BDR
• Up: tiempo que lleva arriba el vecino
• Adjacent: tiempo que lleva arriba la vecindad

Un comando muy importante que sirve para restablecer la vecindad:

• clear ospf neighbor

Hay que tener en cuenta que esto resetea la conexión y puede haber entornos en los que no sea recomendable.

Para monitorizar OSPF:

• show ospf interface
• show ospf route
• show ospf database
• show ospf log
• show ospf statistics

Los vemos en detalle:

show ospf interface

show ospf route

show ospf database

El asterisco indica que ese es el router que origina esa entrada.

El Seq: es el número de secuencia que se usa para determinar el LSA. Si el LSA es nuevo, el número de secuencia será 0x80000001. Según la especificación OSPF, cada 30 minutos el equipo que origina el LSA actualizará la secuencia para prevenir que el LSA expire. Junos, amplía este intervalo a 50 minutos para que no se consuman tantos recursos.Cualquier LSA que supere los 3600 segundos será reseteada, purgada.

Dependiendo del tipo de enlace que tengamos a la hora de montar las vecindades, se verán unos datos u otros en la LSDB:

TIPO	LINK ID	LINK DATA
Point-To-Point	RID del Vecino	Ip de la interface del equipo que origina el LSA
Link-To-Transit	Ip de la interface del DR	Ip de la interface del equipo que origina el LSA
Link-To-Stub	Dirección IP de Red	Dirección de Red con máscara o Ip de equipo (/32)
Virtual-Link	RID del Vecino	Índice MIB-II de la interface del router que origina

Podemos hacer una limpia de la LSDB:

                clear ospf database

 show ospf  log

show ospf statistics

PROBLEMAS TÍPICOS CON LAS VECINDADES

PROBLEMA	COMPROBACIÓN
No se detecta al vecino	-          Comprobamos cable (capa 1) y comprobamos si nos llega la mac (capa 2) -          Comprobamos la ip y la máscara, el número de área, el tipo de área, la autenticación, el intervalo de los paquetes “hello” y “dead”, el tipo de red
Se queda en el estado ExStart	-          Comprobamos que el tamaño de las mtu coinciden
Se queda en el estado 2-way	-          Es el estado normal si es un vecino DR-Other

TRACEOPTION (DEBUG)

Cuando hacemos un traceoption, el archivo se guarda en /var/log/X. Podemos comprobar el archivo escribiendo show log X o con monitor start. 

Para configurar un traceoption para OSPF:

root@JNCIS-OSPF2# set protocols ospf traceoptions file OSPF

root@JNCIS-OSPF2# set protocols ospf traceoptions flag hello

root@JNCIS-OSPF2# set protocols ospf traceoptions flag event

root@JNCIS-OSPF2# set protocols ospf traceoptions flag error

Creamos un archivo con el nombre OSPF. Podemos especificar varias cosas para el archivo, incluso podemos decirle all y nos guardaría todos los de la lista (poner una ? para ver la opciones).

Para ver el archivo: show log OSPF

Dejamos el traceoption puesto y vamos a JNCIS-OSPF1 y configuramos lo siguiente para que nos falle la vecindad y se vea en el archivo del traceoption.

root@JNCIS-OSPF1# delete protocols ospf area 1

root@JNCIS-OSPF1# set protocols ospf area 5

root@JNCIS-OSPF1# set protocols ospf area 5 interface em0.0

Vemos en JNCIS-OSPF2 que se ha perdido la vecindad con JNCIS-OSPF1

Ahora desactivamos en JNCIS-OSPF2 el área 0 para que no se nos llene mucho el archivo.

root@JNCIS-OSPF2# deactivate protocols ospf area 0

Comprobamos el archivo y vemos el problema:

Ahora vamos a JNCIS-OSPF1 y restablecemos la vecindad con el área 1:

root@JNCIS-OSPF1# delete protocols ospf area 5

root@JNCIS-OSPF1# set protocols ospf area 0.0.0.1 interface em0.0

root@JNCIS-OSPF1# set protocols ospf area 0.0.0.1 interface lo0.0

La vecindad se forma. Vemos que está en estado "FULL"

Vamos a comprobar los intervalos del  hello y del dead:

El hello en 10 y el dead en 40. Ambos tienen que coincidir en los vecinos

Vamos a JNCIS-OPSF1 y modificamos el hello:

root@JNCIS-OSPF1# set protocols ospf area 1 interface em0.0 hello-interval 15

Y ahora comprobamos en el archivo de JNCIS-OSPF2.

Ahora restablecemos el intervalo del hello a 10. Vemos que se forma la vecindad.

Cuando vemos la palabra "absorbed" es que el intervalo es correcto

Si le echamos un ojo a las estadísticas podemos ver los errores registrados.

Lo siguiente es configurar una mtu diferente a la em0:

root@JNCIS-OSPF1# set interfaces em0 mtu 1492

Ahora vamos a JNCIS-OSPF2 y vemos que la vecindad no se ha formado del todo y se queda en el estado de ExStart.

NOTA: Ojo, que después de cambiar la MTU he tenido que reinciar el GNS3. No formaba la vecindad al eliminar la configuración de la MTU. (delete interfaces em0 mtu 1492)

Tened en cuenta que muchas veces entre dos vecinos existen equipos de capa 2 en medio y estos pueden cambiar la MTU. Si este es el caso, tendremos que configurar esos equipos para que transporten la misma MTU que tenemos configurada o contactar con la empresa que los lleva (ISP)