Cuestión 1 Suponemos: t1 = tiempo transcurrido desde la última actualización (response) t2 = tiempo hasta llegar una nueva actualización (response) Si en enlace se recupera antes de que la ruta se invalide, o sea, antes que pasen 180s, el tiempo total de convergencia del sistema T= t1+t2 Si el enlace no se recupera y la ruta se invalida, el sistema converge utilizando otra ruta, en cuyo caso tardará T=180-t1+t2; Cuestión 2 Esta prueba la hemos hecho en el entorno virtual. El procedimiento que hemos seguido ha sido tirar la interfaz del R2 que conecta con R1 en la red 10.0.9.160/30. De esta manera simulamos que se ha roto el enlace. R1 sigue teniendo activa la interfaz que conecta con la red 10.0.9.160/30 y tratará de seguir enviando paquetes a través de esta. root@hstOfi1:/dev# traceroute 10.0.9.130 traceroute to 10.0.9.130 (10.0.9.130), 30 hops max, 40 byte packets 1 10.0.9.1 (10.0.9.1) 0.248 ms 0.217 ms 0.158 ms 2 10.0.9.162 (10.0.9.162) 0.383 ms 0.457 ms 0.279 ms 3 10.0.9.130 (10.0.9.130) 1.427 ms 0.344 ms 0.291 ms root@hstOfi1:/dev# ping 10.0.9.130 PING 10.0.9.130 (10.0.9.130) 56(84) bytes of data. 64 bytes from 10.0.9.130: icmp_seq=1 ttl=62 time=0.345 ms 64 bytes from 10.0.9.130: icmp_seq=2 ttl=62 time=1.41 ms 64 bytes from 10.0.9.130: icmp_seq=3 ttl=62 time=1.48 ms ... From 10.0.9.1 icmp_seq=9 Destination Host Unreachable #OJO primero Host Unreachable From 10.0.9.1 icmp_seq=10 Destination Host Unreachable From 10.0.9.1 icmp_seq=11 Destination Host Unreachable From 10.0.9.1 icmp_seq=12 Destination Host Unreachable From 10.0.9.1 icmp_seq=13 Destination Host Unreachable From 10.0.9.1 icmp_seq=14 Destination Host Unreachable From 10.0.9.1 icmp_seq=15 Destination Host Unreachable From 10.0.9.1 icmp_seq=16 Destination Host Unreachable ... From 10.0.9.1 icmp_seq=155 Destination Host Unreachable From 10.0.9.1 icmp_seq=155 Destination Host Unreachable From 10.0.9.1 icmp_seq=160 Destination Host Unreachable From 10.0.9.1 icmp_seq=166 Destination Net Unreachable #OJO La ruta se ha puesto como inalcanzable. 64 bytes from 10.0.9.130: icmp_seq=179 ttl=61 time=1.75 ms root@hstOfi1:/dev# traceroute 10.0.9.130 traceroute to 10.0.9.130 (10.0.9.130), 30 hops max, 40 byte packets 1 10.0.9.1 (10.0.9.1) 0.248 ms 0.217 ms 0.158 ms 2 10.0.9.166 (10.0.9.166) 0.398 ms 0.457 ms 0.297 ms 3 10.0.9.169 (10.0.9.169) 1.679 ms 0.262 ms 0.255 ms 4 10.0.9.130 (10.0.9.130) 1.432 ms 0.344 ms 0.294 ms El tiempo de convergencia ha sido aproximadamente de 176,34 segundos (2:56 min) Cuestión 3 Tardará en un rango de 0-30 segundos, dependiendo de cuando ocurrió la última actualización RIP. Cuestión 4 Debe tardar entre 0-30s, lo que tarda en llegar una actualización, pero siguiendo el procedimiento utilizado en el cálculo experimental de la cuestión 2, volvemos a levantar la interfaz de R2 que conecta con la red 10.0.9.160/30. El entorno no vuelve a converger por el camino más corto, pero al parecer es un fallo en el entorno virtual al volver a levantar la interfaz. Cuestión 5 El tiempo de convergencia será 0-30 segundos, la diferencia de tirar las interfaces con que haya fallado el enlace (como en la cuestión 2) es que al desactivar una interfaz (shutdown) el router sabe que no está disponible y directamente actualiza la tabla de enrutamiento eliminando la ruta. El sistema demora en converger lo que tarda en llegar una actualización. Cuestión 6 En este caso que también probamos en el laboratorio virtual, hemos tirado prácticamente a la vez las interfaces de R1 y R2 que conectan entre ellos a través de la red 10.0.9.160/30. root@hstOfi1:/dev# traceroute 10.0.9.130 traceroute to 10.0.9.130 (10.0.9.130), 30 hops max, 40 byte packets 1 10.0.9.1 (10.0.9.1) 0.310 ms 0.215 ms 0.173 ms 2 10.0.9.162 (10.0.9.162) 1.627 ms 0.285 ms 0.217 ms 3 10.0.9.130 (10.0.9.130) 0.652 ms 0.457 ms 0.243 ms root@hstOfi1:/dev# ping 10.0.9.130 PING 10.0.9.130 (10.0.9.130) 56(84) bytes of data. 64 bytes from 10.0.9.130: icmp_seq=1 ttl=62 time=0.610 ms 64 bytes from 10.0.9.130: icmp_seq=2 ttl=62 time=0.835 ms 64 bytes from 10.0.9.130: icmp_seq=3 ttl=62 time=0.698 ms 64 bytes from 10.0.9.130: icmp_seq=4 ttl=62 time=0.380 ms From 10.0.9.1 icmp_seq=5 Destination Net Unreachable #OJO directamente Net Unreachable From 10.0.9.1 icmp_seq=6 Destination Net Unreachable From 10.0.9.1 icmp_seq=7 Destination Net Unreachable From 10.0.9.1 icmp_seq=8 Destination Net Unreachable 64 bytes from 10.0.9.130: icmp_seq=32 ttl=61 time=0.849 ms 64 bytes from 10.0.9.130: icmp_seq=33 ttl=61 time=0.452 ms 64 bytes from 10.0.9.130: icmp_seq=34 ttl=61 time=0.932 ms 64 bytes from 10.0.9.130: icmp_seq=35 ttl=61 time=0.951 ms 64 bytes from 10.0.9.130: icmp_seq=36 ttl=61 time=1.15 ms 64 bytes from 10.0.9.130: icmp_seq=37 ttl=61 time=0.640 ms 64 bytes from 10.0.9.130: icmp_seq=38 ttl=61 time=0.797 ms 64 bytes from 10.0.9.130: icmp_seq=39 ttl=61 time=0.805 ms 64 bytes from 10.0.9.130: icmp_seq=40 ttl=61 time=1.16 ms 64 bytes from 10.0.9.130: icmp_seq=41 ttl=61 time=0.793 ms 64 bytes from 10.0.9.130: icmp_seq=42 ttl=61 time=0.876 ms 64 bytes from 10.0.9.130: icmp_seq=43 ttl=61 time=0.454 ms 64 bytes from 10.0.9.130: icmp_seq=44 ttl=61 time=0.922 ms 64 bytes from 10.0.9.130: icmp_seq=45 ttl=61 time=1.01 ms 64 bytes from 10.0.9.130: icmp_seq=46 ttl=61 time=0.833 ms --- 10.0.9.130 ping statistics --- 46 packets transmitted, 19 received, +4 errors, 58% packet loss, time 45339ms rtt min/avg/max/mdev = 0.380/0.797/1.162/0.213 ms root@hstOfi1:/dev# traceroute 10.0.9.130 traceroute to 10.0.9.130 (10.0.9.130), 30 hops max, 40 byte packets 1 10.0.9.1 (10.0.9.1) 0.427 ms 0.306 ms 0.258 ms 2 10.0.9.166 (10.0.9.166) 0.462 ms 0.600 ms 0.429 ms 3 10.0.9.169 (10.0.9.169) 0.691 ms 0.592 ms 0.406 ms 4 10.0.9.130 (10.0.9.130) 1.422 ms 0.698 ms 0.584 ms El tiempo de convergencia ha sido aproximadamente de 27s Cuestión 7 t1 = tiempo transcurrido desde la última actualización (response) t2 = tiempo hasta llegar una nueva actualización (response) Garbage-collection time = 120 segundos. El tiempo de convergencia al levantar las interfaces (no shutdown) es 0 segundos, es decir, nada más se activan. Esto ocurre mientras la ruta está guardada en la tabla de encaminamiento como ruta con métrica inalcanzable o menos, es decir, antes de que expire el temporizador “garbage-collection time” (180-t1 + garbage). En caso de que la ruta sea eliminada (pasado el periodo anterior), tardaría de 0 a 30 segundos en recibir la próxima actualización (t2) de los routers vecinos y actualizaría la tabla de rutas. Cuestión 8 El entorno no vuelve a converger por el camino más corto, debido al mismo problema que en la cuestión 4 Cuestión 9 La diferencia está en que las tablas de ruta cuando el sistema está configurado como área regular, los routers aprenden (redistribute static) que en R2 hay una ruta estática (menos distancia administrativa). Sin embargo al configurar el área como stub, ningún router origina rutas externas al dominio OSPF, con lo cual todos los routers olvidan la ruta estática (externa) aprendida , excepto R2 que está directamente conectado. El tráfico fuera del área irá por R4 que es el router de borde de área. El paquete que va desde la red oficinas 1 sale por el R2 si está configurado como área regular ya que existe una menor distancia administrativa, en cambio, si está configurado como stub sale por R4, el router de borde de área (ABR). Cuestión 10 En el hito 9, luego de establecer la configuración para que sólo se distribuya RIP entre R1, R2 y R3 y OSPF entre R3 y R4, vemos que podemos llegar a cualquier equipo de la subred de nuestra sucursal y fuera (en el laboratorio virtual probamos haciendo ping 10.0.100.100). Luego al configurar el área OSPF entre R3 y R4 como stub, lo que ocurre es que como en un área stub los router no originan rutas externas al dominio OSPF, los packetes conocen como llegar fuera de nuestra sucursal pero regresar.