Tengo dos sitios, A y B, en BGP AS 65000, y un tercer sitio, C, en AS 65001. Los tres sitios tienen conectividad a través del operador MPLS y hay conectividad interna entre los sitios A y B. Estoy tratando de influir en BGP de modo que el tráfico del sitio A al sitio C se enrutará a través del enlace MPLS del sitio A, y el tráfico del sitio B al sitio C se enrutará a través del enlace MPLS del sitio B. La topología es similar a la que se describe en este ejemplo .
Los enrutadores de borde en los sitios A y B verán su propio enlace MPLS como la mejor ruta, porque las rutas EBGP son preferibles a las rutas IBGP. Sin embargo, los enrutadores más dentro de AS 65000 preferirán un enlace u otro. Mi objetivo es obligar a todos los enrutadores en cualquiera de los sitios a preferir el enlace más cercano. (Desafortunadamente, no puedo dividir los dos sitios en ASes separados en este momento).
¿Hay alguna forma sensata de lograr esto mientras se permite la conectividad de conmutación por error al sitio C entre los enlaces del sitio A y B?
Editar: debería haber notado que no hay IGP en uso aquí. De hecho, las redes en cada sitio existen dentro de un VRF como parte de una red mucho, mucho más grande. Como tal, cualquier solución debe depender completamente de BGP.
Respuestas:
¿Existe una definición clara entre el sitio A y el sitio B?
Si es así, trataría de definir una política en los enrutadores de borde para inyectar una comunidad al recibir rutas del operador MPLS.
Una vez que esta comunidad se ha colocado en los prefijos (digamos 100: 1 para el sitio A y 100: 2 para el sitio B), puede agregar una política a cada uno de los enrutadores del sitio A para aumentar el LP para cualquier ruta con la comunidad 100: 1 y asimismo para el sitio B con la comunidad 100: 2.
Esta solución cumpliría con el requisito de usar solo BGP y también sería lo suficientemente flexible como para permitir que B siga usando el enlace ascendente de A si pierde su propio enlace ascendente con el operador.
fuente
Esto permite que el sitio A tenga rutas a sus redes, redes del sitio B y una ruta predeterminada para salir del sitio A (el costo OSPF mantiene la ruta predeterminada del sitio B como una opción secundaria si pierde el enlace del sitio A). El sitio A se comunicará directamente con el sitio B, sin usar MPLS a menos que haya un error de enlace entre los sitios.
Además, los costos de OSPF se traducen en BGP MED durante la redistribución, lo que hace que la red MPLS del operador prefiera enviar tráfico del sitio A directamente al sitio A, pero también use el sitio B para llegar al sitio A si es necesario.
fuente
Siento que falta información. ¿Por qué los enrutadores de borde ya no prefieren la mejor ruta?
¿Tiene iBGP de malla completa en 65000? ¿O estás usando la ruta de reflexión?
Si tiene iBGP de malla completa, cada enrutador de borde aprende la ruta de ambos [AB] y recurrirá a comparar el costo de IGP con el siguiente salto, que debería traducirse al cuadro de borde más cercano.
Si hay una ruta reflejada en su lugar, solo reflejará la mejor ruta desde su propio POV, lo que puede eliminar la mejor ruta de reenvío. Esto también se puede solucionar agregando otro RR que elegirá la otra ruta como mejor, luego los cuadros de borde una vez más pueden elegir la mejor ruta. Si la fijación de RR no es posible de esta manera. Puede agregar la misma dirección IPV4 en ambos bucles de rutas fronterizas, y cuando los enrutadores fronterizos anuncian el prefijo a RR, configuran el siguiente salto a esta dirección de difusión ilimitada. Luego, incluso después de la reflexión, seguirás IGP hasta el borde más cercano.
fuente
Si tiene control sobre el IGP:
Lo que hemos hecho es tener solo enrutadores eBGP en la malla iBGP. El resto de nuestros enrutadores internos son enrutadores OSPF. Redistribuimos de BGP a OSPF dentro de cada AS. Nuestra configuración es un poco diferente a la suya, pero esto debería permitir que la métrica de costos de OSPF influya en el camino que toma el tráfico al dirigirlo al enrutador eBGP más cercano.
Si no tiene control sobre el IGP:
Quizás pueda aplicar una política de importación a los enrutadores internos para que prefieran estáticamente los anuncios de ruta del enrutador eBGP de salida deseado. Entonces, por ejemplo, si iBGP contiene dos anuncios para un prefijo dado (uno del enrutador del sitio A y otro del enrutador del sitio B, pero solo uno está instalado en la RIB), entonces podría hacer un prefijo local del anuncio deseado tal como aparece. adentro. Tendría que prepararlo, pero no veo por qué no funcionaría.
fuente