iBGP AS ruta de preposición propagación

7

Tengo el siguiente escenario: Mi AS: 64501 tiene dos enrutadores R3 (Redundand) y R4 (Main).

ISP AS: 64500 tiene 3 enrutadores R1, R2 y R5

Tengo una conexión eBGP con ISP, no tengo acceso a la configuración de ISP, solo a la configuración en mi red (R3, R4).

Necesito que el tráfico entrante del ISP siempre se envíe al enrutador principal (R4) y solo si no se puede acceder a Principal, envíe el tráfico a Geo redundante (R3).

Puedo hacerlo utilizando AS-PATH Prepend enviado desde el enrutador geo-redundante (R3) y está funcionando:

Pero en este caso, el tráfico en el ISP desde R5 se envía como se muestra en la imagen (a través de R1-R2-R4): un salto más, no recto (R5-R2-R4). Esto sucede porque iBGP no está utilizando el prefijo AS-PATH, por lo que R1 prefiere la ruta a través de R2, ya que la ruta R1 <-> R3 se antepone. Pero R1 está enviando la actualización de ruta iBGP a R5 sin el antecedente as-path. Entonces, para R5 hay dos rutas iguales a Mi red, y está eligiendo la ruta a través de R1, ya que la dirección IP de R1 es menor que la IP de R2.

Pregunta n. ° 1: ¿Puedo configurar de alguna manera los dispositivos solo en Mi red, para que el tráfico pase así, sin MED o Comunidades?

Preguntas n. ° 2: ¿Puedo configurar de alguna manera los dispositivos en Mi y en la red ISP, para que el tráfico pase de esta manera, sin MED o Comunidades?

Gracias.

routing bgp

— DmitriiGangan
fuente

6

Creo que estás confundiendo enrutadores y ASes. Para BGP, un AS es un salto, no un enrutador. Puede intentar influir en un AS vecino para el par que utiliza para enviar tráfico a su AS, pero el AS vecino es libre de ignorar sus sugerencias.

Parece que su AS vecino está siguiendo su sugerencia para cuál de sus enrutadores debería usar para llegar a su AS, y podría especificar cuáles de sus rutas podrían entrar en cuál de sus enrutadores, pero no puede controlar el enrutamiento dentro del AS vecino en la medida en que pareces querer. En cualquier caso, MED no sería más efectivo que AS antes. Ambos son bastante contundentes, y ninguno le dará ningún grado de control dentro del vecino AS.

Debería trabajar con los administradores vecinos de AS para ver si puede llegar a un acuerdo. Eso puede estar usando comunidades, o puede ser algo que los administradores vecinos de AS quieran hacer por su cuenta. Simplemente no tiene control directo sobre lo que sucede en un AS diferente. Ese es el sistema autónomo en el sistema autónomo.

Pregunta n. ° 1: ¿Puedo configurar de alguna manera los dispositivos solo en Mi red, para que el tráfico pase así, sin MED o Comunidades?

Nada de lo que haga en su AS cambiará el enrutamiento interno de un AS vecino.

Preguntas n. ° 2: ¿Puedo configurar de alguna manera los dispositivos en Mi y en la red ISP, para que el tráfico pase de esta manera, sin MED o Comunidades?

No tiene la autoridad para configurar dispositivos en el AS de su vecino.

Su problema parece ser que su AS vecino prefiere enviar tráfico R5 a R1, y eso es correcto, y realmente no hay nada que pueda hacer al respecto, excepto a través de la negociación comercial. Lo que podría hacer es hacer de R3 su enrutador principal y R4 su enrutador de respaldo. Eso lograría su objetivo, al menos hasta que se encuentre en una situación de conmutación por error, momento en el que se encontrará en la misma situación en que se encuentra ahora.

— Ron Maupin
fuente

Gracias por su respuesta. En el ejemplo actual para R5, no importa si hay o no antepuestos de los clientes, el único dispositivo que está teniendo en cuenta los antepuestos son los enrutadores de borde (R1 y R2). Para R5, las rutas que vinieron de R1 son iguales a las de R2. Digamos que soy administrador de ISP y quiero que las rutas que vienen con antecedentes en R1 o R2 se propaguen dentro de iBGP (a R5) con un valor más bajo de preferencia local, por ejemplo. En ese caso, si R1 tiene rutas con prepuestos, lo enviará a R5 con Pref local menor. y por lo tanto R5 preferirá la ruta a través de R2. ¿Es posible?

— DmitriiGangan

No, esto no es verdad. Si el AS-Path no se ve alterado por los enrutadores de borde (elimine los AS privados, reemplace como o cosas como esta), el AS-Path en las actualizaciones en R5 todavía contiene el antepuesto como. Eche un vistazo al proceso de decisión de BGP para obtener más detalles: hay buenos ejemplos por ahí. Consulte mi respuesta a continuación: es posible configurar localpref en función de la longitud de la ruta de acceso y posiblemente pueda resolver su segunda pregunta.

— waza-ari

@DmitriiGangan, sus administradores de AS vecinos pueden hacer eso, pero su AS no puede hacer eso en el AS de su vecino. Es por eso que necesitaría negociar a nivel comercial. Simplemente no tiene control de lo que sucede en los AS de sus vecinos, del mismo modo que no desea que los administradores de AS de sus vecinos tengan control de lo que sucede en su AS. Como Ron Trunk y yo hemos señalado, cada AS es autónomo . Eso significa que tiene un control independiente de su propio enrutamiento. Realmente ni siquiera puede saber si es así como se enruta su tráfico dentro del vecino AS a menos que los administradores se lo hayan dicho.

— Ron Maupin

3

Solo para ampliar la respuesta de @RonMaupin:

El punto central de BGP es que el administrador de AS es quien decide cómo fluye el tráfico en su red, no usted. Puede indicar sus deseos, pero el administrador de AS puede (y a menudo lo hace) ignorarlos.

Ahora, dado que, en su ejemplo, puede ver el interior del AS64500, se pregunta por qué el tráfico fluye de la manera en que lo hace. Has asumido que iBGP ignora los prepuestos, pero ese no es el caso.

R1 recibe anuncios de R3 y R2. R3 anuncia el prefijo con los prepuestos, pero R2 no. Entonces, R1 elige la ruta más corta anunciada por R2 y eso es lo que instala en su tabla de enrutamiento.

— Ron Trunk
fuente

2

Para extender las otras dos respuestas: El problema aquí es el enrutamiento IGP dentro del AS64500. La pregunta real es, ¿por qué R5 envía el tráfico a R1 en lugar de R2?

R5 solo tiene una ruta BGP, que es la que no tiene antecedente. Esto se debe a que R1 aprende las rutas eBGP, incluidas la ruta previa y la ruta iBGP desde R2 y prefiere la ruta desde R2 debido a la ruta AS más corta (suponiendo que no se establezca peso o prefijo local). Por lo tanto, R1 solo anunciará su mejor camino a sus vecinos, R5 termina con solo conocer el camino sin publicidad.

Las rutas reales dependen del enrutamiento IGP. La actualización de enrutamiento BGP recibida por R5 contiene el campo del siguiente salto, que probablemente esté configurado en la dirección de R4 en el enlace R2-R4 o en una de las direcciones de R2 (next-hop-self configurado en R2). Este siguiente salto se resuelve utilizando el IGP configurado, que dicta el enrutamiento real del paquete.

Para responder a su segunda pregunta (apenas puede influir en las decisiones de ruta IGP en otro AS a través de su configuración BGP), eche un vistazo a R5, verifique qué próximo salto se anuncia en la actualización de enrutamiento BGP y eche un vistazo a la resolución IGP de Este próximo salto. Esto debería darle una idea bastante buena de por qué el tráfico se enruta como está actualmente. Si puede modificar la configuración BGP del ISP, también puede usar cualquier otra forma "BGPish" para lograrlo. Hay muchas formas, incluida la preferencia local.

— waza-ari
fuente

0

Bueno, si R2 tiene la mejor ruta hacia el prefijo de destino desde su AS 64501, R5 y R1 también deberían tener eso en sus tablas BGP (Regla: Todas las rutas EBGP y mejores IGBP). Entonces, si el ISP usa solo iBGP dentro de su AS, entonces el tráfico de R5 normalmente debe seguir la ruta que desea (R5-R2-R4). Lo único que creo (podría ser correcto) es que el ISP está utilizando un protocolo AD inferior en R5 (por ejemplo: ruta estática) para dirigir el tráfico hacia R1. Como comentaron otros miembros, no puede influir en el enrutamiento dentro de otro AS que no está bajo su control. También es algo extraño para mí que, ¿cómo podría darse cuenta de que el tráfico proviene de R5-R1?

— usuario36501
fuente