Redes de Informacion

UNIVERSIDAD TECNOLÓGICA
NACIONAL FACULTAD REGIONAL

2018 RESISTENCIA
Ingeniería en sistemas de Información
REDES DE INFORMACIÓN
Materia del 4º nivel
Trabajo Tercer Desafío
Elaborado por Grupo: “4”
Integrantes:
• Jose E. CALVANO VIOLA.

• Matías R. JAIME.
• Nicolás MONTOYA.
• Damián C. MORALES MOLINA.
Presentado ante:
• Ing. Ricardo CALCAGNO.

• Ing. Reinaldo SCAPPINI.
~10 de noviembre de 2018~

Facultad Regional Resistencia Trabajo Tercer Desafío.
Universidad Tecnológica Nacional Cátedra: Redes de Inf.
Índice
Introducción:........................................................................................................ 3
1. Mensajes OSPF ................................................................................................ 4
1.1 Encabezado OSPF ................................................................................ 4
1.2 Formato de los distintos tipos de mensaje: ........................................... 6
1.2.1 Formato del mensaje HELLO: ............................................................ 6
1.2.2 Formato del mensaje Database Description (BD Description): .. 8
1.2.3 Formato del mensaje Link Status Request (LS Request): ............ 12
1.2.4 Formato del mensaje Link Status Update (LS Update): .............. 13
1.2.5 Formato del mensaje Link State Acknowledge (LS
Acknowledge): .......................................................................................... 15
2. Establecimiento de Adyacencia y Vecindad .......................................... 16
3. Respecto de la topología ............................................................................ 21
3.1 Manejo de cambios en la topología Ospf .......................................... 21
3.2 Rápido Recalculo de Rutas ................................................................... 21
3.3 Estructura y áreas .................................................................................... 22
3.4 Construcción del mapa de la topología. ............................................ 24
MAPA DE LA TOPOLOGÍA ................................................................................. 51
3.5 Cambio final en la topología ................................................................ 52
4 esquema de direccionamiento IP .............................................................. 53
4.1 Direccionamiento de multidifusión IP y OSPF ..................................... 53
4.2 Redes Involucradas: VLSM y OSPF ........................................................ 53
Conclusión ......................................................................................................... 56
Bibliografía ......................................................................................................... 56
Página 2 de 56
Alumnos: Calvano Jose, Jaime Matías, Montoya Nicolás, Morales Damián.
Introducción:
En el siguiente trabajo analizaremos el protocolo OSPF (Open Shortest

Path First) el cual es la implementación del algoritmo de enrutamiento
por estado de enlace. Este denota cierta complejidad, pero es debido
a las posibilidades y prestaciones que brinda.
Nuestro trabajo consiste en primera instancia analizar los 5 tipos de
mensajes en OSPF para dar al lector un panorama general y luego
adentrarnos en conceptos claves cómo adyacencia y vecindad, cómo
se establece y cómo es el proceso. El análisis fundamental será de una
captura de Wireshark y descubrir la topología de la red en cuestión.
Finalmente brindaremos la topología final y las redes que intervienen
con información de las mismas (cantidad de hosts, rango de
direcciones, etc.).
Página 3 de 56
1. Mensajes OSPF
Al igual que los otros protocolos de enrutamiento dinámicos, OSPF utiliza
mensajes para poder transportar información de su funcionamiento.
Todos los paquetes de OSPF comparten el mismo encabezado. Los
mensajes que utiliza OSPF son:
• Tipo 1: Hello.
• Tipo 2: Database Description (DB Description).
• Tipo 3: Link-State Request (LS Request).
• Tipo 4: Link-State Update (LS Update).
• Tipo 5: Link-State Acknowledgement (LS Acknowledgement).
A continuación, analizaremos las tramas asignadas con el fin de

relacionar la información provista por Wireshark con el formato de los
mensajes OSPF vistos en clase.
1.1 Encabezado OSPF

Cada mensaje OSPF comienza con un encabezado fijo de 24 octetos
(en IPv4) como muestra la siguiente figura 1.1:
Fig. 1.1 Formato del Encabezado OSPF.
Wireshark nos identifica perfectamente este encabezado, para todos

los mensajes del protocolo OSPF:
Página 4 de 56
Fig 1.2 Encabezado de un mensaje OSPF en Wireshark
Versión (1 byte): Especifica la versión del protocolo OSPF, en este caso

la 2.
Message Type (1 byte): Identifica el tipo de mensaje, como uno de los
siguientes:
Fig 1.3 Tipos de mensajes OSPF
Packet Length (2 bytes): Longitud del paquete OSPF (en bytes),

incluyendo el header, para este paquete es de 44 bytes.
Router ID (4 bytes): RID del router que crea el paquete OSPF, el cual
sería el router 200.188.73.10.
Área ID (4 bytes): Área a la cual pertenece la interfaz del router OSPF,
en este caso el área es 0.0.0.0 (Backbone), la cual es el área de red
troncal.
Checksum (2 bytes): Este campo es utilizado para determinar la
integridad del paquete OSPF, en este caso la verificación fue correcta.
Se debe 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).
Authentication Type (2 bytes): Especifica el tipo de autenticación del
protocolo, donde este puede ser:
Página 5 de 56
Type Description
0 Null
1 Simple Password
2 Cryptographic authentication.
Fig 1.4 Tipos de autenticación.
Authentication (8 byte): Campo usado por el esquema de

autenticación, como en este caso el Auth Type es 0(Null), este campo
no se utiliza.
1.2 Formato de los distintos tipos de mensaje:

Como ya vimos, los mensajes que se intercambian en el protocolo OSPF
pueden ser de diferentes tipos, por lo que el formato del mensaje varía
de acuerdo a este. A continuación, se muestran los distintos tipos de
mensajes OSPF y sus formatos.
1.2.1 Formato del mensaje 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, es decir, se envían periódicamente
mensajes HELLO en cada enlace para establecer y probar la
accesibilidad del vecino. En la siguiente figura se muestra su formato:
Fig 1.2.1 Formato del Mensaje Hello.
Si analizamos un paquete Hello con Wireshark, obtenemos la siguiente

información:
Página 6 de 56
Fig 1.2.2 Información de un Mensaje Hello en Wireshark.
Contrastando esta información con el formato visto en clases, tenemos:
Network Mask (4 bytes): corresponde a la máscara de la red

configurada en la interfaz en donde se origina el paquete Hello, en este
caso la máscara es 255.255.255.128.
Hello Interval (2 bytes): número de segundos que el router debe esperar
para enviar un mensaje Hello, por defecto se lo suele configurar en 10
segundos como en este caso.
Options (1 byte): campo utilizado para habilitar capacidades
opcionales de OSPF. Este campo se encuentra en todos los paquetes
OSPF. Los valores son los siguientes:
• DN: impide este bucle de enrutamiento. Cuando un enrutador
OSPF recibió un LSA Tipo 3, 5 o 7 con el bit DN establecido, no
puede usar ese LSA en los cálculos de ruta OSPF.
• O: establece cuando el enrutador de origen admite los Opaque
LSA de los tipos 9, 10 y 11.
• DC: se establece cuando el enrutador de origen admite OSPF
sobre circuitos de demanda.
• L: Indica si el paquete OSPF contiene un bloque de datos de
señalización de enlace local (LLS). Este bit se establece solo en los
paquetes Hello y DBD.
• N: Se usa solo en los paquetes de saludo. El bit N se establece
cuando el enrutador de origen admite tipos-7 NSSA-External-LSA.
Cuando el bit N se establece en 1, el bit E debe ser 0.
Página 7 de 56
• MC: Se establece cuando el enrutador de origen admite

extensiones de multidifusión a OSPF (MOSPF).
• E (ExternalRoutingCapability): se establece cuando el enrutador
de origen es capaz de aceptar AS LSA externos.
• MT: El bit MT se establece cuando el enrutador de origen admite
Multitopology OSPF, MT-OSPF.
Router Priority (1 byte): usado para elegir al DR/BDR del segmento, si este
es configurado en 0, no participa de esta elección, en este caso es 1.
Router Dead Interval (4 bytes): este campo indica la cantidad de
segundos antes de declarar “DOWN” a un router vecino que no
responde, por defecto se lo configura en 40 segundos como en este
caso.
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. En este caso el DR es el
router 200.188.73.10.
Backup Designated Router (4 bytes): identifica al router designado de
respaldo de la red, en caso de que el DR falle. En este caso el valor es
0.0.0.0, lo que significa que no se tiene BDR.
Neighbor (campo variable): identifica cada router vecino, del cual se
recibió un mensaje Hello. En este caso solo se recibió un mensaje Hello
del router 200.188.73.100.
1.2.2 Formato del mensaje Database Description (BD Description):

Los paquetes BD Description 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. En la figura siguiente se muestra su formato:
Página 8 de 56
Fig. 1.2.3 Formato del Mensaje DB Description.
Si analizamos un paquete DB Description con Wireshark, obtenemos la

siguiente información:
Fig 1.3.2 Información de un Mensaje DB Description en Wireshark.
Comparando esta información con el formato visto en clase, tenemos:

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), para este caso el tamaño de la unidad máxima de
transferencia es de 1500 bytes.
Página 9 de 56
Options (1 byte): son los mismos valores enviados en los paquetes hello.
Flags:
Flag Description
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.
Los flags trabajan en pares, y dependiendo de cómo estén

configurados, significa lo siguiente:
Configuraciones
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.
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. Esta cabecera se repite
para cada enlace definido y tiene el siguiente formato:
Fig. 1.2.4 Formato del Encabezado LSA.
Los LSA (Link State Advertisements) son, actualizaciones del estado de

los enlaces, es decir, son los paquetes que contienen toda la
información referente a rutas, quien se conecta con quien, interfaces,
Página 10 de 56
costos, etc. Cada vez que una interfaz levanta o cae, son los LSA
quienes llevan esta información a todos los routers.
De esta cabecera LSA Wireshark nos muestra los siguientes datos:
Fig 1.2.5 Información de la cabecera LSA provista por Wireshark
LS Age (2 byte): Este campo es la edad del LSA en segundos. Se

establece en 0 cuando se origina el LSA. Debe ser incrementado por
InfTransDelay en cada salto del procedimiento de inundación, para este
caso es de 44 segundos.
Options (1 byte): Son los mismos valores enviados en los paquetes hello.
LS Type (1 byte): Describe un enlace de acuerdo a la siguiente tabla:
Tipo Descripción
1 = Router LSA Generado por todos los enrutadores en un área para describir sus
enlaces directamente conectados (rutas dentro del área). No
abandona el área.
2 = Network LSA Generado por el DR de un segmento de broadcast o non-broadcast
para describir a los vecinos conectados a ese segmento. No
abandona el área.
3 = Network Generado por el enrutador de borde de área (ABR) para describir
Summary una ruta a vecinos fuera del área (ruta entre áreas).
4 = ASBR Summary Generado por el ABR para describir una ruta a un Autonomous
System Boundary Router (ASBR) a vecinos fuera del área.
5 = External LSA Generado por el ASBR para describir rutas redistribuidas en el área.
Página 11 de 56
Link State ID (4 bytes): Este campo identifica la parte del dominio de

enrutamiento que se describe en el anuncio. Según el tipo de LS del
anuncio, toma los siguientes valores:
LS Type Link State ID

1 La ID del enrutador de Origen.
2 La dirección IP del enrutador designado de la red.
3 La dirección IP de la red de destino.
4 El ID del enrutador ASBR.
5 La dirección IP de la red de destino.
Como el tipo de LS es “Router LSA” entonces toma la ID del enrutador

de origen 200.188.72.141.
Advertising Router (4 bytes): Este campo especifica el ID del enrutador
OSPF que origina el anuncio. Para los “Router LSA” este campo es
idéntico al campo ID del estado del enlace, por eso toma el valor
200.188.72.141.
LS Sequence Number (4 bytes): se utiliza para detectar LSA antiguos y
duplicados. Cuanto mayor sea el número de secuencia (cuando se
compara con enteros de 32 bits con signo), más reciente será el
anuncio.
LS Checksum (2 bytes): Este campo es la suma de comprobación de los
contenidos completos del anuncio, excepto el campo de antigüedad
LS. Se exceptúa el campo de la edad de LS para que la edad de un
anuncio pueda incrementarse sin actualizar la suma de comprobación.
Length (2 bytes): Longitud de la LSA incluyendo el encabezado de la
LSA, en bytes, en este caso es de 108 bytes.
1.2.3 Formato del mensaje Link Status Request (LS Request):

Después de intercambiar mensajes BD Description con un vecino, un
enrutador puede descubrir que partes de su base de datos están
desactualizadas. Para solicitar que el vecino proporcione información
actualizada, el enrutador envía un mensaje LS Request. El mensaje
enumera enlaces específicos. El vecino responde con la información
más actualizada que tiene sobre esos enlaces. Los tres campos
mostrados se repiten para cada enlace sobre el cual se solicita el
estado. Es posible que se necesite más de un mensaje de solicitud si la
lista de solicitudes es larga. El formato del mensaje LS Request es el
siguiente:
Página 12 de 56
Fig. 1.2.6 Formato del mensaje LS Request.
Al analizar un mensaje LS Request con Wireshark, este nos muestra la

siguiente información, la cual se corresponde exactamente con el
formato anterior:
Fig. 1.2.7 Información de un mensaje LS Request en Wireshark
Donde los valores son los mismos que cuando se analizaron las
cabeceras LSA en el apartado anterior:
LS Type: describe el tipo de LSA, y puede tomar los valores ya vistos.
Link State ID: identifica la parte del dominio de enrutamiento que se
describe en el anuncio.
Advertising Router (4 bytes): especifica el ID del enrutador OSPF que
origina el anuncio.
1.2.4 Formato del mensaje Link Status Update (LS Update):

Los enrutadores transmiten el estado de los enlaces con un mensaje LS
Update. Cada actualización consiste en una lista de anuncios. El
formato de este tipo de mensajes es el siguiente:
Página 13 de 56
Fig. 1.2.8 Formato del mensaje LS Update.
Analizando un mensaje LS Update en Wireshark, obtenemos la siguiente

información:
Fig. 1.2.9 Información de un mensaje LS Update en Wireshark.
Donde nos indica el número de anuncios de estado de enlace incluidos

en esta actualización, que es 6 y cada uno de los LSA.
Además, Wireshark nos provee la información de cada LSA, lo que nos
posibilita conocer quien se conecta con quién, las diferentes interfaces,
los costos, etc.
Página 14 de 56
Fig. 1.2.10 Información de los LSA de un mensaje LS Update en Wireshark.
1.2.5 Formato del mensaje Link State Acknowledge (LS Acknowledge):
Es necesario que la inundación de LSA’s sea confiable, por eso, se

necesita un mecanismo de acuse de recibo para saber si los LSA’s
llegaron al destino. En este punto aparecen los LS Acknowledge, los
cuales son respuestas a los LS Updates (paquete contenedor de LSA’s).
Al igual que con los LS Updates, se pueden responder a todos los LSA’s
intercambiados con un único LS Acknowledge (dependiendo de la
cantidad de LSA’s intercambiados), y estos pueden usar la dirección
multicast o unicast como destino, según la configuración de OSPF.
En esta respuesta, los LS Acknowledge responde con los headers de los
LSA’s enviados por el vecino:
Fig. 1.2.11 Formato de un mensaje LS Acknowledge.
Página 15 de 56
Fig 1.2.12 Información de un mensaje LS Acknowledge en Wireshark.
2. Establecimiento de Adyacencia y
Vecindad
Creación de adyacencias
Describiremos a continuación el proceso que hace que dos routers se

conviertan en adyacentes, estos son los routers 200.188.73.100 y
200.188.73.10. Estos pasan a través de una serie de estados antes de
formar una adyacencia exitosa.
Cuando un router se vea a sí mismo en el paquete hello de su vecino, el

estado hace una transición a bidireccional (two-way). En ese momento,
la elección de DR y BDR se desarrolla en segmentos de acceso múltiple.
Un router continúa formando una adyacencia con un vecino si alguno
de los dos routers es un DR o BDR o están conectados a través de un link
punto a punto o virtual. El router se ha visto a sí mismo en los paquetes
Página 16 de 56
de saludo provenientes de un vecino. Al final de esta etapa, se habría

realizado la elección del DR y el BDR. Al final de la etapa de dos vías, los
routers decidirán si proceden o no a construir una adyacencia.
Fig. 2.1. Paquete Hello de 200.188.73.100 a 200.188.73.10
Fig. 2.2 Reconocimiento de Vecino
El Router 200.188.73.100 envía Hello al 200.188.73.10 en el paquete

podemos ver qué ya lo reconoce como vecino al 200.188.73.10.
Además de la trama podemos saber que el DR es 200.188.73.100.
En el estado Exstart, los dos vecinos establecen una relación

maestra/esclavo en la que coinciden en un número de secuencia
inicial. El número de secuencia se utiliza para detectar Anuncios de
estado de link (LSA) antiguos o duplicados.
fig. 2.3 Primer Intercambio de Base de datos
En primera instancia al intercambiar bases de datos ambos son

maestros, podemos ver qué tienen seteados los bits de maestro.
Página 17 de 56
Fig. 2.4 BD desde 200.188.73.100 a 200.188.73.10
Fig. 2.5. BD desde 200.188.73.10 a 200.188.73.100
Luego de negociar podemos ver que el Maestro será el 200.188.73.10 y

el Esclavo será el 200.188.73.100.
2.6 Fin de la negociación Maestro-Esclavo.
Fig. 2.7 Fin de la negociación Maestro-Esclavo, Paquete.
Página 18 de 56
En el estado de intercambio (exchange), los routers intercambiarán

Paquetes de descripción de bases de datos (DD), es decir sus bases de
datos completas de estado de links al enviar paquetes de descripción
de bases de datos. En este estado, los paquetes se podrían distribuir en
forma de inundaciones a otras interfaces del router. El nodo maestro
envía los paquetes DD que se reconocen con los paquetes DD del nodo
esclavo.
Fig. 2.8 Exchange entre Routers
En el estado de carga (loading), los paquetes de pedido del estado del

link se envían a los vecinos con objeto de solicitar avisos más recientes
que hayan sido descubiertos pero que aún no se hayan recibido. Cada
router crea una lista de LSA requeridos para actualizar su adyacencia.
Se mantiene una Lista de retransmisión para asegurarse de que cada
LSA es reconocido. Se envían paquetes de actualización de estado de
link en respuesta a los paquetes de petición. Los paquetes de
actualización de estado de link se inundarán en todas las adyacencias.
Fig. 2.9 Estado de Carga
En el estado Full, los routers vecinos son totalmente adyacentes. Las

bases de datos para un área común son tienen concordancia exacta
entre routers adyacentes. Cada LSA posee un campo de edad que se
incrementa periódicamente mientras permanece en la base de datos o
a medida que se inunda en el área. Cuando un LSA alcanza una
Maxage (Antigüedad máxima) se purga de la base de datos si ese LSA
no figura en ninguna lista de retransmisión de vecinos.
Fig. 2.10 Estado Full, ya son adyacentes.
Hay que destacar que existe una superposición de LSRequest y

LSUpdate entre el estado full y loading.
Página 19 de 56
Fig. 2.11 Secuencia de estados
Fig. 2.12 Secuencia de conversación con Wireshark
Página 20 de 56
3. Respecto de la topología
3.1 Manejo de cambios en la topología Ospf
El protocolo OSPF utiliza dos mecanismos para detectar cambios de la
topología.
Los cambios del estado del interfaz (tales como falta del portador en un
enlace serial) es el primer mecanismo.
El segundo mecanismo es la falta de recepción de paquetes “hello” de
su vecino dentro de una ventana de la sincronización llamada contador
de tiempo muerto.
Después de que expire este contador de tiempo, el ruteador asume que
el vecino está caído.
El valor prefijado del contador de tiempo muerto es cuatro veces el
valor del intervalo hello, por defecto el lapso de tiempo muerto es de 40
segundos para las redes de difusión (nuestro caso de estudio).
3.1.1 Dead interval 40 Seg
3.2 Rápido Recalculo de Rutas

Después de que se haya detectado una falta, el ruteador que detectó
la falla manda un paquete de Flooding de LSA con la Información del
cambio a todos los ruteadores con las cuales esté conectada
directamente. El ruteador de detección continuará haciendo un
flooding, de esta información hasta que cada ruteador con el cual está
conectada directamente reconoce su recepción.
Todos los ruteadores calcularán sus rutas usando el algoritmo de Dijkstra
(o SPF). Recuerde que cada router construye su tabla de
encaminamiento basada sobre la LSDB, y este cambio altera el
contenido de esa base de datos. Por lo tanto, el ruteador construirá sus
tablas de encaminamiento con ella como la base del árbol de la ruta. El
tiempo requerido para funcionar el algoritmo depende de una
combinación del tamaño del área y del número de rutas en la base de
datos.
OSPF balancea la carga a lo largo de las trayectorias con igual costo,
esto tiene en cuenta una convergencia casi inmediata.
La herramienta wireshark nos permite observar el costo de cada ruta en
las tramas “LS Update”
Página 21 de 56
3.2.2 Costo de la ruta
3.3 Estructura y áreas

El trabajo dentro de un área se organiza jerárquicamente entre los
enrutadores que comparten esta área y se clasifican como:
Área Border Routers (ABR):
Los enrutadores ubicados en los bordes de cada área se conectan a más

de un área OSPF, se denominan ABR Routers. Los enrutadores ABR son
responsables de resumir las direcciones IP de cada área y de suprimir las
actualizaciones entre las áreas para evitar la contención de fallas.
Enrutador de límites del sistema autónomo (ASBR):
Un ASBR es un enrutador que tiene interfaces conectadas a una o más

áreas OSPF, de manera similar a la ABR, sin embargo, la diferencia con un
ASBR es que también se conecta a otros sistemas de enrutamiento como
BGP , EIGRP , Internet y otros. Un enrutador ASBR normalmente anuncia
rutas desde otros sistemas de enrutamiento al área OSPF a la que
pertenece.
Enrutador designado (DR):
Página 22 de 56
Los enrutadores eligen un enrutador designado en segmentos de acceso

múltiple (por ejemplo, red de área local), según su prioridad (ID de
enrutador, prioridad). El enrutador DR realiza funciones especiales, como
generar anuncios de estado de enlace ( LSA ) e intercambiar información
con todos los demás enrutadores en la misma área . Cada enrutador en
la misma área creará una adyacencia con el DR y BDR (analizado a
continuación).
El DR envía actualizaciones a todos los enrutadores de área utilizando la

dirección de multidifusión 224.0.0.5. Todos los enrutadores OSPF, excepto
el DR, utilizan la dirección de multidifusión 224.0.0.6 para enviar paquetes
de actualización de estado de enlace ( LSU) y anuncios de estado de
enlace ( LSA ) al DR .
Enrutador designado de respaldo (BDR):
El BDR es un enrutador que se convierte en el DR si el DR existente falla. El

BDR tiene la segunda prioridad más alta (el DR tiene la prioridad más alta)
en la red OSPF. Cuando el BDR se convierte en DR, se realiza una nueva
elección para encontrar un nuevo BDR .
Internal Router (IR):

Son router que se encuentran dentro de un área determinada, que no es
el área 0.
3.3.1 Estructuras y áreas
Página 23 de 56
3.4 Construcción del mapa de la topología.

Con lo anterior mencionado y contando con las capturas del tráfico
mediante la herramienta wireshark se procederá a la construcción de
un mapa detallado de la topología original, que dio origen a la traza
analizada.
Mensaje 1
Este mensaje no es otra que un mensaje de “HELLO PACKET” a todos los

enlaces a los que dicho Router está conectado.
Mensaje 2
Como el router tiene varios enlaces conectados a él, recibe un mensaje

de “REPLY” por uno de los enlaces por el cual el mando el mensaje.
Página 24 de 56
Mensaje 3
Como el Router 200.188.73.100 recibió el mensaje de “HELLO PACKET”

de 200.188.73.10, esto le va a indicar que la topología qué conocía
cambió, por lo que él va a enviar ahora un mensaje de “HELLO PACKET”
a todos los enlaces a los que él está conectado, para determinar el
estado de los demás Router y para comenzar con el proceso de
Vecindad con el router 200.188.73.1.
Mensaje 4
Como el router 200.18.73.10 recibió el mensaje de “HELLO PACKET” de

200.188.73.100 ahora necesita determinar cuál es la dirección MAC de
dicho router, por lo que manda un mensaje ARP de “WHO HAS
200.188.73.100 ? TELL 200.188.73.10.
Mensaje 5
Página 25 de 56
Como el router “200.188.73.100” recibió el mensaje anterior, ahora envía

el mensaje ARP de “200.188.73.100 is at c4:07:07:d6..00” al router
200.188.73.10, de esta forma le indica la dirección MAC a dicho router.
Mensaje 6
Página 26 de 56
Mensaje 7
El router 200.188.73.100 manda un mensaje de “DATABASE DESCRIPTION”

en el cual se indica, por ejemplo, el MTU máximo de sí mismo, y se
declara a sí mismo como master. El mensaje de envía a 200.188.73.10.
Mensaje 8
El router 200.188.73.10 manda un mensaje de “DATABASE DESCRIPTION”

en el cual se indica, por ejemplo, el MTU máximo de sí mismo, y se
declara a sí mismo como master.
El mensaje se envía a 200.188.73.100.
En este mensaje ya se establece además que el router 200.188.73.100 es
el maestro y el 200.188.73.10 es el esclavo.
El proceso de decisión es el siguiente:
Página 27 de 56
Primero, se pregunta quién tiene la prioridad más alta, y el que la tenga

será el maestro.
Si ambos tienen la misma prioridad, se mira quien tiene el ID más alto, y
el que lo tenga será el maestro.
ACLARACIÓN
En ningún momento se habla de la presencia de los DR y BDR porque el
router 200.188.73.100 solo tiene un enlace, el cual está conectado a
200.188.73.10 por qué no hay manera de qué 200.188.73.100 se pueda
conectar a dichos routers.
Mensaje 9
Se manda un mensaje del router 200.188.73.100 (maestro) al router

200.188.73.10(esclavo) y en el mismo se establece que ambos son
vecinos activos.
Mensaje 10
El router 200.188.73.10 le manda un mensaje de “DATABASE

DESCRIPTION” al router 200.188.73.100.
Mensaje 11
Página 28 de 56
Mensaje 12

DESCRIPTION” al router 200.188.73.10
Mensaje 13
Página 29 de 56

Mensaje 14

Mensaje 15
Página 30 de 56
El router 200.188.73.10 manda un mensaje de “REQUEST LINK STATE ID” al

router 200.188.73.100.
Mensaje 16
El router 200.188.73.10 manda un mensaje de “REQUEST LINK STATE ID” al

router 200.188.73.100.
Página 31 de 56
Mensaje 17

Mensaje 18
El router 200.188.73.10 le manda un mensaje de “LS UPDATE” al router

200.188.73.100.
Página 32 de 56
Mensaje 19
El router 200.188.73.10 le manda un mensaje de “LS UPDATE” al router 200.188.73.100.
Página 33 de 56
Mensaje 20
El router 200.188.73.10 le manda un mensaje de “LS UDPATE” a través de broadcast.
Página 34 de 56
Mensaje 21
El router 200.188.73.10 le manda un mensaje de “LS ACKNOLEDGE” al router 200.188.73.100.
Página 35 de 56
Mensaje 22
El router 200.188.73.10 le manda un mensaje de “DATABASE DESCRIPTION” al router 200.188.73.100.
Página 36 de 56
Mensaje 23
El router 200.188.73.10 le manda un mensaje de “LS ACKNOLEDGE” al router 200.188.73.100.
Página 37 de 56
Mensaje 24
El router 200.188.73.100 manda un mensaje de “LS UPDATE” por broadcas.
Página 38 de 56
Mensaje 25
El router 200.188.73.10 manda un mensaje de “LS UPDATE” por broadcast.
Página 39 de 56
Mensaje 26
Página 40 de 56
Mensaje 27
Página 41 de 56
Mensaje 28
El router 200.188.73.19, recibe un mensaje de “REPLY”.
Página 42 de 56
Mensaje 29
El router 200.188.73.10 manda un mensaje de “LS ACKNOWLEDGE” por broadcast.
Página 43 de 56
Mensaje 30
El router 200.188.73.100 manda un mensaje de “HELLO PACKET” por broadcast.
Página 44 de 56
Mensaje 31
El router le manda un mensaje de “Device” que se utiliza entre router de CISCO.
Página 45 de 56
Mensaje 32
HELLO PACKET
Página 46 de 56
Mensaje 33
REPLY
Página 47 de 56
Mensaje 34
El router manda un mensaje de “Device” que se utiliza entre router de CISCO.
Página 48 de 56
Mensaje 35
REPLY
Página 49 de 56
Mensaje 36
HELLO PACKET
Página 50 de 56
MAPA DE LA TOPOLOGÍA
Página 51 de 56
3.5 Cambio final en la topología
Como podemos ver, en la primera trama, el router 200.188.73.10, creó

un LINK ID (del tipo STUB) 200.188.73.0, el cual se conecta al router
200.188.73.100 porque el interpretó, con la información que él tenía que
dicho router.
Lo qué quiere decir qué el router 200.188.73.0 creía qué el router
200.188.73.100 describía una red de computadoras, o parte de una red
interna, sin conocimiento de otras redes, que generalmente enviarán
gran parte o todo su tráfico no local a través de una única ruta.
Pero en la segunda trama, el router 200.188.73.10, creó un LINK ID (del
tipo TRANSIT): 200.188.73.100, el cual se conecta al router 200.188.73.100
pero ahora lo hace conociendo todas las características de dicho
router y de esa conexión.
Lo que quiere decir esta conexión, es que para el router 200.188.73.100
el router 200.188.73.10 es el router DB (Database Router), lo que significa
que ahora cada vez que exista un cambio en la topología o el router
20.188.73.100 cambie su topología, va a tener qué comunicarse
solamente con el router 200.188.73.10.
Página 52 de 56
4 esquema de direccionamiento IP
Tomando la topología final realizaremos un análisis del Direccionamiento IP
4.1 Direccionamiento de multidifusión IP y OSPF

OSPF utiliza IP Multicast para enviar actualizaciones de estado de link. Esto
garantiza menos procesamiento en los routers que no están escuchando los
paquetes OSPF. Además, las actualizaciones sólo se envían en caso de
cambios de ruteo en lugar de periódicamente. Esto asegura un mejor uso del
ancho de banda.
OSPF usó la multidifusión de IP para intercambiar paquetes de saludo y
actualizaciones de estado de links. Una dirección IP Multicast se implementa
mediante direcciones de clase D. Una dirección clase D posee un rango de
224.0.0.0 a 239.255.255.255.
Algunas direcciones IP Multicast especiales están reservadas para OSPF:
224.0.0.5: Todos los routers OSPF deben ser capaces de transmitir y escuchar
esta dirección. 224.0.0.6: Todos los routers DR y BDR deben ser capaces de
transmitir y escuchar esta dirección.
En nuestro caso la dirección de multicast es 224.0.0.5
4.2 Redes Involucradas: VLSM y OSPF

El concepto de las máscaras de subred de longitud variable es ofrecer
mayor flexibilidad al tratar de dividir una red principal en varias subredes
y conservar la capacidad de mantener un número adecuado de hosts
en cada subred. Sin VLSM, una máscara de subred solo se puede
aplicar a una red principal
A continuación, tenemos una figura dónde se ve la topología y una tabla
mostrando las redes involucradas en la misma.
Página 53 de 56
Tabla
Red Rango de Cantidad Prefijo Dirección de Máscara

Direcciones de Hosts Broadcast
R1 200.188.72.193 64 200.188.72.192 200.188.72.255 255.255.255.192

- / 26
200.188.72.254
R2 200.188.72.161 32 200.188.72.160 200.188.72.191 255.255.255.224

- / 27
200.188.72.190
R3 200.188.72.97 - 32 200.188.72.96 200.188.72.127 255.255.255.224

200.188.72.126 / 27
R4 200.188.72.1 - 16 200.188.72.0 / 200.188.72.15 255.255.255.240

200.188.72.14 28
R5 200.188.73.129 128 200.188.73.128 200.188.73.255 255.255.255.128

- / 25
200.188.73.254
R6 200.188.72.17 - 16 200.188.72.16 200.188.72.31 255.255.255.240

200.188.72.30 / 28
R7 200.188.72.65 - 32 200.188.72.64 200.188.72.95 255.255.255.224

200.188.72.94 / 27
R8 200.188.72.33 - 32 200.188.72.32 200.188.72.63 255.255.255.224

200.188.72.62 / 27
Página 55 de 56
Conclusión
Del análisis realizado podemos destacar que no ha sido sencillo

descubrir la topología, si bien hay mucha documentación, hay
cuestiones muy específicas del protocolo qué están distribuidas en blogs
de cisco y foros afines. Pudimos entender las bases de OSPF y su
funcionamiento para poder que los routers descubran la topología y la
complejidad que conlleva gestionar el intercambio de las bases de
datos considerando que la subred es un lugar no determinístico.
Pudimos reforzar los conceptos de subnetting y VLSM mediante el
análisis de la topología y corroborar la teoría con la práctica.
Bibliografía
https://www.cisco.com/c/es_mx/support/docs/ip/open-shortest-path-first-
ospf/7039-1.pdf
https://www.juniper.net/documentation/en_US/junos/topics/concept/ospf-
routing-packets-overview.html
https://wiki.wireshark.org/Loop
https://www.freesoft.org/CIE/RFC/1583/105.htm
https://learningnetwork.cisco.com/thread/71052
https://sites.google.com/site/amitsciscozone/home/important-tips/ospf/ospf-
packet-types
https://www.cisco.com/c/es_mx/support/docs/ip/open-shortest-path-first-
ospf/7039-1.pdf/
https://bibliotecavirtualapure.files.wordpress.com/2015/06/redes_de_computad
oras-freelibros-org.pdf
http://www.firewall.cx/networking-topics/routing/ospf-routing-protocol/1110-ospf-
operation-basic-advanced-concepts-ospf-areas-roles-theory-overview.html
https://www.w0lff4ng.org/mensajes-ospf/
http://support.huawei.com/hedex/pages/EDOC110002225731180AKG/02/EDO
C110002225731180AKG/02/resources/feature/vrp/dc_vrp_ospf_feature_0037.h
tml
http://network.jecool.net/the-ospf-packet/
http://www.itcertnotes.com/2011/06/ospf-options-field.html
http://www.ciscopress.com/articles/article.asp?p=2180209&seqNum=4
http://mascaradered.blogspot.com/2012/05/mascara-de-red.html
Página 56 de 56

Redes de Informacion

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Redes de Informacion

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD TECNOLÓGICA

NACIONAL FACULTAD REGIONAL

Ingeniería en sistemas de Información

Trabajo Tercer Desafío

Elaborado por Grupo: “4”

• Jose E. CALVANO VIOLA.

• Ing. Ricardo CALCAGNO.

~10 de noviembre de 2018~

En el siguiente trabajo analizaremos el protocolo OSPF (Open Shortest

A continuación, analizaremos las tramas asignadas con el fin de

1.1 Encabezado OSPF

Fig. 1.1 Formato del Encabezado OSPF.

Wireshark nos identifica perfectamente este encabezado, para todos

Fig 1.2 Encabezado de un mensaje OSPF en Wireshark

Versión (1 byte): Especifica la versión del protocolo OSPF, en este caso

Fig 1.3 Tipos de mensajes OSPF

Packet Length (2 bytes): Longitud del paquete OSPF (en bytes),

Authentication (8 byte): Campo usado por el esquema de

1.2 Formato de los distintos tipos de mensaje:

1.2.1 Formato del mensaje HELLO:

Fig 1.2.1 Formato del Mensaje Hello.

Si analizamos un paquete Hello con Wireshark, obtenemos la siguiente

Fig 1.2.2 Información de un Mensaje Hello en Wireshark.

Contrastando esta información con el formato visto en clases, tenemos:

Network Mask (4 bytes): corresponde a la máscara de la red

• MC: Se establece cuando el enrutador de origen admite

1.2.2 Formato del mensaje Database Description (BD Description):

Fig. 1.2.3 Formato del Mensaje DB Description.

Si analizamos un paquete DB Description con Wireshark, obtenemos la

Fig 1.3.2 Información de un Mensaje DB Description en Wireshark.

Comparando esta información con el formato visto en clase, tenemos:

Los flags trabajan en pares, y dependiendo de cómo estén

DD sequence number (4 bytes): es usado para secuenciar los paquetes

Fig. 1.2.4 Formato del Encabezado LSA.

Los LSA (Link State Advertisements) son, actualizaciones del estado de

Fig 1.2.5 Información de la cabecera LSA provista por Wireshark

LS Age (2 byte): Este campo es la edad del LSA en segundos. Se

Link State ID (4 bytes): Este campo identifica la parte del dominio de

LS Type Link State ID

Como el tipo de LS es “Router LSA” entonces toma la ID del enrutador

1.2.3 Formato del mensaje Link Status Request (LS Request):

Fig. 1.2.6 Formato del mensaje LS Request.

Al analizar un mensaje LS Request con Wireshark, este nos muestra la

Fig. 1.2.7 Información de un mensaje LS Request en Wireshark

1.2.4 Formato del mensaje Link Status Update (LS Update):

Fig. 1.2.8 Formato del mensaje LS Update.

Analizando un mensaje LS Update en Wireshark, obtenemos la siguiente

Fig. 1.2.9 Información de un mensaje LS Update en Wireshark.

Donde nos indica el número de anuncios de estado de enlace incluidos

Fig. 1.2.10 Información de los LSA de un mensaje LS Update en Wireshark.

1.2.5 Formato del mensaje Link State Acknowledge (LS Acknowledge):

Es necesario que la inundación de LSA’s sea confiable, por eso, se

Fig. 1.2.11 Formato de un mensaje LS Acknowledge.

Fig 1.2.12 Información de un mensaje LS Acknowledge en Wireshark.

Describiremos a continuación el proceso que hace que dos routers se

Cuando un router se vea a sí mismo en el paquete hello de su vecino, el

de saludo provenientes de un vecino. Al final de esta etapa, se habría

Fig. 2.1. Paquete Hello de 200.188.73.100 a 200.188.73.10

Fig. 2.2 Reconocimiento de Vecino

El Router 200.188.73.100 envía Hello al 200.188.73.10 en el paquete

En el estado Exstart, los dos vecinos establecen una relación

fig. 2.3 Primer Intercambio de Base de datos

En primera instancia al intercambiar bases de datos ambos son