Trabajo Práctico Nº1

Transcripción

1 66.48 Seminario de Redes Trabajo Práctico Nº1 Protocolos de Ruteo Análisis de mensajes protocolares Grupo: MOG 2º uatrimestre 2004

2 Introducción general... 2 RIPv Puntos clave de RIP... 3 Formato del mensaje en RIPv RIPv Autenticación en RIPv OSPF (Open Shortest Path First) Formato del mensaje: Protocolo HELLO: Mensaje de descripción de la base de datos: Formato del mensaje de solicitud de enlace del OSPF Formato del mensaje de actualización de estado de enlace OPSF PARTE III: OPSF onclusiones de OSPF: EIGRP (Enhanced Interior Gateway Routing Protocol) Introducción a EIGRP Funcionamiento general Funcionamiento detallado Fundamentos de EIGRP Tipos de Paquetes Formato de los paquetes EIGRP Bibliografía... 50

3 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.

4 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. ada 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 abe 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

5 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 OMMANDO: omandos Descripción 1 Pedido de la tabla de ruteo parcial o total 2 Respuesta contiendo la/s dirección/es de red y la/s distancia/s 3 Activar el modo de traza (obsoleto) 4 Desactivar el modo de traza (obsoleto) 5 Reservado para Sun Microsystem 9 Pedido de actualización(usado con circuitos en demanda) 10 Respuesta de actualización(usado con circuitos en demanda) 11 onfirmación de actualización(usado con circuitos en demanda) OMMANDO(1-5) VERSIÓN(1) ERO FAMILIA DE RED 1 ERO DIREIÓN IP DE LA RED 1 ERO ERO DISTANIA A LA RED 1 FAMILIA DE RED 2 ERO DIREIÓN IP DE LA RED 2 ERO ERO DISTANIA A LA RED 2... 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.

6 El formato de dirección no está limitado a TP/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 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 DISTANIA 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 TP/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.

7 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. OMMANDO(1-5) VERSIÓN(2) NO UTILIZADO FAMILIA DE RED 1 ETIQUETA DE RUTEO DIREIÓN IP DE LA RED 1 MASARA DE SUBRED PROXIMO SALTO DISTANIA 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: OMMANDO(1-5) VERSIÓN(2) NO UTILIZADO FAMILIA DE RED TIPO DE AUTENTIAIÓN AUTENTIAIÓN FAMILIA DE RED 1 ETIQUETA DE RUTEO DIREIÓN IP DE LA RED 1 MASARA DE SUBRED PROXIMO SALTO DISTANIA 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

8 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 RF 2082 (RIP-2 MD5 Authentication) y tiene el siguiente formato que es un poco diferente al anteriormente especificado: OMMAND(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.

9 MAQUETA Para la realización del trabajo práctico se contó con tres routers ISO y un hub 3OM. 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: ser1: / /24 ser0: ser0: eth0: eth0: /24 Router 1 Sniffer eth0: Router 3

10 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 /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 /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 /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 IMP REDIRET Se configurará como default gateway del host /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 IMP REDIRET. 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.

11 Router 2 ser0: ser1: RIPv1 RIPv / /24 ser0: ser0: eth0: RIPv /24 eth0: Router 1 Sniffer eth0: Router 3 on 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. ada 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 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 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.

12 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 Se espera ver el formato de los paquetes RIPv2 con autenticación de la RF 2082 y que la red converja.

13 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 /24 is subnetted, 3 subnets is directly connected, Serial is directly connected, Ethernet0 R [120/1] via , Ethernet0 [120/1] via , Serial0 R3#sh ip ro R /24 is subnetted, 3 subnets [120/1] via , Ethernet0 [120/1] via , Serial is directly connected, Ethernet is directly connected, Serial0 R2#sh ip ro R /24 is subnetted, 3 subnets is directly connected, Serial [120/1] via , Serial1 [120/1] via , Serial 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 Source Destination Protocol Info RIPv1 Request RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Request RIPv1 Response RIPv1 Response

14 RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520) Routing Information Protocol ommand: 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) Metric: 2 IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520) Routing Information Protocol ommand: 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) Metric: 2 IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) Version: 4

15 Header length: 20 bytes Differentiated Services Field: 0xc0 (DSP 0x30: lass Selector 6; EN: 0x00) Total Length: 52 Identification: 0x0000 (0) Flags: 0x00 Fragment offset: 0 Time to live: 2 Protocol: UDP (0x11) Header checksum: 0xadf7 (correct) Source: ( ) Destination: ( ) User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) 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. onclusiones: 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 /24 is subnetted, 2 subnets [120/1] via , Ethernet is directly connected, Ethernet0 R1#sh ip ro /24 is subnetted, 2 subnets

16 is directly connected, Serial is directly connected, Ethernet0 R2#sh ip ro R /24 is subnetted, 2 subnets is directly connected, Serial [120/1] via , Serial0 Vemos que desaparecieron las entradas que vinculaban a la red /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. Time Source Destination Protocol Info RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 Response RIPv1 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 16 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 16 Address Family: IP (2) IP Address: ( ) 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. onclusiones:

17 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 /24, en este caso un default gateway. Mientras tanto seguía desconectado el cable serial entre R2 y R3. Rutas activas: :\WINDOWS\Escritorio\tmp>route print Dirección de red Máscara de red Puerta de enlace Interfaz Métrica Luego se ejecutó un ping :\WINDOWS\Escritorio>ping Haciendo ping a con 32 bytes de datos: Respuesta desde : bytes=32 tiempo=10ms TDV=254 Respuesta desde : bytes=32 tiempo=4ms TDV=254 Respuesta desde : bytes=32 tiempo=3ms TDV=254 Respuesta desde : bytes=32 tiempo=3ms TDV=254 Estadísticas de ping para : 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: :\WINDOWS\Escritorio\tmp>route print Dirección de red Máscara de red Puerta de enlace Interfaz Métrica Se observa que se ha agregado una ruta hacia , que es una ruta de host, a través del router R1. Luego, se vuelve a ejecutar un ping. :\WINDOWS\Escritorio>ping Haciendo ping a con 32 bytes de datos: Respuesta desde : bytes=32 tiempo=4ms TDV=254 Respuesta desde : bytes=32 tiempo=3ms TDV=254 Respuesta desde : bytes=32 tiempo=3ms TDV=254

18 Respuesta desde : 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 IMP intercambiados: No. Time Source Destination Protocol Info IMP Echo (ping) request IMP Redirect IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) reply IMP Echo (ping) request IMP Echo (ping) 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: ( ), Dst Addr: ( ) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSP 0x00: Default; EN: 0x00) Total Length: 56 Identification: 0x05d7 (1495) Flags: 0x00 Fragment offset: 0 Time to live: 255 Protocol: IMP (0x01) Header checksum: 0xa187 (correct) Source: ( ) Destination: ( ) Internet ontrol Message Protocol Type: 5 (Redirect) ode: 0 (Redirect for network) hecksum: 0x9ba2 (correct) Gateway address: ( ) Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSP 0x00: Default; EN: 0x00) Total Length: 60 Identification: 0x99c5 (39365) Flags: 0x00 Fragment offset: 0 Time to live: 31 Protocol: IMP (0x01) Header checksum: 0xeb96 (correct) Source: ( ) Destination: ( ) Internet ontrol Message Protocol Type: 8 (Echo (ping) request) ode: 0 hecksum: 0x445c (incorrect, should be 0xeeff) Identifier: 0x0300 Sequence number: 0x0600

19 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 ( ) Source: 00:50:73:43:c0:9c ( ) Type: IP (0x0800) Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Internet ontrol Message Protocol Type: 8 (Echo (ping) request) ode: 0 hecksum: 0x445c (correct) Identifier: 0x0300 Sequence number: 0x0600 Se observa como el router R3 indica al host que para alcanzar a tiene que salir por Vale la pena recalcar que el router R3 reenvía el primer IMP echo reply y lo podemos corroborar fijándonos en la MA Address de origen, que es la de R3. Router 2 ser0: ser1: Se desconecta el cable / /24 ser0: eth0: :50:73:43:bb:f0 eth0: :50:73:43:c0:9c ser0: /24 Router 1 eth0: P y Sniffer Router 3 onclusiones: RIPv1 nos permite que, ante la configuración estática de un Default Gateway, genere un mensaje IMP 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 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. onfiguración: se ejecutaron los siguientes comandos en cada router(la loopback fue creada anteriormente) R1#conf ter Enter configuration commands, one per line. End with NTL/Z. R1(config)#router rip R1(config-router)#version 2 R1(config-router)#network R1(config-router)#network

20 R1(config-router)#redist conn R2(config)#router rip R2(config-router)#version 2 R2(config-router)#network R2(config-router)#network R2(config-router)#redist conn R3#conf ter Enter configuration commands, one per line. End with NTL/Z. R3(config)#router rip R3(config-router)#version 2 R3(config-router)#network R3(config-router)#network R3(config-router)# A continuación se muestra el tráfico capturado. No. Time Source Destination Protocol Info RIPv2 Request RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Request RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Request (1) Version: RIPv2 (2) Routing Domain: 0 Address not specified, Metric: 16 Address Family: Unspecified (0) Route Tag: 0 Netmask: ( ) Next Hop: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: , Metric: 1 Address Family: IP (2) Route Tag: 0 IP Address: ( ) Netmask: ( ) Next Hop: ( ) 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 R /8 is variably subnetted, 4 subnets, 2 masks /24 is directly connected, Serial /32 [120/1] via , Serial0

21 R /24 is directly connected, Ethernet /24 [120/1] via , Ethernet0 [120/1] via , Serial0 R2#show ip Gateway of last resort is not set R /8 is variably subnetted, 4 subnets, 2 masks /24 is directly connected, Serial /24 [120/1] via , Serial1 [120/1] via , Serial /32 is directly connected, Loopback /24 is directly connected, Serial1 R3#sh ip ro Gateway of last resort is not set R R /8 is variably subnetted, 4 subnets, 2 masks /24 [120/1] via , Ethernet0 [120/1] via , Serial /32 [120/1] via , Serial /24 is directly connected, Ethernet /24 is directly connected, Serial0 onclusiones: 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 ( ), esto evita a Ps 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: ser1: RIPv1 RIPv / /24 ser0: ser0: eth0: RIPv /24 eth0: Router 1 Sniffer eth0: Router 3

22 onfiguración: R2(config-router)#distan 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: Routing Information Sources: Gateway Distance Last Update :00: :00:25 Distance: (default is 120) Address Wild mask Distance List R1#conf ter Enter configuration commands, one per line. End with NTL/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: Routing Information Sources: Gateway Distance Last Update :00: :00:23 Distance: (default is 120) R3#conf ter Enter configuration commands, one per line. End with NTL/Z. R3(config)#int eth 0 R3(config-if)#ip rip send version 1 R3#conf ter Enter configuration commands, one per line. End with NTL/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: Routing Information Sources: Gateway Distance Last Update :00: :03:58 Distance: (default is 120) A continuación se muestra la tabla de ruteo de R2

23 R2#sho ip ro Gateway of last resort is not set /8 is variably subnetted, 4 subnets, 2 masks /24 is directly connected, Serial0 R /24 [120/1] via , Serial /32 is directly connected, Loopback /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 /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 ( ) Source: 00:50:73:43:c0:9c ( ) Type: IP (0x0800) Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSP 0x00: Default; EN: 0x00) Total Length: 100 Identification: 0x0005 (5) Flags: 0x00 Fragment offset: 0 Time to live: 254 Protocol: IMP (0x01) Header checksum: 0xa72e (correct) Source: ( ) Destination: ( ) Internet ontrol Message Protocol Type: 8 (Echo (ping) request) ode: 0 hecksum: 0xf33a (correct) Identifier: 0x1ef3 Sequence number: 0x0a1a Data (72 bytes) Se observa a partir de la dirección MA, que el router que entrega el mensaje es R3, y a partir de la IP que el router origen es R2, corroborando nuestras suposiciones. onclusiones: 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 IMP en el host /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 ( ) Source: 00:50:73:43:bb:f0 ( ) Type: IP (0x0800) Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Internet ontrol Message Protocol Type: 8 (Echo (ping) request) ode: 0 hecksum: 0xba12 (correct) Identifier: 0x2011 Sequence number: 0x0294 Data (72 bytes)

24 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 ( ) Source: 00:04:76:b8:93:0f ( ) Type: IP (0x0800) Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Internet ontrol Message Protocol Type: 0 (Echo (ping) reply) ode: 0 hecksum: 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) Metric: 1 IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) Metric: 1 IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) Metric: 1 IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) Metric: 1

25 IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 16 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 16 Address Family: IP (2) IP Address: ( ) 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: Response (2) Version: RIPv1 (1) IP Address: , Metric: 1 Address Family: IP (2) IP Address: ( ) Metric: 1 IP Address: , Metric: 2 Address Family: IP (2) IP Address: ( ) Metric: 2 Vemos que al dar de baja el enlace la información se propaga rápidamente haciendo uso del Poison Reverse. onclusión: Al caerse la conexión entre R2 y R3 que poseía menor distancia administrativa, se pudo ver que los mensajes de Echo IMP 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 Se espera ver el formato de los paquetes RIPv2 con autenticación y que la red converja. onfiguración de los routers R1#conf ter Enter configuration commands, one per line. End with NTL/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

26 R1(config-if)#ip rip authentication mode text R1(config)#exit R1(config)#router rip R1(config-router)#version 2 R1(config-router)#network R1(config-router)#network R3#conf ter Enter configuration commands, one per line. End with NTL/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 R3(config-router)#network Resultado de la captura: No. Time Source Destination Protocol Info RIPv2 Request RIPv2 Request RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response RIPv2 Response Tramas detalladas No. Time Source Destination 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: router (520), Dst Port: router (520) Routing Information Protocol ommand: 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: ( ) Next Hop: ( ) Metric: 16 No. Time Source Destination Protocol Info RIPv2 Request