¿Por qué BGP RR solo refleja el mejor camino?


15

¿Alguien puede responder por qué BGP RR solo refleja el mejor camino?


¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


18

Para conservar la memoria en el destino, no era importante optimizar el camino de reenvío en el pasado. Esta es una cita de RFC4456 :

Uno de los componentes clave del enfoque de reflexión de ruta al
abordar el problema de escalamiento es que el RR resume la
información de ruta y solo refleja su mejor ruta.

Si bien el escalado siempre es importante, claramente hay escenarios actuales en los que preferimos gastar memoria RIB que elegir una ruta subóptima.

Para abordar este problema, hay BGP AddPath y BGP una reflexión óptima . AddPath está disponible tanto en Cisco como en Juniper, mientras que los proveedores principales no implementan actualmente una reflexión óptima.

AddPath permite que BGP envíe más de la mejor ruta. La reflexión óptima utilizará SPF (ISIS, OSPF) para reflejar la mejor ruta desde el punto de vista del receptor, no desde el punto de vista de los reflectores de ruta.


3

Tenga en cuenta que la idea con iBGP y la reflexión de ruta ha sido distribuir información de ruta con la idea de que las decisiones específicas de enrutamiento / reenvío serían acomodadas por el IGP subyacente (particularmente incluyendo rutas múltiples, conmutación por error interna, etc.). Como tal, un puntero a lo que debería ser los próximos saltos bastante estáticos puede mantenerse en la tabla mientras se evita la rotación asociada con la información de red localizada.

La escalabilidad y la estabilidad fueron (y posiblemente deberían ser) los objetivos principales de BGP, incluso al precio de la elección de ruta subóptima y la convergencia rápida. La implementación tradicional del RR lo resume. Idealmente, la información sobre los RR debe ser lo más estática posible y los temporizadores deben mantenerse en el lado largo.

Por cierto: hay circunstancias en las que un RR puede enviar múltiples rutas al mismo destino v4 / v6, tanto la función AddPath mencionada anteriormente como en el caso de MPLS VPN donde un prefijo dado está asociado con los RD de múltiples PE.


No estoy seguro de que agregaría RR con los objetivos de diseño originales de iBGP (sobre los cuales tiene toda la razón, especialmente con respecto a la escalabilidad y la estabilidad); RR se propuso en un RFC separado para aliviar los problemas de escalado que alguien tendría con la malla completa iBGP y el deseo de deshabilitar la sincronización. De lo contrario, una gran respuesta, y votó como tal.
John Jensen

Me gustaría señalar que el prefijo con RD diferente es un prefijo único , el reflector no tiene idea de que no será único en el receptor PE en el receptor VRF. Esta es exactamente la función de RD, sin ella, no podría tener prefijos superpuestos en VRF.
ytti

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.