Reflector de ruta BGP
Descripción de los reflector de ruta 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 de jerarquía. 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 mediante la prohibición de publicar cualquier ruta en las bases de información de enrutamiento rpd asociadas (RB), también conocidas como tablas de enrutamiento, en esos componentes.
En versiones anteriores a Junos OS versión 15.1, puede reducir la carga de trabajo en un reflector de ruta que no esté en la ruta de reenvío de tráfico mediante una política de exportación de tabla de reenvío que rechace las rutas aprendidas del BGP.
Debido al requisito de malla completa interno del BGP (IBGP), la mayoría de las redes utilizan reflectores de ruta para simplificar la configuración. La fórmula para calcular la cantidad de sesiones necesarias para una malla completa es v* (v - 1)/2, donde v es el número de dispositivos habilitados para el BGP. El modelo de malla completa no escala bien. Con un reflector de ruta, se agrupan enrutadores en clústeres, los cuales se identifican mediante identificadores numéricos únicos del sistema autónomo (AS). 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, designa uno o más enrutadores como reflector de ruta; normalmente, uno por punto de presencia (POP). Los reflectores de ruta tienen la capacidad especial del BGP de readvertir las rutas aprendidas de un par interno a otros pares internos. Así que, en lugar de requerir que todos los pares internos estén completamente mallados entre sí, la reflexión de rutas 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.
Para algunos dispositivos de Juniper Networks, debe tener una licencia de función avanzada del BGP instalada en cada dispositivo que use un reflector de ruta. Para obtener detalles de la licencia, consulte la Guía de instalación y actualización de software.
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. Las rutas del BGP se anuncian al enrutador RR por cualquiera de los pares internos. RR, luego, vuelve a invertir 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 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 readverte la ruta a los otros reflectores de ruta, los cuales, a su vez, vuelven a invertir 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 escalamiento creados por el requisito de malla completa.
Un reflector de ruta compatible con varios clústeres no acepta una ruta con el mismo ID de clúster desde un enrutador que no sea de cliente. Por lo tanto, debe configurar un ID de clúster diferente para que un RR redundante refleje 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 reflector de ruta. Para ayudar a compensar este problema, puede agrupar clústeres de enrutadores en clústeres de clústeres para la reflexión jerárquica de rutas (consulte Figura 3).
Figura 3 muestra RR 2, RR 3 y RR 4 como los reflectores de ruta para los grupos 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 readverte la ruta a todos los enrutadores de su propio clúster y, luego, vuelve a invertir la ruta a RR 1. RR 1 readverte la ruta a los enrutadores de su clúster, y esos enrutadores propagan la ruta hacia abajo a través de sus clústeres.
Consulte también
Ejemplo: Configurar 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 el BGP (IBGP) deben estar completamente mallados, ya que el IBGP no revierte las actualizaciones a otros dispositivos habilitados para IBGP. La malla completa es una malla lógica que se logra 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 escala bien en implementaciones grandes.
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 de pares con todos los dispositivos habilitados para IBGP incluyendo la neighbor instrucción para los clientes (dispositivos B y C) y los no clientes (dispositivos D y 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 usa la dirección IP de la 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 que no son clientes, necesita una neighbor instrucción para cada dispositivo que no es 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 (dispositivos B y C).
Se considera que los dispositivos D y E no son clientes porque han configurado explícitamente las relaciones entre pares entre sí. Para que sean clientes del reflector RRroute, quite la neighbor 192.168.5.5 instrucción de la configuración en el dispositivo D y elimine la neighbor 192.168.0.1 instrucción de la configuración del dispositivo E.
Configuración
- Procedimiento
- Configuración del reflector de ruta
- Configuración de pares de cliente
- Configuración de pares que no son clientes
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
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
Dispositivo B
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
Dispositivo C
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
Dispositivo D
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
Dispositivo E
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
Procedimiento paso a paso
Configuración del reflector de ruta
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de 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:
Configure las interfaces.
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
Configure el BGP, incluido el identificador de clúster y las relaciones de vecinos con todos los dispositivos habilitados para IBGP en el sistema autónomo (AS).
También aplique la política que redistribuye las rutas del OSPF en BGP.
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
Configure el enrutamiento estático o un protocolo de puerta de enlace interior (IGP).
En este ejemplo, se utiliza OSPF.
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
Configure la política que redistribuye las rutas del OSPF en BGP.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
Configure el ID de enrutador y el número de sistema autónomo (AS).
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
Resultados
Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@A# show interfaces
fe-0/0/0 {
unit 1 {
description to-B;
family inet {
address 10.10.10.1/30;
}
}
}
fe-0/0/1 {
unit 3 {
description to-D;
family inet {
address 10.10.10.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.6.5/32;
}
}
}
user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4;
neighbor 192.168.40.4;
neighbor 192.168.0.1;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface fe-0/0/0.1;
interface fe-0/0/1.3;
}
}
user@A# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Repita estos pasos para cada par de BGP que no sea cliente dentro del clúster que esté configurando, si los otros dispositivos que no son clientes son de Juniper Networks. De lo contrario, consulte la documentación del dispositivo para obtener instrucciones.
Configuración de pares de cliente
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de 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 los pares de cliente:
Configure las interfaces.
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
Configure la relación de vecino del BGP con el reflector de ruta.
También aplique la política que redistribuye las rutas del OSPF en BGP.
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
Configure la política que redistribuye las rutas del OSPF en BGP.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
Configure el ID de enrutador y el número de AS.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
Resultados
Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@B# show interfaces
fe-0/0/0 {
unit 2 {
description to-A;
family inet {
address 10.10.10.2/30;
}
}
}
fe-0/0/1 {
unit 5 {
description to-C;
family inet {
address 10.10.10.5/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.163.6.4/32;
}
}
}
user@B# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.163.6.4;
export send-ospf;
neighbor 192.168.6.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-0/0/0.2;
interface fe-0/0/1.5;
}
}
user@B# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Repita estos pasos para cada par del BGP del cliente dentro del clúster que está configurando si los otros dispositivos cliente son de Juniper Networks. De lo contrario, consulte la documentación del dispositivo para obtener instrucciones.
Configuración de pares que no son clientes
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de 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 que no son clientes:
Configure las interfaces.
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
Configure las relaciones de vecino del BGP con el reflector RRroute y con los otros pares que no son clientes.
También aplique la política que redistribuye las rutas del OSPF en BGP.
[edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
Configure la política que redistribuye las rutas del OSPF en BGP.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
Configure el ID de enrutador y el número de AS.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
Resultados
Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@D# show interfaces
fe-0/0/0 {
unit 4 {
description to-A;
family inet {
address 10.10.10.10/30;
}
}
}
fe-0/0/1 {
unit 7 {
description to-E;
family inet {
address 10.10.10.13/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.1/32;
}
}
}
user@D# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.0.1;
export send-ospf;
neighbor 192.168.6.5;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
interface fe-0/0/0.4;
interface fe-0/0/1.7;
}
}
user@D# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Repita estos pasos para cada par de BGP que no sea cliente dentro del clúster que esté configurando si los otros dispositivos que no son de 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
- Verificar grupos BGP
- Verificar la información de resumen del BGP
- Verificar la información de la tabla de enrutamiento
Verificar vecinos del BGP
Propósito
Compruebe que el BGP se ejecuta en interfaces configuradas y que la sesión del BGP está establecida para cada dirección de vecino.
Acción
Desde el modo operativo, ingrese el show bgp neighbor comando.
user@A> show bgp neighbor
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 3 Checked 19
Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480
Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235
Output Queue[0]: 0
Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 3
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 18 Sent 20 Checked 12
Input messages: Total 15 Updates 5 Refreshes 0 Octets 447
Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307
Output Queue[0]: 0
Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 2
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 17 Sent 3 Checked 9
Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 23 Checked 52
Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0Verificar 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.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Peers: 4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
Verificar la información de resumen del BGP
Propósito
Compruebe que la configuración del BGP es correcta.
Acción
Desde el modo operativo, ingrese el show bgp summary comando.
user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
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.
user@A> show route
inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 *[Direct/0] 22:22:03
> via fe-0/0/0.1
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.1/32 *[Local/0] 22:22:03
Local via fe-0/0/0.1
10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.8/30 *[Direct/0] 22:22:03
> via fe-0/0/1.3
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
10.10.10.9/32 *[Local/0] 22:22:03
Local via fe-0/0/1.3
10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.6.5/32 *[Direct/0] 22:22:04
> via lo0.1
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1
MultiRecvDescripción de un reflector de ruta que pertenece a dos clústeres diferentes
El propósito de la reflexión de ruta es la prevención de bucles cuando los dispositivos de enrutamiento interno del BGP (IBGP) no están completamente mallados. Para lograr esto, los RR rompen una de las reglas del funcionamiento normal del BGP: Readverten las rutas aprendidas de un par de BGP interno a otros pares de 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 se incluye uno de los IDENTIFICA de clúster en la lista de clústeres. Esto se debe a que tener un ID de clúster en la lista de clústeres es adecuado para la prevención de bucles en este caso.
Tabla 1 resume las reglas que utilizan los reflectores de ruta al completar la lista de clústeres de una ruta reflejada con los IDENTIFICA de clústeres.
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 rellena el ID de clúster asociado con ese cliente en la lista de clústeres de la ruta reflejada. |
Cuando se refleja una ruta de un enrutador que no es de cliente a un enrutador de cliente cliente RR-> que no es cliente > |
El RR rellena el ID de clúster asociado con ese cliente en la lista de clústeres de la ruta reflejada. |
Al reflejar una ruta desde un enrutador de cliente a otro enrutador de cliente que se encuentra en un clúster diferente client1 -> RR -> client2 (clúster diferente) |
El RR rellena el ID de clúster asociado con client1 en la lista de clústeres antes de reflejar el ID de clúster en el cliente2. No se agrega el ID de clúster asociado con el cliente 2. |
Al reflejar una ruta desde un enrutador de cliente a un enrutador que no es de cliente que se encuentra en un sistema autónomo diferente. Por ejemplo, cuando ha configurado un grupo RR de nivel 2 y 2 BGP, uno para los clientes RR y el otro para rr de nivel 1, y está reflejando 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 no cliente, ya que el ID de clúster es específico de un sistema autónomo. |
Consulte también
Ejemplo: Configurar 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 del dispositivo y un protocolo de puerta de enlace interna (IGP). Para ver un ejemplo de una configuración RR que incluye la interfaz y la configuración de IGP, consulte Ejemplo: Configurar un reflector de ruta.
Descripción general
En este ejemplo, el dispositivo RR1 es un reflector de ruta para los dispositivos R3 y RR2. El reflector de ruta RR1 tiene asignados dos identificaciones de clúster diferentes, una es 5.5.5.5 para RR1-R3 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.
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
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 10.13.1.3 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 10.12.1.2 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
Dispositivo RR2
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 10.24.2.4 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
Configuración del dispositivo RR1
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de 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:
-
Configure la relación de emparejamiento con el dispositivo R3.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.13.1.3 user@RR1# set neighbor 192.168.48.1
-
Configure la relación de emparejamiento con el dispositivo R0.
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
-
Configure la relación de emparejamiento con el dispositivo RR2.
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.12.1.2 user@RR1# set neighbor 192.168.40.1
Resultados
Desde el modo de configuración, ingrese el comando para confirmar la show protocols configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@RR1# show protocols
bgp {
group RR1_client {
type internal;
local-address 192.168.20.1;
cluster 10.13.1.3;
neighbor 192.168.48.1;
}
group Non_client {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group RR1_to_RR2 {
type internal;
local-address 192.168.20.1;
cluster 10.12.1.2;
neighbor 192.168.40.1;
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Configuración del dispositivo RR2
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de 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:
-
Configure la relación de emparejamiento con el dispositivo R4.
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 10.24.2.4 user@RR2# set neighbor 192.168.32.1
-
Configure la relación de emparejamiento con el dispositivo RR1.
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
Resultados
Desde el modo de configuración, ingrese el comando para confirmar la show protocols configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@RR2# show protocols
bgp {
group RR2_client {
type internal;
local-address 192.168.40.1;
cluster 10.24.2.4;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
- Comprobar el ID de clúster anunciado para Route 10. 3. 3. 3
- Comprobar el ID de clúster anunciado para la ruta 10.1. 0.1
Comprobar el ID de clúster anunciado para Route 10. 3. 3. 3
Propósito
Compruebe que el BGP se ejecuta en interfaces configuradas y que la sesión del BGP está establecida para cada dirección de vecino.
Acción
Desde el modo operativo, ingrese el show route advertising-protocol bgp neighbor-address comando.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.3.3.3 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.3.3.3/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.48.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.13.1.3
Originator ID: 192.168.48.1
Significado
El 10. 3. 3. La ruta 3/32 se origina en el par de 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.
Comprobar el 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.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.1.0.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.1.0.1/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.16.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.12.1.2
Originator ID: 192.168.16.1Significado
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 adjunto, que es el ID de clúster para RR1-RR2.
El dispositivo RR1 conserva el ID de clúster entrante del dispositivo RR2 cuando anuncia a otro cliente en un clúster diferente (dispositivo R4).
Descripción de la reflexión de ruta óptima del BGP
Puede configurar la reflexión de ruta óptima 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 del BGP-ORR. Esto se hace mediante el uso de la métrica de 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 de IGP o similar se pueden agrupar como un grupo par de BGP. Puede configurar optimal-route-reflection para habilitar el BGP-ORR en ese grupo par del BGP. También puede configurar uno de los nodos de cliente como el nodo principal (igp-primary) en un grupo par 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 del BGP. Opcionalmente, también puede seleccionar otro nodo de cliente como nodo de copia de seguridad (igp-backup), que se utiliza cuando el nodo principal (igp-primary) cae o no es accesible.
Para habilitar el BGP-ORR, incluya la optimal-route-reflection instrucción en el nivel de jerarquía [edit protocols bgp group group-name].
El BGP-ORR solo funciona cuando se utiliza IGP para la resolución de rutas del BGP. BGP-ORR no funciona cuando se utiliza MPLSLDP/RSVP para la resolución de rutas.
Para que el BGP-ORR funcione, el prefijo BGP debe resolverse mediante IGP. En escenarios normales de VPN de capa 3 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 de salto siguiente del prefijo sería RSVP o LDP (y no un protocolo IGP como IS-IS u OSPF). Para que el BGP-ORR funcione, debe configurar el enrutador para que use inet.0 para la resolución de ruta de los prefijos de VPN de capa 3, VPN de capa 2, VPLS, MVPN o EVPN. Puede hacerlo a través de los siguientes comandos:
Para el prefijo VPN de capa 3:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
Para el prefijo VPN de capa 2 o VPLS:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
Para el prefijo de EVPN:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
Para el prefijo MVPN:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
Otro método es filtrar las rutas de IGP en inet.3 y convertirlas en la ruta principal en inet.3.
Utilice la siguiente jerarquía de CLI para configurar BGP-ORR:
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
Consulte también
Configurar la reflexión de ruta óptima del BGP en un reflector de ruta para anunciar la mejor ruta
Puede configurar la reflexión de ruta óptima 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 del BGP-ORR. Esto se hace mediante el uso de la métrica de IGP más corta desde la perspectiva de un cliente, en lugar de la vista del reflector de ruta.
Para habilitar el 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 de IGP o similar se pueden agrupar como un grupo par de BGP. Puede configurar optimal-route-reflection para habilitar el BGP-ORR en ese grupo par del BGP.
Para configurar el BGP-ORR:
Utilice los siguientes comandos de CLI para supervisar y solucionar problemas de la configuración del BGP-ORR:
show bgp group—Vea las configuraciones principal y de respaldo del BGP-ORR.show isis bgp-orr—Vea la métrica BGP-ORR (RIB) del IS-IS.show ospf bgp-orr—Vea la métrica BGP-ORR (RIB) del OSPF.show ospf route— Ver las entradas en la tabla de enrutamiento OSPFshow route— Vea 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.
Consulte también
Descripción general del servidor de ruta BGP
Un servidor de ruta BGP es el equivalente de BGP externo (EBGP) de un reflector de ruta IBGP interno (IBGP) que simplifica la cantidad de sesiones de EBGP directas de punto a punto necesarias en una red. Los servidores de ruta EBGP son transparentes en términos de propagación de atributos de BGP, de modo que una ruta recibida de un servidor de ruta lleve el conjunto de atributos de BGP (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP y Comunidades) si la ruta es de un par de EBGP conectado directamente.
Al igual que con un reflector de ruta IBGP, un servidor de ruta EBGP se conecta a una red fuera de la ruta de reenvío directo entre los pares del 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 enlaces EBGP punto a punto que proporcionan accesibilidad de direcciones de circuito cerrado de pares (típicas en redes de centros de datos).
El protocolo BGP se ha mejorado para proporcionar capacidad de servidor de ruta 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 RB de varios servidores de ruta para mitigar la ocultación de rutas.
La programabilidad del BGP aprovecha la funcionalidad del servidor de ruta. La API JET bgp_route_service.proto del BGP se ha mejorado para admitir la funcionalidad del servidor de ruta de la siguiente manera:
Programe el servidor de ruta EBGP.
Inyecte rutas al RIB del servidor de ruta específico para anunciarlo selectivamente en los grupos de clientes en RB específicas del cliente.
La API JET bgp_route_service.proto del BGP incluye un objeto de tipo par que identifica rutas individuales como EBGP o IBGP (predeterminado).
La funcionalidad del servidor de enrutamiento es generalmente independiente de la familia de direcciones, aunque cierto soporte de atributos de BGP específico puede ser específico de familia de direcciones (por ejemplo, AIGP solo se admite para familias de direcciones etiquetadas de unidifusión). La funcionalidad del servidor de enrutamiento es compatible con todas las familias de direcciones EBGP.
- Transparencia de atributo BGP
- Siguiente salto
- Ruta del AS
- Otros atributos
- RIB de cliente del servidor de ruta BGP
- Requisitos y consideraciones de política
Transparencia de atributo BGP
La transparencia de atributo EBGP [RFC7947] para el servidor de ruta se admite mediante la modificación de la propagación normal de ruta del BGP, de modo que ni los atributos transitivos ni los no transitivos se despojaran o modifiquen durante la propagación de rutas.
Los cambios en el comportamiento normal del 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 de atributo BGP del servidor de ruta.
El servidor de ruta ofrece transparencia de atributos tanto para ebGP de un solo salto como para configuraciones de varios saltos. Por lo tanto, la
route-server-clientconfiguración incluye implícitamente la funcionalidad de para sesiones deno-nexthop-changeun solo salto y de varios saltos. Para las sesiones de BGP de varios saltos, debe configurar lamultihoppalabra clave.Se
route-server-clientpuede configurar en los niveles de protocolo, grupo o vecino de la jerarquía [edit protocol bgp].La
route-server-clientconfiguración solo se aplica cuando el tipo de grupo es external. Cuando seroute-server-clientconfigura para internal grupos, se emite un error de configuración al intentar confirmar.La
route-server-clientconfiguración no tiene parámetros.El privilegio normal del BGP se aplica a la
route-server-clientconfiguración.
Los atributos se manejan de forma independiente con respecto a la transparencia de atributo. Incluso si los próximos saltos no se pueden enviar sin modificar por el servidor de ruta, otros atributos se envían de forma transparente según corresponda para esos atributos.
La siguiente es una configuración de ejemplo route-server-client :
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
Siguiente salto
El atributo del siguiente salto no se debe modificar imponiendo autoimpulso del siguiente salto ni modificando de otro modo el siguiente salto, a menos que se configure explícitamente mediante una política. El servidor de ruta debe propagar los próximos saltos del BGP de acuerdo con las reglas de próximo salto de terceros del RFC 4271.
El comportamiento del siguiente salto se especifica para los siguientes escenarios de servidor de ruta:
En el caso de las interconexiones LAN y WAN, cuando el servidor de ruta se conecta a los pares del cliente a través de una subred LAN y WAN compartidas, el servidor de ruta anuncia los próximos saltos de terceros recibidos sin modificaciones como se define en el 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 a través de una interconexión multihop, se debe configurar el multihop ebGP y el comportamiento de la configuración de CLI
no-nexthop-changese impone implícitamente por laroute-server-clientconfiguración. Los próximos saltos de terceros recibidos se anuncian en el servidor de ruta sin modificaciones, según el comportamiento opcional de terceros definido en el RFC 4271.En otros casos, como las conexiones de un solo salto punto a punto entre el servidor de ruta y los pares de cliente, se utilizan procedimientos normales de publicidad de próximo salto para evitar la publicidad de próximos saltos que podrían rechazar los pares del BGP (por ejemplo, la mayoría de las implementaciones de BGP, de forma predeterminada, rechazan direcciones de saltos próximos que no están cubiertos por la dirección de subred en sesiones que no son multipunto.
Ruta del AS
La ruta del AS no se debe modificar anteponiendo el número de AS local del servidor de ruta. La configuración de route-server-client la CLI para un par suprime la anteposición del número de AS local en los anuncios. Además, el comando de cli show route advertising-protocol bgp peer se cambia para pares que son clientes de servidor de enrutamiento, 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, no exportación y comunidades extendidas no transitivas, se deben propagar como se recibió.
El atributo de IGP acumulado (AIGP) (opcional, no transitivo) se debe propagar como se recibió.
Nota:Junos OS solo admite AIGP para familias de direcciones BGP-LU (IPv4 e IPv6).
RIB de cliente del servidor de ruta BGP
Un RIB específico del cliente del servidor de ruta es una vista distinta de un BGP Loc-RIB que puede contener rutas diferentes para el mismo destino que otras vistas. Los clientes del servidor de enrutamiento, a través de sus grupos de pares, pueden asociarse con una vista individual específica del cliente o con un RIB común compartido.
Para proporcionar la capacidad de anunciar diferentes rutas a diferentes clientes para el mismo destino, es conceptualmente necesario permitir que varias instancias de la selección de ruta del BGP se produzcan para el mismo destino, pero en diferentes contextos de cliente/grupo.
Para implementar el requisito de alto nivel de un control de políticas flexible con selección de ruta por cliente/grupo, el servidor de ruta del BGP adopta el enfoque de usar instancias de enrutamiento sin reenvío (NFI) a varias instancias de la canalización del BGP, incluida la selección de ruta del BGP, Loc-RIB y la política. El servidor de ruta está configurado para agrupar clientes de servidor de enrutamiento dentro de grupos BGP configurados en instancias de enrutamiento independientes sin reenvío. Este enfoque aprovecha el hecho de que el BGP que se ejecuta dentro de una instancia de enrutamiento hace la selección de rutas y tiene un RIB independiente del BGP que se ejecuta en otras instancias de enrutamiento.
Requisitos y consideraciones de política
Para propagar rutas entre los clientes del servidor de ruta, las rutas se filtran entre las RIss (RIB) de las instancias de enrutamiento según 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 enrutamiento deben configurarse en la misma instancia principal o instancia de enrutamiento para recibir la misma vista de 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 enrutamiento deben configurarse en diferentes grupos pares de BGP en la misma instancia de enrutamiento para tener una política de exportación diferente en la misma vista de 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-importpolíticas coninstance-any. Cuando se configura con políticainstance-importque contieneinstance-any:instance-anyse puede utilizar en:policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-anyno tiene parámetros.El uso
instance-anyen políticas distintasinstance-importa las que no tenga ningún efecto.
La configuración de muchas instancias de enrutamiento y grupos de pares distintos afecta la escala y el rendimiento.
La configuración de la CLI del BGP
forwarding-contexten el nivel de jerarquía [edit protocols bgp group neighbor] divide la instancia de enrutamiento para un vecino del BGP en una instancia de configuración y una instancia de reenvío. La configuración de la CLI del BGPforwarding-contexttambién admite una instancia de no reenvío con pares de BGP configurados comoroute-server-clientdonde 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.
Consulte también
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).