Ospf-ipv4-enunciado

Ejercicico práctico sobre OSPF con IPv4: ENUNCIADO

OBJETIVOS

Open Shortest Path First (abreviado como OSPF) es un protocolo de encaminamiento dinámico y jerárquico de pasarela interior (Interior Gateway Protocol -IGP-), es decir, se ejecuta dentro de un Sistema Autónomo. Está basado en el algoritmo de Estado de Enlaces (Link State Algorithm -LSA-) y generalmente utiliza el algoritmo de Dijstra para el cálculo de rutas una vez que los nodos conocen la topología de la red. El objetivo de esta práctica es profundizar en los fundamentos de OSPF, observando y analizando el intercambio de paquetes entre los nodos de una red en los cuales se ejecuta el proceso OSPF así como el contenido de sus bases de datos de encaminamiento (Routing Information Base -RIB-). Como implementación del protocolo OSPF se utilizará el paquete de software de encaminamiento "Quagga" que provee servicios basados en TCP/IP con soporte de protocolos de encaminamiento, como es el caso de OSPFv2 (OSPF para IPv4) y OSPFv3 (OSPF para IPv6).

Este enunciado está preparado para el estudio de OSPFv2, sin embargo, se aconseja también su seguimiento con OSPFv3 (Ver ospfv3: Enunciado). En el Anexo VI en "ospfv3: Enunciado" se indican todas las diferencias existentes entre los resultados obtenidos para OSPFv2 y OSPFv3.

DESCRIPCIÓN DEL ESCENARIO

El escenario está compuesto de 7 nodos conectados por enlaces punto a punto como se muestra en la figura. Adicionalmente, algunos de ellos se conectan directamente a redes locales. Los nodos E, F y G están conectados a la misma LAN. En las redes P2 y P4 se dispone de un host (H2 y H4).

La siguiente figura muestra la asignación de direcciones para las máquinas y subredes del escenario para IPv4.

Figura 1: Topología del escenario OSPF para IPv4

En la siguiente tabla se muestra los identificadores OSPF para los routers del escenario:

Nombre del router	Identificador OSPF
A	10.0.0.1
B	10.0.0.2
C	10.0.0.3
D	10.0.0.4
E	10.0.0.5
F	10.0.0.6
G	10.0.0.7

NOTAS

• Si decide resolver un apartado por separado (y no de manera secuencial como se aconseja, en principio), inicie la simulación del archivo ospfv2.xml:

root@host# sudo su (para trabajar como root)
root@host:/home/usuario# cd /vnuml/ospfv2
root@host:/home/usuario/vnuml/ospfv2# vnumlparser.pl -t ospfv2.xml -v -u root

y ejecute este comando para todos los apartados anteriores al que desee estudiar:

root@host:/home/usuario/vnuml/ospfv2# vnumlparser.pl -x aptdo1@ospfv2.xml -v
root@host:/home/usuario/vnuml/ospfv2# vnumlparser.pl -x aptdo2@ospfv2.xml -v
...

A continuación puede proceder como se indica en el enunciado del apartado correspondiente. Debe notar que en esta práctica sólo es necesario ejecutar esos comandos para los apartados 1, 2, 3 y 7.

Adicionalmente puede utilizar este comando para parar el proceso de encaminamiento dinámico "ospfd" en todos los nodos y poder así comenzar a ejecutar los apartados de nuevo:

root@host:/home/usuario/vnuml/ospfv2# vnumlparser.pl -x stop@ospfv2.xml -v

Si desea matar el proceso en una sola de las máquinas ejecute:

root@host:/home/usuario/vnuml/ospfv2# vnumlparser.pl -x stop@ospfv2.xml -v -M <nombre de la máquina>

• A partir de ahora se sustituirá root@host:/home/usuario/vnuml/ospfv2# por root@host# con el fin de no recargar el enunciado.

• Ignore las líneas informativas que resultan de la ejecución de cada apartado, no son relevantes para la resolución de esta práctica.

Apartado 1: Arranque del proceso OSPFv2 en el nodo A.

En este apartado se procederá a arrancar el proceso OSPFv2 en el nodo A.

• Inicie la simulación del archivo ospfv2.xml:

root@host# sudo su (para trabajar como root)
root@host# cd /vnml/ospfv2
root@host# vnumlparser.pl -t ospfv2.xml -v -u root

• Regístrese en cada máquina virtual:

# login: root
# password: xxxx

Figura 2: Ventanas de las máquinas virtuales

• En primer lugar se comienza a capturar tráfico en la máquina virtual A, en su enlace con B, guardando el resultado en un fichero:

A# tethereal -i eth2 -S -w aptdo1_v2.cap

NOTA: Puede recuperar el fichero obtenido desde su PC escribiendo en un Terminal:

root@host# scp A:aptdo1_v2.cap .

• Para arrancar el proceso OSPFv2 en el nodo A escriba el comando:

root@host# vnumlparser.pl -x aptdo1@ospfv2.xml -v -u root

A partir de este momento el nodo A comienza a enviar mensajes "Hello" así como mensajes IGMP correspondientes al grupo multicast al que se envían los paquetes OSPF.

Pasados unos segundos (los suficientes para que OSPF converja), detenga la captura y analícela.

¿Recibe el nodo A algún mensaje en respuesta a los mensajes Hello que envía periódicamente? ¿Cuál es la utilidad de esos mensajes? Estime el periodo de envío de los paquetes Hello.

• En el nodo A se pueden solicitar ciertas informaciones sobre OSPF. Para ello debemos hacer "telnet" al puerto del proceso "ospfd", correspondiente a OSPFv2: OSPF para IPV4 (caso que nos ocupa). Cualquiera de los siguientes comandos es válido: el primero si se ejecuta desde el host y el segundo si se ejecuta desde el propio nodo. La contraseña del proceso es "xxxx".

root@host# telnet A 2604

A# telnet localhost 2604

Aparecerá entonces lo siguiente:

A:~# telnet localhost 2604
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
 

User Access Verification

Password: 
A-ospfd> 

Una vez dentro del proceso se ejecutarán los siguientes comandos de solicitud de información:

• 1. sh ip ospf interface: muestra la información relacionada con las interfaces de un nodo. Cuando una interfaz está activada se expresa como "<nombre de la interfaz> is up", pero si no se permite en ella el protocolo OSPF se añade "OSPF not enabled on this interface".

¿En qué interfaces activas del nodo A participan en el protocolo OSPF?

• 2. sh ip ospf neighbor: muestra las vecindades establecidas por el nodo.

¿Qué vecindades ha establecido el nodo A hasta el momento?

• 3. sh ip ospf database: muestra un resumen de la información relativa a OSPF aprendida por el nodo.

¿De qué nodos contiene información la base de datos del nodo A?

• 4. sh ip ospf route: muestra las rutas aprendidas por el nodo gracias al protocolo de encaminamiento dinámico OSPF.

¿Qué rutas conoce el nodo A?

¿Con qué tipo de interfaces se corresponden las entradas /32? ¿Cuál es la utilidad de esas interfaces?

NOTA: Puede obtener más información acerca de los comandos que solicitan información relativa a OSPFv2 aquí: [1]

Apartado 2: Arranque del proceso OSPFv2 en el nodo B.

A continuación se arrancará OSPFv2 en el nodo B (vecino de A).

• Realice una nueva captura en el enlace A-B desde el nodo A:

A# tethereal -i eth2 -S -w aptdo2_v2.cap

root@host# vnumlparser.pl -x aptdo2@ospfv2.xml -v -u root

En la captura de tráfico del enlace A-B se recogen los paquetes intercambiados por los nodos para el establecimiento de su vecindad, la sincronización de sus bases de datos y el intercambio de información.

Pasados unos segundos (los suficientes para que OSPF converja), detenga la captura y analícela.

La captura obtenida puede encontrarse en modo texto en el Anexo I o como aptdo2_v2.cap en las capturas de muestra.

• Analice la secuencia de paquetes capturada. ¿Qué paquetes intercambian los nodos y para qué sirve cada uno?

• Dentro del proceso "ospfd" del nodo A se solicitará de nuevo cierta información:

• 1. sh ip ospf neighbor:

¿Qué vecindades ha establecido el nodo A hasta el momento?

2. sh ip ospf database:

¿De qué nodos contiene información la base de datos del nodo A?

3. sh ip ospf route:

¿Qué rutas conoce el nodo A?

4. sh ip ospf database router: muestra información de los LSAs de tipo router generados por A o recibidos desde otros nodos.

¿Qué es un LSA? ¿De qué tipo de mensajes OSPF forma parte? ¿A qué nodos de la red se envían, mediante qué mecanismo?

¿Para que sirven los LSAs de tipo 1, 2 y 3?

¿Cuántos LSAs de tipo router almacena el nodo A?

Apartado 3: Arranque del proceso OSPFv2 en los nodos C, D y E.

Por último se iniciará el proceso para OSPFv2 en el resto de máquinas.

• Realice una nueva captura en el enlace A-B desde el nodo A:

A# tethereal -i eth2 -S -w aptdo3_v2.cap

root@host# vnumlparser.pl -x aptdo3@ospfv2.xml -v -u root

Pasados unos segundos (los suficientes para que OSPF converja), detenga la captura y analícela.

La captura obtenida puede encontrarse en modo texto en el Anexo I o como aptdo3_v2.cap en las capturas de muestra.

¿Cuál es la dirección IP destino de los paquetes OSPF? ¿Que nodos de la red reciben los paquetes generados por un nodo particular?

Transcurrido un cierto tiempo, el protocolo OSPF converge en la red. Esto ocurre cuando todos los nodos conocen la información completa de la topología de la red. Tras este proceso, se pueden repetir las consultas en A, que contendrá una información completa de todos los nodos del escenario:

• 1. sh ip ospf neighbor:

¿Qué vecindades ha establecido el nodo A hasta el momento?

• 2. sh ip ospf database:

¿De qué nodos contiene información la base de datos del nodo A?

• 3. sh ip ospf route:

¿Qué rutas conoce el nodo A?

• 4. sh ip ospf database router:

Describa en líneas generales el resultado que se obtiene al ejecutar el comando "sh ip ospf database router" destacando su estructura e información proporcionada.

¿Qué LSAs almacena el nodo A?

Apartado 4: Efecto de la caída de un enlace.

En este apartado se estudiarán los efectos que tiene la caída de un enlace en las bases de datos de los nodos, así como el intercambio de paquetes que genera.

• Realice un "traceroute" desde H2 hasta H4.

H2# traceroute 10.0.4.10

¿Qué enlaces están implicados en el camino H2-H4?

El enlace implicado es: B->C.

Este es el resultado de realizar el "traceroute" H2-H4:

H2:~# traceroute 10.0.4.10
traceroute to 10.0.4.10 (10.0.4.10), 30 hops max, 40 byte packets
 1  10.0.2.1 (10.0.2.1)  30.865 ms  0.634 ms  0.237 ms
 2  10.0.100.10 (10.0.100.10)  28.372 ms  0.975 ms  0.340 ms
 3  10.0.4.10 (10.0.4.10)  30.635 ms  1.208 ms  0.432 ms

• Comience a capturar en el enlace A-B desde la interfaz del nodo A. A continuación inicie en H2 un "ping" hacia H4 y déjelo ejecutándose.

A# tethereal -i eth2 -S -w aptdo4_v2.cap

H2# ping 10.0.4.10

• Simultáneamente entre en la máquina C y ejecute, sin dejar de observar la ejecución del "ping" H2-H4:

C# ifconfig eth3 down

Con este comando está desactivando la interfaz de C hacia el enlace punto a punto con B. Ya puede detener el "ping" H2-H4. Detenga también la captura asociada pasado aproximadamente un minuto para que todos los nodos actualicen su información de la topología de la red.

La captura obtenida puede encontrarse en modo texto en el Anexo I o como aptdo4_v2.cap en las capturas de muestra. El resultado de ejecutar el "ping" en la máquina H2 puede encontrarse en el Anexo VI.

Ahora responda las siguientes preguntas:

• ¿Ha observado en algún momento alguna anomalía en la ejecución del "ping"? Si ha sido así, ¿cuándo ha ocurrido?, ¿por qué ha ocurrido?, ¿cuándo se ha solucionado?

• ¿Qué cambios se observan en las vecindades del nodo B?

• ¿Ha cambiado de alguna forma el "traceroute" H2-H4? ¿Qué enlaces se ven implicados? A partir del análisis del "traceroute" tras la caída del enlace, ¿qué podría decir de las tablas de rutas de los nodos?

• ¿Cómo ha cambiado el LSA de tipo router del nodo B que está almacenado el nodo A? Compárelo con el obtenido en el Apartado 3 y explique por qué se ha producido el cambio.

• ¿Cómo ha cambiado el LSA de tipo router del nodo C que está almacenado el nodo A? Compárelo con el obtenido en el Apartado 3 y explique por qué se ha producido el cambio.

• Analice con Ethereal la captura obtenida en el enlace A-B. Identifique los paquetes de actualización del estado de la red y describa dónde se observa el efecto de la caída del enlace B-C.

Apartado 5: Efecto de la activación de un enlace.

En este apartado se estudiarán los efectos que tiene la reactivación de un enlace en las bases de datos de los nodos, así como el intercambio de paquetes que genera.

• Comience a capturar de nuevo en el enlace A-B desde la interfaz del nodo A. A continuación inicie en H2 otro "ping" hacia H4 y déjelo ejecutándose.

A# tethereal -i eth2 -S -w aptdo5_v2.cap

H2# ping 10.0.4.10

• Simultáneamente entre en la máquina C y ejecute, sin dejar de observar la ejecución del "ping" H2-H4:

C# ifconfig eth3 up

Con este comando se vuelve a activar la interfaz de C en el enlace punto a punto B-C. Ya puede detener el "ping" H2-H4. Detenga también la captura asociada pasado aproximadamente un minuto para que todos los nodos actualicen su información de la topología de la red.

La captura obtenida puede encontrarse en modo texto en el Anexo I o como aptdo5_v2.cap en las capturas de muestra. El resultado de ejecutar el "ping" en la máquina H2 puede encontrarse en el Anexo VI.

Ahora responda las siguientes preguntas:

• ¿Ha observado en algún momento alguna anomalía en la ejecución del "ping"? Si ha sido así, ¿cuándo ha ocurrido?, ¿por qué ha ocurrido?, ¿cuándo se ha solucionado?

• ¿Qué cambios se observan en las vecindades del nodo B?

• ¿Ha cambiado de alguna forma el "traceroute" H2-H4? ¿Qué enlaces se ven implicados? A partir del análisis del "traceroute" tras la caída del enlace, ¿qué podría decir de las tablas de rutas de los nodos?

• Analice con Ethereal la captura obtenida en el enlace A-B. Identifique los paquetes de actualización del estado de la red y describa dónde se observa el efecto de la activación del enlace B-C.

Apartado 6: Caída y rearranque del proceso OSPFv2 en un nodo.

El objetivo de este apartado es ilustrar el comportamiento de un nodo cuando, tras haber caído, se rearranca en él el proceso OSPFv2. En concreto estudiaremos este fenómeno en el nodo B, analizando el tráfico en el nodo A en su interfaz con el enlace A-B. De esta forma será posible analizar el intercambio de paquetes producido.

• Comience a capturar tráfico en el nodo A, guardando la captura en un fichero:

A:~# tethereal -i eth2 -S -w aptdo6_v2.cap

• Pare el proceso OSPF del nodo B con el siguiente comando:

B:~# killall ospfd

• Pasado unos segundos rearranque el proceso OSPF en el nodo B ejecutando:

B:~# /usr/local/bin/ospfd -d -f /etc/quagga/ospfd.conf

• Detenga la captura pasado por lo menos un minuto para observar el intercambio de paquetes completo.

• ¿Con qué tipo de mensajes vuelve a establecerse la vecindad? ¿Qué nodos reciben esos mensajes?

• ¿Qué tipo de mensajes permiten dar a conocer la base de datos de cada nodo? ¿Cuál es su contenido? ¿Qué nodos los reciben?

• ¿Qué es lo que produce que un nodo envíe un mensaje LS Request? ¿Qué mensaje recibe como respuesta?

• ¿Es OSPF un protocolo fiable? Si es así, ¿qué mecanismos se utilizan para tal fin?

Apartado 7: Router Designado y Router Designado de backup.

En este momento se iniciará también el proceso OSPFv2 en las máquinas F y G. Los nodos E, F y G forman parte de un mismo segmento de difusión. OSPF incluye un mecanismo para que sea uno sólo de ellos el que anuncie el prefijo de la subred y los identificadores de todos los nodos conectados a ella.

• En primer lugar inicie una captura desde su host en la interfaz correspondiente a la subred "P7". Para ello, dentro de Ethereal seleccione:

> Capture > Interfaces 

Aparecerá una lista de interfaces, de entre los cuales el interfaz "P7" será el utilizado a lo largo de este apartado:

Figura 3: Interfaces del escenario

Seleccione ahora:

> P7 > Prepare (P7) > Capture File: aptdo7_1_v2.cap > Start

Gracias a esta nueva interfaz, puede evitarse guardar las capturas en ficheros de las máquinas virtuales y su posterior copia remota. Además podrá observar todo el tráfico generado en cualquier máquina de la subred.

• Para iniciar el proceso OSPF en las máquinas F y G ejecute:

root@host# vnumlparser.pl -x aptdo7@ospfv2.xml -v -u root

• Pasado el tiempo suficiente para que el protocolo converja, obtenga del nodo A los LSAs de tipo router que tiene almacenados para los routers E, F y G. Solicite también los LSAs de tipo network contenidos en A.

A-ospfd> sh ip ospf database router 10.0.0.5
A-ospfd> sh ip ospf database router 10.0.0.6
A-ospfd> sh ip ospf database router 10.0.0.7
A-ospfd> sh ip ospf database network

• ¿Qué nodos incluyen en su LSA de tipo router el prefijo de la subred "P7"?

• ¿Para qué sirve la nueva entrada de los LSAs de tipo router de los nodos E, F y G denominada como "Link connected to: a Transit Network"?

• A partir de la información proporcionada por el comando "sh ip ospf database network" ejecutado en A, ¿qué router de la subred "P7" es el "Router Designado"?

• ¿Qué otra información proporciona el LSA de tipo network?

• Observe la captura obtenida. ¿Qué mensajes se utilizan para la negociación del Router Designado? ¿Cómo se realiza dicha negociación en este escenario?

• ¿Qué es un Router Designado de backup? ¿Cuál es el Router Designado de backup en esta situación?

• ¿Qué nodos de la subred almacenan y actualizan la información topológica de la subred?

• Inicie una nueva captura desde su host con Ethereal en la interfaz "P7":

> Capture > Interfaces 

> P7 > Prepare (P7) > Capture File: aptdo7_2_v2.cap > Start

• Pare ahora el proceso OSPF en el Router Designado escribiendo en su consola:

# killall ospfd

• Vuelva a solicitar los LSAs de tipo routers que almacena A procedentes de los nodos de la subred "P7" (salvo aquel en el que ha parado el proceso OSPF), así como los LSAs de tipo network:

Los resultados de ejecutar estos comandos pueden encontrarse en el Anexo V, Apartado 7_2.

• ¿Qué diferencia se observa en las entradas "Link connected to: a Transit Network" de los LSAs de tipo router para los nodos de la subred "P7" respecto a la situación anterior?

• ¿Qué diferencias observa en el resultado de ejecutar en el nodo A el comando "sh ip ospf database network"?

• ¿Por qué sigue almacenando A el LSA de tipo network correspondiente al anterior Router Designado? ¿Se tendrá en cuenta ese LSA para el cálculo de rutas?

• Observe la captura obtenida. ¿Qué mensajes se utilizan para la renegociación del Router Designado? ¿Cómo se realiza dicha renegociación en este escenario?

• ¿Cuál es el Router Designado de backup en esta nueva situación? NOTA: Por razones de implementación el router E se ha configurado de forma que no pueda ser nombrado Router Designado.