Réflecteurs de route BGP
Comprendre les réflecteurs de route BGP
Cette rubrique traite de l’utilisation des réflecteurs de route pour simplifier la configuration et faciliter la mise à l’échelle. Une autre façon de réduire la charge de travail sur un réflecteur de route qui ne se trouve pas dans le chemin de transfert du trafic consiste à utiliser l’instruction no-install au niveau de la [edit protocols bgp family family-name] hiérarchie. À partir de Junos OS version 15.1, l’instruction élimine l’interaction no-install entre le démon des protocoles de routage (rpd) et d’autres composants du système Junos tels que le noyau ou le démon de pare-feu distribué (dfwd). Cette interaction est éliminée en interdisant la publication de toutes les routes dans les bases d’informations de routage (RIB) rpd associées, également appelées tables de routage, dans ces composants.
Dans les versions antérieures à Junos OS version 15.1, vous pouvez réduire la charge de travail sur un réflecteur de route qui ne se trouve pas dans le chemin de transfert du trafic à l’aide d’une stratégie d’exportation de table de transfert qui rejette les routes apprises de BGP.
En raison de l’exigence de maillage intégral interne du BGP (IBGP), la plupart des réseaux utilisent des réflecteurs de route pour simplifier la configuration. La formule de calcul du nombre de sessions requises pour un maillage complet est v * (v - 1)/2, où v est le nombre de périphériques compatibles BGP. Le modèle à maillage intégral n’est pas bien évolutif. À l’aide d’un réflecteur de route, vous regroupez les routeurs en clusters, qui sont identifiés par des identifiants numériques propres au système autonome (AS). Au sein du cluster, vous devez configurer une session BGP à partir d’un routeur unique (le réflecteur de route) vers chaque homologue interne. Avec cette configuration, l’exigence de maillage intégral de l’IBGP est satisfaite.
Pour utiliser la réflexion de route dans un AS, vous devez désigner un ou plusieurs routeurs en tant que réflecteur de route, généralement un par point de présence (POP). Les réflecteurs de route ont la capacité spéciale BGP de republier les routes apprises d’un homologue interne vers d’autres pairs internes. Ainsi, plutôt que d’exiger que tous les homologues internes soient entièrement maillés les uns avec les autres, la réflexion de route nécessite seulement que le réflecteur de route soit entièrement maillé avec tous les pairs internes. Le réflecteur de route et tous ses homologues internes forment un cluster, comme illustré à Figure 1la .
Pour certains équipements Juniper Networks, une licence de fonctionnalité BGP avancée doit être installée sur chaque équipement qui utilise un réflecteur de route. Pour plus d’informations sur les licences, reportez-vous au Guide d’installation et de mise à niveau des logiciels.
Figure 1 affiche le RR du routeur configuré en tant que réflecteur de route pour le cluster 127. Les autres routeurs sont désignés comme homologues internes au sein du cluster. Les routes BGP sont annoncées sur le RR du routeur par n’importe lequel des homologues internes. RR publie ensuite à nouveau ces routes à tous les autres homologues du cluster.
Vous pouvez configurer plusieurs clusters et les lier en configurant un maillage complet de réflecteurs de route (reportez-vous à la section Figure 2).
Figure 2 affiche les réflecteurs de route RR 1, RR 2, RR 3 et RR 4 en tant qu’homologues internes entièrement maillés. Lorsqu’un routeur annonce une route vers RR 1, RR 1 annonce à nouveau la route aux autres réflecteurs de route, qui, à leur tour, annoncent à nouveau la route aux routeurs restants dans l’AS. La réflexion de route permet à la route d’être propagée dans l’ensemble de l’AS sans les problèmes de mise à l’échelle créés par l’exigence de maillage complet.
Un réflecteur de route qui prend en charge plusieurs clusters n’accepte pas une route avec le même ID de cluster provenant d’un routeur non-client. Par conséquent, vous devez configurer un ID de cluster différent pour un RR redondant afin de refléter le chemin vers d’autres clusters.
Cependant, à mesure que les agrégats deviennent grands, un maillage complet avec un réflecteur de route devient difficile à mettre à l’échelle, tout comme un maillage complet entre des réflecteurs de route. Pour pallier ce problème, vous pouvez regrouper des clusters de routeurs en clusters de clusters pour une réflexion hiérarchique sur le routage (reportez-vous à Figure 3la section ).
Figure 3 montre RR 2, RR 3 et RR 4 comme réflecteurs de route pour les amas 127, 19 et 45, respectivement. Plutôt que de mailler entièrement ces réflecteurs de route, l’administrateur réseau les a configurés dans le cadre d’un autre cluster (cluster 6) pour lequel RR 1 est le réflecteur de route. Lorsqu’un routeur annonce une route vers RR 2, RR 2 annonce à nouveau la route à tous les routeurs de son propre cluster, puis annonce à nouveau la route vers RR 1. RR 1 annonce à nouveau la route aux routeurs de son cluster, et ces routeurs propagent la route vers le bas à travers leurs clusters.
Voir également
Exemple : Configuration d’un réflecteur de route
Cet exemple montre comment configurer un réflecteur de route.
Conditions préalables
Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.
Présentation
En règle générale, les périphériques internes compatibles BGP (IBGP) doivent être entièrement maillés, car IBGP ne renouvelle pas les mises à jour vers d’autres périphériques compatibles IBGP. Le maillage complet est un maillage logique obtenu grâce à la configuration de plusieurs neighbor instructions sur chaque périphérique compatible IBGP. Le maillage complet n’est pas nécessairement un maillage complet physique. Le maintien d’un maillage complet (logique ou physique) n’est pas adapté aux déploiements à grande échelle.
Figure 4 montre un réseau IBGP avec l’appareil A agissant comme réflecteur de route. L’appareil B et l’appareil C sont les clients du réflecteur de route. Les périphériques D et E se trouvent à l’extérieur du cluster, ils sont donc des non-clients du réflecteur de route.
Sur le périphérique A (le réflecteur de route), vous devez établir des relations d’homologue avec tous les périphériques compatibles IBGP en incluant l’instruction neighbor pour les clients (périphérique B et périphérique C) et les non-clients (périphérique D et périphérique E). Vous devez également inclure l’instruction cluster et un identificateur de cluster. L’identificateur de cluster peut être n’importe quelle valeur de 32 bits. Cet exemple utilise l’adresse IP de l’interface de bouclage du réflecteur de route.
Sur les périphériques B et C, les clients du réflecteur de route, vous n’avez besoin que d’une neighbor seule instruction qui forme une relation d’homologue avec le réflecteur de route, le périphérique A.
Sur les périphériques D et E, les non-clients, vous avez besoin d’une neighbor instruction pour chaque périphérique non-client (D-to-E et E-to-D). Vous avez également besoin d’une neighbor instruction pour le réflecteur de route (D-to-A et E-to-A). Les périphériques D et E n’ont pas besoin d’instructions neighbor pour les périphériques clients (périphériques B et C).
L’appareil D et l’appareil E sont considérés comme des non-clients, car ils ont explicitement configuré des relations d’égal à égal l’un avec l’autre. Pour en faire des clients RRroute reflector, supprimez l’instruction neighbor 192.168.5.5 de la configuration sur le périphérique D, et supprimez-la neighbor 192.168.0.1 de la configuration sur le périphérique E.
Configuration
- Procédure
- Configuration du réflecteur de route
- Configuration des homologues clients
- Configuration d’homologues non-clients
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.
Appareil 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
Appareil 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
Appareil 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
Appareil 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
Dispositif 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
Procédure étape par étape
Configuration du réflecteur de route
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer IBGP dans le réseau en utilisant l’équipement A de Juniper Networks comme réflecteur de route :
Configurez les 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
Configurez BGP, y compris l’identificateur de cluster et les relations de voisinage avec tous les équipements compatibles IBGP dans le système autonome (AS).
Appliquez également la stratégie qui redistribue les routes OSPF dans 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
Configurez un routage statique ou un protocole IGP (Interior Gateway Protocol).
Cet exemple utilise 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
Configurez la stratégie qui redistribue les routes OSPF dans BGP.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
Configurez l’ID du routeur et le numéro du système autonome (AS).
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show policy-optionset show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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 vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Répétez ces étapes pour chaque pair BGP non client dans le cluster que vous configurez, si les autres équipements non clients proviennent de Juniper Networks. Sinon, consultez la documentation de l’appareil pour obtenir des instructions.
Configuration des homologues clients
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer les homologues clients :
Configurez les 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
Configurez la relation de voisinage BGP avec le réflecteur de route.
Appliquez également la stratégie qui redistribue les routes OSPF dans 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
Configurez 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
Configurez la stratégie qui redistribue les routes OSPF dans BGP.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
Configurez l’ID du routeur et le numéro AS.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show policy-optionset show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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 vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Répétez ces étapes pour chaque pair BGP client dans le cluster que vous configurez si les autres périphériques clients proviennent de Juniper Networks. Sinon, consultez la documentation de l’appareil pour obtenir des instructions.
Configuration d’homologues non-clients
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer des homologues non-clients :
Configurez les 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
Configurez les relations de voisinage BGP avec le réflecteur RRroute et avec les autres homologues non clients.
Appliquez également la stratégie qui redistribue les routes OSPF dans 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
Configurez 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
Configurez la stratégie qui redistribue les routes OSPF dans BGP.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
Configurez l’ID du routeur et le numéro AS.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , show protocols, show policy-optionset show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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 vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Répétez ces étapes pour chaque pair BGP non client du cluster que vous configurez si les autres équipements non clients proviennent de Juniper Networks. Sinon, consultez la documentation de l’appareil pour obtenir des instructions.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification des voisins BGP
- Vérification des groupes BGP
- Vérification des informations récapitulatives BGP
- Vérification des informations de la table de routage
Vérification des voisins BGP
But
Vérifiez que BGP est en cours d’exécution sur les interfaces configurées et que la session BGP est établie pour chaque adresse voisine.
Action
À partir du mode opérationnel, entrez la show bgp neighbor commande.
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]: 0Vérification des groupes BGP
But
Vérifiez que les groupes BGP sont correctement configurés.
Action
À partir du mode opérationnel, entrez la show bgp group commande.
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
Vérification des informations récapitulatives BGP
But
Vérifiez que la configuration BGP est correcte.
Action
À partir du mode opérationnel, entrez la show bgp summary commande.
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
Vérification des informations de la table de routage
But
Vérifiez que la table de routage contient les routes IBGP.
Action
À partir du mode opérationnel, entrez la show route commande.
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
MultiRecvComprendre un réflecteur de route appartenant à deux clusters différents
L’objectif de la réflexion de route est d’éviter les boucles lorsque les périphériques de routage BGP (IBGP) internes ne sont pas entièrement maillés. Pour ce faire, les RR enfreignent l’une des règles du fonctionnement normal du BGP : Ils republient les routes apprises d’un pair BGP interne vers d’autres homologues BGP internes.
Normalement, un seul RR n’est membre que d’un seul cluster. Considérons, par exemple, que dans une conception de RR hiérarchique, un RR de niveau deux peut être le client d’un RR de niveau 1, mais qu’ils ne peuvent pas être clients l’un de l’autre.
Toutefois, lorsque deux RR sont clients l’un de l’autre et que les routes sont reflétées d’un cluster à un autre, un seul des ID de cluster est inclus dans la liste des clusters. En effet, le fait d’avoir un ID de cluster dans la liste des clusters est suffisant pour la prévention des boucles dans ce cas.
Tableau 1 Récapitule les règles utilisées par les réflecteurs de route pour remplir la liste de clusters d’une route réfléchie avec des ID de cluster.
Scénario de réflexion de route |
Configuration |
|---|---|
Lors de la réflexion d’un routage entre l’un des clients et un routeur non-client client -> RR -> non-client |
Le RR remplit l’ID de cluster associé à ce client dans la liste des clusters de l’itinéraire réfléchi. |
Lors de la réflexion d’un routage d’un routeur non-client vers un routeur client non-client -> RR -> client |
Le RR remplit l’ID de cluster associé à ce client dans la liste des clusters de l’itinéraire réfléchi. |
Lors de la réflexion d’un routage d’un routeur client vers un autre routeur client se trouvant dans un cluster différent client1 -> RR -> client2 (cluster différent) |
Le RR remplit l’ID de cluster associé à client1 dans la liste de cluster avant de refléter l’ID de cluster à client2. L’ID de cluster associé au client 2 n’est pas ajouté. |
Lors de la réflexion d’un routage entre un routeur client et un routeur non-client se trouvant dans un autre système autonome. Par exemple, lorsque vous avez configuré un RR de niveau 2 et 2 groupes BGP, l’un pour les clients RR et l’autre pour le RR de niveau 1, et que vous reflétez un itinéraire d’un système autonome à un autre système autonome. client -> RR -> non-client (AS différent) |
Le RR ne remplit pas la liste des clusters avec l’ID de cluster avant de refléter l’itinéraire vers l’appareil non-client, car l’ID de cluster est spécifique à un système autonome. |
Voir également
Exemple : Configuration d’un réflecteur de route appartenant à deux clusters différents
Cet exemple montre comment configurer un réflecteur de route (RR) qui appartient à deux clusters différents. Ce n’est pas un scénario courant, mais il peut être utile dans certaines situations.
Conditions préalables
Configurez les interfaces de l’appareil et un protocole de passerelle interne (IGP). Pour obtenir un exemple de configuration RR incluant l’interface et la configuration IGP, reportez-vous à la section Exemple : Configuration d’un réflecteur de route.
Présentation
Dans cet exemple, le périphérique RR1 est un réflecteur de route pour le périphérique R3 et le périphérique RR2. Deux ID de cluster différents sont attribués au réflecteur de route RR1, l’un est 10.13.1.3 pour RR1-R3 et 10.12.1.2 pour RR1-RR2.
Le périphérique RR2 est un réflecteur de route pour le périphérique R4.
Considérons la figure Figure 5.
Cet exemple montre la configuration BGP sur les périphériques RR1 et RR2.
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.
Appareil 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
Appareil 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
Configuration de l’appareil RR1
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer l’appareil RR1 :
-
Configurez la relation d’appairage avec l’appareil 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
-
Configurez la relation d’appairage avec l’appareil 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
-
Configurez la relation d’appairage avec l’appareil 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
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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 vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration de l’appareil RR2
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer l’appareil RR2 :
-
Configurez la relation d’appairage avec l’appareil 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
-
Configurez la relation d’appairage avec l’appareil 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
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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 vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’ID de cluster annoncé pour Route 10.3. Le3. Le3
- Vérification de l’ID de cluster annoncé pour Route 10.1.0,1
Vérification de l’ID de cluster annoncé pour Route 10.3. Le3. Le3
But
Vérifiez que BGP est en cours d’exécution sur les interfaces configurées et que la session BGP est établie pour chaque adresse voisine.
Action
À partir du mode opérationnel, entrez la show route advertising-protocol bgp neighbor-address commande.
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
Sens
Le 10.3. Le3. LeLa route 3/32 provient de l’homologue client de l’appareil RR1, l’appareil R3. Lorsque cette route est envoyée au client de RR1, l’appareil RR2, la route a le 10.Débloquer le niveau 13.1. Le 3 ID de cluster attaché, qui est l’ID de cluster pour RR1-R3.
Vérification de l’ID de cluster annoncé pour Route 10.1.0,1
But
Vérifiez l’annonce de routage de l’appareil RR1 vers l’appareil RR2.
Action
À partir du mode opérationnel, entrez la show route advertising-protocol bgp neighbor-address commande.
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.1Sens
Le 10.1.La route 0.1/32 provient de l’homologue non-client de l’appareil RR1, l’appareil R0. Lorsque cette route est envoyée au client de RR1, l’appareil RR2, la route a le 10.Débloquer le niveau 12.1. Le 2 ID de cluster attaché, qui est l’ID de cluster pour RR1-RR2.
L’appareil RR1 conserve l’ID de cluster entrant de l’appareil RR2 lors de l’annonce à un autre client dans un autre cluster (appareil R4).
Comprendre la réflexion optimale du routage BGP
Vous pouvez configurer BGP Optimal Route Reflection (BGP-ORR) avec IS-IS et OSPF en tant que protocole de passerelle intérieure (IGP) sur un réflecteur de route pour annoncer le meilleur chemin aux groupes de clients BGP-ORR. Pour ce faire, la métrique IGP la plus courte est utilisée du point de vue du client, au lieu de la vue du réflecteur de route.
Les groupes de clients partageant la même topologie IGP ou une topologie similaire peuvent être regroupés en un seul groupe homologue pair BGP. Vous pouvez configurer optimal-route-reflection pour activer BGP-ORR dans ce groupe pair BGP. Vous pouvez également configurer l’un des noeuds réflecteurs en tant que noeud principal (igp-primary) dans un groupe homologue pair BGP afin que la métrique IGP de ce noeud principal soit utilisée pour sélectionner le meilleur chemin et l’annoncer aux clients du même groupe homologue pair BGP. Si vous le souhaitez, vous pouvez également sélectionner un autre noeud de réflecteur comme noeud de secours (igp-backup), qui est utilisé lorsque le noeud de réflecteur principal (igp-primary) tombe en panne ou est inaccessible.
Pour activer BGP-ORR, incluez l’instruction optimal-route-reflection au niveau de la hiérarchie [edit protocols bgp group group-name].
BGP-ORR ne fonctionne que lorsque IGP est utilisé pour la résolution de routage BGP. BGP-ORR ne fonctionne pas lorsque MPLSLDP/RSVP est utilisé pour la résolution de route.
Pour que BGP-ORR fonctionne, le préfixe BGP doit être résolu via IGP. Dans les scénarios normaux de VPN de couche 3, ou VPN de couche 2, ou VPLS, ou MVPN, ou EVPN, les préfixes sont résolus via inet.3. Dans inet.3, la route principale pour le protocole-next-hop du préfixe serait RSVP ou LDP (et non un protocole IGP comme IS-IS ou OSPF). Pour que BGP-ORR fonctionne, vous devez configurer le routeur pour qu’il utilise inet.0 pour la résolution de routage des préfixes VPN de couche 3, VPN de couche 2, VPLS, MVPN ou EVPN. Vous pouvez le faire à l’aide des commandes suivantes :
-
Pour le préfixe VPN de couche 3 :
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
-
Pour le VPN de couche 2, ou préfixe VPLS :
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
Pour le préfixe EVPN :
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
-
Pour le préfixe MVPN :
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
Une autre méthode consiste à faire fuiter les routes IGP dans inet.3 et à en faire la route principale dans inet.3.
Utilisez la hiérarchie CLI suivante pour configurer BGP-ORR :
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
Voir également
Configuration de BGP Optimal Route Reflection sur un réflecteur de route pour annoncer le meilleur chemin
Vous pouvez configurer BGP Optimal Route Reflection (BGP-ORR) avec IS-IS et OSPF en tant que protocole de passerelle intérieure (IGP) sur un réflecteur de route pour annoncer le meilleur chemin aux groupes de clients BGP-ORR. Pour ce faire, la métrique IGP la plus courte est utilisée du point de vue du client, au lieu de la vue du réflecteur de route.
Pour activer BGP-ORR, incluez l’instruction optimal-route-reflection au niveau de la hiérarchie [edit protocols bgp group group-name].
Les groupes de clients partageant la même topologie IGP ou une topologie similaire peuvent être regroupés en un seul groupe homologue pair BGP. Vous pouvez configurer optimal-route-reflection pour activer BGP-ORR dans ce groupe pair BGP.
Pour configurer BGP-ORR :
Utilisez les commandes CLI suivantes pour surveiller et dépanner la configuration de BGP-ORR :
show bgp group: permet d’afficher les configurations principale et secondaire de BGP-ORR.show isis bgp-orr: permet d’afficher la métrique IS-IS BGP-ORR (RIB).show ospf bgp-orr: permet d’afficher la métrique OSPF BGP-ORR (RIB).show ospf route—Afficher les entrées de la table de routage OSPFshow route: permet d’afficher les entrées actives dans les tables de routage.show route advertising protocol bgp peer: vérifiez si les routes sont annoncées conformément aux règles BGP-ORR.
Voir également
Présentation du serveur de routage BGP
Un serveur de routage BGP est l’équivalent BGP externe (EBGP) d’un réflecteur de route IBGP interne qui simplifie le nombre de sessions EBGP point à point directes requises dans un réseau. Les serveurs de routage EBGP sont transparents en termes de propagation des attributs BGP, de sorte qu’un routage reçu d’un serveur de routage porte l’ensemble des attributs BGP (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP et Communities) s’il provient d’un homologue EBGP directement connecté.
Comme pour un réflecteur de route IBGP, un serveur de route EBGP est attaché à un réseau en dehors du chemin de transfert direct entre les homologues EBGP à l’aide de la fonctionnalité de serveur de route. Cette connectivité peut se faire via une liaison physique directe, ou via des réseaux de couche 2 tels qu’un VPLS LAN ou EVPN, ou via une fabric IP de liaisons EBGP point à point assurant l’accessibilité des adresses loopback des pairs (typique des réseaux de datacenter).
Le protocole BGP a été amélioré pour fournir une fonctionnalité de serveur de routage avec les fonctionnalités suivantes décrites dans la RFC 7947 :
Attribuez la transparence pour NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP et Communities.
Contrôle des stratégies par client et plusieurs RIB de serveur de routage pour atténuer le masquage des chemins.
La programmabilité BGP s’appuie sur la fonctionnalité de serveur de routage. L’API JET bgp_route_service.proto BGP a été améliorée pour prendre en charge la fonctionnalité de serveur de routage comme suit :
Programmez le serveur de route EBGP.
Injectez des routes dans le RIB spécifique du serveur de routes pour les annoncer de manière sélective aux groupes de clients dans des RIB spécifiques au client.
L’API JET bgp_route_service.proto BGP inclut un objet de type homologue qui identifie les routes individuelles comme EBGP ou IBGP (par défaut).
La fonctionnalité du serveur de routage est généralement indépendante de la famille d’adresses, bien que la prise en charge de certains attributs BGP spécifiques puisse être spécifique à la famille d’adresses (par exemple, AIGP n’est pris en charge que pour les familles d’adresses unicast étiquetées). La fonctionnalité de serveur de routage est prise en charge pour toutes les familles d’adresses EBGP.
- Transparence des attributs BGP
- Saut suivant
- AS-Chemin
- Autres attributs
- Rib client du serveur de routage BGP
- Exigences et considérations relatives à la stratégie
Transparence des attributs BGP
La transparence de l’attribut EBGP [RFC7947] pour le serveur de routage est prise en charge en modifiant la propagation normale de la route BGP de sorte que ni les attributs transitifs ou non transitifs ne soient supprimés ou modifiés lors de la propagation des routes.
Les modifications apportées au comportement normal de l’EBGP sont contrôlées par la configuration de l’interface de ligne de route-server-client commande. La route-server-client configuration de l’interface de ligne de commande au niveau de la hiérarchie [edit protocols bgp group group-name] implémente le comportement de transparence des attributs BGP du serveur de routage.
Le serveur de routage assure la transparence des attributs pour les configurations EBGP à saut unique et à sauts multiples. Par conséquent, la
route-server-clientconfiguration inclut implicitement la fonctionnalité deno-nexthop-changepour les sessions à un ou plusieurs sauts. Pour les sessions BGP à sauts multiples, vous devez configurer lemultihopmot-clé.Le
route-server-clientpeut être configuré au niveau du protocole, du groupe ou du voisin de la hiérarchie [edit protocol bgp].La
route-server-clientconfiguration n’est applicable que lorsque le type de groupe est external. Lorsque le estroute-server-clientconfiguré pour internal des groupes, une erreur de configuration est émise lors de la tentative de validation.La
route-server-clientconfiguration n’a pas de paramètres.Le privilège BGP normal s’applique à la
route-server-clientconfiguration.
Les attributs sont gérés indépendamment en ce qui concerne la transparence des attributs. Même si les next-hops ne peuvent pas être envoyés sans modification par le serveur de route, d’autres attributs sont envoyés de manière transparente en fonction de ces attributs.
Voici un exemple route-server-client de configuration :
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
Saut suivant
L’attribut next-hop ne doit pas être modifié en imposant next-hop self ou en modifiant le next-hop, sauf s’il est explicitement configuré par le biais d’une stratégie. Le serveur de routage doit propager les sauts suivants BGP conformément aux règles de saut suivant tierces de la RFC 4271.
Le comportement de saut suivant est spécifié pour les scénarios de serveur de routage suivants :
Dans le cas de l’interconnexion LAN et WAN, lorsque le serveur de routage est connecté à des homologues clients par le biais d’un sous-réseau LAN et WAN partagés, les next-hops tiers reçus sont annoncés par le serveur de routage sans modification, comme défini dans la RFC 4271.
Dans le cas de l’interconnexion à sauts multiples de centres de données, lorsque le serveur de routage est connecté à des homologues clients par le biais d’une interconnexion à sauts multiples, le saut multiple EBGP doit être configuré et le comportement de la
no-nexthop-changeconfiguration CLI est implicitement imposé par laroute-server-clientconfiguration. Les next-hops tiers reçus sont annoncés par le serveur de routage sans modification, conformément au comportement tiers facultatif défini dans la RFC 4271.Dans d’autres cas, tels que les connexions point à point par saut unique entre le serveur de routage et les homologues clients, les procédures normales d’annonce de saut suivant sont utilisées pour empêcher la publication de sauts suivants qui pourraient être rejetés par les homologues BGP (par exemple, la plupart des implémentations BGP, par défaut, rejettent les adresses de saut suivant qui ne sont pas couvertes par l’adresse de sous-réseau sur les sessions non multipoints.
AS-Chemin
AS-Path ne doit pas être modifié en préfixant le numéro AS local du serveur de routage. La configuration route-server-client de l’interface de ligne de commande pour un homologue supprime le préfixe du numéro d’AS local dans les publications. En outre, la show route advertising-protocol bgp peer commande CLI est modifiée pour les homologues qui sont des clients de serveur de routage, de sorte que l’AS local n’est pas affiché dans les métriques annoncées.
Autres attributs
MULTI_EXIT_DISC attribut (facultatif, non transitif) doit être propagé tel qu’il a été reçu.
Tous les attributs de communauté, y compris les communautés étendues sans publicité, sans exportation et non transitives, doivent être propagés tels qu’ils ont été reçus.
L’attribut IGP cumulé (AIGP) (facultatif, non transitif) doit être propagé tel qu’il a été reçu.
REMARQUE :Junos OS prend en charge AIGP uniquement pour les familles d’adresses BGP-LU (IPv4 et IPv6).
Rib client du serveur de routage BGP
Un RIB spécifique au client d’un serveur de routage est une vue distincte d’un Loc-RIB BGP qui peut contenir des routes différentes pour la même destination que les autres vues. Les clients du serveur de routage, par l’intermédiaire de leurs groupes homologues, peuvent s’associer à une vue individuelle spécifique au client ou à un RIB commun partagé.
Afin de permettre d’annoncer différents itinéraires à différents clients pour la même destination, il est conceptuellement nécessaire d’autoriser plusieurs instances de la sélection de chemin BGP pour la même destination, mais dans des contextes de client/groupe différents.
Pour implémenter l’exigence de haut niveau d’un contrôle flexible des stratégies avec sélection de chemin par client/groupe, le serveur de routage BGP utilise des instances de routage sans transfert (NFI) pour multi-instancier le pipeline BGP, y compris la sélection du chemin BGP, le Loc-RIB et la stratégie. Le serveur de routage est configuré pour regrouper les clients du serveur de routage au sein de groupes BGP configurés dans des instances de routage distinctes autres que le transfert. Cette approche tire parti du fait que BGP s’exécutant dans une instance de routage sélectionne le chemin et possède un RIB distinct du BGP exécuté dans d’autres instances de routage.
Exigences et considérations relatives à la stratégie
Pour propager les routes entre les clients du serveur de routage, les routes sont divulguées entre les RIB des instances de routage en fonction des stratégies configurées.
La configuration du serveur de routage pour le contrôle des stratégies inclut les considérations suivantes :
Les clients du serveur de routage doivent être configurés dans la même instance principale ou instance de routage pour recevoir la même vue Loc-RIB.
Les clients du serveur de routage doivent être configurés dans leur propre instance de routage pour recevoir des vues Loc-RIB totalement uniques.
Les clients du serveur de routage doivent être configurés dans différents groupes homologues pair BGP dans la même instance de routage pour avoir une stratégie d’exportation différente sur la même vue Loc-RIB.
Pour que les vues RIB spécifiques au client du serveur de routes reçoivent par défaut toutes les routes d’autres tables, un maillage complet de
instance-importstratégies est configuré avecinstance-any. Lors de la configurationinstance-importavec une stratégie contenantinstance-any:instance-anyPeut être utilisé dans :policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-anyn’a pas de paramètres.L’utilisation
instance-anydans des stratégies autres queinstance-importn’a aucun effet.
La configuration d’un grand nombre d’instances de routage et de groupes homologues distincts a un impact sur l’échelle et les performances.
La configuration de l’interface de ligne de commande BGP
forwarding-contextau niveau de la hiérarchie [edit protocols bgp group neighbor] divise l’instance de routage d’un voisin BGP en une instance de configuration et une instance de transfert. La configuration de l’interface de ligne de commande BGPforwarding-contextprend également en charge les instances sans transfert avec des homologues BGP configurés commeroute-server-clientl’instance spécifiée est une instance capable de transférer une instance principale ou une instance de routage qui n’est pas de type no-forwarding.
Voir également
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
no-install entre le démon des protocoles de routage (rpd) et d’autres composants du système Junos tels que le noyau ou le démon de pare-feu distribué (dfwd).