Reflectores de ruta BGP

En este tema, se describe el uso de reflectores de ruta BGP para simplificar la configuración y ayudar en el escalado.

En un sistema autónomo (AS) de BGP, las rutas se deben distribuir entre todos los enrutadores de borde del AS. El Protocolo de puerta de enlace de frontera (BGP) logra esto a través de sesiones de emparejamiento internas de BGP (IBGP). De forma predeterminada, las rutas aprendidas de un par de IBGP no se anuncian a otros pares de IBGP. Esta restricción requiere una malla completa de sesiones de IBGP entre todos los enrutadores del AS para garantizar una visibilidad completa de la ruta.

Sin embargo, mantener una malla completa aumenta la complejidad de la configuración y limita la escalabilidad. Cada nuevo par de IBGP debe establecer sesiones con todos los demás pares del AS. La cantidad total de sesiones necesarias para una malla completa se calcula mediante la fórmula v * (v - 1)/2, donde v representa la cantidad de pares BGP.

Además de la sobrecarga de configuración, una malla completa puede aumentar el escalado de rutas. Cada par de IBGP recibe todas las rutas, incluso si muchas no son óptimas para su ubicación en la red.

La reflexión de la ruta del BGP, definida en RFC 4456, aborda los desafíos de escalabilidad de las topologías de malla completa del IBGP. La reflexión de ruta permite que un enrutador, conocido como reflector de ruta (RR), redistribuya las rutas aprendidas de un par de IBGP a otros pares de IBGP. Esto relaja la regla predeterminada del BGP que impide el anuncio de rutas de IBGP a IBGP.

Dado que la reflexión de rutas introduce la posibilidad de bucles de enrutamiento, el RFC 4456 define dos atributos de ruta de BGP nuevos que garantizan la prevención de bucles y la selección de ruta coherente:

• ORIGINATOR_ID : identifica el ID de enrutador del vecino del BGP que anunció originalmente la ruta. El atributo ORIGINATOR_ID solo se asocia cuando la ruta se refleja por primera vez.

• CLUSTER_LIST : registra los ID de clúster de los reflectores de ruta que han reflejado la ruta a medida que se propaga por la red.

Para obtener más información sobre cómo influyen estos atributos en la selección de la mejor ruta del BGP, consulte Descripción de la selección de ruta del BGP.

Debido al requisito de malla completa del BGP interno (IBGP), la mayoría de las redes utilizan reflectores de ruta para simplificar la configuración. Mediante un reflector de ruta, los enrutadores se agrupan en clústeres, que se identifican mediante identificadores numéricos únicos para el sistema autónomo. Dentro del clúster, debe configurar una sesión de BGP desde un único enrutador (el reflector de ruta) a cada par interno. Con esta configuración, se cumple el requisito de malla completa del IBGP.

Para usar la reflexión de ruta en un AS, designe uno o más enrutadores como reflector de ruta, normalmente, uno por punto de presencia (POP). Los reflectores de ruta tienen la capacidad de volver a anunciar las rutas aprendidas de un par interno a otros pares internos. En lugar de requerir que todos los pares internos estén completamente mallados entre sí, la reflexión de ruta solo requiere que los reflectores de ruta estén completamente mallados con todos los pares internos. El reflector de ruta y todos sus pares internos forman un clúster, como se muestra en la Figura 1.

Figura 1: Topología de reflector de ruta simple (un clúster)

La Figura 1 muestra el RR del enrutador configurado como reflector de ruta para el clúster 127. Los otros enrutadores son pares internos designados dentro del clúster. Cualquiera de los pares internos anuncia las rutas del BGP al RR del enrutador. Luego, RR vuelve a anunciar esas rutas a todos los demás pares dentro del clúster.

Puede configurar varios clústeres y vincularlos configurando una malla completa de reflectores de ruta (consulte la Figura 2).

Figura 2: Reflexión básica de la ruta (varios clústeres completamente mallados)

La Figura 2 muestra los reflectores de ruta RR 1, RR 2, RR 3 y RR 4 como pares internos completamente mallados. Cuando un enrutador anuncia una ruta a RR 1, RR 1 vuelve a anunciar la ruta a los otros reflectores de ruta, los cuales, a su vez, vuelven a anunciar la ruta a los enrutadores restantes del AS. La reflexión de la ruta permite que la ruta se propague por todo el AS sin los problemas de escalabilidad creados por el requisito de malla completa.

Sin embargo, a medida que los clústeres se hacen grandes, una malla completa con un reflector de ruta se vuelve difícil de escalar, al igual que una malla completa entre reflectores de ruta. Para ayudar a compensar este problema, puede agrupar clústeres de enrutadores en clústeres de clústeres para la reflexión de rutas jerárquicas (consulte la Figura 3).

Figura 3: Reflexión de ruta jerárquica (clústeres de clústeres)

La Fig. 3 muestra RR 2, RR 3 y RR 4 como reflectores de ruta para los clústeres 127, 19 y 45, respectivamente. En lugar de mallar completamente esos reflectores de ruta, el administrador de red los configuró como parte de otro clúster (clúster 6) para el cual RR 1 es el reflector de ruta. Cuando un enrutador anuncia una ruta a RR 2, RR 2 vuelve a anunciar la ruta a todos los enrutadores de su propio clúster y, luego, vuelve a anunciar la ruta a RR 1. RR 1 vuelve a anunciar la ruta a los enrutadores de su clúster y esos enrutadores propagan la ruta hacia abajo a través de sus clústeres.

En muchas redes, los reflectores de ruta BGP se implementan para mejorar la escalabilidad, pero no están directamente involucrados en el reenvío del tráfico. Estos reflectores de ruta mantienen las funciones del plano de control del BGP sin participar en el reenvío de datos. Cuando un reflector de ruta no está en la ruta de tráfico, no necesita instalar las rutas que refleja en su tabla de reenvío. Estos dispositivos se denominan reflectores de ruta que no son de reenvío.

Puede configurar reflectores de ruta que no sean de reenvío de una de las siguientes maneras:

• Con la no-install instrucción: introducida en la versión 15.1 de Junos OS, la no-install instrucción impide que las rutas del BGP se instalen en la tabla de reenvío. Puede configurar esta opción por familia de direcciones en el siguiente nivel jerárquico:

• Uso de una política de exportación de tabla de reenvío: en versiones de Junos OS anteriores a la 15.1, puede lograr un comportamiento similar configurando una política de exportación de tabla de reenvío que rechace las rutas aprendidas del BGP.

Los reflectores de ruta que no son de reenvío ayudan a reducir la carga de recursos en dispositivos que sirven principalmente como enrutadores de plano de control, especialmente en redes de proveedores de servicios a gran escala.

En este ejemplo, se muestra cómo configurar un reflector de ruta.

El propósito de la reflexión de ruta es la prevención de bucles cuando los dispositivos de enrutamiento BGP internos (IBGP) no están completamente mallados. Para lograr esto, los RR rompen una de las reglas de la operación normal del BGP: Vuelven a anunciar las rutas aprendidas de un par BGP interno a otros pares BGP internos.

Normalmente, un solo RR es miembro de un solo clúster. Considere, por ejemplo, que en un diseño de RR jerárquico, un RR de nivel dos puede ser el cliente de un RR de nivel 1, pero no pueden ser clientes entre sí.

Sin embargo, cuando dos RR son clientes entre sí y las rutas se reflejan de un clúster a otro, solo uno de los ID de clúster se incluye en la lista de clústeres. Esto se debe a que, en este caso, tener un ID de clúster en la lista de clústeres es adecuado para la prevención de bucles.

En la tabla 1 se resumen las reglas que utilizan los reflectores de enrutamiento al rellenar la lista de clústeres de una ruta reflejada con ID de clúster.

En este ejemplo, se muestra cómo configurar un reflector de ruta (RR) que pertenece a dos clústeres diferentes. Este no es un escenario común, pero puede ser útil en algunas situaciones.

En la mayoría de las implementaciones, los reflectores de ruta del BGP funcionan exclusivamente como enrutadores internos del BGP (IBGP). Sin embargo, en algunos diseños de red, un reflector de ruta también puede funcionar como un enrutador de borde del sistema autónomo (ASBR) y mantener sesiones de emparejamiento de BGP externo (EBGP).

Cuando un enrutador de Junos OS desempeña ambas funciones y recibe una ruta de un par EBGP, se aplican consideraciones especiales si el enrutador anuncia esa ruta a pares de IBGP configurados como clientes de reflector de ruta mediante la cluster opción. En este caso, Junos OS adjunta los atributos de ruta ORIGINATOR_ID y CLUSTER_LIST al reflejar la ruta a los clientes de IBGP.

El RFC 4456, que define la reflexión de la ruta del BGP, no especifica explícitamente el comportamiento esperado para las rutas aprendidas mediante EBGP y posteriormente reflejadas a los clientes del IBGP por un ASBR de doble función y un reflector de ruta. Junos OS aplica los atributos de reflexión de ruta de forma coherente en este escenario para evitar bucles de enrutamiento y conservar la selección de ruta determinista dentro del sistema autónomo.

Al implementar la reflexión de rutas en enrutadores de borde de AS, considere detenidamente la política de enrutamiento, la selección de rutas y los escenarios de error para asegurarse de que las rutas reflejadas no introduzcan un comportamiento de enrutamiento no deseado.