El problema principal con los protocolos de enrutamiento de vector de distancia ( DVR ) son los bucles de enrutamiento, ya que el algoritmo Bellman-Ford no puede evitar los bucles. Este bucle de enrutamiento en la red DVR provoca el problema de la cuenta hasta el infinito. Los bucles de enrutamiento generalmente ocurren cuando una interfaz falla o dos enrutadores envían actualizaciones al mismo tiempo.
Problema de contar hasta el infinito:
Entonces, en este ejemplo, el algoritmo Bellman-Ford convergerá para cada enrutador, tendrán entradas entre sí. B sabrá que puede llegar a C a un costo de 1 y A sabrá que puede llegar a C a través de B a un costo de 2.
Si el enlace entre B y C se desconecta, B sabrá que ya no puede llegar a C a través de ese enlace y lo eliminará de su tabla. Antes de que pueda enviar actualizaciones, es posible que reciba una actualización de A que anunciará que puede llegar a C a un costo de 2. B puede llegar a A a un costo de 1, por lo que actualizará una ruta a C a través de A a un costo de 3. A luego recibirá actualizaciones de B más tarde y actualizará su costo a 4. Luego continuarán alimentándose mutuamente con información incorrecta hacia el infinito, lo que se conoce como el problema Count to Infinity .
Solución para el problema de Contar hasta el infinito: –
Envenenamiento de ruta:
cuando falla una ruta, los protocolos de vector de distancia difunden las malas noticias sobre una falla de ruta envenenando la ruta. El envenenamiento de rutas se refiere a la práctica de anunciar una ruta, pero con un valor métrico especial llamado Infinito. Los enrutadores consideran que las rutas anunciadas con una métrica infinita han fallado. Cada protocolo de enrutamiento por vector de distancia utiliza el concepto de un valor métrico real que representa el infinito. RIP define el infinito como 16. La principal desventaja del veneno inverso es que puede aumentar significativamente el tamaño de los anuncios de enrutamiento en ciertas topologías de red bastante comunes.
Horizonte dividido:
si el enlace entre B y C falla, y B ha recibido una ruta de A, B podría terminar usando esa ruta a través de A. A enviaría el paquete de regreso a B, creando un bucle. Pero de acuerdo con la regla del horizonte dividido, el Node A no anuncia su ruta para C (es decir, de A a B a C) de regreso a B. En la superficie, esto parece redundante ya que B nunca enrutará a través del Node A porque la ruta cuesta más de la ruta directa de B a C.
Considere la siguiente topología de red que muestra Split horizon-
- Además de estos, también podemos usar el horizonte dividido con el envenenamiento de rutas donde ambas técnicas se usarán combinadas para lograr eficiencia y menos aumentar el tamaño de los anuncios de enrutamiento.
- El protocolo de información de enrutamiento (RIP) utiliza la técnica de horizonte dividido con veneno inverso para reducir los bucles de enrutamiento. Además, se pueden utilizar temporizadores de espera para evitar la formación de bucles. El temporizador de espera se inicia inmediatamente cuando se informa al enrutador que el enlace adjunto está caído. Hasta este momento, el enrutador ignora todas las actualizaciones de la ruta descendente a menos que reciba una actualización del enrutador de ese enlace caído. Durante el temporizador, si se puede volver a acceder al enlace descendente, se puede actualizar la tabla de enrutamiento.
Referencias:
https://en.wikipedia.org/wiki/Distance-vector_routing_protocol#Count-to-infinity_problem
https://en.wikipedia.org/wiki/Route_poisoning
https://en.wikipedia.org/wiki/Split_horizon_route_advertisement
Este artículo es una contribución de Akash Sharan . Si te gusta GeeksforGeeks y te gustaría contribuir, también puedes escribir un artículo usando write.geeksforgeeks.org o enviar tu artículo por correo a review-team@geeksforgeeks.org. Vea su artículo que aparece en la página principal de GeeksforGeeks y ayude a otros Geeks.
Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.
Publicación traducida automáticamente
Artículo escrito por GeeksforGeeks-1 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA