Enrutar el tráfico a través de diferentes enlaces desde el mismo BGP AS


19

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 .

AS 65000 y 65001

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.


Hola Jeremy: hay dos buenas soluciones para esto a continuación, pero no puedo suponer con seguridad que tienes control administrativo sobre el IGP. ¿Puedes aclarar eso?
John Jensen

No hay IGP en este escenario. Esto es realmente representativo de un solo VRF dentro de una red mucho más grande; cuyos detalles he dejado de lado por razones de claridad.
Jeremy Stretch

De eso tenía miedo. :-) Gracias por aclararlo.
John Jensen

Algo falta aquí, creo; ¿Entonces dos asumimos que hay un enlace (posiblemente muchos, debido a múltiples enrutadores internos?) Entre A y B dentro de AS 65000? Además, ¿qué estás viendo que es subóptimo? ¿A / o muchos enrutadores más cercanos a A (topológicamente hablando) envían tráfico a través de B, para llegar a C?
jwbensley

@javano el problema es que tanto A como B (los enrutadores de borde) son pares iBGP en el mismo ASN, por lo tanto, cualquier prefijo (s) aprendido de C en cualquiera de los dos tendrá 2 rutas en el RIB en ambas cajas, y la ruta eBGP tendrá siempre gana, por lo que el tráfico saliente de AS6500 a AS65001 se atasca en un enlace.
John Jensen

Respuestas:


12

¿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.


1
Esta es probablemente la mejor manera de hacerlo, pero si Jeremy está anunciando un resumen único de C, entonces tendrá que dividirlo en trozos para que esto funcione de manera efectiva.
John Jensen

Creo que este es el camino que voy a tomar. Tendré que estudiarlo mañana y ver si me engancho en algún lado.
Jeremy Stretch

@JohnJensen no debería haber ninguna necesidad de esto, ya que tanto el sitio A como el B recibirán los mismos prefijos del operador y, por lo tanto, pueden hacer modificaciones a sus propios prefijos de 'sitios' con el interruptor de desempate llegando al LP.
David Rothera

1
Como una nota adicional al pensarlo más, podría ser mejor usar un atributo localmente significativo como el peso en lugar de uno transitivo como LP.
David Rothera

1
@DavidRothera Si se anuncian múltiples prefijos desde C, estaría en lo correcto: es posible que solo pueda haber un prefijo proveniente de C, en cuyo caso no estoy completamente seguro de que establecer localpref con una comunidad haga la diferencia para resolver el problema de Jeremy, debido a que hay un solo prefijo con una opción de dos comunidades y dos valores de LP diferentes, se preferirá el LP más alto y el tráfico aún se fijará en un enlace. También estoy de acuerdo en que usar un atributo localmente significativo puede ser mejor aquí.
John Jensen

6

ingrese la descripción de la imagen aquíCuando hice algo similar, no usé eBGP entre los enrutadores. Hice que el enrutador de habla BGP solo enviara la ruta predeterminada a los enrutadores del sitio A y del sitio B a través de OSPF y luego redistribuya las rutas de OSPF en BGP. En el enlace entre los dos sitios apliqué un costo OSPF.

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.


3

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.


2

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.


Sí, esa sería la mejor manera que imagino, suponiendo que tengas la capacidad de usar un IGP. Lamentablemente ese no es mi caso. :( He actualizado la pregunta para incluir este detalle descuidado.
Jeremy Stretch

Me gusta la respuesta de David Rothera, ya que es la misma que la mía, pero añade el detalle de la utilización de las comunidades :)
netdad
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.