Escenario 1
En este artículo mostraremos cuando y porque es buena idea implementar Route-Reflector (RR) en un esquema de BGP. Para iniciar nos basaremos en el escenario (utilizando las direcciones IP de las interfaces físicas para los BGP peering).
En un escenario donde todos los routers que se encuentran conectados directa o indirectamente y trabajando bajo un mismo sistema autónomo (AS) de BGP se le conoce como iBGP o Internal Border Gateway Protocol. Como una regla de oro, se dice que una red iBGP debe ser interconectada con una topología Full Mesh y ya veremos porque, pero mientras tanto veamos cómo funciona nuestro escenario 1.
En iBGP es recomendable utilizar las loopbacks para la creación de los peerings, debido a que las loopbacks son publicadas a traves de un NLRI (un IGP o ruta estatica) ofreciendo disponibilidad, ya que si una interface directamente conectada al router se pierde el peering puede seguir establecido, en eBGP lo recomendable es usar las direcciones IP de las interfaces que están directamente conectadas.
En nuestro ejemplo utilizaremos las direcciones IP de las interfaces directamente, con la finalidad de ver cómo funciona BGP Split Horizon, Route Reflector y posibles inconvenientes de accesibilidad.
Configuración:
Router 1
Router 2
Router 3
> La configuración de R4 la omitimos ya que esta previamente configurado para crear un eBGP peering con R1 y se advierte la loopback 0 -> 4.4.4.4/32<
Una vez configurados los equipos que conforman el iBGP, revisamos la tabla de BGP y los vecinos.
Muy bien, podemos observar que cada router conoce todos los prefijos que han sido advertidos a través de cada router, por ejemplo, todos conocen como llegar a al prefijo 4.4.4.4/32 e incluso R4 conoce como alcanzar las loopbacks de R2 y R3. Todas las entradas en las tablas de BGP son validas (>).
Ahora bien, como en muchas situaciones o casos de redes, debemos ser curiosos o saber del porqué de las cosas. Por ejemplo: Conocemos que BGP incluye únicamente la mejor ruta en la tabla de enrutamiento, no 2 ni 3 si existieran, aunque hay comandos para incluir caminos adicionales, pero eso lo platicaremos en otro artículo. Revisemos la tabla de enrutamiento de R1.
Si, por ejemplo, revisamos por donde R1 conoce la dirección IP 2.2.2.2/32 podemos observar que la conoce únicamente a través de R2 y lo mismo pasaría con la IP 3.3.3.3/32, la cual será conocida a través de R3 unicamente.
Ahora bien, que pasaría si yo deshabilito la interface FastEthernet 0/0 de R2, veamos que sucede:
R2 solo posee iBGP peering con R3 y si somos observadores, R2 ya no conoce cómo alcanzar la dirección IP 4.4.4.4/32 ubicada en R4; Uno podría decir ¿Que paso? perdió un camino pero tiene otro de respaldo que es a través de R3, debería de conocer la IP 4.4.4.4/32 a través de ese camino. Antes de explicar lo que sucedió, observemos las entradas en la tabla de BGP en R1:
Podemos observar que R1 tampoco conoce como alcanzar las direcciones IP de la loopback0 de R2, y esto se debe a lo siguiente:
> iBGP tiene un método de prevención de loops (ojo esto aplica solo a iBGP), el cual dice: si un vecino aprende un prefijo a través de otro router iBGP y este vecino lo advierte hacia mi router, el prefijo será descartado, debido a que un router iBGP no puede aceptar prefijos que incluyan en su AS-Path el mismo AS del router local (en este caso mi router)<
A este método se le conoce como BGP Split-Horizon. Es bueno aclarar puede verse similar al funcionamiento de Split Horizon de los protocolos RIP y EIGRP (Protocolos Vector Distancia) pero la diferencia es que aquí se involucra el AS-Path.
Dos o más routers iBGP que tienen peers directamente conectados como es el caso de R1 con R2, R1 con R3, R2 con R3 pueden advertir sus prefijos propios o locales con la seguridad que sus peers los recibirán y crearan las entradas en sus respectivas tablas de BGP y enrutamiento. Resumiéndolo: Los prefijos generados a partir de un solo salto son recibidos y se crean sus respectivas entradas. Pero si son prefijos generados desde de 2 o más saltos y en estos prefijos viene incluido el mismo AS del router que recibe, el prefijo será descartado para evitar posibles loops. Tal es el caso de nuestro actual escenario.
Pongamos el ejemplo si R2 tuviera habilitadas sus 2 interfaces y esta sentencia de iBGP de BGP Split Horizon no existiera, ¿Que pasaría?: Podría suceder que R2 le advierte sus loopbacks a R1, R1 se las advierte a R3 lo cual puede generar una situación no deseada ya que R2 tambien le advierte la loopbacks a R3 y R3 se las advierte a R1 y luego este a R2.
Si observamos los pasos en nuestra imagen podemos decir:
Paso 1: R4 le publica su loopback0 a R1, observemos la entrada en R1:
Paso 2: R1 le advierte el prefijo 4.4.4.4/32 a R3, este lo recibe y su AS-Path se mantiene con 4, ya que la esta recibiendo de su iBGP peer directo. Lo interesante es lo que pasa cuando R3 le advierte este prefijo a R2.
Paso 3: , R2 no lo aceptara porque en el AS-Path parece el AS 123, en algunos casos esta situación se puede visualizar a traves del comando debug: debug ip bgp updates. Y es aquí donde entran 2 metodos para evadir el BGP Split Horizon, y estos son: BGP Confederation y Route Reflector. El primero me atrevería a decir que no es muy utilizado hoy en día y suele ser mucho mas complejo que Route Reflector.
Estos metodos nos permiter evitar una topología Full Mesh en un ambiente iBGP, esto nos ayuda a minimizar costos y evitar una administración compleja (solo imaginen 50 routers en Full Mesh).
Agreguemos la loopback 0 con dirección IP 1.1.1.1/32 y la advertimos a través de BGP en R1 y veamos que sucede en R2
R3 si tiene una entrada válida en su tabla de BGP, veamos en R2:
No paso nada, no se recibe la nueva loopback de R1 ni la loopback de R4.
ROUTE REFLECTOR
Con RR nosotros podemos resolver el actual problema con R1 y R2, si queremos verlo de esta manera RR es básicamente un mediador entre los routers iBGP, por ende, no es necesario que R2 tenga una conexión directa con R1, solo basta hacer un iBGP peering con R3 e igual R1 con R3 para habilitar la comunicación.
Ahora bien, parte de un buen diseño de red es anticiparse a estas situaciones y realizar un estudio antes de implementar una nueva infraestructura de red, y hacerse algunas preguntas como:
¿Cómo fluirán los datos?
¿Cuáles seran los caminos redundantes?
¿Utilizar direcciones IP directamente conectadas o loopbacks?
¿Qué equipos recibiran más tráfico?
¿Comó hacer mi infraestructura escalable?
etc.
Antes de seguir debemos conocer que existen 3 tipos de routers en un esquema de RR:
- Route Reflector Server: es básicamente el mediador entre los routers que participan en el iBGP.
- Router Reflector cliente: Son los routers como R2 que no tienen un peering directo con sus vecinos.
- No iBGP Router Reflector cliente: Todo router que tiene una conexión con el Route Reflector Server pero no participa en la configuración de RR.
- Basado en lo anterior existen 3 reglas, las cuales son:
Regla_1: Si un prefijo (red o host) es aprendida a través de un router que es iBGP route-reflector cliente este puede publicar el prefijo a todo mundo, ya sea este un router eBGP, un iBGP route-reflector cliente y a vecinos iBGP no clientes.
Regla_2: Si un prefijo es conocido por un vecino que no es cliente route-reflector, este puede publicar el prefijo a todo mundo excepto a otro vecino iBGP que no es cliente. Esto debido al BGP Split Horizon.
Regla_3: Si un prefijo es conocido a través de un router eBGP este puede publicarlo a través a todo mundo, igual que la regla 1.
Si deseamos recibir un prefijo externo (eBGP) el cual es aprendido por un router iBGP RR Cliente y el cual tiene eBGP peering (como R1 y R2), es importante que ese prefijo sea publicado internamente como válido de lo contrario el RR Server no lo transmitira a los otros iBGP RR Clientes. Para que sea valido este iBGP RR cliente que tiene un eBGP peering debe utilizar el comando Next-Hop-Self hacia su RR Server (neighbor 10.13.0.2 next-hop-self)
Muy bien, ahora que ya sabemos como funciona RR, podemos aplicarlo en nuestro esquema, ¿Cual consideran que sería nuestro RR Server? .... Correcto en nuestro caso sería R3 ya que es el router que conecta a R1 y R2.
Cabe mencionar que existen muchos tipos situaciones donde podemos aplicar RR, ejemplo: si hay un NLRI (Network Layer Reachability Information) que es básicamente el uso de un protocolo IGP como RIP, OSPF, EIGRP, etc, utilizando loopbacks para la creación de los iBGP peerings en lugar de las direcciones IP de las interfaces físicas (como hemos hecho en nuestro escenario) , que el router RR Server es el router de borde, etc, podemos encontrarnos con varios esquemas. Ahora bien, es importante definir cuál sera nuestro RR Server, este debe ser un router robusto en sus características, throughput, memoria, CPU, capacidad de interfaces, etc. La ubicación o instalación de los routers que funcionaran como RR Servers depende mucho de la infraestructura, pero en la mayoría de ocasiones son instalados detrás de los routers de borde, pero reitero mucho depende del tipo de equipo y la infraestructura.
Aplicando nuestra solución, como observaran la configuración es muy sencilla, esto se realiza unicamente en el RR Server (en este caso R3), se agrega el comando: route-reflector-client en los peerings con los routers que se interconectaran en este caso R1 y R2. Este proceso realizara un reset de los peerings.
Una vez implementado podemos verificar si conocemos los prefijos de nuestros vecinos RR Clientes:
Se observa que tanto el prefijo 2.2.2.2/32 y 4.4.4.4/32 son conocidos a través de RR Clientes (R2 y R1 respectivamente).
El debug ip bgp 10.13.0.2 updates en R1 mostro lo siguiente:
R1 recibio una actualización de ya aparecen las direcciones de R2. Veamos si esto solvento nuestro inconveniente con R1 y R2:
Podemos observar que funciono, y que los respectivos prefijos remotos son conocidos a través del router que publica las redes, por ejemplo, el siguiente salto de R1 para alcanzar la IP 2.2.2.2/32 o 22.22.22.22/32 es la IP 10.23.0.1 (R2) y el siguiente salto de R2 para alcanzar la IP 4.4.4.4/32 es el siguiente salto 10.13.0.1 (R1). Por ende, un ping ya será satisfactorio:
La comunicación es satisfactoria!
Para finalizar cabe mencionar que, si no hubiéramos utilizado OSPF para que los routers conocieran todas las redes utilizadas para la conexión punto a punto entre los routers, hubiéramos tenido inconvenientes entre R1 y R2 aun implementando RR, para solventar eso R3 tendría que advertir a través de BGP las redes 10.13.0.0/30 y 10.23.0.0/30, a pesar de que no es un esquema que me gustaría recomendar.
Ejemplo, eliminemos OSPF en R3 y veamos que sucede con los prefijos remotos que conoce R1 y R2:
Podemos observar que, si se dejan de conocer las redes que hacen la conexión punto a punto en los routers, las redes remotas se siguen conociendo a través del RR pero son inaccesibles lo que genera entradas invalidas (sin >), por ende un ping, un traceroute no podría ser satisfactorios ya que no hay manera de habilitar la comunicación hasta que se establezca el IGP o se publiquen a través de BGP las redes de los punto a punto.
También mencionar que para tener un esquema de alta disponibilidad se pueden instalar 2 o más RR servers, donde el Router con menor BGP router-id será preferido como el path primario o también se pueden utilizar los Atributos de BGP para la selección de caminos. En la implementación de mas RR Servers se recomienda utilizar BGP Cluster-ID para mantener un orden y evitar loops.
