Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Reflectores de ruta bgp

Descripción de los reflectores de ruta del BGP

En este tema se analiza el uso de reflectores de ruta para simplificar la configuración y ayudar a escalar. Otra forma de reducir la carga de trabajo en un reflector de ruta que no se encuentra en la ruta de reenvío de tráfico es usar la no-install instrucción en el [edit protocols bgp family family-name] nivel jerárquico. A partir de Junos OS versión 15.1, la instrucción elimina la no-install interacción entre el demonio de protocolos de enrutamiento (rpd) y otros componentes del sistema Junos, como el kernel o el demonio de firewall distribuido (dfwd). Esta interacción se elimina al prohibir que cualquier ruta de las bases de información de enrutamiento rpd asociadas (RIB), también conocidas como tablas de enrutamiento, se publique en esos componentes.

Nota:

En las versiones anteriores a Junos OS versión 15.1, puede reducir la carga de trabajo en un reflector de ruta que no se encuentra en la ruta de reenvío de tráfico mediante una política de exportación de tabla de reenvío que rechaza las rutas aprendidas del BGP.

Debido al requisito interno de malla completa del BGP (IBGP), la mayoría de las redes utilizan reflectores de ruta para simplificar la configuración. La fórmula para calcular el número de sesiones necesarias para una malla completa es v * (v - 1)/2, donde v es la cantidad de dispositivos habilitados para BGP. El modelo de malla completa no escala bien. Con un reflector de ruta, agrupa enrutadores en clústeres que se identifican mediante identificadores numéricos únicos del sistema autónomo (AS). Dentro del clúster, debe configurar una sesión bgp desde un solo 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, por lo general, uno por punto de presencia (POP). Los reflectores de ruta tienen la capacidad especial del BGP de leer las rutas aprendidas de un par interno a otros pares internos. Por lo tanto, en lugar de requerir que todos los pares internos estén completamente mallados entre sí, la reflexión de ruta solo requiere que el reflector de ruta esté completamente mallado con todos los pares internos. El reflector de ruta y todos sus pares internos forman un clúster, como se muestra en Figura 1.

Nota:

Para algunos dispositivos de Juniper Networks, debe tener instalada una licencia de función bgp avanzada en cada dispositivo que use un reflector de ruta. Para obtener más información sobre la licencia, consulte la Guía de instalación y actualización de software.

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

Figura 1 muestra el RR del enrutador configurado como reflector de ruta para el clúster 127. Los otros enrutadores se designan pares internos dentro del clúster. Cualquiera de los pares internos anuncia las rutas BGP al RR del enrutador. A continuación, RR readvierte esas rutas a todos los demás pares del clúster.

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

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

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 readvierte la ruta a los otros reflectores de ruta, lo que, a su vez, readvierte la ruta a los enrutadores restantes del AS. La reflexión de ruta permite que la ruta se propague por todo el AS sin los problemas de escalabilidad creados por el requisito de malla completa.

Nota:

Un reflector de ruta que admite varios clústeres no acepta una ruta con el mismo ID de clúster de un enrutador que no es cliente. Por lo tanto, debe configurar un ID de clúster diferente para un RR redundante para reflejar la ruta a otros clústeres.

Sin embargo, a medida que los clústeres se vuelven 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 para una reflexión jerárquica de rutas (consulte Figura 3).

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

Figura 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 por completo esos reflectores de ruta, el administrador de red los ha configurado 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 readvierte la ruta a todos los enrutadores dentro de su propio clúster y, luego, readvierte la ruta a RR 1. RR 1 readvierte la ruta a los enrutadores de su clúster, y esos enrutadores propagan la ruta hacia abajo a través de sus clústeres.

Ejemplo: Configuración de un reflector de ruta

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

Requisitos

No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar este ejemplo.

Descripción general

Por lo general, los dispositivos internos habilitados para BGP (IBGP) deben estar completamente mallados, ya que el IBGP no readvierte las actualizaciones a otros dispositivos habilitados para IBGP. La malla completa es una malla lógica lograda mediante la configuración de varias neighbor instrucciones en cada dispositivo habilitado para IBGP. La malla completa no es necesariamente una malla completa física. Mantener una malla completa (lógica o física) no se escala bien en implementaciones de gran tamaño.

Figura 4 muestra una red IBGP con el dispositivo A que actúa como reflector de ruta. Los dispositivos B y C son clientes del reflector de ruta. Los dispositivos D y E están fuera del clúster, por lo que no son clientes del reflector de ruta.

En el dispositivo A (el reflector de ruta), debe formar relaciones par con todos los dispositivos habilitados para IBGP incluyendo la neighbor instrucción para los clientes (dispositivo B y C) y los noclientes (dispositivo D y dispositivo E). También debe incluir la cluster instrucción y un identificador de clúster. El identificador de clúster puede ser cualquier valor de 32 bits. En este ejemplo, se utiliza la dirección IP de interfaz de circuito cerrado del reflector de ruta.

En los dispositivos B y C, los clientes del reflector de ruta, solo necesita una neighbor instrucción que forme una relación par con el reflector de ruta, el dispositivo A.

En los dispositivos D y E, los noclientes, necesita una neighbor instrucción para cada dispositivo no cliente (D-a-E y E-a-D). También necesita una neighbor instrucción para el reflector de ruta (D-a-A y E-a-A). Los dispositivos D y E no necesitan neighbor instrucciones para los dispositivos del cliente (dispositivo B y C).

Consejo:

Los dispositivos D y E se consideran noclientes porque han configurado explícitamente relaciones par entre sí. Para convertirlos en clientes reflectores RRroute, quite la neighbor 192.168.5.5 instrucción de la configuración en el dispositivo D y quite la neighbor 192.168.0.1 instrucción de la configuración en el dispositivo E.

Figura 4: Red IBGP mediante un reflector de rutaRed IBGP mediante un reflector de ruta

Configuración

Procedimiento

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.

Dispositivo A

Dispositivo B

Dispositivo C

Dispositivo D

Dispositivo E

Procedimiento paso a paso

Configuración del reflector de ruta

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el IBGP en la red mediante el dispositivo A de Juniper Networks como reflector de ruta:

  1. Configure las interfaces.

  2. Configure el BGP, incluidos el identificador de clúster y las relaciones de vecino con todos los dispositivos habilitados para IBGP en el sistema autónomo (AS).

    También aplique la política que redistribuye las rutas OSPF en el BGP.

  3. Configure el enrutamiento estático o un protocolo de puerta de enlace interior (IGP).

    En este ejemplo, se utiliza OSPF.

  4. Configure la política que redistribuye las rutas OSPF en el BGP.

  5. Configure el ID del enrutador y el número del sistema autónomo (AS).

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Nota:

Repita estos pasos para cada par bgp no cliente dentro del clúster que está configurando, si los otros dispositivos no cliente son de Juniper Networks. De lo contrario, consulte la documentación del dispositivo para obtener instrucciones.

Configuración de pares de clientes

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar pares de clientes:

  1. Configure las interfaces.

  2. Configure la relación del vecino del BGP con el reflector de ruta.

    También aplique la política que redistribuye las rutas OSPF en el BGP.

  3. Configure OSPF.

  4. Configure la política que redistribuye las rutas OSPF en el BGP.

  5. Configure el ID del enrutador y el número de AS.

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Nota:

Repita estos pasos para cada par del BGP del cliente dentro del clúster que está configurando si los otros dispositivos de cliente son de Juniper Networks. De lo contrario, consulte la documentación del dispositivo para obtener instrucciones.

Configuración de pares noclientes

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar pares noclientes:

  1. Configure las interfaces.

  2. Configure las relaciones de vecino del BGP con el reflector RRroute y con los otros pares no cliente.

    También aplique la política que redistribuye las rutas OSPF en el BGP.

  3. Configure OSPF.

  4. Configure la política que redistribuye las rutas OSPF en el BGP.

  5. Configure el ID del enrutador y el número de AS.

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Nota:

Repita estos pasos para cada par bgp no cliente dentro del clúster que está configurando si los otros dispositivos no cliente son de Juniper Networks. De lo contrario, consulte la documentación del dispositivo para obtener instrucciones.

Verificación

Confirme que la configuración funciona correctamente.

Verificar vecinos del BGP

Propósito

Compruebe que el BGP se ejecuta en interfaces configuradas y que la sesión del BGP se establece para cada dirección de vecino.

Acción

Desde el modo operativo, ingrese el show bgp neighbor comando.

Verificar grupos bgp

Propósito

Compruebe que los grupos BGP estén configurados correctamente.

Acción

Desde el modo operativo, ingrese el show bgp group comando.

Verificar la información de resumen del BGP

Propósito

Verifique que la configuración del BGP sea correcta.

Acción

Desde el modo operativo, ingrese el show bgp summary comando.

Verificar la información de la tabla de enrutamiento

Propósito

Compruebe que la tabla de enrutamiento contiene las rutas del IBGP.

Acción

Desde el modo operativo, ingrese el show route comando.

Descripción de un reflector de ruta que pertenece a dos grupos diferentes

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

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 se incluye uno de los IDs de clúster 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.

Tabla 1 resume las reglas que usan los reflectores de ruta al rellenar la lista de clústeres de una ruta reflejada con los IDs de clúster.

Tabla 1: Reglas para reflectores de ruta

Escenario de reflexión de ruta

Configuración

Cuando se refleja una ruta de uno de los clientes a un enrutador que no es cliente

cliente -> RR -> no cliente

El RR llena el ID de clúster asociado a ese cliente en la lista de clústeres de la ruta reflejada.

Cuando se refleja una ruta de un enrutador no cliente a un enrutador cliente

cliente no cliente -> RR -> cliente

El RR llena el ID de clúster asociado a ese cliente en la lista de clústeres de la ruta reflejada.

Cuando se refleja una ruta de un enrutador cliente a otro enrutador cliente que se encuentra en un clúster diferente

client1 -> RR -> client2 (clúster diferente)

El RR llena el ID de clúster asociado con client1 en la lista de clústeres antes de reflejar el ID de clúster en client2. No se agrega el ID de clúster asociado con el cliente 2.

Cuando se refleja una ruta de un enrutador cliente a un enrutador no cliente que se encuentra en un sistema autónomo diferente.

Por ejemplo, cuando ha configurado un RR de nivel 2 y 2 grupos BGP, uno para los clientes RR y el otro para RR de nivel 1, y refleja una ruta de un sistema autónomo a otro sistema autónomo.

cliente -> RR -> no cliente (AS diferente)

El RR no llena la lista de clústeres con el ID de clúster antes de reflejar la ruta al dispositivo que no es cliente, ya que el ID de clúster es específico de un sistema autónomo.

Ejemplo: Configuración de un reflector de ruta que pertenece a dos clústeres diferentes

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

Requisitos

Configure las interfaces de dispositivo y un protocolo de puerta de enlace interno (IGP). Para obtener un ejemplo de una configuración de RR que incluye la interfaz y la configuración de IGP, consulte Ejemplo: Configuración de un reflector de ruta.

Descripción general

En este ejemplo, el dispositivo RR1 es un reflector de ruta para el dispositivo R2 y el dispositivo RR2. El reflector de ruta RR1 tiene dos IDs de clúster diferentes asignados, uno es 5.5.5.5 para RR1-R2 y 6.6.6.6 para RR1-RR2.

El dispositivo RR2 es un reflector de ruta para el dispositivo R4.

Considere la figura Figura 5.

Figura 5: Reflector de ruta en dos grupos diferentes Reflector de ruta en dos grupos diferentes

En este ejemplo, se muestra la configuración del BGP en los dispositivos RR1 y RR2.

Configuración

Procedimiento

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.

Dispositivo RR1

Dispositivo RR2

Configuración del dispositivo RR1

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo RR1:

  1. Configure la relación de emparejamiento con el dispositivo R3.

  2. Configure la relación de emparejamiento con el dispositivo R0.

  3. Configure la relación de emparejamiento con el dispositivo RR2.

Resultados

Desde el modo de configuración, escriba el comando para confirmar la show protocols configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Configuración del dispositivo RR2

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo RR2:

  1. Configure la relación de emparejamiento con el dispositivo R4.

  2. Configure la relación de emparejamiento con el dispositivo RR1.

Resultados

Desde el modo de configuración, escriba el comando para confirmar la show protocols configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Verificación

Confirme que la configuración funciona correctamente.

Comprobación del ID de clúster anunciado para la ruta 10. 3. 3. 3

Propósito

Compruebe que el BGP se ejecuta en interfaces configuradas y que la sesión del BGP se establece para cada dirección de vecino.

Acción

Desde el modo operativo, ingrese el show route advertising-protocol bgp neighbor-address comando.

Significado

Los 10. 3. 3. La ruta 3/32 se origina en el par del cliente del dispositivo RR1, el dispositivo R3. Cuando se envía esta ruta al cliente de RR1, el dispositivo RR2, la ruta tiene el 10. 13. 1. 3 ID de clúster adjunto, que es el ID de clúster para RR1-R3.

Comprobación del ID de clúster anunciado para la ruta 10.1. 0.1

Propósito

Compruebe el anuncio de ruta del dispositivo RR1 al dispositivo RR2.

Acción

Desde el modo operativo, ingrese el show route advertising-protocol bgp neighbor-address comando.

Significado

El 10,1. La ruta 0.1/32 se origina en el par no cliente del dispositivo RR1, el dispositivo R0. Cuando se envía esta ruta al cliente de RR1, el dispositivo RR2, la ruta tiene el 10. 12. 1. 2 ID de clúster conectado, que es el ID de clúster para RR1-RR2.

El dispositivo RR1 conserva el ID de clúster entrante del dispositivo RR2 cuando se anuncia a otro cliente en un clúster diferente (dispositivo R4).

Descripción de la reflexión óptima de ruta del BGP

Puede configurar la reflexión óptima de ruta del BGP (BGP-ORR) con IS-IS y OSPF como el protocolo de puerta de enlace interior (IGP) en un reflector de ruta para anunciar la mejor ruta a los grupos de clientes BGP-ORR. Esto se hace mediante el uso de la métrica IGP más corta desde la perspectiva de un cliente, en lugar de la vista del reflector de ruta.

Los grupos de clientes que comparten la misma topología IGP o similar se pueden agrupar como un grupo par BGP. Puede configurar optimal-route-reflection para habilitar BGP-ORR en ese grupo par BGP. También puede configurar uno de los nodos de cliente como el nodo principal (igp-primary) en un grupo de pares bgp para que la métrica IGP de ese nodo principal se use para seleccionar la mejor ruta y anunciarla a los clientes del mismo grupo de pares bgp. Opcionalmente, también puede seleccionar otro nodo de cliente como el nodo de copia de seguridad (igp-backup), que se usa cuando el nodo principal (igp-primary) se cae o no es accesible.

Para habilitar BGP-ORR, incluya la optimal-route-reflection instrucción en el nivel de jerarquía [edit protocols bgp group group-name].

Nota:

BGP-ORR solo funciona cuando se utiliza IGP para la resolución de ruta del BGP. BGP-ORR no funciona cuando se utiliza MPLSLDP/RSVP para la resolución de rutas.

Nota:

Para que el BGP-ORR funcione, el prefijo BGP se debe resolver mediante IGP. En situaciones normales de VPN de capa 3, VPN o VPN de capa 2, o VPLS, O MVPN o EVPN, los prefijos se resuelven a través de inet.3. En inet.3, la ruta principal para el protocolo-próximo salto del prefijo sería RSVP o LDP ( y no un protocolo IGP como IS-IS o OSPF). Para que el BGP-ORR funcione, debe configurar el enrutador para que use inet.0 para la resolución de rutas de VPN de capa 3, VPN de capa 2, VPLS, MVPN o prefijos EVPN. Puede hacerlo mediante los siguientes comandos:

  • Para el prefijo VPN de capa 3:

  • Para VPN de capa 2 o prefijo VPLS:

  • Para el prefijo EVPN:

  • Para el prefijo MVPN:

Otro método es filtrar las rutas IGP en inet.3 y hacerlas como la ruta principal en inet.3.

Utilice la siguiente jerarquía de CLI para configurar BGP-ORR:

Configuración de la reflexión óptima de ruta del BGP en un reflector de ruta para anunciar la mejor ruta

Puede configurar la reflexión óptima de ruta del BGP (BGP-ORR) con IS-IS y OSPF como el protocolo de puerta de enlace interior (IGP) en un reflector de ruta para anunciar la mejor ruta a los grupos de clientes BGP-ORR. Esto se hace mediante el uso de la métrica IGP más corta desde la perspectiva de un cliente, en lugar de la vista del reflector de ruta.

Para habilitar BGP-ORR, incluya la optimal-route-reflection instrucción en el nivel de jerarquía [edit protocols bgp group group-name].

Los grupos de clientes que comparten la misma topología IGP o similar se pueden agrupar como un grupo par BGP. Puede configurar optimal-route-reflection para habilitar BGP-ORR en ese grupo par BGP.

Para configurar BGP-ORR:

  1. Configure una reflexión óptima de ruta.
  2. Configure uno de los nodos de cliente como el nodo principal (igp-primary) en un grupo de pares bgp para que la métrica IGP de ese nodo principal se use para seleccionar la mejor ruta y anunciarla a los clientes del mismo grupo de pares bgp.
  3. (Opcional) Configure otro nodo de cliente como el nodo de respaldo (igp-backup), que se usa cuando el nodo principal (igp-primary) se cae o no es accesible.

Utilice los siguientes comandos de CLI para supervisar y solucionar problemas de configuración para BGP-ORR:

  • show bgp group: permite ver las configuraciones principales y de respaldo del BGP-ORR.

  • show isis bgp-orr: vea la métrica BGP-ORR (RIB) IS-IS.

  • show ospf bgp-orr: vea la métrica BGP-ORR (RIB) de OSPF.

  • show ospf route: permite ver las entradas de la tabla de enrutamiento OSPF

  • show route: permite ver las entradas activas en las tablas de enrutamiento.

  • show route advertising protocol bgp peer: compruebe si las rutas se anuncian de acuerdo con las reglas del BGP-ORR.

Descripción general del servidor de ruta del BGP

Un servidor de ruta BGP es el equivalente de BGP externo (EBGP) de un reflector de ruta interno de IBGP (IBGP) que simplifica la cantidad de sesiones EBGP de punto a punto directas necesarias en una red. Los servidores de ruta EBGP son transparentes en términos de propagación de atributos BGP, de modo que una ruta recibida de un servidor de ruta lleva el conjunto de atributos bgp (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP y Comunidades) si la ruta es de un par EBGP conectado directamente.

Al igual que con un reflector de ruta de IBGP, un servidor de ruta EBGP está conectado a una red fuera de la ruta de reenvío directo entre los pares de EBGP mediante la funcionalidad del servidor de ruta. Esta conectividad puede ser a través de un vínculo físico directo, o a través de redes de capa 2, como VPLS LAN o EVPN, o a través de una estructura IP de vínculos EBGP punto a punto que proporcionan accesibilidad de direcciones de circuito cerrado de pares (típico en las redes de centros de datos).

El protocolo BGP se mejora para proporcionar capacidad de enrutamiento-servidor con las siguientes funcionalidades descritas en RFC 7947:

  • Transparencia de atributos para NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP y comunidades.

  • Control de políticas por cliente y varios RIB de servidor de ruta para mitigar la ocultación de rutas.

La programabilidad del BGP aprovecha la funcionalidad del servidor de ruta. La API BGP JET bgp_route_service.proto se ha mejorado para admitir la funcionalidad del servidor de ruta de la siguiente manera:

  • Programe el servidor de ruta del EBGP.

  • Inyectar rutas al servidor de rutas RIB específico para anunciarlo selectivamente a los grupos de clientes en RIB específicas del cliente.

La API BGP JET bgp_route_service.proto incluye un objeto de tipo par que identifica rutas individuales como EBGP o IBGP (predeterminado).

La funcionalidad del servidor de ruta generalmente es independiente de la familia de direcciones, aunque ciertos atributos bgp específicos pueden ser específicos de la familia de direcciones (por ejemplo, AIGP solo se admite para familias de direcciones de unidifusión etiquetadas). La funcionalidad del servidor de ruta se admite para todas las familias de direcciones de EBGP.

Transparencia del atributo BGP

La transparencia de atributo de EBGP [RFC7947] para el servidor de rutas se admite mediante la modificación de la propagación normal de ruta del BGP, de modo que ni los atributos transitivos ni no transitivos se eliminan o modifican mientras propagan rutas.

Los cambios en el comportamiento normal de EBGP se controlan mediante la configuración de la route-server-client CLI. La route-server-client configuración de CLI en el nivel de jerarquía [edit protocols bgp group group-name] implementa el comportamiento de transparencia del atributo del BGP del servidor de ruta.

  • El servidor de ruta proporciona transparencia de atributos para configuraciones de EBGP de un solo salto y de varios saltos. Por lo tanto, la route-server-client configuración incluye implícitamente la funcionalidad de para sesiones de no-nexthop-change salto único y de varios saltos. Para las sesiones de BGP de varios saltos, debe configurar la multihop palabra clave.

  • El route-server-client se puede configurar en los niveles de protocolo, grupo o vecino de la jerarquía [edit protocol bgp].

  • La route-server-client configuración solo se aplica cuando el tipo de grupo es externo. route-server-client Cuando se configura para grupos internos, se emite un error de configuración cuando se intenta confirmar.

  • La route-server-client configuración no tiene parámetros.

  • El privilegio bgp normal se aplica a la route-server-client configuración.

Nota:

Los atributos se manejan de forma independiente con respecto a la transparencia de atributos. Incluso si el servidor de ruta no puede enviar los saltos siguientes sin modificarlos, otros atributos se envían de manera transparente según corresponda para esos atributos.

A continuación, se muestra una configuración de ejemplo route-server-client :

Siguiente salto

El atributo de salto siguiente no se debe modificar mediante la imposición de uno mismo del salto siguiente ni modificar de otro modo el salto siguiente, a menos que se configure explícitamente a través de una política. El servidor de ruta debe propagar los próximos saltos bgp según las reglas de salto siguiente de terceros de RFC 4271.

El comportamiento del salto siguiente se especifica para los siguientes escenarios de enrutamiento-servidor:

  • En el caso de la interconexión LAN y WAN, cuando el servidor de ruta está conectado a los pares del cliente mediante una subred LAN y WAN compartida, el servidor de ruta anuncia los próximos saltos recibidos de terceros sin modificaciones según se define en RFC 4271.

  • En el caso de la interconexión multihop del centro de datos, cuando el servidor de ruta está conectado a los pares del cliente mediante una interconexión multihop, se debe configurar el multihop EBGP y el comportamiento de la configuración de CLI no-nexthop-change se impone implícitamente por la route-server-client configuración. El servidor de ruta anuncia los próximos saltos recibidos de terceros sin modificaciones, según el comportamiento opcional de terceros definido en RFC 4271.

  • En otros casos, como las conexiones de un solo salto de punto a punto entre el servidor de ruta y los pares de cliente, se utilizan procedimientos normales de anuncio de próximo salto para evitar que los pares del BGP puedan rechazar los próximos saltos (por ejemplo, la mayoría de las implementaciones del BGP, de forma predeterminada, rechaza direcciones de saltos siguientes que no están cubiertas por la dirección de subred en sesiones no multipunto.

Ruta del AS

La ruta del AS no se debe modificar anteponiendo el número de AS local del servidor de ruta. Configurar la route-server-client CLI para un par suprime la anteposición del número de AS local en los anuncios. Además, el comando de la show route advertising-protocol bgp peer CLI se cambia para los pares que son clientes del servidor de ruta de modo que el AS local no se muestra en las métricas anunciadas.

Otros atributos

  • MULTI_EXIT_DISC atributo (opcional, no transitivo) se debe propagar como se recibió.

  • Todos los atributos de la comunidad, incluidas las comunidades extendidas sin publicidad, sin exportación y no transitivas, se deben propagar según lo recibido.

  • El atributo IGP acumulado (AIGP) (opcional, no transitivo) se debe propagar según lo recibido.

    Nota:

    Junos OS solo admite AIGP para familias de direcciones BGP-LU (IPv4 e IPv6).

RIB del cliente del servidor de ruta BGP

Una RIB específica del cliente del servidor de ruta es una vista distinta de una Loc-RIB bgp que puede contener rutas diferentes para el mismo destino que otras vistas. Los clientes del servidor de ruta, a través de sus grupos par, pueden asociarse con una vista específica del cliente individual o con una RIB común compartida.

Para proporcionar la capacidad de anunciar diferentes rutas a diferentes clientes para el mismo destino, es conceptualmente necesario permitir que se produzcan varias instancias de la selección de ruta bgp para el mismo destino, pero en contextos de cliente o grupo diferentes.

Para implementar el requisito de alto nivel de control de política flexible con selección de ruta por cliente/grupo, el servidor de ruta BGP adopta el enfoque de usar instancias de enrutamiento no de reenvío (NFIs) para varias instancias de la canalización del BGP, incluida la selección de rutas BGP, Loc-RIB y la política. El servidor de ruta está configurado para agrupar clientes de servidor de ruta dentro de grupos BGP configurados dentro de instancias de enrutamiento independientes que no se reenvían. Este enfoque aprovecha el hecho de que el BGP que se ejecuta en una instancia de enrutamiento realiza la selección de rutas y tiene un RIB que es independiente del BGP que se ejecuta en otras instancias de enrutamiento.

Requisitos y consideraciones de políticas

Para propagar rutas entre clientes de servidor de rutas, las rutas se filtran entre los RIB de las instancias de enrutamiento según las políticas configuradas.

La configuración del servidor de ruta para el control de políticas incluye las siguientes consideraciones:

  • Los clientes del servidor de ruta se deben configurar dentro de la misma instancia principal o instancia de enrutamiento para recibir la misma vista Loc-RIB.

  • Los clientes del servidor de ruta deben configurarse dentro de su propia instancia de enrutamiento para recibir vistas de Loc-RIB totalmente únicas.

  • Los clientes del servidor de ruta se deben configurar en diferentes grupos par BGP en la misma instancia de enrutamiento para tener una política de exportación diferente en la misma vista Loc-RIB.

  • Para que las vistas RIB específicas del cliente del servidor de ruta reciban todas las rutas de otras tablas de forma predeterminada, se configura una malla completa de instance-import políticas con instance-any. Cuando se instance-import configura con una política que contiene instance-any:

    • instance-any se puede utilizar en:

      • policy-statement ... term ... from

      • policy-statement ... from

      • policy-statement ... term ... to

      • policy-statement ... to

    • instance-any no tiene parámetros.

    • El uso instance-any en políticas distintas instance-import de no tiene ningún efecto.

  • La configuración de muchas instancias de enrutamiento y grupos pares distintos afecta la escala y el rendimiento.

  • La configuración de la CLI del BGP forwarding-context en el nivel de jerarquía [edit protocols bgp group neighbor] divide la instancia de enrutamiento de un vecino del BGP en una instancia de configuración y una instancia de reenvío. La configuración de la CLI del BGP forwarding-context también admite instancia no de reenvío con pares bgp configurados como route-server-client donde la instancia especificada es cualquier instancia capaz de reenviar una instancia principal o una instancia de enrutamiento que no sea de tipo sin reenvío.

Tabla de historial de versiones
Liberación
Descripción
15.1
A partir de Junos OS versión 15.1, la instrucción elimina la no-install interacción entre el demonio de protocolos de enrutamiento (rpd) y otros componentes del sistema Junos, como el kernel o el demonio de firewall distribuido (dfwd).
15.1
En las versiones anteriores a Junos OS versión 15.1, puede reducir la carga de trabajo en un reflector de ruta que no se encuentra en la ruta de reenvío de tráfico mediante una política de exportación de tabla de reenvío que rechaza las rutas aprendidas del BGP.