Tp1 (Routing Protocols)

66.48 Seminario de Redes
Trabajo Práctico Nº1
Protocolos de Ruteo
Análisis de mensajes protocolares
Grupo: MOG
2º Cuatrimestre 2004
66.48 Seminario de Redes
MOG
Introducción general................................................................................................................................ 2
RIPv1 ......................................................................................................................................................... 3
Puntos clave de RIP ............................................................................................................................ 3
Formato del mensaje en RIPv1 ......................................................................................................... 4
RIPv2 ......................................................................................................................................................... 6
Autenticación en RIPv2 ..................................................................................................................... 6
OSPF (Open Shortest Path First) ....................................................................................................... 32
Formato del mensaje: ........................................................................................................................ 32
Protocolo HELLO: ........................................................................................................................... 33
Mensaje de descripción de la base de datos: ............................................................................. 34
Formato del mensaje de solicitud de enlace del OSPF ........................................................... 34
Formato del mensaje de actualización de estado de enlace OPSF ........................................ 34
PARTE III: OPSF............................................................................................................................. 36
Conclusiones de OSPF: .................................................................................................................... 45
EIGRP (Enhanced Interior Gateway Routing Protocol) ................................................................ 46
Introducción a EIGRP.......................................................................................................................... 46
Funcionamiento general ................................................................................................................... 46
Funcionamiento detallado ................................................................................................................ 46
Fundamentos de EIGRP.................................................................................................................. 47
Tipos de Paquetes.............................................................................................................................. 47
Formato de los paquetes EIGRP .................................................................................................... 48
Bibliografía ......................................................................................................................................... 50
66.48 Seminario de Redes
MOG
Introducción general
La asignación de rutas de manera estática puede resultar trivial cuando la topología de
la red es simple, es decir, cuando hay un único camino entre cualesquiera dos redes. Sin
embargo cuando la red cambia, el administrador debe reconfigurar las rutas en todos los
dispositivos de ruteo. Por ello es que la principal desventaja de esta metodología es que la
configuración manual no se puede acomodar rápidamente a los cambios, además la
complejidad de dicha tarea aumenta de manera desmedida si existen múltiples caminos. En
estos casos es más conveniente recurrir a algoritmos que automatizan la administración de las
rutas, que a su vez mejoran la confiabilidad y el tiempo medio de respuesta ante una falla
cuando existen rutas alternativas.
Para implementar dichos algoritmos se desarrollaron protocolos que permiten el
intercambio de mensajes entre los procesos de ruteo, que son ejecutados en los sistemas
intermediarios. Según los mensajes sean intercambiados entre routers del mismo sistema
autónomo (SA: un grupo de redes y ruteadores controlados por una sola autoridad
administrativa que garantiza que las rutas internas se mantengan consistentes y viables ) o no,
se los distingue como protocolos de ruteo interno o externo respectivamente. Un Sistema
Autónomo tiene la libertad para seleccionar una arquitectura de ruteo interna, utilizando un
Protocolo Interior de Ruteo (IGP, Interior Gateway Protocol), pero debe reunir información
sobre todas sus redes y designar uno o más ruteadores que habrán de transferir información de
accesibilidad hacia otros Sistemas Autónomos mediante un Protocolo Exterior de Ruteo
(EGP, Exterior Gateway Protocols). Dos tipos de algoritmos utilizados por los IGP’s son
Distance-Vector y Link-State, que se distinguen entre sí según la forma en la cual establecen las
rutas. El primero tiene como ventaja la fácil implementación debido a su simplicidad, y el
segundo, obtiene un tiempo de convergencia mejor y genera menos tráfico, hecho que es
tomado en consideración en los enlaces WAN.
66.48 Seminario de Redes
MOG
RIPv1
El Routing Information Protocol, RIP, es uno de los IGP’s más ampliamente utilizados. Es
la típica implementación de un algoritmo distance-vector, en la cual aparecen dos tipos de
participantes: activos y pasivos. Los ruteadores activos anuncian sus rutas a los otros; los
participantes pasivos listan y actualizan sus rutas con base a esos anuncios. El término distancevector obtiene su nombre a causa del método en que propaga la información de ruteo. Esta clase
de algoritmos envía mensajes protocolares que sólo contienen la distancia a una red, que vendría
a ser el vector. Resumiendo, los participantes activos publican sus rutas a los otros
participantes; los participantes pasivos escuchan los mensajes RIP y los usan para actualizar sus
tablas de ruteo pero no publican. Solamente un router puede actuar como un participante
activo, por lo tanto un host sólo puede ser pasivo(se supone que no está corriendo demonios
para actuar de gateway).
Un router ejecutando RIP de modo activo envía un mensaje de actualización de tipo
broadcast cada 30 segundos. Esta actualización contiene información extraída de la tabla de
ruteo. Cada actualización contiene una lista de pares, donde cada par contiene una dirección IP
de red y un entero que simboliza la distancia a esa red. RIP utiliza el hop-count como métrica para
medir la distancia. De esta manera, un router está a un salto de distancia de una ruta conectada
directamente, dos saltos desde la red que está al alcance a través de otro router. El usar la
cantidad de saltos como métrica no siempre produce resultados óptimos, debido a que existen
muchos otros factores que afectan la perfomance de una red.
Puntos clave de RIP
Cabe mencionar, que en cierta topología de red, pueden existir dos caminos distintos
de igual métrica. Para evitar oscilaciones en el algoritmo, RIP especifica que se deben
conservar las rutas existentes hasta que aparezca una ruta nueva con un costo o métrica
estrictamente menor.
Especifica a su vez, que al instalar una ruta en su tabla, se inicia un temporizador para
asociar un tiempo límite a esa ruta. El temporizador se reinicia con cada mensaje RIP
anunciando la ruta. Así evitamos poseer rutas incorrectas en la tabla en caso que el router que
publicaba aquella ruta falle. Este tiempo se fija en 180 segundos.
Limitaciones:
•
•
•
No detecta ciclos de ruteo.
Para prevenir inestabilidades, utiliza un valor bajo para la distancia máxima posible
(16).
El algoritmo distance-vector es de convergencia lenta y puede ocasionar conteo al infinito. Un
valor infinito pequeño (16) ayuda a limitar la convergencia lenta pero no la elimina.
Para resolver la convergencia lenta se utiliza la técnica de Split Horizon Update, por la
cual, un router registra la interfaz por la cual ha recibido una ruta particular y así evitar publicar
información sobre esa ruta sobre la misma interfaz. Esta técnica no resuelve el problema para
las distintas topologías posibles.
Otra técnica es la de Hold Down, mediante la cual los routers están obligados a ignorar
información acerca de una ruta durante un tiempo fijo luego de la recepción de un mensaje que
66.48 Seminario de Redes
MOG
indica que la ruta es inaccesible (60 segundos). El objetivo es esperar lo suficiente para que todas
las máquinas reciban el mensaje de inaccesiblidad. La desventaja que presenta es que si se
presenta un ciclo de ruteo, este se mantendrá por la duración del período de hold down.
La última técnica utilizada se conoce como Poison Reverse que establece que, al
desaparecer una conexión, el router anuncia la misma con un costo infinito y la conserva por
varios períodos de actualización. Para que esto sea más efectivo se combina con los Triggered
Updates o actualizaciones activadas (por eventos), que obligan a un router a enviar
inmediatamente un broadcast al recibir la caída de la ruta, en lugar de esperar. La contra de este
tipo de actualizaciones es que puede cambiar las tablas de un router, que a su vez cambia la de
otro y así sucesivamente, generando una avalancha de broadcasts.
Formato del mensaje en RIPv1
Hay dos tipos de mensajes: el de información de ruteo, y los utilizados para solicitar la
información. Ambos poseen el mismo formato.
Operaciones del campo COMMANDO:
Comandos
1
2
3
4
5
9
10
11
Descripción
Pedido de la tabla de ruteo parcial o total
Respuesta contiendo la/s dirección/es de red y la/s distancia/s
Activar el modo de traza (obsoleto)
Desactivar el modo de traza (obsoleto)
Reservado para Sun Microsystem
Pedido de actualización(usado con circuitos en demanda)
Respuesta de actualización(usado con circuitos en demanda)
Confirmación de actualización(usado con circuitos en demanda)
COMMANDO(1-5)
VERSIÓN(1)
FAMILIA DE RED 1
DIRECCIÓN IP DE LA RED 1
CERO
CERO
DISTANCIA A LA RED 1
FAMILIA DE RED 2
DIRECCIÓN IP DE LA RED 2
CERO
CERO
DISTANCIA A LA RED 2
....
CERO
CERO
CERO
Un router o host puede solicitar información de ruteo a otro router al enviarle un
comando request(1). El router responde a la solicitud mediante el comando response(2). El campo
VERSIÓN, contiene el número de versión del Protocolo.
66.48 Seminario de Redes
MOG
El formato de dirección no está limitado a TCP/IP. Puede reportar direcciones de
hasta 14 octetos. En IP se utilizan sólo 4, los restantes deben ser cero (la IP se coloca a partir
del tercer octeto para asegurar una alineación de 32 bits). El campo FAMILIA DE RED
identifica la familia de protocolo bajo la que la dirección de red deberá interpretarse. IP tiene
asignado el valor 2.
También hace uso de la convención de que la dirección 0.0.0.0 denota una ruta por
omisión, incluyendo en ella como en cualquier otra una métrica de distancia.
El campo al final de cada entrada DISTANCIA A LA RED, contiene un contador
entero de la distancia hacia la red especificada. Se mide en saltos de routers, y sus valores están
entre 1 y 16, con 16 como distancia infinita, que denota que la ruta no existe.
RIP no contiene un campo de longitud del mensaje. Asume que los mecanismos de
entrega subyacente dirán al receptor su longitud. En TCP/IP, dependen del UDP, y opera en
el puerto 520. Aunque una solicitud RIP se puede originar en otro puerto UDP, el puerto de
destino para solicitudes es siempre 520.
66.48 Seminario de Redes
MOG
RIPv2
El protocolo RIPv2 presenta algunas utilidades extras respecto a RIPv1:
•
•
•
introduce la capacidad de transportar la máscara, por lo tanto permite utilizar Variable
Length Subnet Mask – VLSM;
posee un sistema no muy sofisticado de autenticación que consiste en una clave que
viaja en claro de 16 bytes o se realiza un fingerprint del mensaje RIP;
y a su vez, permite realizar actualizaciones parciales de la tabla de ruteo.
Así como RIPv1, utiliza el algoritmo distance-vector.
COMMANDO(1-5)
VERSIÓN(2)
NO UTILIZADO
FAMILIA DE RED 1
ETIQUETA DE RUTEO
DIRECCIÓN IP DE LA RED 1
MASCARA DE SUBRED
PROXIMO SALTO
DISTANCIA A LA RED 1
…
Etiqueta de Ruteo: sirve para soportar EGP (exterior gateway protocols). Provee un método para
separar las rutas RIP internas (rutas para las redes que se encuentran en el dominio de ruteo
RIP) de las rutas RIP externas, que pueden haber sido importadas de un EGP o de otro IGP.
Máscara de Subred: lleva la máscara asociada a la dirección IP.
Proximo Salto: es la dirección IP a donde deben ser enviados los paquetes que llevan la dirección
IP destino.
Autenticación en RIPv2
Para la autenticación se agrega un pequeño header:
COMMANDO(1-5)
VERSIÓN(2)
NO UTILIZADO
FAMILIA DE RED
TIPO DE AUTENTICACIÓN
AUTENTICACIÓN
FAMILIA DE RED 1
ETIQUETA DE RUTEO
DIRECCIÓN IP DE LA RED 1
MASCARA DE SUBRED
PROXIMO SALTO
DISTANCIA A LA RED 1
…
En RIP1 cualquier equipo de la red podía enviar mensajes RIP1 modificando así las tablas de
ruteo. Esta utilidad de autenticación permite mediante un clave cierta seguridad mínima de
quienes pueden modificar las tablas de los routers. El campo Familia de Red del header toma el
valor FFFF indica que se está utilizando autenticación. El campo Tipo de Autenticación indica
el tipo de seguridad que se está utilizando, y toma valor 2 cuando se usa sencillamente una
66.48 Seminario de Redes
MOG
clave. El campo Autenticación lleva la clave de 16 bytes. El resto de las entradas lleva
información de ruteo.
Para el caso en que la autenticación es un digesto de MD5 el formato del paquete de RIPv2
está especificado en la RFC 2082 (RIP-2 MD5 Authentication) y tiene el siguiente formato que
es un poco diferente al anteriormente especificado:
COMMAND(1)
VERSION(2)
Routing Domain (2)
0xFFFF
AuType=Keyed Message Digest
RIP-2 Packet Length
Key ID
Auth Data Len
Sequence Number (non-decreasing)
reserved must be zero
reserved must be zero
(RIP-2 Packet Length - 24) bytes of Data
0xFFFF
0x0001
Authentication Data (var. length; 16 bytes with Keyed MD5)
La Authenticatin Data es un fingerprint de la información del paquete RIPv2, y es corroborada
ya que se pasa el Key ID. Es importante recalcar que el “secreto” nunca viaja a través de la red;
es necesario que los routers lo conozcan previamente.
66.48 Seminario de Redes
MOG
MAQUETA
Para la realización del trabajo práctico se contó con tres routers CISCO y un hub
3COM. La maqueta elegida es un red de topología sencilla pero que permite vislumbrar varios
de los aspectos claves de los protocolos de ruteo.
Router 2
ser0: 10.0.2.2
ser1: 10.0.1.2
10.0.2.0/24
10.0.1.0/24
ser0: 10.0.2.1
ser0: 10.0.1.3
eth0: 10.0.0.1
eth0: 10.0.0.3
10.0.0.0/24
Router 3
Router 1
eth0: 10.0.0.100
Sniffer
66.48 Seminario de Redes
MOG
PARTE 1: RIPv1
En esta primer parte se propusieron algunos escenarios básicos para analizar el
funcionamiento de RIPv1.
Escenario 1: Encapsulamiento de RIPv1 sobre UDP y funcionamiento básico.
Se configurará RIPv1 en todos los routers y se capturará el tráfico que circule por la red
10.0.0.0/24. De esta manera se podrá analizar detalladamente como entra en funcionamiento
el algoritmo, como converge la red, como son los mensajes de RIPv1.
Al finalizar la captura, cada router habrá publicado sus rutas y aprendido las rutas de los
demás. En principio cada router tendrá dos rutas directas hacia las dos redes directamente
conectadas, luego de correr el algoritmo cada router habrá aprendido las rutas para llegar a las
redes no conectadas de manera directa. Por ejemplo, se espera que R2 pueda llegar a la red
10.0.0.0/24 a través de R1 o R3 con métrica 2. Se espera observar que a pesar de que la
máscara no es transmitida, la red convergerá igualmente bien ya que se está utilizando subnetting
de máscara fija.
Escenario 2: Respuesta ante un cambio de topología
-
Se realizarán los siguientes cambio mientras que se captura tráfico en la red 10.0.0.0/24
Se dará de baja la interfaz S1 del router R2.
Se esperará hasta que la red converja, por lo menos 3 minutos.
De esta manera podremos observar como las rutas se van actualizando.
Escenario 3: Mensaje ICMP REDIRECT
Se configurará como default gateway del host 10.0.0.100/24 al router R1. Se dará de baja la
interfaz S1 de R2 y se ejecutará un ping desde el host al router R2. Se espera que el router R1
informe al host que una ruta más conveniente de salida se encuentra disponible a través de R3, y
lo hará a través de un mensaje ICMP REDIRECT.
PARTE 2: RIPv2
En la segunda parte se propusieron algunos escenarios básicos que mostrasen el
funcionamiento de RIPv2.
Escenario 4: Mensaje RIPv2
Se configurará RIPv2 en cada router y se observará el intercambio protocolar. Se
espera observar la inclusión de la máscara en el mensaje de RIPv2.
Escenario 5: Distancia Administrativa I
Se configurará a R2 para que hable RIPv1 por la interfaz S0 y RIPv2 por la interfaz S1.
El router R1 hablará RIPv1 por sus dos interfaces, mientras que el router R3 hablará RIPv1 por
la interfaz Eth0 y RIPv1 por la interfaz S0.
66.48 Seminario de Redes
MOG
Router 2
ser0: 10.0.2.2
ser1: 10.0.1.2
RIPv1
RIPv2
10.0.2.0/24
10.0.1.0/24
ser0: 10.0.2.1
ser0: 10.0.1.3
eth0: 10.0.0.1
eth0: 10.0.0.3
RIPv1
10.0.0.0/24
Router 3
Router 1
eth0: 10.0.0.100
Sniffer
Con este escenario se espera, no solo observar el funcionamiento de RIPv2, sino como
maneja un router rutas que ha recibido de dos protocolos diferentes. Para estas situaciones,
donde más de un protocolo se está utilizando en la zona, se define la Distancia Administrativa.
Cada router se basa en este parámetro a la hora de decidir entre una ruta hacia un destino
recibida a través de un protocolo de ruteo, y otra ruta hacia otro destino recibida a través de
otro protocolo de ruteo, quedándose siempre con la de menor distancia administrativa. La
distancia administrativa se puede configurar en cada router, por lo tanto configurando una
distancia administrativa para RIPv1 y otra para RIPv2 en algún router podremos obtener los
resultados buscados. Esperamos observar que los routers se quedaran con las rutas que les
llegan a través del protocolo de menor Distancia Administrativa.
Escenario 6: Distancia Administrativa II
A partir de la configuración lograda en el escenario anterior, se desconectará el vínculo
entre R2 y R3.
Escenario 7: RIPv2 con Autenticación en claro
Se configuró RIPv2 en todos los routers y en los routers R1 y R3 se usó la opción de
autenticación en claro. El tráfico se capturó mediante el host 10.0.0.100. Se espera ver el
formato de los paquetes RIPv2 con autenticación y que la red converja.
Escenario 8: RIPv2 con Autenticación Inválida
Se configuró RIPv2 en todos los routers y en los routers R1 y R3 se usó la opción de
autenticación en claro. Además, a propósito se configuraron distintas palabras clave. El tráfico
se capturó mediante el host 10.0.0.100. Se espera ver que la red tenga menos caminos que
cuando converge completamente y se utilizará un comando del router para verificar que está
ignorando los paquetes con distinta clave.
66.48 Seminario de Redes
MOG
Escenario 9: RIPv2 con Autenticación Digesto de MD5
Se configuró RIPv2 en todos los routers y en los routers R1 y R3 se usó la opción de
autenticación con digesto MD5. El tráfico se capturó mediante el host 10.0.0.100. Se espera
ver el formato de los paquetes RIPv2 con autenticación de la RFC 2082 y que la red converja.
66.48 Seminario de Redes
MOG
DESARROLLO DEL TRABAJO
PARTE 1: RIPv1
Escenario 1:
Primeramente se procedió a configurar RIPv1 en cada router. Los comandos utilizados
para ello, partiendo del modo configuración, son los siguientes:
router rip
version 1
network 1 (red vecina Nº1)
network 2 (red vecina Nº2)
redistribute connected
A continuación se muestra como convergió la red, para ello mostramos las tablas de ruteo de
cada router.
R1#sh ip ro
10.0.0.0/24
C
10.0.2.0
C
10.0.0.0
R
10.0.1.0
is subnetted, 3 subnets
is directly connected, Serial0
is directly connected, Ethernet0
[120/1] via 10.0.0.3, Ethernet0
[120/1] via 10.0.2.2, Serial0
R3#sh ip ro
R
C
C
10.0.0.0/24 is subnetted, 3 subnets
10.0.2.0 [120/1] via 10.0.0.1, Ethernet0
[120/1] via 10.0.1.2, Serial0
10.0.0.0 is directly connected, Ethernet0
10.0.1.0 is directly connected, Serial0
R2#sh ip ro
C
R
C
10.0.0.0/24 is subnetted, 3 subnets
10.0.2.0 is directly connected, Serial0
10.0.0.0 [120/1] via 10.0.1.3, Serial1
[120/1] via 10.0.2.1, Serial0
10.0.1.0 is directly connected, Serial1
Por la topología de la red, cada router tiene dos redes directamente conectadas y una
tercer red a un salto de distancia, a la cual puede llegar a través de dos caminos diferentes. Para
estos casos, el router elegirá como ruta la que primero le llegue.
A continuación se muestran las capturas
Paquetes capturados:
No.
Time
47 159.880653
49
1.983260
51
7.800736
59 28.270040
67 28.182630
76 27.700603
85 25.774174
92 26.885839
97 14.072953
98
0.003976
99
1.978429
Source
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
Destination
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
10.0.0.3
255.255.255.255
Protocol
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
Info
Request
Response
Response
Response
Response
Response
Response
Response
Request
Response
Response
66.48 Seminario de Redes
102
103
111
113
119
121
129
130
137
138
146
148
7.989903
5.208606
21.953834
3.693502
24.548319
1.297362
26.953226
0.975650
26.722149
0.365870
26.212231
1.036731
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
MOG
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Nota: El tiempo que muestra es el tiempo desde que se recibió el paquete anterior
Detalle de los paquetes marcados:
Frame 47 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Routing Information Protocol
Command: Request (1)
Version: RIPv1 (1)
Address not specified, Metric: 16
Address Family: Unspecified (0)
Metric: 16
Frame 49 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 2
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 2
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.2.0 (10.0.2.0)
Metric: 1
Frame 97 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Routing Information Protocol
Command: Request (1)
Version: RIPv1 (1)
Address not specified, Metric: 16
Address Family: Unspecified (0)
Metric: 16
Frame 98 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 00:50:73:43:c0:9c
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.3 (10.0.0.3)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 2
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 2
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.2.0 (10.0.2.0)
Metric: 1
Frame 99 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 255.255.255.255 (255.255.255.255)
Version: 4
66.48 Seminario de Redes
MOG
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 52
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: UDP (0x11)
Header checksum: 0xadf7 (correct)
Source: 10.0.0.3 (10.0.0.3)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 1
Las capturas se fueron haciendo mientras se configuraban los routers, por ello en el
inicio de la captura solo se observan mensajes provenientes de R1, ya que éste fue configurado
antes que R3. También se observa en la trama 49 que R1 ya conoce las redes de R2, esto es
debido a que R2 fue el primero en ser configurado y debe haber contestado el request de R1
(trama 48). Se observa en la trama 98 que los mensajes del tipo request son brodcast, pero las
respuestas a estos mensajes por parte de los routers están dirigidas únicamente al que preguntó.
Otro detalle interesante es que el router R3 solamente publicó una ruta, la directamente
conectada, ya que la otra la aprendió de R1 (porque tiene la misma métrica) y no se la publica.
Esta técnica es conocida como split horizont, un router nunca publica una ruta por donde la
aprendió.
También se puede observar que en todos los paquetes RIP el TTL de IP es de 2, que
en teoría alcanzaría para recorrer un solo salto, ya que se decrementa este campo antes de
interpretar el datagrama. A su vez, se puede verificar que el tiempo entre publicaciones de rutas
es de 30 segundos menos un tiempo aleatorio para evitar una posible sincronización.
Conclusiones:
Se pudo ver en las tramas, broadcast en general, como viaja RIPv1 encapsulado sobre UDP, y que utiliza para
ello el puerto 520, recordando que las respuestas siempre son sobre ese puerto aunque para las solicitudes se
pueden originar en otro. Un punto interesante que se chequeó es la técnica de Split Horizon cuando publica sus
rutas el router R3.
Escenario 2: Se desactivó el vínculo serial entre R2 y R3, a través del comando shutdown en el
router R2, en la interfaz S1. A continuación se muestra como quedaron, luego de un tiempo, las
tablas de ruteo.
Desconectamos serial 1 (R2-R3)
R3#sh ip ro
R
C
10.0.0.0/24 is subnetted, 2 subnets
10.0.2.0 [120/1] via 10.0.0.1, Ethernet0
10.0.0.0 is directly connected, Ethernet0
R1#sh ip ro
10.0.0.0/24 is subnetted, 2 subnets
66.48 Seminario de Redes
C
C
MOG
10.0.2.0 is directly connected, Serial0
10.0.0.0 is directly connected, Ethernet0
R2#sh ip ro
C
R
10.0.0.0/24 is subnetted, 2 subnets
10.0.2.0 is directly connected, Serial0
10.0.0.0 [120/1] via 10.0.2.1, Serial0
Vemos que desaparecieron las entradas que vinculaban a la red 10.0.1.0/24, ya que se dio de
baja el vínculo y consecuentemente se dio de baja en R3 por ser un vínculo punto a punto.
A continuación se analizan las capturas realizadas.
No.
3
5
7
8
16
24
33
40
49
55
63
70
76
Time
2.137746
10.325227
12.023543
12.314770
30.483235
59.478905
87.490531
114.697169
143.296543
169.574647
195.753682
221.364736
248.063472
Source
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
Destination
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
Protocol
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
RIPv1
Info
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Se muestran en detalle los paquetes marcados seleccionados:
Frame 5 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 16
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 16
Frame 8 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 16
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 16
Vemos que cada router publica una distancia “infinita” para las rutas que comprendían
al vínculo caído. Este mecanismo es conocido como Poison Reverse y como se observa se basa
en publicar nuevas rutas con distancias infinitas cuando un enlace se cae, de manera de que
todos los routers aprendan que se ha dado un cambio en la topología. Vemos que luego de esto
el router R3 no publica más nada, ya que no tiene nada que publicar.
Conclusiones:
66.48 Seminario de Redes
MOG
Se pudo ver como se utiliza la técnica de Poison Reverse al caerse un vínculo de la red para poder ahorrarse el
tiempo de convergencia típico de 180 segundos que es el tiempo mientras el cual una ruta es válida en la tabla
sin recibir aviso de ésta.
Escenario 3:
Se configuró una ruta estática en el host 10.0.0.100/24, en este caso un default gateway.
Mientras tanto seguía desconectado el cable serial entre R2 y R3.
Rutas activas:
C:\WINDOWS\Escritorio\tmp>route print
Dirección de red
0.0.0.0
10.0.0.0
10.0.0.100
10.255.255.255
127.0.0.0
224.0.0.0
255.255.255.255
Máscara de red Puerta de enlace
0.0.0.0
10.0.0.3
255.255.255.0
10.0.0.100
255.255.255.255
127.0.0.1
255.255.255.255
10.0.0.100
255.0.0.0
127.0.0.1
224.0.0.0
10.0.0.100
255.255.255.255
10.0.0.100
Interfaz Métrica
10.0.0.100
1
10.0.0.100
1
127.0.0.1
1
10.0.0.100
1
127.0.0.1
1
10.0.0.100
1
10.0.0.100
1
Luego se ejecutó un ping
C:\WINDOWS\Escritorio>ping 10.0.2.2
Haciendo ping a 10.0.2.2 con 32 bytes de datos:
Respuesta
Respuesta
Respuesta
Respuesta
desde
desde
desde
desde
10.0.2.2:
10.0.2.2:
10.0.2.2:
10.0.2.2:
bytes=32
bytes=32
bytes=32
bytes=32
tiempo=10ms TDV=254
tiempo=4ms TDV=254
tiempo=3ms TDV=254
tiempo=3ms TDV=254
Estadísticas de ping para 10.0.2.2:
Paquetes: enviados = 4, Recibidos = 4, perdidos = 0 (0% loss),
Tiempos aproximados de recorrido redondo en milisegundos:
mínimo = 3ms, máximo = 10ms, promedio = 5ms
Se debe observar que el primer mensaje de Echo tarda más que el doble de tiempo que
el resto, consecuencia de que previamente hay un diálogo con el router default, como se
muestra luego.
Luego volvemos a revisar la tabla de ruteo:
C:\WINDOWS\Escritorio\tmp>route print
Dirección de red
0.0.0.0
10.0.0.0
10.0.0.100
10.0.2.2
10.255.255.255
127.0.0.0
224.0.0.0
255.255.255.255
Máscara de red Puerta de enlace
0.0.0.0
10.0.0.3
255.255.255.0
10.0.0.100
255.255.255.255
127.0.0.1
255.255.255.255
10.0.0.1
255.255.255.255
10.0.0.100
255.0.0.0
127.0.0.1
224.0.0.0
10.0.0.100
255.255.255.255
10.0.0.100
Interfaz Métrica
10.0.0.100
1
10.0.0.100
1
127.0.0.1
1
10.0.0.100
1
10.0.0.100
1
127.0.0.1
1
10.0.0.100
1
10.0.0.100
1
Se observa que se ha agregado una ruta hacia 10.0.2.2, que es una ruta de host, a través del
router R1. Luego, se vuelve a ejecutar un ping.
C:\WINDOWS\Escritorio>ping 10.0.2.2
Haciendo ping a 10.0.2.2 con 32 bytes de datos:
Respuesta desde 10.0.2.2: bytes=32 tiempo=4ms TDV=254
Respuesta desde 10.0.2.2: bytes=32 tiempo=3ms TDV=254
Respuesta desde 10.0.2.2: bytes=32 tiempo=3ms TDV=254
66.48 Seminario de Redes
MOG
Respuesta desde 10.0.2.2: bytes=32 tiempo=3ms TDV=254
Se observa que, a diferencia que el ping anterior, todas las respuestas tardan aproximadamente
lo mismo en volver.
A continuación mostramos los mensajes ICMP intercambiados:
No.
18
19
20
21
24
25
26
27
29
30
47
48
50
51
52
53
54
55
Time
46.046628
46.048563
46.048788
46.054461
47.063900
47.066727
48.067289
48.070059
49.075030
49.077877
108.989486
108.993663
110.095495
110.098313
111.102674
111.105428
112.112427
112.115285
Source
10.0.0.100
10.0.0.3
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
Destination
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
10.0.2.2
10.0.0.100
Protocol
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
ICMP
Info
Echo (ping)
Redirect
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
Echo (ping)
request
request
reply
request
reply
request
reply
request
reply
request
reply
request
reply
request
reply
request
reply
Se observa que el host manda el datagrama al default router, R3, el cual le comunica que hay otra
ruta mejor disponible a través de R1. Aprendido esto, el host manda nuevamente el mensaje
pero esta vez por el router que le ha sido indicado.
Se muestra a continuación en detalle el datagrama marcado.
Frame 19 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 00:e0:7d:92:9e:9d
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 56
Identification: 0x05d7 (1495)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xa187 (correct)
Source: 10.0.0.3 (10.0.0.3)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 0 (Redirect for network)
Checksum: 0x9ba2 (correct)
Gateway address: 10.0.0.1 (10.0.0.1)
Internet Protocol, Src Addr: 10.0.0.100 (10.0.0.100), Dst Addr: 10.0.2.2 (10.0.2.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 60
Identification: 0x99c5 (39365)
Flags: 0x00
Fragment offset: 0
Time to live: 31
Protocol: ICMP (0x01)
Header checksum: 0xeb96 (correct)
Source: 10.0.0.100 (10.0.0.100)
Destination: 10.0.2.2 (10.0.2.2)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x445c (incorrect, should be 0xeeff)
Identifier: 0x0300
Sequence number: 0x0600
66.48 Seminario de Redes
MOG
Frame 20 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 00:50:73:43:bb:f0
Destination: 00:50:73:43:bb:f0 (10.0.0.1)
Source: 00:50:73:43:c0:9c (10.0.0.3)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.0.0.100 (10.0.0.100), Dst Addr: 10.0.2.2 (10.0.2.2)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x445c (correct)
Identifier: 0x0300
Sequence number: 0x0600
Se observa como el router R3 indica al host que para alcanzar a 10.0.2.2 tiene que salir por
10.0.0.1. Vale la pena recalcar que el router R3 reenvía el primer ICMP echo reply y lo podemos
corroborar fijándonos en la MAC Address de origen, que es la de R3.
Router 2
ser0: 10.0.2.2
ser1: 10.0.1.2
Se desconecta
el cable
10.0.2.0/24
10.0.1.0/24
ser0: 10.0.2.1
ser0: 10.0.1.3
eth0: 10.0.0.3
00:50:73:43:c0:9c
eth0: 10.0.0.1
00:50:73:43:bb:f0
10.0.0.0/24
Router 1
Router 3
eth0: 10.0.0.100
PC y
Sniffer
Conclusiones:
RIPv1 nos permite que, ante la configuración estática de un Default Gateway, genere un mensaje ICMP
Redirect al origen informando sobre una “mejor” ruta, en este caso la única posible, pero en un caso real la
topología de la red sería obviamente más complicada.
PARTE 1: RIPv2
Escenario 4:
Se configuró RIPv2 en todos los routers y se capturó el tráfico mediante el host
10.0.0.100. A su vez se dio de alta una interfaz loopback en el router R2 para verificar que para
un mismo netnumber puedan existir dos máscaras distintas.
Configuración: se ejecutaron los siguientes comandos en cada router(la loopback fue creada
anteriormente)
R1#conf ter
Enter configuration commands, one per line.
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#network 10.0.2.0
R1(config-router)#network 10.0.0.0
End with CNTL/Z.
66.48 Seminario de Redes
MOG
R1(config-router)#redist conn
R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#network 10.0.2.0
R2(config-router)#network 10.0.1.0
R2(config-router)#redist conn
R3#conf ter
Enter configuration commands, one per line.
R3(config)#router rip
R3(config-router)#version 2
R3(config-router)#network 10.0.0.0
R3(config-router)#network 10.0.1.0
R3(config-router)#
End with CNTL/Z.
A continuación se muestra el tráfico capturado.
No.
3
4
5
6
9
10
11
12
13
14
15
16
Time
17.398371
19.380897
27.372994
53.294631
73.885374
73.889290
75.868670
81.470903
83.856742
104.404209
104.410756
108.635079
Source
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
Destination
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
10.0.0.3
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
Protocol
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
Info
Request
Response
Response
Response
Request
Response
Response
Response
Response
Response
Response
Response
A continuación se muestra en detalle los paquetes marcados.
Frame 9 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Request (1)
Version: RIPv2 (2)
Routing Domain: 0
Address not specified, Metric: 16
Address Family: Unspecified (0)
Route Tag: 0
Netmask: 0.0.0.0 (0.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16
Frame 10 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 00:50:73:43:c0:9c
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.3 (10.0.0.3)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.2.0 (10.0.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
A continuación se muestran las tablas de ruteo de cada router.
R1#sh ip ro
Gateway of last resort is not set
C
R
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.0.2.0/24 is directly connected, Serial0
10.1.0.1/32 [120/1] via 10.0.2.2, Serial0
66.48 Seminario de Redes
C
R
MOG
10.0.0.0/24 is directly connected, Ethernet0
10.0.1.0/24 [120/1] via 10.0.0.3, Ethernet0
[120/1] via 10.0.2.2, Serial0
R2#show ip
Gateway of last resort is not set
C
R
C
C
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.0.2.0/24 is directly connected, Serial0
10.0.0.0/24 [120/1] via 10.0.1.3, Serial1
[120/1] via 10.0.2.1, Serial0
10.1.0.1/32 is directly connected, Loopback0
10.0.1.0/24 is directly connected, Serial1
R3#sh ip ro
Gateway of last resort is not set
R
R
C
C
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.0.2.0/24 [120/1] via 10.0.0.1, Ethernet0
[120/1] via 10.0.1.2, Serial0
10.1.0.1/32 [120/1] via 10.0.1.2, Serial0
10.0.0.0/24 is directly connected, Ethernet0
10.0.1.0/24 is directly connected, Serial0
Conclusiones:
Se marcó en negrita en los paquetes enviados, la inclusión de la Máscara de Red, así como en las tablas de
ruteo, diferencia principal entre RIPv1 y RIPv2. Se vio que RIPv2 soporta VLSM ya que publica las
máscaras y por ejemplo para el netnumber 10 existe una máscara de 24 bits y una de 32 bits. También tiene
como característica principal que sus paquetes no son broadcast sino multicast (224.0.0.9), esto evita a PCs que
corren Windows que intenten interpretar esos paquetes como si fuesen mensajes de NetBios y a otros sistemas
operativos a intentar interpretar esos paquetes.
Escenario 5:
Se procedió a configurar los protocolos de ruteo en cada uno de los routers. Al router
R2 se le configuró RIPv1 por la interfaz S0 y RIPv2 por la S1, además se le asignó distancia
métrica de 200 y 120 respectivamente. En la red Ethernet se activó únicamente RIPv1.
Router 2
ser0: 10.0.2.2
ser1: 10.0.1.2
RIPv1
RIPv2
10.0.2.0/24
10.0.1.0/24
ser0: 10.0.2.1
ser0: 10.0.1.3
eth0: 10.0.0.1
eth0: 10.0.0.3
RIPv1
10.0.0.0/24
Router 1
Router 3
eth0: 10.0.0.100
Sniffer
66.48 Seminario de Redes
MOG
Configuración:
R2(config-router)#distan 200 10.0.2.1 255.255.255.0
R2#sh ip proto
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 14 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: connected, rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
Loopback0
2
2
Serial0
1
1
Serial1
2
2
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
10.0.1.3
120
00:00:17
10.0.2.1
200
00:00:25
Distance: (default is 120)
Address
Wild mask
Distance List
0.0.0.1
255.255.255.0
200
R1#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router rip
R1(config-router)#version 1
R1(config-router)#^Z
R1#sho ip proto
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: connected, rip
Default version control: send version 1, receive version 1
Interface
Send Recv Triggered RIP Key-chain
Ethernet0
1
1
Serial0
1
1
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
10.0.0.3
120
00:00:37
10.0.2.2
120
00:00:23
Distance: (default is 120)
R3#conf ter
Enter configuration commands, one per line.
R3(config)#int eth 0
R3(config-if)#ip rip send version 1
End with CNTL/Z.
R3#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int eth 0
R3(config-if)#ip rip receive version 1
R3(config-if)#^Z
R3#sho ip prot
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 2 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: connected, rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
Ethernet0
1
1
Serial0
2
2
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
10.0.1.2
120
00:00:28
10.0.0.1
120
00:03:58
Distance: (default is 120)
A continuación se muestra la tabla de ruteo de R2
66.48 Seminario de Redes
MOG
R2#sho ip ro
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C
10.0.2.0/24 is directly connected, Serial0
R
10.0.0.0/24 [120/1] via 10.0.1.3, Serial1
C
10.1.0.1/32 is directly connected, Loopback0
C
10.0.1.0/24 is directly connected, Serial1
Vemos que la otra ruta, con distancia administrativa mayor no aparece.
Para corroborar que la ruta será la de menor distancia administrativa, se ejecutó un ping desde
R2 hacia el host 10.0.0.100/24, el cual debe llegar por el router R3.
Al ejecutar el ping, capturamos el siguiente tráfico en el host:
Frame 63 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 00:04:76:b8:93:0f
Destination: 00:04:76:b8:93:0f (10.0.0.100)
Source: 00:50:73:43:c0:9c (10.0.0.3)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.0.1.2 (10.0.1.2), Dst Addr: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 100
Identification: 0x0005 (5)
Flags: 0x00
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa72e (correct)
Source: 10.0.1.2 (10.0.1.2)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xf33a (correct)
Identifier: 0x1ef3
Sequence number: 0x0a1a
Data (72 bytes)
Se observa a partir de la dirección MAC, que el router que entrega el mensaje es R3, y a partir de
la IP que el router origen es R2, corroborando nuestras suposiciones.
Conclusiones:
Es así que confirmamos el hecho de que al utilizar diferentes protocolos en una misma zona, en este caso RIPv1
y RIPv2, las rutas con mayor importancia o peso para los routers al momento de decidir entre una u otra son
las de menor Distancia Administrativa.
Escenario 6:
Se desconectó el vínculo entre R2 y R3 y posteriormente se ejecutó un ping. A
continuación se muestra la captura de tráfico ICMP en el host 10.0.0.100/24.
Frame 35 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 00:04:76:b8:93:0f
Destination: 00:04:76:b8:93:0f (10.0.0.100)
Source: 00:50:73:43:bb:f0 (10.0.0.1)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.0.2.2 (10.0.2.2), Dst Addr: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xba12 (correct)
Identifier: 0x2011
Sequence number: 0x0294
Data (72 bytes)
66.48 Seminario de Redes
Frame 36 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: 00:04:76:b8:93:0f, Dst: 00:50:73:43:bb:f0
Destination: 00:50:73:43:bb:f0 (10.0.0.1)
Source: 00:04:76:b8:93:0f (10.0.0.100)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.0.0.100 (10.0.0.100), Dst Addr: 10.0.2.2 (10.0.2.2)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0xc212 (correct)
Identifier: 0x2011
Sequence number: 0x0294
Data (72 bytes)
Vemos que la ruta elegida ahora es a través del router R1, que es la única habilitada.
A continuación se muestra el tráfico de mensajes RIP capturados.
Frame 1 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.2.0 (10.0.2.0)
Metric: 1
IP Address: 10.1.0.1, Metric: 2
Address Family: IP (2)
IP Address: 10.1.0.1 (10.1.0.1)
Metric: 2
Frame 2 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 1
IP Address: 10.1.0.1, Metric: 2
Address Family: IP (2)
IP Address: 10.1.0.1 (10.1.0.1)
Metric: 2
Frame 5 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 1
IP Address: 10.1.0.1, Metric: 2
Address Family: IP (2)
IP Address: 10.1.0.1 (10.1.0.1)
Metric: 2
Frame 6 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.2.0 (10.0.2.0)
Metric: 1
MOG
66.48 Seminario de Redes
MOG
IP Address: 10.1.0.1, Metric: 2
Address Family: IP (2)
IP Address: 10.1.0.1 (10.1.0.1)
Metric: 2
Frame 7 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 16
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 16
Frame 8 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.1.0, Metric: 16
Address Family: IP (2)
IP Address: 10.0.1.0 (10.0.1.0)
Metric: 16
Frame 9 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
IP Address: 10.0.2.0 (10.0.2.0)
Metric: 1
IP Address: 10.1.0.1, Metric: 2
Address Family: IP (2)
IP Address: 10.1.0.1 (10.1.0.1)
Metric: 2
Vemos que al dar de baja el enlace la información se propaga rápidamente haciendo uso del
Poison Reverse.
Conclusión:
Al caerse la conexión entre R2 y R3 que poseía menor distancia administrativa, se pudo ver que los mensajes
de Echo ICMP viajaron por el único enlace posible, que justamente es el que posee mayor distancia
administrativa, es decir a través de R1.
Escenario 7: (RIPv2 con Autenticación en claro)
Se configuró RIPv2 en todos los routers y en los routers R1 y R3 se usó la opción de
autenticación en claro. El tráfico se capturó mediante el host 10.0.0.100. Se espera ver el
formato de los paquetes RIPv2 con autenticación y que la red converja.
Configuración de los routers
R1#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#key chain MogR1
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string Guillote
R1(config-keychain-key)#interface ethernet 0
R1(config-if)#ip rip authentication key-chain MogR1
66.48 Seminario de Redes
MOG
R1(config-if)#ip rip authentication mode text
R1(config)#exit
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#network 10.0.0.0
R1(config-router)#network 10.0.2.0
R3#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#key chain MogR3
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string Guillote
R3(config-keychain-key)#interface ethernet 0
R3(config-if)#ip rip authentication key-chain MogR3
R3(config-if)#ip rip authentication mode text
R3(config)#exit
R3(config)#router rip
R3(config-router)#version 2
R3(config-router)#network 10.0.0.0
R3(config-router)#network 10.0.1.0
Resultado de la captura:
No.
5
9
12
13
16
17
22
23
28
29
30
31
34
35
38
39
42
43
49
50
51
52
55
56
Time
122.893070
123.091335
124.895693
125.084586
132.877890
133.078143
160.738625
161.165838
186.609736
189.557071
214.913121
219.015661
243.053951
245.783987
270.956595
274.004585
296.839485
299.483254
323.045532
328.819657
349.851416
358.222041
377.833485
386.367270
Source
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
Destination
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
Protocol
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
Tramas detalladas
No.
Time
5 122.893070
Source
10.0.0.1
Destination
224.0.0.9
Protocol Info
RIPv2
Request
Frame 5 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Request (1)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: Guillote
Address not specified, Metric: 16
Address Family: Unspecified (0)
Route Tag: 0
Netmask: 0.0.0.0 (0.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16
No.
Time
9 123.091335
Source
10.0.0.3
Destination
224.0.0.9
Protocol Info
RIPv2
Request
Info
Request
Request
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
66.48 Seminario de Redes
MOG
Frame 9 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Request (1)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: Guillote
Address not specified, Metric: 16
Address Family: Unspecified (0)
Route Tag: 0
Netmask: 0.0.0.0 (0.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16
No.
Time
12 124.895693
Source
10.0.0.1
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 12 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: Guillote
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.2.0 (10.0.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
No.
Time
13 125.084586
Source
10.0.0.3
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 13 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: Guillote
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
R1#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
C
C
R
10.0.0.0/24
10.0.2.0
10.0.0.0
10.0.1.0
is subnetted, 3 subnets
is directly connected, Serial0
is directly connected, Ethernet0
[120/1] via 10.0.0.3, Ethernet0
[120/1] via 10.0.2.2, Serial0
66.48 Seminario de Redes
MOG
R3#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
R
C
C
10.0.0.0/24 is subnetted, 3 subnets
10.0.2.0 [120/1] via 10.0.0.1, Ethernet0
[120/1] via 10.0.1.2, Serial0
10.0.0.0 is directly connected, Ethernet0
10.0.1.0 is directly connected, Serial0
Se observa como fue existoso el intercambio de mensajes de RIPv2 con autenticación, ya que
la tabla de ruteo es igual a cuando no había autenticación y la red había convergido. Este tipo
de autenticación no puede brindar seguridad alguna, pero podría utilizarse para que por una
misma LAN ethernet distintos routers usen la palabra clave como para separar dominios de
ruteo utilizando RIPv2.
Conclusión:
Si bien este tipo de autenticación no puede proveer seguridad, es una herramienta que puede servir para
que al agregar routers a una red ethernet haya que configurarlo explícitamente antes de que pueda intercambiar
información de ruteo. Como anteriormente se dijo, se puede utilizar para distinguir dominios de ruteo en
diferentes routers.
Escenario 8: (RIPv2 con Autenticación Inválida)
Se configuró RIPv2 en todos los routers y en los routers R1 y R3 se usó la opción de
autenticación en claro. Además, a propósito se configuraron distintas palabras clave. El tráfico
se capturó mediante el host 10.0.0.100. Se espera ver que la red tenga menos caminos que
cuando converge completamente y se utilizará un comando del router para verificar que está
ignorando los paquetes con distinta clave.
Comandos ejecutados en R3:
R3#conf ter
R3(config)#key chain MogR3
R3(config-keychain)#key 1
R3(config-keychain-key)#no key-string Guillote
R3(config)#key chain MogR3
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string badpass
R3(config-keychain-key)#exit
R3(config-keychain)#^Z
Resultado de la captura:
No.
1
2
5
8
9
10
11
14
15
16
Time
0.000000
17.328274
25.772346
44.243006
54.750890
73.570321
80.312810
99.524610
109.569145
127.915931
Source
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
Destination
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
Protocol
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
Info
Response
Response
Response
Response
Response
Response
Response
Response
Response
Response
66.48 Seminario de Redes
17
18
21
22
137.130981
154.887705
165.319957
183.217216
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
MOG
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
RIPv2
RIPv2
RIPv2
RIPv2
Response
Response
Response
Response
Tramas detalladas
No.
Time
1 0.000000
Source
10.0.0.1
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 1 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: Guillote
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.2.0 (10.0.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
No.
Time
2 17.328274
Source
10.0.0.3
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 2 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: Guillote
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
No.
Time
10 73.570321
Source
10.0.0.3
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 10 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
Esta última trama no lleva autenticación porque fue enviada mientras se hacía el cambio de
key-string.
No.
Time
14 99.524610
Source
10.0.0.3
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 14 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
66.48 Seminario de Redes
MOG
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Simple Password
Authentication type: Simple Password (2)
Password: badpass
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
Aquí se muestra la tabla de ruteo del router R3 y se ve que la red 10.0.2.0 no se puede alcanzar
via la Ethernet0.
R3#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
R
C
C
10.0.0.0/24
10.0.2.0
10.0.0.0
10.0.1.0
is subnetted, 3 subnets
[120/1] via 10.0.1.2, Serial0
is directly connected, Ethernet0
is directly connected, Serial0
Se ejecuta el comando debug ip rip events en el router R3.
R3#debug ip rip events
RIP event debugging is on
R3#
00:15:05: RIP: ignored v2 packet from 10.0.0.1 (invalid authentication)
00:15:21: RIP: received v2 update from 10.0.1.2 on Serial0
00:15:21: RIP: Update contains 1 routes
00:15:24: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.0.3)
00:15:24: RIP: Update contains 2 routes
00:15:24: RIP: Update queued
00:15:24: RIP: sending v2 update to 224.0.0.9 via Serial0 (10.0.1.3)
00:15:24: RIP: Update contains 1 routes
00:15:24: RIP: Update queued
00:15:24: RIP: Update sent via Ethernet0
00:15:24: RIP: Update sent via Serial0
00:15:32: RIP: ignored v2 packet from 10.0.0.1 (invalid authentication)
00:15:50: RIP: received v2 update from 10.0.1.2 on Serial0
00:15:50: RIP: Update contains 1 routes
00:15:52: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.0.3)
00:15:52: RIP: Update contains 2 routes
00:15:52: RIP: Update queued
00:15:52: RIP: sending v2 update to 224.0.0.9 via Serial0 (10.0.1.3)
00:15:52: RIP: Update contains 1 routes
00:15:52: RIP: Update queued
00:15:52: RIP: Update sent via Ethernet0
00:15:52: RIP: Update sent via Serial0
RIP event debugging is off
Conclusión:
Acá se prueba lo dicho en el escenario anterior, es decir, que al ignorar los paquetes RIPv2
correspondientes a otra key-string puede haber, por ejemplo 4 routers en una misma LAN, donde 2 hablen
RIPv2 y los otros 2 hablen RIPv2 sin interferirse entre sí.
66.48 Seminario de Redes
MOG
Escenario 9: (RIPv2 con Autenticación Digesto de MD5)
Se configuró RIPv2 en todos los routers y en los routers R1 y R3 se usó la opción de
autenticación con digesto MD5. El tráfico se capturó mediante el host 10.0.0.100. Se espera
ver el formato de los paquetes RIPv2 con autenticación de la RFC 2082 y que la red converja.
Para hacer uso de la autenticación MD5 se ejecutaron las siguientes líneas de comando en R1 y
R3:
R1#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface ethernet 0
R1(config-if)#ip rip authentication mode md5
R1(config-if)#^Z
Resultado de la captura:
No.
1
2
5
6
7
8
11
12
Time
0.000000
2.861295
28.266098
28.550221
56.862150
57.301256
85.237582
86.567306
Source
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
Destination
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
224.0.0.9
Protocol
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
RIPv2
Tramas detalladas
No.
Time
1 0.000000
Source
10.0.0.3
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 1 (126 bytes on wire, 126 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Keyed Message Digest
Authentication type: Keyed Message Digest (3)
Digest Offset: 64
Key ID: 1
Auth Data Len: 20
Seq num: 3
Zero Padding
Authentication Data Trailer
Authentication Data: a1 b2 ac 33 4b aa e7 4d 28 1c a9 5c 51 e4 2b 4b
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 10.0.2.0, Metric: 2
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.2.0 (10.0.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 2
No.
Time
2 2.861295
Source
10.0.0.1
Destination
224.0.0.9
Protocol Info
RIPv2
Response
Frame 2 (126 bytes on wire, 126 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:09
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Info
Response
Response
Response
Response
Response
Response
Response
Response
66.48 Seminario de Redes
MOG
Version: RIPv2 (2)
Routing Domain: 0
Authentication: Keyed Message Digest
Authentication type: Keyed Message Digest (3)
Digest Offset: 64
Key ID: 1
Auth Data Len: 20
Seq num: 2
Zero Padding
Authentication Data Trailer
Authentication Data: 1b 16 cc 4d c8 8f d4 b1 73 7d 28 f5 96 23 e8 78
IP Address: 10.0.1.0, Metric: 2
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 2
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.2.0 (10.0.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
Se puede observar que si bien se definía un formato de paquete para la autenticación en RIPv2
(RFC 2453) éste sólo especificaba un único método de autenticación (tipo 2: password en
claro). En cambio, la RFC 2082 describe como se debe implementar la autenticación cuando
lleva digestos criptográficos. Puede parecer curioso que una RFC anterior defina algo que no
estaba normado en una RFC posterior, pero como la burocracia es lenta en los grandes
ámbitos, las compañías arman forums para ponerse de acuerdo y adelantarse al cambio.
A su vez se puede corroborar que es un digesto y no el hash de una clave ya que varía
en los diferentes paquetes de RIPv2.
Conclusión:
Este método provee una manera segura de intercambiar información sobre ruteo, y es bastante díficil de
violar ya que primero se debe conocer el algoritmo que utilizan los routers CISCO, si realizan un append o
prepend del hash de la clave o de la clave al mensaje RIPv2 y luego calculan su digesto MD5. Por lo tanto es
práctico de utilizar en redes LAN donde hay computadoras que puedan poner en riesgo la seguridad de la red.
66.48 Seminario de Redes
MOG
OSPF (Open Shortest Path First)
El OSPF es un algoritmo del tipo link state usado por la comunidad de Internet y
diseñado por IETF. El OPSF es clasificado como un algoritmo IGP (interior gateway protocol), es
decir que distribuye información de ruteo entre routers de un mismo sistema autónomo (AS).
OSPF es transportado sobre IP, el campo de PROTOCOL en el datagrama IP lleva el valor de
89.
Cada router OSPF mantiene una base de datos describiendo la topología del AS. De
esta base de datos se calcula una tabla de ruteo construyendo un árbol con los caminos más
cortos. Ante cambios en la topología, OSPF recalcula rápidamente las rutas más convenientes,
utilizando un mínimo de tráfico de protocolo.
Entre las características de OSPF podemos resaltar:
• es un estándar abierto
• se incluye un ruteo por tipo de servicio, los administradores pueden instalar varias rutas
hacia un mismo destino, una por cada tipo de servicio
• se puede hacer balance de carga, especificando varias rutas hacia un mismo destino
• permite el crecimiento de la red mediante la sudivisión en áreas
• viaja directamente sobre IP
• los intercambios entre ruteadores son autenticados
• una métrica arbitraria y adimensional
El protocolo de ruteo OPSF permite agrupar un conjunto de redes que forman lo que
se denomina un Área. La topología del Área se mantiene oculta para el resto del AS, similar al
concepto de subnetting de IP. El agrupar varias redes en áreas permite reducir
significativamente el tráfico de ruteo.
La base de datos que describe la topología del AS permite representar al mismo como
un grafo, cuyos vértices son los routers y las redes son las aristas. OSPF permite tres tipos de
redes físicas: enlaces punto a punto, redes broadcast y redes no broadcast. Cada red tiene una
IP y una máscara asociada. El grafo se va armando a partir de mensajes llamados link state
advertisement, generado por los routers. Cada router asigna un costo a cada una de sus interfaces,
el mismo puede ser configurado por el administrador y es usado para el cálculo de las rutas
más cortas mediante un algoritmo de Dijkstra.
Formato del mensaje:
A continuación se analizan los distintos mensajes que intervienen en OSPF.
El encabezado general es el siguiente:
VERSIÓN
TIPO
LONGITUD DEL MENSAJE
DIERECCIÓN IP DEL RUTEADOR FUENTE
ÁREA ID
SUMA DE VERIFICACIÓN
TIPO DE AUTENTIFICACIÓN
66.48 Seminario de Redes
MOG
AUTENTICACIÓN (octetos 0-3)
AUTENTICACIÓN (octetos 4-7)
El campo TIPO identifica al tipo de mensaje
TIPO
1
2
3
4
5
SIGNIFICADO
HELLO se utiliza para pruebas de accesibilidad
Descripción de la base de datos (topología)
Solicitud de estado de enlace
Actualización de estado de enlace
Acuse de recibo de estado de enlace
Protocolo HELLO:
Este protocolo es responsable de establecer, mantener y asegurar la comunicación
bidireccional entre vecinos. Los paquetes HELLO son enviados periódicamente a todas las
interfaces de los routers. La comunicación bidireccional se corrobora cuando un router se ve a
él mismo en la lista del router vecino que se incluye en el mensaje de HELLO.
En redes multiacceso, típicamente Ethernet, el protocolo HELLO elige un router
designado (DR), el cual tiene entre otras funciones elegir la información a propagar hacia otras
redes.
A continuación se muestra el formato del protocolo HELLO.
ENCABEZADO OSPF CON TIPO = 1
MÁSCARA DE RED
DEAD TIMER
HELLO INTER
ROUTER DESIGNADO
ROUTER DESIGNADO DE RESPALDO
DIRECCIÓN IP DEL VECINO 1
DIRECCIÓN IP DEL VECINO 2
…
DIRECCIÓN IP DEL VECINO n
GWAY PRIOR
La máscara de red es la correspondiente a la interfaz por la cual se manda el mensaje.
El Dead Timer contiene el tiempo en segundos después del cual se considera sin actividad un
vecino. El campo HELLO INTERVAL es el tiempo normal, medido en segundos, entre
mensajes HELLO. El campo GWAY PRIOR es un entero que indica la prioridad del router y
se utiliza para seleccionar al router de respaldo. Los campos de Router Designado y de Router
designado de Respaldo indican quién es el router designado y el de respaldo para ésta red,
puede no haber router de respaldo en cuyo caso aparece 0.0.0.0. Luego se listan los vecinos
que han sido descubiertos.
El papel del DR es concentrar y propagar la información. Cuando un router publica el
estado del enlace, se lo comunica sólo al DR quien luego se lo comunicará al resto de la red.
66.48 Seminario de Redes
MOG
Esto evita que todos los routers manden mensajes multicast a todos los routers cuando quieran
informar algo.
La elección del DR se basa en una prioridad asignada a cada router, y a igual prioridad
se escoje el router de mayor IP.
Mensaje de descripción de la base de datos:
Este mensaje es intercambiado por los routers para iniciar su base de datos de la topología de la
red.
ENCABEZADO OSPF CON TIPO 0 2
CERO
NÚMERO DE SECUENCIA DE BASE DE DATOS
TIPO DE ENLACE
ID DE ENLACE
ADVERTISING ROUTER
NÚMERO DE SECUENCIA DE ENLACE
SUMA DE VERIFICACIÓN
LINK AGE
…
I M S
EL bit I indica que es el mensaje inicial, y el bit M indica que más mensajes van a seguir. De
esta manera, si la tabla base de datos es extensa se divide la información y se la manda de a
varios mensajes. El bit S indica que el mensaje fue mandado por un Router maestro (S=1) o
esclavo (S=0). Los mensajes son numerados con el Número de Secuencia, el mensaje inicial
tiene un entero aleatorio, los siguientes se numeran incrementando el número en una unidad.
Formato del mensaje de solicitud de enlace del OSPF
Para solicitar a un vecino información actualizada el router envía un mensaje de solicitud de
enlace.
ENCABEZADO OSPF CON TIPO = 1
TIPO DE ENLACE
ID DE ENLACE
ADVERTISING ROUTER
…
Formato del mensaje de actualización de estado de enlace OPSF
Los routers difunden el estado de enlace con un mensaje de actualización de estado de enlace.
Cada actualización consiste en una lista de anuncios, como se muestra a continuanción:
66.48 Seminario de Redes
MOG
ENCABEZADO OSPF CON TIPO = 4
NÚMERO DE ANUNCIOS DE ESTADO DE ENLACE
ANUNCIO DE ESTADO DE ENLACE 1
…
ANUNCIO DE ESTADO DE ENLACE n
A su vez los anuncios (LSA) se encapsulan con el siguiente formato:
LINK AGE
TIPO DE ENLACE
ID DE ENLACE
ADVERTISING ROUTER
NÚMERO DE SECUENCIA DE ENLACE
SUMA DE VERIFICIÓN DE ENLACE
LONGITUD
Escenario 10: Sin modificar la maqueta, se configurarán los routers para que difundan las rutas
vía OSPF. Se harán capturas de tráfico en el host 10.0.0.100/24 con el fin de verificar los
formatos y contenidos de los mensajes de OSPF.
Escenario 11: Se procederá a estudiar la respuesta del algoritmo frente a cambios en la red.
Para ello se desconectará el vínculo entre R1 y la red Ethernet 10.0.0.0/24.
66.48 Seminario de Redes
MOG
PARTE III: OPSF
Escenario 10: Se procedió a configurar el protocolo de ruteo OSPF, sin variar la topología de
la red. Por ejemplo, para el router R3 se ejecutaron los siguientes comandos
router ospf 1
network 10.0.0.0 0.0.0.255 area 0.0.0.51
network 10.0.1.0 0.0.0.255 area 0.0.0.51
El número de Área fue asignado arbitrariamente (0.0.0.51), así como la identificación del
proceso (1). El campo de wild-card mask debe ser igual al dual de la dirección de red (0.0.0.255).
Se procedió de manera análoga en cada router.
Luego grabamos la configuración a la flash. A continuación se muestra como queda la
configuración R3.
R3#sh ip ospf int
Ethernet0 is up, line protocol is up
Internet Address 10.0.0.3/24, Area 0.0.0.51
Process ID 1, Router ID 10.0.1.3, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 10.0.2.1, Interface address 10.0.0.1
Backup Designated router (ID) 10.0.1.3, Interface address 10.0.0.3
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.0.2.1 (Designated Router)
Suppress hello for 0 neighbor(s)
Serial0 is up, line protocol is up
Internet Address 10.0.1.3/24, Area 0.0.0.51
Process ID 1, Router ID 10.0.1.3, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.1.0.1
Suppress hello for 0 neighbor(s)
R3#sh ru
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R3
!
enable secret 5 $1$m4MG$gtYDul0d1OWlvu46c.5h50
enable password cisco1
!
ip subnet-zero
!
!
!
!
interface Ethernet0
66.48 Seminario de Redes
MOG
ip address 10.0.0.3 255.255.255.0
no ip directed-broadcast
no keepalive
!
interface Serial0
ip address 10.0.1.3 255.255.255.0
no ip directed-broadcast
!
router ospf 1
redistribute connected
network 10.0.0.0 0.0.0.255 area 0.0.0.51
network 10.0.1.0 0.0.0.255 area 0.0.0.51
!
ip classless
no ip http server
!
!
line con 0
transport input none
line 1
line vty 0 4
password cisco2
login
!
end
-
Se observa que el DR es el de mayor IP en cualquiera de sus interfaces.
Se observa la diferencia de costo asignada a una interfaz serial con una red PTP (64) y a
una interfaz Ethernet 10BT (10)
Se observa la ausencia de una DR en un vínculo PTP.
A continuación vemos como queda la tabla de ruteo de R3.
R3#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
O
C
C
10.0.0.0/24
10.0.2.0
10.0.0.0
10.0.1.0
is subnetted, 3 subnets
[110/74] via 10.0.0.1, Ethernet0
is directly connected, Ethernet0
is directly connected, Serial0
R1#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
C
C
O
10.0.0.0/24
10.0.2.0
10.0.0.0
10.0.1.0
is subnetted, 3 subnets
is directly connected, Serial0
is directly connected, Ethernet0
[110/74] via 10.0.0.3, Ethernet0
R2#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
66.48 Seminario de Redes
C
O
C
MOG
10.0.0.0/24 is subnetted, 3 subnets
10.0.2.0 is directly connected, Serial0
10.0.0.0 [110/74] via 10.0.1.3, Serial1
[110/74] via 10.0.2.1, Serial0
10.0.1.0 is directly connected, Serial1
A continuación se muestran los resultados de la captura.
No.
Time
30 47.578190
38 52.961308
42 57.495235
45 62.877777
47 67.415929
49 72.798594
50 77.336585
52 82.719432
55 87.259280
57 92.217772
58 92.640248
59 92.644791
60 92.647675
61 92.651696
62 92.654164
63 92.656550
64 92.658966
65 93.176666
66 93.190326
68 95.658494
69 95.672301
70 97.177948
72 102.561110
73 107.098530
75 112.481950
77 117.019259
78 122.402771
Source
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
Destination
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
10.0.0.1
224.0.0.5
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
224.0.0.5
224.0.0.6
224.0.0.6
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
224.0.0.5
Protocol Info
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
DB Descr.
OSPF
Hello Packet
OSPF
DB Descr.
OSPF
DB Descr.
OSPF
DB Descr.
OSPF
DB Descr.
OSPF
DB Descr.
OSPF
DB Descr.
OSPF
LS Update
OSPF
LS Update
OSPF
LS Acknowledge
OSPF
LS Acknowledge
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
OSPF
Hello Packet
Se observa que todos los mensajes, salvo las descripciones de base de datos, son enviadas a
través de mensajes Multicast. Esto es indicado ya que los primeros 3 bits de la dirección están
seteados en 1 y el cuarto en 0 (224.0.0.0 a 239.255.255.255). Los 28 restantes especifican el
grupo de multidifusión particular.
A continuación se analizan en detalle los datagramas marcados.
Mensaje HELLO:
Frame 30 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: Hello Packet (1)
Packet Length: 44
Source OSPF Router: 10.0.1.3 (10.0.1.3)
Area ID: 0.0.0.51
Packet Checksum: 0xf168 (correct)
Auth Type: Null
Auth Data (none)
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
66.48 Seminario de Redes
MOG
Router Dead Interval: 40 seconds
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Por ser el primer HELLO aún no hay un DR. Mostramos a continuación dos mensajes
HELLO transmitidos hacia el final de la captura.
Frame 86 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.1.3
Frame 87 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.2.1
Vemos que efectivamente el router con mayor IP (en cualquiera de sus interfaces) es designado
como DR, y el que le sigue como DR de respaldo.
Mensaje de Descripción de la base de datos: Ahora cada router sabe qué vecinos se encuentran
activos. Lo que sigue es que cada router informe a cada DR acerca del estado de la red
mediante un mensaje Multicast.
Frame 57 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 00:50:73:43:bb:f0
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 10.0.0.1 (10.0.0.1)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: DB Descr. (2)
Packet Length: 32
Source OSPF Router: 10.0.1.3 (10.0.1.3)
Area ID: 0.0.0.51
Packet Checksum: 0xd5df (correct)
Auth Type: Null
Auth Data (none)
OSPF DB Description
Interface MTU: 1500
Options: 0x2 (E)
Flags: 0x7 (MS/M/I)
DD Sequence: 5349
Frame 59 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 00:50:73:43:c0:9c
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.3 (10.0.0.3)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: DB Descr. (2)
Packet Length: 32
Source OSPF Router: 10.0.2.1 (10.0.2.1)
Area ID: 0.0.0.51
66.48 Seminario de Redes
Packet Checksum: 0xe706 (correct)
Auth Type: Null
Auth Data (none)
OSPF DB Description
Interface MTU: 1500
Options: 0x2 (E)
Flags: 0x7 (MS/M/I)
DD Sequence: 704
Formato del mensaje de actualización del estado de enlace
Frame 65 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: LS Update (4)
Packet Length: 120
Source OSPF Router: 10.0.2.1 (10.0.2.1)
Area ID: 0.0.0.51
Packet Checksum: 0x68d4 (correct)
Auth Type: Null
Auth Data (none)
LS Update Packet
Number of LSAs: 2
LS Type: Network-LSA
LS Age: 1 seconds
Options: 0x22 (E/DC)
Link-State Advertisement Type: Network-LSA (2)
Link State ID: 10.0.0.1
Advertising Router: 10.0.2.1 (10.0.2.1)
LS Sequence Number: 0x80000001
LS Checksum: ac5a
Length: 32
Netmask: 255.255.255.0
Attached Router: 10.0.2.1
Attached Router: 10.0.1.3
LS Type: Router-LSA
LS Age: 1 seconds
Options: 0x22 (E/DC)
Link-State Advertisement Type: Router-LSA (1)
Link State ID: 10.0.2.1
Advertising Router: 10.0.2.1 (10.0.2.1)
LS Sequence Number: 0x80000003
LS Checksum: 141c
Length: 60
Flags: 0x02
Number of Links: 3
Type: PTP
ID: 10.0.2.2
Data: 10.0.2.1
Metric: 64
Neighboring router's Router ID: 10.0.2.2
Link Data: 10.0.2.1
Link Type: 1 - Point-to-point connection to another router
Number of TOS metrics: 0
TOS 0 metric: 64
Type: Stub
ID: 10.0.2.0
Data: 255.255.255.0
Metric: 64
IP network/subnet number: 10.0.2.0
Link Data: 255.255.255.0
Link Type: 3 - Connection to a stub network
Number of TOS metrics: 0
TOS 0 metric: 64
Type: Transit ID: 10.0.0.1
Data: 10.0.0.1
Metric: 10
IP address of Designated Router: 10.0.0.1
Link Data: 10.0.0.1
Link Type: 2 - Connection to a transit network
Number of TOS metrics: 0
TOS 0 metric: 10
Frame 66 (122 bytes on wire, 122 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:06
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.6 (224.0.0.6)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: LS Update (4)
Packet Length: 88
Source OSPF Router: 10.0.1.3 (10.0.1.3)
Area ID: 0.0.0.51
Packet Checksum: 0xafae (correct)
MOG
66.48 Seminario de Redes
Auth Type: Null
Auth Data (none)
LS Update Packet
Number of LSAs: 1
LS Type: Router-LSA
LS Age: 1 seconds
Options: 0x22 (E/DC)
Link-State Advertisement Type: Router-LSA (1)
Link State ID: 10.0.1.3
Advertising Router: 10.0.1.3 (10.0.1.3)
LS Sequence Number: 0x80000003
LS Checksum: 4cdf
Length: 60
Flags: 0x02
Number of Links: 3
Type: PTP
ID: 10.0.2.2
Data: 10.0.1.3
Metric: 64
Neighboring router's Router ID: 10.0.2.2
Link Data: 10.0.1.3
Link Type: 1 - Point-to-point connection to another router
Number of TOS metrics: 0
TOS 0 metric: 64
Type: Stub
ID: 10.0.1.0
Data: 255.255.255.0
Metric: 64
IP network/subnet number: 10.0.1.0
Link Data: 255.255.255.0
Link Type: 3 - Connection to a stub network
Number of TOS metrics: 0
TOS 0 metric: 64
Type: Transit ID: 10.0.0.1
Data: 10.0.0.3
Metric: 10
IP address of Designated Router: 10.0.0.1
Link Data: 10.0.0.3
Link Type: 2 - Connection to a transit network
Number of TOS metrics: 0
TOS 0 metric: 10
Mensaje de acuse de recibo del estado de enlace
Frame 68 (98 bytes on wire, 98 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:06
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.6 (224.0.0.6)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: LS Acknowledge (5)
Packet Length: 64
Source OSPF Router: 10.0.1.3 (10.0.1.3)
Area ID: 0.0.0.51
Packet Checksum: 0xbfa3 (correct)
Auth Type: Null
Auth Data (none)
LSA Header
LS Age: 1 seconds
Options: 0x22 (E/DC)
Link-State Advertisement Type: Network-LSA (2)
Link State ID: 10.0.0.1
Advertising Router: 10.0.2.1 (10.0.2.1)
LS Sequence Number: 0x80000001
LS Checksum: ac5a
Length: 32
LSA Header
LS Age: 1 seconds
Options: 0x22 (E/DC)
Link-State Advertisement Type: Router-LSA (1)
Link State ID: 10.0.2.1
Advertising Router: 10.0.2.1 (10.0.2.1)
LS Sequence Number: 0x80000003
LS Checksum: 141c
Length: 60
Frame 69 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Version: 2
Message Type: LS Acknowledge (5)
Packet Length: 44
Source OSPF Router: 10.0.2.1 (10.0.2.1)
Area ID: 0.0.0.51
Packet Checksum: 0xec73 (correct)
Auth Type: Null
MOG
66.48 Seminario de Redes
MOG
Auth Data (none)
LSA Header
LS Age: 1 seconds
Options: 0x22 (E/DC)
Link-State Advertisement Type: Router-LSA (1)
Link State ID: 10.0.1.3
Advertising Router: 10.0.1.3 (10.0.1.3)
LS Sequence Number: 0x80000003
LS Checksum: 4cdf
Length: 60
A continuación se adjuntan unos comandos ejecutados sobre las consolas de los routers que
resumen la información intercambiada por OSPF. Puede verse el DR y el BDR que ganaron
por su dirección IP más grande aunque no sea la interfaz Ethernet.
R1#sh ip ospf neighbor
Neighbor ID
10.0.1.3
10.0.2.2
Pri
1
1
State
FULL/BDR
FULL/ -
Dead Time
00:00:38
00:00:30
Address
10.0.0.3
10.0.2.2
Interface
Ethernet0
Serial0
R1#sh ip ospf database
OSPF Router with ID (10.0.2.1) (Process ID 1)
Router Link States (Area 51)
Link ID
10.0.1.3
10.0.2.1
10.0.2.2
ADV Router
10.0.1.3
10.0.2.1
10.0.2.2
Age
158
165
159
Seq#
0x80000003
0x80000004
0x80000004
Checksum
0x46E7
0xC25
0x9009
Age
165
Seq#
Checksum
0x80000001 0xAC5A
Link count
3
3
4
Net Link States (Area 51)
Link ID
10.0.0.1
ADV Router
10.0.2.1
R2#sh ip ospf neighbor
Neighbor ID
10.0.2.1
10.0.1.3
Pri
1
1
State
FULL/
FULL/
Dead Time
00:00:30
00:00:36
-
Address
10.0.2.1
10.0.1.3
Interface
Serial0
Serial1
R2#sh ip ospf database
OSPF Router with ID (10.0.2.2) (Process ID 1)
Router Link States (Area 51)
Link ID
10.0.1.3
10.0.2.1
10.0.2.2
ADV Router
10.0.1.3
10.0.2.1
10.0.2.2
Age
150
158
150
Seq#
0x80000003
0x80000004
0x80000004
Checksum
0x46E7
0xC25
0x9009
Link count
3
3
4
Net Link States (Area 51)
Link ID
10.0.0.1
ADV Router
10.0.2.1
Age
158
Seq#
Checksum
0x80000001 0xAC5A
R3#show ip ospf neighbor
Neighbor ID
10.0.2.1
10.0.2.2
Pri
1
1
State
FULL/DR
FULL/ -
Dead Time
00:00:33
00:00:31
Address
10.0.0.1
10.0.1.2
Interface
Ethernet0
Serial0
R3#sh ip ospf database
OSPF Router with ID (10.0.1.3) (Process ID 1)
Router Link States (Area 51)
Link ID
10.0.1.3
10.0.2.1
10.0.2.2
ADV Router
10.0.1.3
10.0.2.1
10.0.2.2
Age
162
170
164
Seq#
0x80000003
0x80000004
0x80000004
Checksum
0x46E7
0xC25
0x9009
Link count
3
3
4
66.48 Seminario de Redes
MOG
Net Link States (Area 51)
Link ID
10.0.0.1
ADV Router
10.0.2.1
Age
171
Seq#
Checksum
0x80000001 0xAC5A
Escenario 11: Se desconectó el vínculo entre R1 y la red 10.0.0.0/24. Las tablas de ruteo finales
se muestran a continuación.
R2#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
C
O
C
10.0.0.0/24 is subnetted, 3 subnets
10.0.2.0 is directly connected, Serial0
10.0.0.0 [110/74] via 10.0.1.3, Serial1
[110/74] via 10.0.2.1, Serial0
10.0.1.0 is directly connected, Serial1
R2#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
C
O
C
10.0.0.0/24 is subnetted, 3 subnets
10.0.2.0 is directly connected, Serial0
10.0.0.0 [110/74] via 10.0.1.3, Serial1
[110/74] via 10.0.2.1, Serial0
10.0.1.0 is directly connected, Serial1
R3#sh ip ospf database
OSPF Router with ID (10.0.1.3) (Process ID 1)
Router Link States (Area 0.0.0.51)
Link ID
10.0.1.3
10.0.2.1
10.0.2.2
ADV Router
10.0.1.3
10.0.2.1
10.0.2.2
Age
156
154
347
Seq#
0x80000004
0x80000007
0x80000009
Checksum
0x7DBA
0x8BAB
0x8C06
Link count
3
3
4
R3#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
O
C
C
10.0.0.0/24
10.0.2.0
10.0.0.0
10.0.1.0
is subnetted, 3 subnets
[110/128] via 10.0.1.2, Serial0
is directly connected, Ethernet0
is directly connected, Serial0
Las tablas de ruteo resultan tal y como se esperaba, lo interesante es analizar el tiempo en que
se dio la convergencia. Para ello observaremos el tráfico capturado en el Host 10.0.0.1/24.
66.48 Seminario de Redes
Frame 1 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.2.1
Frame 3 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.1.3
Frame 5 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.2.1
Frame 6 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.2.1
Frame 7 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.2.1
Frame 8 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
MOG
66.48 Seminario de Redes
MOG
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.1
Backup Designated Router: 10.0.0.3
Active Neighbor: 10.0.2.1
Frame 9 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:05
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval: 10 seconds
Options: 0x2 (E)
Router Priority: 1
Router Dead Interval: 40 seconds
Designated Router: 10.0.0.3
Backup Designated Router: 0.0.0.0
Se observa que R3 tarda aproximadamente 40 segundos (4 mensajes HELLO que se envían
cada 10 segundos) en darse cuenta que R1 ya no se encuentra disponible. Esto se observa ya
que por un lado el DR pasa a ser R3, y además éste ya no reconoce a R1 (ID 10.0.2.1) como
vecino activo. El tiempo es de esperar que sea próximo a 40 segundos, ya que es el tiempo en
el que está seteado el Dead Timer.
Conclusiones de OSPF:
Con la realización de los últimos dos escenarios verificamos varias de las características fundamentales
de OSPF. Pudimos aprender a configurar el protocolo en routers dentro una red real. También se pudo
corroborar la secuencia y formato de los mensajes del protocolo. Se verificó el rol que desempeñan los “Designated
Routers” y la comunicación entre routers a través de los mensajes Multicast. Finalmente pudimos verificar la
gran velocidad la respuesta del algoritmo frente a alteraciones en la topología de la red. En conclusión pudimos
notar las excelentes cualidades de este algoritmo de ruteo, que si bien resulta muy superior a RIP se debe tener
en cuenta que la excelente performance de este algoritmo es realizada mediante un incremento importante del uso
de CPU, y un protocolo mucho más complejo.
66.48 Seminario de Redes
MOG
EIGRP (Enhanced Interior Gateway Routing Protocol)
Introducción a EIGRP
La sigla EIGRP significa Enhanced Interior Gateway Routing Protocol y es una evolución del
predecesor protocolo IGRP. EIGRP integra las capacidades de un protocolo link-state en un
distance vector. Este hecho se debe gracias a la implementación de diversos algoritmos como el
DUAL (Diffusing Update ALgorithm) y el uso de protocolos de transporte confiables entre otras
razones. DUAL le permite a los routers que corren EIGRP determinar si esa ruta tiene un
loop o no, y a su vez le permite encontrar rutas alternativas sin esperar las actualizaciones de
otros routers.
Esto se refleja en sus características que lo diferencian de otros protocolos de ruteo,
cómo: convergencia rápida, soporte para VLSM (Variable Length Subnet Mask), soporte para
updates parciales y soporte para múltiples protocolos de red.
Funcionamiento general
Un router corriendo EIGRP almacena todas las tablas de ruteo de sus vecinos de
manera tal que puede adaptarse rápidamente a rutas alternativas. Si no existen rutas alternativas
apropiadas, EIGRP emite un pedido (query) para descubrir una ruta alternativa. Este pedido se
propaga hasta que se encuentra una ruta alternativa.
EIGRP no realiza updates periódicos como RIP; en cambio, manda actualizaciones
parciales cuando la métrica de una ruta cambia. La propagación de esta información está
limitada solo a aquellos routers que la necesitan, por lo tanto consume menos recursos que
IGRP.
A su vez, EIGRP tiene la capacidad de redistribuir rutas aprendidas por otros
protocolos OSPF, RIP, IS-IS(Intermediate System-to-Intermediate System), EGP y BGP.
Funcionamiento detallado
Para lograr la perfomance anteriormente descripta EIGRP se basa en el uso de cuatro
tecnologías: neighbor discovery/recovery (descubrimiento y recuperación de vecinos), reliable transport
protocol (RTP), máquinas de estado finitas del algoritmo DUAL, y módulos dependientes de
cada protocolo.
Neighbor discovery/recovery permite a los routers aprender dinámicamente sobre los otros
routers a los cuáles puede acceder a través de una ruta directa. Además, reconoce cuando un
router vecino se hace inaccesible o inoperable. Dicha tarea es alcanzada a través del
intercambio de hellos (paquetes de pequeño tamaño). Es decir, mientras el router reciba
paquetes hello de sus routers vecinos, asumirá que el correspondiente vecino está funcionando.
Reliable transport protocol es responsable de garantizar la correcta llegada de paquetes
EIGRP ordenados secuencialmente. Por razones de eficiencia, sólo ciertos tipos de paquetes
usan RTP. Por ejemplo, los paquetes hello no necesitan confirmaciones (acknowlegdes). A su vez,
para lograr un menor tiempo de convergencia permite enviar paquetes multicast aún cuando
hay otros paquetes pendientes de confirmación.
Las máquinas de estado finitas de DUAL están encargadas de tomar las decisiones
acerca del cálculo de rutas realizando un análisis de todas las rutas publicadas por todos sus
vecinos. DUAL utiliza información sobre saltos para una ruta para seleccionar eficientemente
una ruta sin loops, y selecciona las rutas a insertar en la tabla de ruteo según la definición de
66.48 Seminario de Redes
MOG
feasible successor (sucesor factible). Un sucesor factible es un router vecino que realiza forwarding
hacia un cierto destino, que tiene el mínimo costo hacia ella y que está garantizado que no es
parte de un loop. Si DUAL encuentra un feasible successor evita recomputar la ruta
innecesariamente; si no lo encuentra y sus vecinos siguen publicando información acerca de
ese destino, debe recomputar la ruta (hace diffusing computation) para determinar un sucesor
factible. Si bien este cálculo no demanda demasiados recursos del procesador, sí afecta el
tiempo de convergencia, por eso siempre conviene evitar estos cómputos.
Los módulos dependientes de cada protocolo son los encargados de encapsular los
paquetes de EIGRP, pasar la información a las máquinas de estado de DUAL y de aprovechar
las ventajas si el medio tiene capacidades de multicast.
Fundamentos de EIGRP
EIGRP se basa sobre cuatro fundamentos: Neighbor tables, Topology tables, Route states, y
Route tagging.
En la Neighbor table se guarda la información acerca de los vecinos, su dirección y su
interfaz entre otros datos. Cuando un vecino manda un paquete hello, en él publica un hold time
que indica que hasta que pase ese tiempo se lo trate como alcanzable y operativo. Si otro
paquete hello no es recibido en dicho intervalo de tiempo, se informa a DUAL que hubo un
cambio de topología. A su vez, la tabla guarda información acerca de los números de secuencia
para poder utilizar RTP.
En la Topology table se almacenan todos los destinos publicados por los routers vecinos.
Esta tabla es manejada por el algoritmo DUAL. Además, cada entrada en la Topology table
contiene el destino y una lista de vecinos a través de la cual se puede llegar a él.
El Route state que puede tener un destino de la Topology table puede ser activo o pasivo. Si
es pasivo, significa que no se está realizando una recomputación del destino. Si existe un feasible
sucessor, el destino no debe pasar a estado activo y por ende se evita el recómputo del mismo.
En el otro caso, cuando no hay sucesores factibles, el router inicia el cómputo enviando un
paquete query a cada uno de sus vecinos. El router vecino puede mandar un paquete reply
indicando que tiene un sucesor factible, o puede enviar un paquete query indicando que está
participando en el cómputo. Mientras un destino está en estado activo, no se puede tocar ese
destino en la tabla de ruteo. Sólo después de haber recibido un reply de cada uno de sus
vecinos, el destino pasa a estado pasivo y el router puede elegir un sucesor.
Por último, Route tagging es utilizado para distinguir las rutas externas(de otro AS u otro
protocolo). Estas últimas son marcadas de manera tal que le facilitan la tarea de implementar
políticas flexibles al administrador de la red.
Tipos de Paquetes
EIGRP usa los siguientes tipos de paquetes: hello, acknowledgement, update, query y reply.
Los paquetes hello son de tipo multicast utilizados en el proceso de neighbor
discovery/recovery y no requieren de confirmaciones. Un paquete de acknowledgement no contiene
datos, sólo contienen el número de confirmación(ACK) y siempre se envían usando unicast.
Los paquetes de update son utilizados como medio de transporte de la información
acerca de la alcanzabilidad de los destinos, es decir que transportan la información de ruteo.
Cuando un nuevo vecino es descubierto, se envian paquetes update unicast para que este pueda
construir su topology table. En otros casos, como el cambio de costo de un enlace, los paquetes
66.48 Seminario de Redes
MOG
update son multicast. Por ser su información crítica para el buen funcionamiento de la red, los
paquetes update son transmitidos confiablemente usando RTP.
Formato de los paquetes EIGRP
Header EIGRP
0
Version
8
Opcode
16
Flags
Sequence
ACK
Autonomous System Number
Checksum
31
TLVs
Version: versión de EIGRP.
Opcode: 1 Update
3 Query
4 Reply
5 Hello
6 IPX SAP
Flags: actualmente se usan sólo dos: Init (0x00000001)que indica que las rutas enviadas son las
primeras en una nueva relación de vecinos, y Conditional Receive (0x00000002) usado por
RTP en reliable multicasting.
Sequence: el número de secuencia de 32 bits utilizado por RTP.
ACK: el número de secuencia de 32 bits del último paquete recibido del vecino al que se le
enviará el correspondiente paquete.
Autonomous System Number: número que identifica al dominio EIGRP.
TLVs: (Type/Length/Value) ternas de distintos tipos que llevan información de ruteo, versión
de IOS, parámetros EIGRP, etc.
Tipos de TLV
número
TLV type
TLVs Generales
0x0001
EIGRP parameters
0x0003
Sequence
0x0004
Software Version
0x0005
Next Multicast Sequence
TLVs específicas de IP
0x0102
IP internal routes
0x0103
IP external routes
A continuación describimos los TLVs más frecuentes.
66.48 Seminario de Redes
MOG
EIGRP parameter TLV
0
8
Type = 0x0001
K1
K2
K5
Reserved
EIGRP IP internal route TLV
0
8
Type = 0x0102
16
K3
16
MTU
Load
Next Hop
Delay
Bandwidth
Length
Hold Time
31
K4
Length
31
Hop Count
Reliability
Reserved (0x0000)
Prefix Length
Destination*
*la longitud de este campo es variable y será llenada con ceros hasta el próximo límite de 32
bits. Por ejemplo, si el destino es 10.1.0.0 entonces Destination=0x0A0100 (zero padding), en
cambio si es 192.168.9.24 entonces Destination=0xC0A80918000000 (zero padding).
Next Hop: puede o no ser la dirección IP del originante del paquete.
Delay: suma de los delays configurados en unidades de 10 microsegundos. Si es
0xFFFFFFFF significa que el destino es inalcanzable.
Load: carga en la interfaz del tráfico saliente calculada en un promedio exponencial de
5 minutos.
Prefix Length: cantidad de bits de la dirección IP destino que corresponde a la parte de
red.
Métrica EIGRP
La métrica en EIGRP se calcula de manera similar a IGRP, exceptuando que se
multiplica por 256 para obtener una mayor granularidad.
Bandwidth: se mide en kilobits y es un número estático, es decir que no refleja en ancho de
banda disponible. EIGRP usa 3 octetos y calcula su contribución de la siguiente
manera: 107/Bw (ejemplo: BwEIGRP=107/1544 = 6476 = 0x00194C )
Delay: también es un número estático y se mide en microsegundos. EIGRP usa 3 octetos y
calcula su contribución de la siguiente manera: DLYEIGRP=DLY/10 (ejemplo:
50usecs/10 = 5 = 0x000005). Además si DLYEIGRP=0xFFFFFF significa que la ruta
no es alcanzable.
Reliability: es una variable medida dinámicamente y se representa como un número de 8 bits,
expresada como fracción de la siguiente manera:
si es 100%, entonces
rely=255/255
Load: representa la carga del enlace y se representa como un número de 8 bits, también
expresada como fracción: si la carga es mínima load=1/255, si es máxima 255/255
metric=256*[K1* BwEIGRP+K2* BwEIGRP/(256-load)+K3* DLYEIGRP]*[K5/(rely + K4)]
66.48 Seminario de Redes
MOG
Los valores por default son K1 = K3 = 1 and K2 = K4 = K5 = 0. Si el término K5=0 se
ignora el último factor, ya que sino daría 0. Entonces por default la métrica es:
metric=256*[ BwEIGRP+ DLYEIGRP]
Bibliografía
• EIGRP, http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm
• Cisco Press – CCIE Professional Development Routing TCP/IP Volume I
66.48 Seminario de Redes
MOG
Escenario 12: Se configura el protocolo de ruteo EIGRP en los tres routers en todas sus
interfaces. Se apagan los 3 routers y se encienden. Y se procede a examinar el funcionamiento
del mismo. Se espera ver el transporte via IP, los paquetes Hello, Update y Acknowledge.
Configuración de R1
R1(config)#router eigrp 1
R1(config-router)#network 10.0.0.0 0.0.0.255
R1(config-router)#network 10.0.2.0 0.0.0.255
Las demás configuraciones son análogas.
Resultado de la captura:
No.
43
44
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Time
151.899534
156.772200
160.994099
165.370690
167.403786
167.411352
169.395029
170.235403
170.243149
172.206591
172.226952
172.279536
172.280563
172.371013
172.379147
172.386696
172.391297
172.396021
172.401558
172.402853
172.413163
172.414704
172.422697
172.428948
174.695434
176.785717
179.127614
181.424323
Source
10.0.0.3
10.0.0.3
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
Destination
224.0.0.10
224.0.0.10
224.0.0.10
224.0.0.10
224.0.0.10
10.0.0.1
10.0.0.1
224.0.0.10
10.0.0.3
224.0.0.10
10.0.0.3
224.0.0.10
224.0.0.10
10.0.0.1
10.0.0.3
10.0.0.1
224.0.0.10
10.0.0.1
224.0.0.10
224.0.0.10
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
224.0.0.10
224.0.0.10
224.0.0.10
224.0.0.10
Protocol
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
Info
Hello
Hello
Hello
Hello
Hello
Update
Update
Hello
Update
Hello
Update
Hello
Update
Update
Update
Acknowledge
Query
Acknowledge
Update
Update
Acknowledge
Acknowledge
Reply
Acknowledge
Hello
Hello
Hello
Hello
La secuencia de paquetes de Update, Query y Acknowledge se supone que es por la oscilación
de una interfaz al levantar IOS y que esté siendo “forzado” a publicar inmediatamente sus
rutas cuando no terminó de cargar otras tareas; ya que después se ve que la red queda bien
conformada, como lo muestran las tablas de topología de los diferentes routers.
Tramas detalladas
No.
Time
51 169.395029
Source
10.0.0.3
Destination
10.0.0.1
Protocol Info
EIGRP
Update
Frame 51 (110 bytes on wire, 110 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 00:50:73:43:bb:f0
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 10.0.0.1 (10.0.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 96
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xa383 (correct)
66.48 Seminario de Redes
MOG
Source: 10.0.0.3 (10.0.0.3)
Destination: 10.0.0.1 (10.0.0.1)
Cisco EIGRP
Version
= 2
Opcode = 1 (Update)
Checksum
= 0x0d4c
Flags
= 0x00000001
Sequence
= 3
Acknowledge = 0
Autonomous System : 1
IP internal route =
10.0.1.0/24
Type = 0x0102 (IP internal route)
Size = 28 bytes
Next Hop
= 0.0.0.0
Delay
= 512000
Bandwidth
= 1657856
MTU
= 1500
Hop Count
= 0
Reliability = 255
Load
= 1
Reserved
Prefix Length = 24
Destination = 10.0.1.0
IP internal route =
10.0.2.0/24
Type = 0x0102 (IP internal route)
Size = 28 bytes
Next Hop
= 0.0.0.0
Delay
= 1024000
Bandwidth
= 1657856
MTU
= 1500
Hop Count
= 1
Reliability = 255
Load
= 1
Reserved
Prefix Length = 24
Destination = 10.0.2.0
Esta última trama fue unicast porque al descubrir un nuevo vecino quiere pasarle toda su
información sólo a éste y no a los demás supuestos routers con quien ya estableció relación de
vecino.
No.
Time
52 170.235403
Source
10.0.0.3
Destination
224.0.0.10
Protocol Info
EIGRP
Hello
Frame 52 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:0a
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.10 (224.0.0.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 60
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xcd9d (correct)
Source: 10.0.0.3 (10.0.0.3)
Destination: 224.0.0.10 (224.0.0.10)
Cisco EIGRP
Version
= 2
Opcode = 5 (Hello)
Checksum
= 0xeed1
Flags
= 0x00000000
Sequence
= 0
Acknowledge = 0
Autonomous System : 1
EIGRP Parameters
Type = 0x0001 (EIGRP Parameters)
Size = 12 bytes
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
Reserved
Hold Time = 15
Software Version: IOS=12.0, EIGRP=1.0
66.48 Seminario de Redes
MOG
Type = 0x0004 (Software Version)
Size = 8 bytes
IOS release version = 12.0
EIGRP release version = 1.0
No.
Time
53 170.243149
Source
10.0.0.1
Destination
10.0.0.3
Protocol Info
EIGRP
Update
Frame 53 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 00:50:73:43:c0:9c
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 10.0.0.3 (10.0.0.3)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 40
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xa3bb (correct)
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.3 (10.0.0.3)
Cisco EIGRP
Version
= 2
Opcode = 1 (Update)
Checksum
= 0xfdfb
Flags
= 0x00000001
Sequence
= 1
Acknowledge = 0
Autonomous System : 1
Suponemos que no llegó a mandar nada porque no había terminado de intercambiar rutas con
sus vecinos ya que si observamos el timestamp todo sucede en alrededor de diezmilésimas de
segundos.
No.
Time
57 172.280563
Source
10.0.0.1
Destination
224.0.0.10
Protocol Info
EIGRP
Update
Frame 57 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:0a
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.10 (224.0.0.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 68
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xcd97 (correct)
Source: 10.0.0.1 (10.0.0.1)
Destination: 224.0.0.10 (224.0.0.10)
Cisco EIGRP
Version
= 2
Opcode = 1 (Update)
Checksum
= 0xeda6
Flags
= 0x00000002
Sequence
= 2
Acknowledge = 0
Autonomous System : 1
IP internal route =
10.0.2.0/24
Type = 0x0102 (IP internal route)
Size = 28 bytes
Next Hop
= 0.0.0.0
Delay
= 512000
Bandwidth
= 1657856
MTU
= 1500
Hop Count
= 0
Reliability = 255
Load
= 1
Reserved
Prefix Length = 24
Destination = 10.0.2.0
66.48 Seminario de Redes
MOG
Ahora, cuando ya estableció las relaciones con sus vecinos tiene información por mandar y así
lo hace.
Status de los Routers
R1#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
1
0
10.0.2.2
10.0.0.3
Se0
Et0
Hold Uptime
SRTT
(sec)
(ms)
11 00:04:04 616
14 00:04:10
11
RTO
Q
Cnt
3696 0
200 0
Seq
Num
4
6
R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.0.2.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.0.2.0/24, 1 successors, FD is 2169856
via Connected, Serial0
P 10.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
P 10.0.1.0/24, 1 successors, FD is 2195456
via 10.0.0.3 (2195456/2169856), Ethernet0
via 10.0.2.2 (2681856/2169856), Serial0
R2#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
1
0
10.0.2.1
10.0.1.3
Se0
Se1
Hold Uptime
SRTT
(sec)
(ms)
12 00:04:40
8
13 00:07:23
6
RTO
Q
Cnt
200 0
200 0
Seq
Num
5
5
R2#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.0.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.0.2.0/24, 1 successors, FD is 2169856
via Connected, Serial0
P 10.0.0.0/24, 2 successors, FD is 2195456
via 10.0.2.1 (2195456/281600), Serial0
via 10.0.1.3 (2195456/281600), Serial1
P 10.0.1.0/24, 1 successors, FD is 2169856
via Connected, Serial1
R3#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
1
0
10.0.0.1
10.0.1.2
Et0
Se0
Hold Uptime
SRTT
(sec)
(ms)
11 00:03:16
13
13 00:05:52 931
RTO
Q
Cnt
200 0
5000 0
Seq
Num
4
5
R3#show ip eigrp topology 1
IP-EIGRP Topology Table for AS(1)/ID(10.0.1.3)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.0.2.0/24, 1 successors, FD is 2195456
via 10.0.0.1 (2195456/2169856), Ethernet0
via 10.0.1.2 (2681856/2169856), Serial0
P 10.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
P 10.0.1.0/24, 1 successors, FD is 2169856
via Connected, Serial0
Como se puede observar en router R2 se ve que tiene 2 sucesores, ya que la métrica calculada
da igual, por lo tanto automáticamente realiza load-share para tráfico que por ejemplo va hacia
10.0.0.0/24.
66.48 Seminario de Redes
MOG
El router R1 tiene 1 sucesor y un feasible successor para el destino 10.0.1.0/24 ya que cumple la
condición que la métrica publicada (2169856) que se recibió en la Serial0 es menor que la feasible
distance (FD)(2195456).
A su vez, el router R3, por simetría, tiene 1 sucesor y un feasible successor para el destino
10.0.2.0/24 ya que cumple la condición que la métrica publicada (2169856) que se recibió en la
Serial0 es menor que la feasible distance (FD)(2195456).
Conclusión:
Se pudo observar el funcionamiento de EIGRP sobre IP, más específicamente usando el protocol
identifier 88. A su vez, se vio como EIGRP hizo uso de mensajes tanto unicast(en el caso de descubrir nuevos
vecinos y mandar replies) como multicast (dirección reservada 224.0.0.10) para comunicarse con los demás
routers y evitar que las demás computadoras pertenecientes a la misma red gasten recursos intentando decodificar
esos mensajes ya que no son broadcast. También vale recalcar sus propiedades híbridas, ya que no manda
updates todo el tiempo sino que solamente cuando haya cambios de topología, el cómputo es distribuido y no
individual como en OSPF que se traduce en menor utilización de CPU y memoria. Además, sin olvidar sus
características propietarias que garantizan loop-free routing para todo instante de tiempo, gracias al algoritmo
DUAL.
66.48 Seminario de Redes
MOG
EIGRP Falla de enlace
Escenario 13: Una vez que la red convergió en el escenario anterior, se desconecta el cable
serial del router R1, es decir la red 10.0.2.0. Se esperan ver los paquetes de Query y Reply, ya
que para algunos routers no habrá feasible successors.
Router 2
ser0: 10.0.2.2
ser1: 10.0.1.2
Se desconecta
el cable
10.0.2.0/24
10.0.1.0/24
ser0: 10.0.2.1
ser0: 10.0.1.3
eth0: 10.0.0.1
eth0: 10.0.0.3
10.0.0.0/24
Router 3
Router 1
eth0: 10.0.0.100
Sniffer
Vecinos EIGRP del router R1 después de desconectar el cable de la interfaz serie:
R1#sho ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
0
10.0.0.3
Et0
Hold Uptime
SRTT
(sec)
(ms)
12 00:09:26
37
RTO
Q Seq
Cnt Num
222 0 10
Vecinos EIGRP y Topology Table del router R1 luego de reconectar el cable de la interfaz serie:
R1#sho ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
1
0
10.0.2.2
10.0.0.3
Se0
Et0
Hold Uptime
SRTT
(sec)
(ms)
14 00:00:04
0
11 00:10:22
30
RTO
Q
Cnt
3000 0
200 0
Seq
Num
13
11
R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.0.2.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.0.2.0/24, 1 successors, FD is 2169856
via Connected, Serial0
P 10.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
P 10.0.1.0/24, 1 successors, FD is 2195456
via 10.0.0.3 (2195456/2169856), Ethernet0
via 10.0.2.2 (2681856/2169856), Serial0
Vecinos EIGRP y Topology Table del router R3 después de desconectar el cable de la interfaz
serie de R1:
R3#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
1
0
10.0.0.1
10.0.1.2
Et0
Se0
Hold Uptime
SRTT
(sec)
(ms)
10 00:10:10
28
13 00:12:46 600
RTO
Q
Cnt
200 0
3600 0
Seq
Num
7
8
66.48 Seminario de Redes
MOG
R3#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.0.1.3)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
P 10.0.1.0/24, 1 successors, FD is 2169856
via Connected, Serial0
Vecinos EIGRP y Topology Table del router R3 luego de reconectar el cable de la interfaz serie
de R1:
R3#sho ip eigrp neighbor
IP-EIGRP neighbors for process 1
H
Address
Interface
1
0
10.0.0.1
10.0.1.2
Et0
Se0
Hold Uptime
SRTT
(sec)
(ms)
13 00:10:31
23
11 00:13:06 386
RTO
Q
Cnt
200 0
2316 0
Seq
Num
8
14
R3#sho ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.0.1.3)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 10.0.2.0/24, 1 successors, FD is 2195456
via 10.0.0.1 (2195456/2169856), Ethernet0
via 10.0.1.2 (2681856/2169856), Serial0
P 10.0.0.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
P 10.0.1.0/24, 1 successors, FD is 2169856
via Connected, Serial0
Se puede observar como el router R1 pierde un vecino al desconectar el cable serie. En cambio
R3 no pierde un vecino ya que la desconexión del cable no tiene que ver con un router
adyacente pero sin embargo su topology table se ve alterada ya que al cambiar la interfaz de R2 a
un down state, éste pierde conectividad con la red 10.0.2.0/24 y dicho cambio es propagado
hacia R3. Luego, al reconectar el cable vemos como todo vuelve a la normalidad.
Resultado de la captura:
No.
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
...
133
134
135
136
137
138
139
140
Time
103.547125
106.849054
108.261155
110.710123
110.725378
110.744654
110.749266
110.765730
110.794525
110.831861
110.918347
111.539159
112.733044
115.876095
117.455031
...
257.770261
260.641350
261.557590
261.563589
261.576023
261.580153
262.686488
264.982359
Source
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
...
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.3
10.0.0.1
Destination
224.0.0.10
224.0.0.10
224.0.0.10
224.0.0.10
10.0.0.1
224.0.0.10
10.0.0.3
10.0.0.3
10.0.0.1
10.0.0.1
10.0.0.3
224.0.0.10
224.0.0.10
224.0.0.10
224.0.0.10
...
224.0.0.10
224.0.0.10
224.0.0.10
10.0.0.1
224.0.0.10
10.0.0.3
224.0.0.10
224.0.0.10
Protocol
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
...
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
EIGRP
Info
Hello
Hello
Hello
Query
Acknowledge
Query
Acknowledge
Reply
Acknowledge
Reply
Acknowledge
Hello
Hello
Hello
Hello
...
Hello
Hello
Update
Acknowledge
Update
Acknowledge
Hello
Hello
66.48 Seminario de Redes
MOG
Tramas detalladas
No.
Time
53 110.710123
Source
10.0.0.1
Destination
224.0.0.10
Protocol Info
EIGRP
Query
El router R1 al no tener feasible successors en la topology table desencadena una difussing computation
de la ruta 10.0.2.0/24 mediante un paquete EIGRP de Query.
Frame 53 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:bb:f0, Dst: 01:00:5e:00:00:0a
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 224.0.0.10 (224.0.0.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 68
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xcd97 (correct)
Source: 10.0.0.1 (10.0.0.1)
Destination: 224.0.0.10 (224.0.0.10)
Cisco EIGRP
Version
= 2
Opcode = 3 (Query)
Checksum
= 0x08c6
Flags
= 0x00000000
Sequence
= 6
Acknowledge = 0
Autonomous System : 1
IP internal route =
10.0.2.0/24 - Destination unreachable
Type = 0x0102 (IP internal route)
Size = 28 bytes
Next Hop
= 0.0.0.0
Delay
= 4294967295
Bandwidth
= 0
MTU
= 1500
Hop Count
= 0
Reliability = 0
Load
= 0
Reserved
Prefix Length = 24
Destination = 10.0.2.0
No.
Time
54 110.725378
Source
10.0.0.3
Destination
10.0.0.1
Protocol Info
EIGRP
Acknowledge
Correspondiente Acknowledge por parte de R3 que se puede corroborar ya que el sequence
number es igual al acknowledge number.
Frame 54 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 00:50:73:43:bb:f0
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 10.0.0.1 (10.0.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 40
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xa3bb (correct)
Source: 10.0.0.3 (10.0.0.3)
Destination: 10.0.0.1 (10.0.0.1)
Cisco EIGRP
Version
= 2
Opcode = 5 (Acknowledge)
Checksum
= 0xfdf3
Flags
= 0x00000000
Sequence
= 0
Acknowledge = 6
Autonomous System : 1
No.
Time
55 110.744654
Source
10.0.0.3
Destination
224.0.0.10
Protocol Info
EIGRP
Query
66.48 Seminario de Redes
MOG
R3 pierde sus dos feasible successors por lo dicho anteriormente y también desencadena un
proceso de difussing computation de la ruta 10.0.2.0/24 mediante un paquete EIGRP de Query.
Frame 55 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: 00:50:73:43:c0:9c, Dst: 01:00:5e:00:00:0a
Internet Protocol, Src Addr: 10.0.0.3 (10.0.0.3), Dst Addr: 224.0.0.10 (224.0.0.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 68
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 2
Protocol: EIGRP (0x58)
Header checksum: 0xcd95 (correct)
Source: 10.0.0.3 (10.0.0.3)
Destination: 224.0.0.10 (224.0.0.10)
Cisco EIGRP
Version
= 2
Opcode = 3 (Query)
Checksum
= 0x08c3
Flags
= 0x00000000
Sequence
= 9
Acknowledge = 0
Autonomous System : 1
IP internal route =
10.0.2.0/24 - Destination unreachable
Type = 0x0102 (IP internal route)
Size = 28 bytes
Next Hop
= 0.0.0.0
Delay
= 4294967295
Bandwidth
= 0
MTU
= 1500
Hop Count
= 0
Reliability = 0
Load
= 0
Reserved
Prefix Length = 24
Destination = 10.0.2.0
Para poder comprender globalmente que es lo que está pasando necesitamos información extra
brindada por el comando debug eigrp packets ejecutado en el router R3:
R3#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK)
R3#
01:36:36: EIGRP: Sending HELLO on Serial0
01:36:36:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:37: EIGRP: Sending HELLO on Ethernet0
01:36:37:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:38: EIGRP: Received HELLO on Ethernet0 nbr 10.0.0.1
01:36:38:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:41: EIGRP: Received HELLO on Serial0 nbr 10.0.1.2
01:36:41:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:41: EIGRP: Sending HELLO on Serial0
01:36:41:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:41: EIGRP: Sending HELLO on Ethernet0
01:36:41:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:42: EIGRP: Received HELLO on Ethernet0 nbr 10.0.0.1
01:36:42:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:44: EIGRP: Received QUERY on Serial0 nbr 10.0.1.2
01:36:44:
AS 1, Flags 0x0, Seq 6/5 idbQ 0/0 iidbQ un/rely 0/0
01:36:44: EIGRP: Enqueueing ACK on Serial0 nbr 10.0.1.2
01:36:44:
Ack seq 6 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:44: EIGRP: Sending ACK on Serial0 nbr 10.0.1.2
01:36:44:
AS 1, Flags 0x0, Seq 0/6 idbQ 0/0 iidbQ un/rely 0/0
01:36:44: EIGRP: Enqueueing REPLY on Serial0 nbr 10.0.1.2 iidbQ
01:36:44: EIGRP: Requeued unicast on Serial0
01:36:44: EIGRP: Sending REPLY on Serial0 nbr 10.0.1.2
01:36:44:
AS 1, Flags 0x0, Seq 7/6 idbQ 0/0 iidbQ un/rely 0/0
01:36:44: EIGRP: Received ACK on Serial0 nbr 10.0.1.2
01:36:44:
AS 1, Flags 0x0, Seq 0/7 idbQ 0/0 iidbQ un/rely 0/0
01:36:44: EIGRP: Received UPDATE on Serial0 nbr 10.0.1.2
01:36:44:
AS 1, Flags 0x0, Seq 7/7 idbQ 0/0 iidbQ un/rely 0/0
01:36:44: EIGRP: Enqueueing ACK on Serial0 nbr 10.0.1.2
01:36:44:
Ack seq 7 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:44: EIGRP: Sending ACK on Serial0 nbr 10.0.1.2
peerQ un/rely 0/0
peerQ un/rely 0/0
peerQ un/rely 0/0
peerQ un/rely 0/0
peerQ un/rely 1/0
un/rely 0/1 peerQ un/rely 0/0 serno 7-7
peerQ un/rely 0/1 serno 7-7
peerQ un/rely 0/1
peerQ un/rely 0/0
66.48 Seminario de Redes
MOG
01:36:44:
AS 1, Flags 0x0, Seq 0/7 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Received QUERY on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 6/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Este último mensaje se corresponde con la trama número 55, ya que su sequence number y el
tipo de paquete son coincidentes.
01:36:45: EIGRP: Enqueueing ACK on Ethernet0 nbr 10.0.0.1
01:36:45:
Ack seq 6 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Sending ACK on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 0/6 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Enqueueing QUERY on Serial0 iidbQ un/rely 0/1 serno 8-8
01:36:45: EIGRP: Enqueueing QUERY on Ethernet0 iidbQ un/rely 0/1 serno 8-8
01:36:45: EIGRP: Enqueueing QUERY on Serial0 nbr 10.0.1.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 8-8
01:36:45: EIGRP: Sending QUERY on Ethernet0
01:36:45:
AS 1, Flags 0x0, Seq 9/0 idbQ 0/0 iidbQ un/rely 0/0 serno 8-8
01:36:45: EIGRP: Sending QUERY on Serial0 nbr 10.0.1.2
01:36:45:
AS 1, Flags 0x0, Seq 8/7 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 8-8
01:36:45: EIGRP: Received ACK on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 0/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
01:36:45: EIGRP: Ethernet0 multicast flow blocking cleared
01:36:45: EIGRP: Received ACK on Serial0 nbr 10.0.1.2
01:36:45:
AS 1, Flags 0x0, Seq 0/8 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
01:36:45: EIGRP: Serial0 multicast flow blocking cleared
01:36:45: EIGRP: Received REPLY on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 7/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:36:45: EIGRP: Enqueueing ACK on Ethernet0 nbr 10.0.0.1
01:36:45:
Ack seq 7 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Sending ACK on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 0/7 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Received REPLY on Serial0 nbr 10.0.1.2
01:36:45:
AS 1, Flags 0x0, Seq 8/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:36:45: EIGRP: Enqueueing ACK on Serial0 nbr 10.0.1.2
01:36:45:
Ack seq 8 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Sending ACK on Serial0 nbr 10.0.1.2
01:36:45:
AS 1, Flags 0x0, Seq 0/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
01:36:45: EIGRP: Enqueueing REPLY on Ethernet0 nbr 10.0.0.1 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 9-9
01:36:45: EIGRP: Requeued unicast on Ethernet0
01:36:45: EIGRP: Sending REPLY on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 10/7 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 9-9
01:36:45: EIGRP: Received ACK on Ethernet0 nbr 10.0.0.1
01:36:45:
AS 1, Flags 0x0, Seq 0/10 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
01:36:45: EIGRP: Sending HELLO on Serial0
01:36:45:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:36:46: EIGRP: Received HELLO on Serial0 nbr 10.0.1.2
01:36:46:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:36:46: EIGRP: Sending HELLO on Ethernet0
01:36:46:
AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
EIGRP Packets debugging is off
Los eventos marcados en negrita explican que antes de que el Query de R1 llegue, R3 había
recibido un Update de R2 informándole que la red 10.0.2.0/24 era inaccesible por lo tanto R3
pierde sus dos sucesores factibles: R1 y R2.
Conclusión:
Se pudo observar el proceso de diffusing computation que efectuó al perder todos los feasible successors.
En este caso, por ser una red muy chica y con enlaces de considerable ancho de banda, el tiempo de convergencia
fue de aproximadamente 2 segundos. Esto fue así porque al caerse en una red punto a punto el nivel de enlace,
no fue necesario esperar el hold time para dar de baja a un vecino.
66.48 Seminario de Redes
MOG