Reflectores de ruta BGP
Descripción de los reflectores de ruta BGP
En este tema se describe el uso de reflectores de ruta para simplificar la configuración y ayudar en el escalado. Otra forma de reducir la carga de trabajo en un reflector de ruta que no está en la ruta de reenvío de tráfico es usar la no-install instrucción en el nivel de [edit protocols bgp family family-name] 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 prohibiendo que cualquier ruta en las bases de información de enrutamiento (RIB) de RPD asociadas, también conocidas como tablas de enrutamiento, se publique 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 interno de malla completa de 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 el número de dispositivos habilitados para BGP. El modelo de malla completa no escala bien. Mediante un reflector de ruta, los enrutadores se agrupan en clústeres, que se identifican mediante identificadores numéricos exclusivos del sistema autónomo (AS). Dentro del clúster, debe configurar una sesión BGP desde un único enrutador (el reflector de ruta) a cada par interno. Con esta configuración, se cumple el requisito de malla completa de 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 especial BGP de reanunciar 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 entrelazados 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.
Para algunos dispositivos de Juniper Networks, debe tener instalada una licencia de función BGP avanzada en cada dispositivo que utilice 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 muestra el enrutador RR configurado como reflector de ruta para el clúster 127. Los otros enrutadores se designan como pares internos dentro del clúster. Las rutas BGP se anuncian al enrutador RR por cualquiera de los pares internos. A continuación, RR vuelve a anunciar esas rutas a todos los demás pares del clúster.
Puede configurar varios clústeres y vincularlos configurando 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 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 dentro del AS. La reflexión de ruta permite que la ruta se propague por todo el AS sin los problemas de escala creados por el requisito de malla completa.
Un reflector de ruta que admita varios clústeres no acepta una ruta con el mismo ID de clúster de un enrutador que no sea 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 grupos se hacen grandes, una malla completa con un reflector de ruta se vuelve difícil de escalar, al igual que una malla completa entre los reflectores de ruta. Para ayudar a solucionar este problema, puede agrupar clústeres de enrutadores en grupos de clústeres para la reflexión jerárquica de ruta (consulte Figura 3).
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 completamente esos reflectores de ruta, el administrador de red los ha configurado como parte de otro clúster (clúster 6) para el que 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 dentro de su propio clúster y, a continuación, vuelve a anunciar la ruta a RR 1. El RR 1 vuelve a anunciar la ruta a los enrutadores de su clúster y esos enrutadores propagan la ruta a través de sus clústeres.
Consulte también
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 vuelve a anunciar 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. El mantenimiento de una malla completa (lógica o física) no se escala bien en implementaciones grandes.
Figura 4 muestra una red IBGP con el dispositivo A actuando 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 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 instrucción y un identificador de cluster clúster. El identificador de clúster puede ser cualquier valor de 32 bits. En este ejemplo se utiliza 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 sea cliente (D-to-E y E-to-D). También necesita una neighbor instrucción para el reflector de ruta (D-to-A y E-to-A). Los dispositivos D y E no necesitan neighbor instrucciones para los dispositivos cliente (dispositivos B y C).
Los dispositivos D y E se consideran no clientes porque han configurado explícitamente relaciones de pares entre sí. Para convertirlos en clientes reflectores RRroute, elimine la neighbor 192.168.5.5 instrucción de la configuración del dispositivo D y quite 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] 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
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para configurar el IBGP en la red con 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 vecino con todos los dispositivos habilitados para IBGP en el sistema autónomo (AS).
Aplique también la política que redistribuye las rutas 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 de 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 del 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuració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;
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Repita estos pasos para cada par BGP que no sea cliente dentro del clúster que está configurando, si los otros dispositivos que no son cliente 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
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para configurar 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 del vecino del BGP con el reflector de ruta.
Aplique también la política que redistribuye las rutas 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 de 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuració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;
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Repita estos pasos para cada par BGP de 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
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para configurar pares que no sean 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 demás pares que no sean clientes.
Aplique también la política que redistribuye las rutas 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 de 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuració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;
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Repita estos pasos para cada par BGP que no sea cliente dentro del clúster que esté configurando si los otros dispositivos que no son cliente son de Juniper Networks. De lo contrario, consulte la documentación del dispositivo para obtener instrucciones.
Verificación
Confirme que la configuración funcione correctamente.
- Comprobación de vecinos de BGP
- Comprobación de grupos BGP
- Verificación de la información de resumen de BGP
- Comprobación de la información de la tabla de enrutamiento
Comprobación de vecinos de BGP
Propósito
Compruebe que BGP se está ejecutando en interfaces configuradas y que la sesión BGP está establecida para cada dirección de vecino.
Acción
Desde el modo operativo, ingrese el comando show bgp neighbor.
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]: 0Comprobación de grupos BGP
Propósito
Compruebe que los grupos BGP estén configurados correctamente.
Acción
Desde el modo operativo, ingrese el comando show bgp group.
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
Verificación de la información de resumen de BGP
Propósito
Compruebe que la configuración del BGP es correcta.
Acción
Desde el modo operativo, ingrese el comando show bgp summary.
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
Comprobación de 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 comando show route.
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 BGP (IBGP) internos no están completamente mallados. Para lograr esto, los RR rompen una de las reglas del funcionamiento normal del BGP: Reanuncian rutas aprendidas de un par de BGP interno a otros pares de BGP internos.
Normalmente, un solo RR es miembro de un solo grupo. 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 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 rellenar la lista de clústeres de una ruta reflejada con identificadores de clúster.
Escenario de reflexión de ruta |
Configuración |
|---|---|
Al reflejar 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. |
Al reflejar una ruta de un enrutador que no es cliente a un enrutador cliente non-client -> RR -> client |
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 de un enrutador cliente a otro enrutador cliente que se encuentra en un clúster diferente cliente1 -> RR -> cliente2 (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 a client2. No se agrega el ID de clúster asociado con el cliente 2. |
Cuando se refleja una ruta desde un enrutador cliente a un enrutador que no es 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 está reflejando una ruta de un sistema autónomo a otro sistema autónomo. cliente-> RR-> no cliente (AS diferente) |
El RR no rellena 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. |
Consulte también
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. Este no es un escenario común, pero puede ser útil en algunas situaciones.
Requisitos
Configure las interfaces de dispositivo y un protocolo de puerta de enlace interna (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 tanto para el dispositivo R3 como para el dispositivo RR2. El reflector de ruta RR1 tiene dos ID de clúster diferentes asignados, uno 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] 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
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de 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, confírmela con el comando show protocols. 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;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Configuración del dispositivo RR2
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de 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, confírmela con el comando show protocols. 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;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Confirme que la configuración funcione correctamente.
- Comprobación del ID de clúster anunciado para Route 10.3.3.3
- Comprobación del ID de clúster anunciado para Route 10.1.0.1 Español
Comprobación del ID de clúster anunciado para Route 10.3.3.3
Propósito
Compruebe que BGP se está ejecutando en interfaces configuradas y que la sesión BGP está establecida para cada dirección de vecino.
Acción
Desde el modo operativo, ingrese el comando show route advertising-protocol bgp neighbor-address.
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 cliente del dispositivo RR1, el dispositivo R3. Cuando esta ruta se envía 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 Route 10.1.0.1 Español
Propósito
Compruebe el anuncio de ruta del dispositivo RR1 al dispositivo RR2.
Acción
Desde el modo operativo, ingrese el comando show route advertising-protocol bgp neighbor-address .
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 esta ruta se envía 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 se anuncia a otro cliente en un clúster diferente (dispositivo R4).
Descripción de la reflexión de ruta óptima de BGP
Puede configurar la reflexión de ruta óptima BGP (BGP-ORRR) con IS-IS y OSPF como 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 utilizando la métrica IGP más corta desde la perspectiva del cliente, en lugar de la vista del reflector de ruta.
Los grupos de clientes que comparten la misma topología de IGP o una 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 reflectores como nodo principal (igp-primary) en un grupo par BGP de modo que la métrica IGP de ese nodo principal se use para seleccionar la mejor ruta y anunciarla a los clientes del mismo grupo par BGP. Opcionalmente, también puede seleccionar otro nodo reflector como nodo de reserva (igp-backup), que se utiliza cuando el nodo reflector principal (igp-primary) deja de funcionar o es inaccesible.
Para habilitar BGP-ORR, incluya la optimal-route-reflection instrucción en el nivel de jerarquía [edit protocols bgp group group-name].
BGP-ORR solo funciona cuando IGP se usa para la resolución de rutas BGP. BGP-ORR no funciona cuando se utiliza MPLSLDP/RSVP para la resolución de rutas.
Para que BGP-ORR funcione, el prefijo BGP debe resolverse a través de IGP. En escenarios normales de VPN de capa 3, VPN de capa 2, VPLS, MVPN o EVPN, los prefijos se resuelven a través de inet.3. En inet.3, la ruta principal para el siguiente salto del protocolo del prefijo sería RSVP o LDP (y no un protocolo IGP como IS-IS u OSPF). Para que BGP-ORR funcione, debe configurar el enrutador para que use inet.0 para la resolución de ruta de los prefijos 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 VPN de capa 2 o prefijo VPLS:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
Para el prefijo 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 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
Configuración de 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 BGP (BGP-ORRR) con IS-IS y OSPF como 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 utilizando la métrica IGP más corta desde la perspectiva del 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 de IGP o una 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:
Utilice los siguientes comandos de CLI para supervisar y solucionar problemas de configuración de BGP-ORR:
show bgp group: vea las configuraciones principal y de respaldo de 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: ver las entradas en la tabla de enrutamiento OSPFshow route: permite ver las entradas activas en las tablas de enrutamiento.show route advertising protocol bgp peer—Verifique si las rutas se anuncian de acuerdo con las reglas BGP-ORR.
Consulte también
Descripción general de BGP Route Server
Un servidor de rutas BGP es el equivalente BGP externo (EBGP) de un reflector de ruta IBGP interno (IBGP) que simplifica el número de sesiones EBGP directas punto a punto requeridas en una red. Los servidores de rutas 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 proviene de un par 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 EBGP mediante la funcionalidad de servidor de ruta. Esta conectividad puede ser a través de un enlace 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 proporciona accesibilidad de direcciones de circuito cerrado de pares (típico 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 atributo para NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP y comunidades.
Control de políticas por cliente y varias RIB de servidor de ruta para mitigar la ocultación de rutas.
La programabilidad de BGP aprovecha la funcionalidad de servidor de ruta. La API de BGP JET bgp_route_service.proto se ha mejorado para admitir la funcionalidad del servidor de rutas de la siguiente manera:
Programe el servidor de rutas EBGP.
Inyecte rutas a la RIB específica del servidor de rutas para anunciarla selectivamente a los grupos de clientes en las RIB específicas del cliente.
La API de 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 enrutamiento 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 de servidor de enrutamiento es compatible con todas las familias de direcciones EBGP.
- Transparencia de atributos BGP
- Siguiente salto
- Ruta de AS
- Otros atributos
- RIB de cliente de BGP Route Server
- Requisitos y consideraciones de política
Transparencia de atributos BGP
La transparencia de atributos EBGP [RFC7947] para el servidor de rutas se admite mediante la modificación de la propagación de ruta BGP normal de modo que ni los atributos transitivos ni no transitivos se eliminen ni modifiquen mientras se propagan 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 atributos BGP del servidor de enrutamiento.
El servidor de rutas proporciona transparencia de atributos para las configuraciones de EBGP de un solo salto y de múltiples saltos. Por lo tanto, la
route-server-clientconfiguración incluye implícitamente la funcionalidad de para sesiones deno-nexthop-changeun solo salto y de múltiples saltos. Para las sesiones BGP de varios saltos, debe configurar lamultihoppalabra clave.El
route-server-clientse puede configurar en los niveles de protocolo, grupo o vecino de la jerarquía [edit protocol bgp].La
route-server-clientconfiguración sólo es aplicable 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 BGP normal se aplica a la
route-server-clientconfiguración.
Los atributos se manejan de forma independiente con respecto a la transparencia de los atributos. Incluso si el servidor de ruta no puede enviar los saltos siguientes sin modificarlos, otros atributos se envían de forma transparente según corresponda para esos atributos.
A continuación se muestra un ejemplo de route-server-client configuración:
[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 salto siguiente no debe modificarse imponiendo el propio salto siguiente ni modificando el salto siguiente, a menos que se configure explícitamente mediante una directiva. El servidor de enrutamiento debe propagar los próximos saltos del BGP de acuerdo con las reglas del siguiente salto de terceros de RFC 4271.
El comportamiento del siguiente salto se especifica para los siguientes escenarios de servidor de ruta:
En el caso de la interconexión LAN y WAN, cuando el servidor de enrutamiento está conectado a pares de cliente a través de una subred LAN y WAN compartida, el servidor de enrutamiento anuncia los próximos saltos de terceros recibidos sin modificaciones, tal como se define en RFC 4271.
En el caso de la interconexión multisalto del centro de datos, cuando el servidor de enrutamiento está conectado a pares de cliente a través de una interconexión multisalto, se debe configurar el multisalto EBGP y la configuración impone implícitamente el comportamiento de la
no-nexthop-changeconfiguración de CLIroute-server-client. El servidor de enrutamiento anuncia los próximos saltos de terceros recibidos sin modificaciones, según el comportamiento opcional de terceros definido en RFC 4271.En otros casos, como las conexiones punto a punto de un solo salto entre el servidor de enrutamiento y los pares del cliente, se usan procedimientos normales de publicidad del próximo salto para evitar que se anuncien los próximos saltos que podrían ser rechazados por los pares del BGP (por ejemplo, la mayoría de las implementaciones de BGP, de forma predeterminada, rechazan las direcciones de los próximos saltos que no están cubiertas por la dirección de subred en sesiones que no son multipunto.
Ruta de AS
AS-Path no debe modificarse anteponiendo el número de AS local del servidor de rutas. La configuración route-server-client de la CLI para un par suprime el antepuesto del número de AS local en los anuncios. Además, el comando de la show route advertising-protocol bgp peer CLI se ha cambiado para los pares que son clientes del servidor de ruta de manera que el AS local no se muestre en las métricas anunciadas.
Otros atributos
MULTI_EXIT_DISC atributo (opcional, no transitivo) debe propagarse tal como se recibió.
Todos los atributos de la comunidad, incluidas las comunidades extendidas sin publicidad, sin exportación y no transitivas, deben propagarse tal como se recibieron.
El atributo IGP acumulado (AIGP) (opcional, no transitivo) debe propagarse tal como se recibió.
Nota:Junos OS admite AIGP solo para las familias de direcciones BGP-LU (IPv4 e IPv6).
RIB de cliente de BGP Route Server
Una RIB específica del cliente del servidor de rutas es una vista distinta de un Loc-RIB de BGP que puede contener rutas diferentes para el mismo destino que otras vistas. Los clientes del servidor de enrutamiento, a través de sus grupos pares, pueden asociarse a una vista individual específica del cliente o a 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 de BGP para el mismo destino pero en contextos de cliente o grupo diferentes.
Para implementar el requisito de alto nivel de control de políticas flexible con selección de ruta por cliente/grupo, el servidor de enrutamiento BGP adopta el enfoque de usar instancias de enrutamiento sin reenvío (NFI) para varias instancias de la canalización BGP, incluida la selección de ruta BGP, Loc-RIB y política. El servidor de enrutamiento está configurado para agrupar clientes de servidor de rutas dentro de grupos BGP configurados en instancias de enrutamiento independientes que no reenvíen. Este enfoque aprovecha el hecho de que el BGP que se ejecuta dentro de una instancia de enrutamiento realiza una selección de ruta y tiene una RIB que es independiente del BGP que se ejecuta en otras instancias de enrutamiento.
Requisitos y consideraciones de política
Para propagar rutas entre clientes de servidor de rutas, las rutas se filtran entre las RIB de las instancias de enrutamiento en función de las políticas configuradas.
La configuración del servidor de enrutamiento para el control de directivas incluye las siguientes consideraciones:
Los clientes del servidor de enrutamiento deben configurarse dentro de la misma instancia principal o instancia de enrutamiento para recibir la misma vista Loc-RIB.
Los clientes del servidor de enrutamiento deben configurarse dentro de su propia instancia de enrutamiento para recibir vistas Loc-RIB totalmente únicas.
Los clientes del servidor de enrutamiento deben configurarse en diferentes grupos de pares 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 rutas reciban todas las rutas de otras tablas de forma predeterminada, se configura una malla completa de
instance-importdirectivas coninstance-any. Cuando se configurainstance-importcon una directiva que 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 distintas deinstance-importno tiene 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 de un vecino de BGP en una instancia de configuración y una instancia de reenvío. La configuración de la CLI de BGPforwarding-contexttambién admite instancias que no son de reenvío con pares 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 no-forwarding.
Consulte también
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.
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).