RIPv2
- Protocolo de vector distancia.
- Apto para enrutar redes pequeñas a medianas.
- Velocidad de convergencia media.
- Soporta VLSM.
- Soporta CIDR.
- Estándar (soporta redes multi-vendor).
- Dirección de multicast de las actualizaciones: 224.0.0.9
- Distancia administrativa: 120.
- Conocimientos requeridos para su administración: pocos.
- Protocolo de vector distancia avanzado.
- Apto para enrutar redes grandes.
- Velocidad de convergencia muy alta.
- Soporta VLSM.
- Soporta CIDR.
- Propietario de Cisco.
- Dirección de multicast de las actualizaciones: 224.0.0.10
- Distancia administrativa: interno 90, externo 170.
- Conocimientos requeridos para su administración: buenos.
- Protocolo de estado de enlace.
- Apto para enrutar redes grandes.
- Velocidad de convergencia alta.
- Soporta VLSM.
- Soporta CIDR.
- Estándar (soporta redes multi-vendor).
- Dirección de multicast de las actualizaciones: 224.0.0.5 / 224.0.0.6
- Distancia administrativa: 110.
- Conocimientos requeridos para su administración: buenos.
- Protocolo de estado de enlace.
- Apto para enrutar redes grandes.
- Velocidad de convergencia alta.
- Soporta VLSM.
- Soporta CIDR.
- Estándar OSI (soporta redes multi-vendor).
- Distancia administrativa: 115.
- Conocimiento requeridos para su administración: muy buenos.
- Protocolo de vector ruta.
- Apto para Internet.
- Velocidad de convergencia: baja.
- Soporta VLSM.
- Soporta CIDR.
- Estándar (soporta redes multi-vendor).
- Actualizaciones por unicast.
- Distancia administrativa: eBGP 20, iBGP 200.
- Conocimientos requeridos para su administración: muy buenos.
Enlaces de Interés:
- Post: Protocolos de enrutamiento
- Post: EIGRP - Conceptos básicos
- Post: Introducción a BGP4
- Post: Introducción a OSPF
- Post: Principios básicos de RIPv2
- Post: Distancia administrativa
- Post: Redistribución de rutas
¿Tenés alguna información o comentario para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta
Tenía entendido que el tiempo de convergencia de RIP era el más alto de todos estos protocolos, de ahí que se limitase a 15 saltos.
ResponderBorrarEl tiempo de convergencia y la cantidad de saltos en RIP no están directamente relacionados.
ResponderBorrarEl límite en la cantidad de saltos obedece a uno de los mecanismos para solucionar la formación de bucles de enrutamiento llamado cuenta al infinito, y que en el caso de RIP está fijado en 15 saltos. Todo destino a más de 15 saltos es considerado inalcanzable.
Por supuesto que cuanto más grande y compleja es la topología de una red, más difícil es su convergencia, y esto puede hacerlo más lenta. Pero no es esa la causa de la velocidad comparativa de un protocolo respecto de otro.
Pero si el motivo es sólo ese por qué no 14 o 16 o 17 por qué 15 ¿Es correcto el cálculo que los dos router más alejados en una red de 15 routers tardarían 7 minutos en conocer sus rutas 30 segundos x 15.
ResponderBorrarPorqué se tomó la referencia de 15 saltos, lo desconozco.
ResponderBorrarEl cálculo de 7 minutos es correcto en el peor escenario posible ya que debés considerar que todos los routers de la ruta reciben el update en el instante en que cada uno de ellos está enviando su propio update.
Pero esto no es así en un contexto IOS, ya que IOS incluye para RIP actualizaciones por eventos, con lo que cuando un router recibe una actualización que cambia la tabla de ruteo, inmediatamente la comunica a sus vecinos. Con lo que en ese caso la convergencia puede darse en un minuto dependiendo de la velocidad de la interfaces y la capacidad de procesamiento.
En campo, cuando se trata de redes pequeñas, es posible que RIP sea más rápido para converger que los otros protocolos.
Oscar, Muchas gracias por todo. Las actualizaciones por eventos no lo entiendo bien. Si yo tengo dos routers en hsrp uno bakcup del otro. El principal se cae, por lo que el respaldo anuncia la red con peor métrica (configurado para que anuncie con peor métrica), pero ¿El respaldo lo anuncia desde el mismo momento en que se realiza el cambio de HSRP o espera a que le toque enviar una actualizacion? Es decir si el principal acaba de anunciar la red en el momento en que se cae, el respaldo lo anuncia en el mismo momento en que toma el control o lo hace a los 30 segundos ya que el principal acaba de mandar una. Espero haber explicado mi duda correctamente. Gracias.
BorrarLa actualización por eventos refiere a que cuando se produce cualquier situación que involucra una actualización de la propia tabla de enrutamiento (por caída de una interfaz o por recálculo de una ruta), inmediatamente se dispara una actualización informando de este cambio sin esperar que se venza el tiempo de actualización de los temporizadores.
BorrarPero esto está referido a protocolos de enrutamiento, no a HSRP que es un FHRP (no un protocolo de enrutamiento), y opera independientemente del enrutamiento.
Creo que no me he explicado bien. Si yo tengo varios routers conectados a un switch, cada router representa una oficina y se cae la unica interfaz con la que habla rip con los demás. ¿Como detectan los demás que ha caido? Porque en Rip no hay paquetes hello ni adyacencias. He visto poca informacion respecto a la actualizacion disparada por eventos para RIP en el ambito CISCO.
BorrarLa caida de la interfaz provoca una actualización desencadenada por el evento, pero evidentemente esa actualización no puede enviarse a través de la interfaz que ahora está down, sino solamente por las demás.
BorrarEn consecuencia, los demás routers conectados a través de la interfaz que acaba de caer, si no tienen activado algún mecanismo que les permita detectar este evento (por ejemplo un IP SLA), detectarán la ausencia de ese vecino cuando venza el temporizador de time out.
Ok es algo que no entendia clarmante pero si yo tengo un respaldo con un mecanismo de HSRP (track a la wan) que asuma el control en caso de caida del principal y anuncie las redes con peor métrica. Eso desencadenaríaa la actualizacion por eventos o solo por temportizador. ¿El router de respaldo anuncia las rutas en el mismo momento que toma el control o cuando venza el timeout?
BorrarMuchas Gracias
Insisto en mi respuesta anterior.
BorrarHSRP es un protocolo de administración de redundancia en el gateway de la LAN, y no impacta ni influencia en la operación de cualquier protocolo de enrutamiento, que es totalmente independiente.
HSRP no sube ni baja interfaces, solamente cambia el router "activo", es decir, el dispositivo que responde las solicitudes ARP que se dirigen a la IP virtual definida como gateway de la red.
El cambio de standby a activo no tiene ningún impacto en el enrutamiento. Ambos dispositivos tienen sus procesos de enrutamiento independientes y mantienen sus tablas de acuerdo a la lógica del protocolo que se haya configurado.
A ver si logro explicarme o enteder bien esta ultima parte. Yo tengo dos routers con rip uno configurado con un offset-list 0 out 2 para penalizar sus anuncios, además esos routers estan configurados en HSRP, en la LAN de tal forma que el que no tiene ninguna penalizacion es el activo y el que tiene el ofsset-list es standby en el grupo de HSRP (que se que es para redundancia de LAN). Si yo apago el router que está activo (le doy al interruptor de apagado). El router q es standby pasa a ser active y es el unico que se puede comunicar con el exterior, pero anuncia las mismas redes que el otro equipo, aunque con peor métrica. En el momento en que yo apague el router activo, esto se considera sufuciente para disparar las actualizaciones por eventos o puesto que tengo un respaldo, aunque sea penalizado, esperara a que venza el timeout. Estamos hablando de que si se cae una LAN se desencadena una actualizacion de rip. ¿Pero el caso que expongo desencadenaría este tipo de actualización?
BorrarEl router que apagas, no genera él mismo actualizaciones ya que ha sido apagado y no produce en consecuencia ningún tipo de información de enrutamiento.
BorrarLos que podrían generar actualizaciones por eventos son los routers vecinos que se encuentran directamente conectados. Esto dependerá de que las interfaces que los conectan con el dispositivo que apagaste pasen a estado de down (y esto depende obviamente de la tecnología que da conectividad entre ambos equipos).
Si la interfaz que conectaba al router apagado pasa a estado de down, esto produce una actualización por evento e inmediatamente se comunica que esa ruta ya no está disponible; si la interfaz no pasa a estado de down, el proceso de enrutamiento tomará noticia de que esta ruta ya no está disponible recién cuando venzan los temporizadores.
Ahora... en una implementación tan compleja, ¿es RIP una buena elección?
Parece que no es buena decision que sea RIP y creo que te voy entendiendo.Aunque yo tenga un respaldo que anuncie lo mismo que anuncia el router apagado (aunque con peor métrica) no se considera un actualizacion por eventos, porque el que deberia generar los eventos, es el principal no el respaldo aunque asuma el estado activo de HSRP, es el principal el que debe comunicar los eventos no el respaldo, aunque este haya asumido las funciones del principal, al no ser el router con problemas, debe esperar a que venzan los temporizadores. ¿Pero cuando los demas routers reciban una actualizacion con peor métrica por la misma interfaz que antes, que haran? Porque al no haber detectado la caida, puesto que la interfaz, por la que se comunicaban no ha pasado a down ( estan conectados a un switch) el temporizador de espera no se ha activado, por tanto la incorporarán inmediatamente, entiendo. Gracias Oscar, a veces RIP no es un protocolo tan sencillo como parece.
BorrarHabría que hacer un laboratorio reproduciendo la topología para estar seguros, pero a mi parecer, en tu caso particular (todos están conectados a un mismo switch y en consecuencia las actualizaciones de primario y secundario de HSRP se reciben por la misma interfaz), siempre esperará que se venzan los temporizadores porque la ruta alternativa tiene peor métrica y se recibe por la misma interfaz.
Borrar