Réflecteurs de route BGP
Comprendre les réflecteurs de route BGP
Cette rubrique traite de l’utilisation de réflecteurs de route pour simplifier la configuration et faciliter l’évolutivité. Un autre moyen de réduire la charge de travail sur un réflecteur de route qui n’est pas dans le chemin de transfert de trafic est d’utiliser l’instruction no-install au niveau de la [edit protocols bgp family family-name] hiérarchie. À partir de la version 15.1 de Junos OS, l’instruction élimine l’interaction no-install entre le daemon 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 toute publication de routes dans les bases d’informations de routage (RIB) associées, également appelées tables de routage, d’être publiées vers 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 n’est pas dans le chemin de transfert de trafic à l’aide d’une stratégie d’exportation de table de transfert qui rejette les routes apprises par BGP.
En raison de l’exigence interne de maillage complet BGP (IBGP), la plupart des réseaux utilisent des réflecteurs de route pour simplifier la configuration. La formule pour calculer le nombre de sessions requises pour un maillage complet est v * (v - 1)/2, où v est le nombre d’équipements compatibles BGP. Le modèle full-mesh n’évolue pas bien. À l’aide d’un réflecteur de route, vous regroupez les routeurs en clusters, qui sont identifiés par des identifiants numériques uniques au système autonome (AS). Dans le cluster, vous devez configurer une session BGP à partir d’un seul routeur (le réflecteur de route) vers chaque homologue interne. Avec cette configuration, la condition de maillage complet IBGP est satisfaite.
Pour utiliser la réflexion de route dans un AS, vous désignez un ou plusieurs routeurs comme 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 réévertir les routes apprises d’un pair interne vers d’autres pairs internes. Ainsi, plutôt que d’exiger que tous les pairs internes soient entièrement en maillage les uns avec les autres, la réflexion de route nécessite seulement que le réflecteur de route soit entièrement en maillage avec tous les pairs internes. Le réflecteur de route et tous ses pairs internes forment un cluster, comme illustré dans Figure 1.
Pour certains équipements Juniper Networks, vous devez disposer d’une licence de fonctionnalités BGP avancées installée sur chaque équipement qui utilise un réflecteur de route. Pour plus de détails sur les licences, consultez le Guide d’installation et de mise à niveau des logiciels.
Figure 1 affiche le routeur RR configuré en tant que réflecteur de route pour le cluster 127. Les autres routeurs sont désignés pairs internes au sein du cluster. Les routes BGP sont annoncées au routeur RR par n’importe quel pair interne. RR les revertit ensuite vers tous les autres pairs du cluster.
Vous pouvez configurer plusieurs clusters et les relier en configurant un maillage complet de réflecteurs de route (voir Figure 2).
Figure 2 affiche les réflecteurs de route RR 1, RR 2, RR 3 et RR 4 comme des pairs internes entièrement maillés. Lorsqu’un routeur annonce une route vers RR 1, LA 1 révertise la route vers les autres réflecteurs de route, qui, à leur tour, révertissent la route vers les routeurs restants dans l’AS. La réflexion de route permet de propager la route à travers l’AS sans les problèmes d’évolutivité créés par l’exigence de maillage complet.
Un réflecteur de route qui prend en charge plusieurs clusters n’accepte pas un routage avec le même ID de cluster provenant d’un routeur non client. Par conséquent, vous devez configurer un autre ID de cluster pour un RR redondant afin de refléter le chemin vers d’autres clusters.
Cependant, à mesure que les clusters deviennent importants, un maillage complet avec un réflecteur de route devient difficile à mettre à l’échelle, tout comme un maillage complet entre les réflecteurs de route. Pour compenser ce problème, vous pouvez regrouper des clusters de routeurs en clusters pour une réflexion hiérarchique des routes (voir Figure 3).
Figure 3 montre RR 2, RR 3 et RR 4 comme réflecteurs de route pour les clusters 127, 19 et 45, respectivement. Plutôt que de mailler complètement 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 lavertit vers tous les routeurs de son propre cluster, puis la revertit vers RR 1. RR 1 redéfinit le routage vers les routeurs de son cluster, et ces routeurs propagent le chemin vers le bas via 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’équipement n’est requise avant de configurer cet exemple.
Présentation
En règle générale, les équipements internes compatibles BGP (IBGP) doivent être entièrement maillage, car IBGP ne lit pas les mises à jour des autres équipements compatibles IBGP. Le maillage complet est un maillage logique obtenu grâce à la configuration de plusieurs neighbor déclarations sur chaque équipement compatible IBGP. Le maillage complet n’est pas nécessairement un maillage complet physique. La maintenance d’un maillage complet (logique ou physique) n’est pas bien évolutive dans les déploiements de grande envergure.
Figure 4 affiche un réseau IBGP avec un équipement A agissant comme un réflecteur de route. Les équipements B et C sont des clients du réflecteur de route. Les équipements D et E se trouvent en dehors du cluster. Ils ne sont donc pas des clients du réflecteur de route.
Sur l’équipement A (le réflecteur de route), vous devez former des relations d’appairage avec tous les équipements compatibles IBGP en incluant l’instruction neighbor des clients (équipement B et équipement C) et des non-clients (équipement D et équipement E). Vous devez également inclure l’instruction cluster et un identifiant de cluster. L’identifiant du cluster peut être n’importe quelle valeur 32 bits. Cet exemple utilise l’adresse IP de l’interface de bouclage du réflecteur de route.
Sur l’équipement B et l’équipement C, les clients de réflecteur de route, vous n’avez besoin que d’une seule neighbor déclaration qui forme une relation d’appairage avec le réflecteur de route, l’équipement A.
Sur l’équipement D et l’équipement E, les non-clients, vous avez besoin d’une neighbor déclaration pour chaque équipement non client (D-à-E et E-à-D). Vous avez également besoin d’une neighbor déclaration pour le réflecteur de route (D-to-A et E-to-A). Les équipements D et E n’ont pas besoin d’instructions neighbor pour les équipements clients (équipement B et équipement C).
Les équipements D et E sont considérés comme des non-clients, car ils ont explicitement configuré des relations d’appairage entre eux. Pour créer des clients de réflecteur RRroute, supprimez l’instruction neighbor 192.168.5.5 de la configuration sur l’équipement D et supprimez l’instruction neighbor 192.168.0.1 de la configuration sur l’équipement E.
Configuration
- Procédure
- Configuration du réflecteur de route
- Configuration des pairs clients
- Configuration des pairs non-clients
Procédure
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
Équipement 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
Équipement 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
Équipement 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
Équipement 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
Équipement 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
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer IBGP sur le réseau à l’aide de l’équipement Juniper Networks A 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’identifiant du 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 le 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 entrant le show interfaces, show protocols, show policy-optionset les show routing-options commandes. 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Répétez ces étapes pour chaque homologue BGP non client dans le cluster que vous configurez, si les autres équipements non-clients sont de Juniper Networks. Sinon, consultez la documentation de l’équipement pour obtenir des instructions.
Configuration des pairs clients
Procédure étape par étape
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer des pairs 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 entrant le show interfaces, show protocols, show policy-optionset les show routing-options commandes. 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Répétez ces étapes pour chaque homologue BGP client dans le cluster que vous configurez si les autres équipements clients sont de Juniper Networks. Sinon, consultez la documentation de l’équipement pour obtenir des instructions.
Configuration des pairs non-clients
Procédure étape par étape
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer des pairs 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 pairs non client.
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 entrant le show interfaces, show protocols, show policy-optionset les show routing-options commandes. 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Répétez ces étapes pour chaque homologue BGP non client dans le cluster que vous configurez si les autres équipements non-clients sont de Juniper Networks. Sinon, consultez la documentation de l’équipement 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 de synthèse BGP
- Vérification des informations de table de routage
Vérification des voisins BGP
But
Vérifiez que BGP s’exécute sur des interfaces configurées et que la session BGP est établie pour chaque adresse voisine.
Action
Depuis le mode opérationnel, saisissez 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
Depuis le mode opérationnel, saisissez 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 de synthèse BGP
But
Vérifiez que la configuration BGP est correcte.
Action
Depuis le mode opérationnel, saisissez 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 table de routage
But
Vérifiez que la table de routage contient les routes IBGP.
Action
Depuis le mode opérationnel, saisissez 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 de prévenir les boucles lorsque les équipements de routage BGP internes (IBGP) ne sont pas entièrement maillage. Pour ce faire, les RR en rupture avec l’une des règles du fonctionnement BGP normal : Ils revertissent les routes apprises d’un pair BGP interne vers d’autres pairs BGP internes.
Normalement, un seul RR est membre d’un seul cluster. Prenons, par exemple, que dans une conception RR hiérarchique, un RR de niveau 2 peut être le client d’un RR de niveau 1, mais ils ne peuvent pas être des clients les uns des autres.
Toutefois, lorsque deux RR sont des clients l’un de l’autre et que les routes sont reflétées d’un cluster à l’autre, seul l’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 prévenir les boucles dans ce cas.
Tableau 1 résume les règles que les réflecteurs de route utilisent pour remplir la liste de clusters d’un routage réfléchi avec des ID de cluster.
Scénario de réflexion de route |
Configuration |
|---|---|
Lors de la réflexion d’un routage de l’un des clients vers un routeur non client client -> RR -> non-client |
Le RR remplit l’ID de cluster associé à ce client dans la liste des clusters du routage 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 du routage réfléchi. |
Lors de la réflexion d’un routage d’un routeur client vers un autre routeur client qui se trouve dans un autre cluster client1 -> RR -> client2 (cluster différent) |
Le RR remplit l’ID de cluster associé au client1 dans la liste des clusters avant de refléter l’ID de cluster vers le client2. L’ID de cluster associé au client 2 n’est pas ajouté. |
Lors de la réflexion d’un routage d’un routeur client vers un routeur non-client qui se trouve dans un système autonome différent. Par exemple, lorsque vous avez configuré un groupe RR de niveau 2 et 2 BGP, un pour les clients RR et l’autre pour le RR de niveau 1, et que vous réfléchissez à un routage d’un système autonome vers un autre système autonome. client -> RR -> non-client (AS différent) |
Le RR ne remplit pas la liste de clusters avec l’ID de cluster avant de refléter la route vers l’équipement 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) appartenant à deux clusters différents. Ce scénario n’est pas courant, mais il peut être utile dans certaines situations.
Conditions préalables
Configurez les interfaces des équipements et un protocole de passerelle interne (IGP). Pour obtenir un exemple de configuration RR comprenant l’interface et la configuration IGP, voir Exemple : Configuration d’un réflecteur de route.
Présentation
Dans cet exemple, l’équipement RR1 est un réflecteur de route pour l’équipement R2 et l’équipement RR2. Le réflecteur de route RR1 a deux ID de cluster différents assignés, l’un est 5.5.5.5 pour RR1-R2 et 6.6.6.6 pour RR1-RR2.
L’équipement RR2 est un réflecteur de route pour l’équipement R4.
Prenons la figure Figure 5.
Cet exemple illustre la configuration BGP sur les équipements RR1 et RR2.
Configuration
Procédure
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
Équipement 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
Équipement 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’équipement RR1
Procédure étape par étape
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer l’équipement RR1 :
-
Configurez la relation d’appairage avec l’équipement 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’équipement 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’équipement 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Configuration de l’équipement RR2
Procédure étape par étape
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer l’équipement RR2 :
-
Configurez la relation d’appairage avec l’équipement 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’équipement 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 fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’ID de cluster annoncé pour la route 10. 3. 3. 3
- Vérification de l’ID de cluster annoncé pour route 10.1. 0,1
Vérification de l’ID de cluster annoncé pour la route 10. 3. 3. 3
But
Vérifiez que BGP s’exécute sur des interfaces configurées et que la session BGP est établie pour chaque adresse voisine.
Action
Depuis le mode opérationnel, saisissez 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
Les 10. 3. 3. Le routage 3/32 provient de l’homologue client de l’équipement RR1, l’équipement R3. Lorsque ce routage est envoyé au client RR1, l’équipement RR2, le routage a le 10. 13. 1. 3 ID de cluster joints, c’est-à-dire l’ID de cluster pour RR1-R3.
Vérification de l’ID de cluster annoncé pour route 10.1. 0,1
But
Consultez l’annonce de routage de l’équipement RR1 vers l’équipement RR2.
Action
Depuis le mode opérationnel, saisissez 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. Le routage 0.1/32 provient de l’homologue non client de l’équipement RR1, l’équipement R0. Lorsque ce routage est envoyé au client RR1, l’équipement RR2, le routage a le 10. 12. 1. 2 ID de cluster joints, c’est-à-dire l’ID de cluster pour RR1-RR2.
L’équipement RR1 préserve l’ID de cluster entrant de l’équipement RR2 lorsqu’il fait de la publicité à un autre client d’un autre cluster (équipement R4).
Comprendre la réflexion de route optimale BGP
Vous pouvez configurer BGP Optimal Route Reflection (BGP-ORR) avec IS-IS et OSPF en tant que protocole IGP (Interior Gateway Protocol) sur un réflecteur de route pour annoncer le meilleur chemin aux groupes de clients BGP-ORR. Pour ce faire, on utilise la métrique IGP la plus courte 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 IGP similaire peuvent être regroupés en un seul groupe d’homologues BGP. Vous pouvez configurer optimal-route-reflection pour activer BGP-ORR dans ce groupe d’homologues BGP. Vous pouvez également configurer l’un des nœuds clients en tant que nœud principal (igp-primary) dans un groupe d’homologues BGP afin que la métrique IGP de ce nœud principal soit utilisée pour sélectionner le meilleur chemin et l’annoncer aux clients du même groupe d’homologues BGP. Vous pouvez également sélectionner un autre nœud client comme nœud de sauvegarde (igp-backup), qui est utilisé lorsque le nœud 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 L’IGP est utilisé pour la résolution de route 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 vpn de couche 3, VPN de couche 2, VPLS, MVPN ou EVPN, les préfixes sont résolus sur inet.3. Dans inet.3, le routage principal pour le protocole next-hop du préfixe serait soit 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 route d’un VPN de couche 3, d’un VPN de couche 2, d’un VPLS, d’un MVPN ou d’un préfixe EVPN. Vous pouvez le faire via les 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 un VPN de couche 2 ou un 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 à les transformer en 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 la réflexion de route optimale BGP 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 IGP (Interior Gateway Protocol) sur un réflecteur de route pour annoncer le meilleur chemin aux groupes de clients BGP-ORR. Pour ce faire, on utilise la métrique IGP la plus courte 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 IGP similaire peuvent être regroupés en un seul groupe d’homologues BGP. Vous pouvez configurer optimal-route-reflection pour activer BGP-ORR dans ce groupe d’homologues BGP.
Pour configurer BGP-ORR :
Utilisez les commandes CLI suivantes pour surveiller et dépanner la configuration de BGP-ORR :
show bgp group: affiche les configurations primaires et de sauvegarde de BGP-ORR.show isis bgp-orr: affiche la métrique IS-IS BGP-ORR (RIB).show ospf bgp-orr: affiche la métrique OSPF BGP-ORR (RIB).show ospf route— Afficher les entrées dans la table de routage OSPFshow route: affiche 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 (IBGP) qui simplifie le nombre de sessions EBGP directes requises sur 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 transporte l’ensemble des attributs BGP (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP et communautés) si le routage provient d’un homologue EBGP directement connecté.
Comme avec un réflecteur de route IBGP, un serveur de route EBGP est connecté à un réseau en dehors du chemin de transfert direct entre les pairs EBGP à l’aide de la fonctionnalité de serveur de routage. Cette connectivité peut se faire via une liaison physique directe, ou via des réseaux de couche 2 tels que VPLS LAN ou EVPN, ou via une structure IP de liaisons EBGP point à point offrant une accessibilité des adresses de bouclage des pairs (typique des réseaux de centre de données).
Le protocole BGP est amélioré pour fournir une capacité de routage-serveur avec les fonctionnalités suivantes décrites dans la RFC 7947 :
Attribuez la transparence aux NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP et communautés.
Contrôle des stratégies par client et plusieurs RIB de routage-serveur pour atténuer la disssimulation des chemins.
La programmabilité BGP exploite la fonctionnalité de serveur de routage. L’API JET bgp_route_service.proto BGP a été améliorée pour prendre en charge les fonctionnalités de serveur de routage comme suit :
Programmez le serveur de routage EBGP.
Injectez des routes vers le RIB du serveur de routage spécifique pour faire de la publicité sélective auprès des groupes de clients dans des RIB spécifiques au client.
L’API JET bgp_route_service.proto BGP comprend un objet de type peer qui identifie les routes individuelles comme EBGP ou IBGP (par défaut).
La fonctionnalité de serveur de routage est généralement indépendante de la famille d’adresses, bien que certains attributs BGP spécifiques puissent être spécifiques à la famille d’adresses (par exemple, l’AIGP n’est prise en charge que pour les familles d’adresses étiquetées-unicast). La fonctionnalité de serveur de routage est prise en charge pour toutes les familles d’adresses EBGP.
- Transparence des attributs BGP
- Saut suivant
- Chemin d’accès AS
- Autres attributs
- RIB client de routage BGP
- Exigences et considérations de stratégie
Transparence des attributs BGP
La transparence des attributs EBGP [RFC7947] pour le serveur de routage est prise en charge par la modification de la propagation de route BGP normale de telle sorte que ni les attributs transitifs ni non transitifs ne soient dépouillés ou modifiés lors de la propagation des routes.
Les modifications apportées au comportement normal d’EBGP sont contrôlées par la route-server-client configuration CLI. La route-server-client configuration CLI 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 et multi-sauts à saut unique. Par conséquent, la
route-server-clientconfiguration inclut implicitement la fonctionnalité desno-nexthop-changesessions à saut unique et multi-saut. Pour les sessions BGP multi-sauts, 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 leroute-server-clientfichier est configuré pour des internal groupes, une erreur de configuration est émise lors de la tentative de validation.La
route-server-clientconfiguration n’a aucun paramètre.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 sauts suivants ne peuvent pas être envoyés sans avoir été modifiés par le serveur de routage, d’autres attributs sont envoyés de manière transparente, le cas échéant pour ces attributs.
Voici un exemple de route-server-client 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 lui-même le saut suivant ou en modifiant le saut suivant, sauf s’il est configuré explicitement par le biais d’une stratégie. Le serveur de routage doit propager les sauts BGP suivant les règles tierces du saut suivant de la RFC 4271.
Le comportement du saut suivant est spécifié pour les scénarios de routage-serveur suivants :
Dans le cas de l’interconnexion LAN et WAN, lorsque le serveur de routage est connecté à des pairs clients via un sous-réseau LAN et WAN partagé, les sauts suivants tiers reçus sont annoncés par le serveur de routage sans modification, comme défini dans la RFC 4271.
Dans le cas d’une interconnexion multihéop de centre de données, lorsque le serveur de routage est connecté à des pairs client via une interconnexion multi-hop, le multihéop EBGP doit être configuré et le comportement de la
no-nexthop-changeconfiguration CLI est implicitement imposé par laroute-server-clientconfiguration. Les sauts suivants tiers reçus sont annoncés par le serveur de routage sans modification, conformément au comportement tiers optionnel défini dans la RFC 4271.Dans d’autres cas, comme les connexions point à point entre le serveur de routage et les pairs clients, les procédures normales d’annonces de sauts suivants sont utilisées pour empêcher les sauts suivants qui pourraient être rejetés par les pairs BGP (par exemple, la plupart des implémentations BGP, par défaut, rejettent les adresses de sauts suivants qui ne sont pas couvertes par l’adresse de sous-réseau sur des sessions non multipoint.
Chemin d’accès AS
L’AS-Path ne doit pas être modifié en préinséant le numéro AS local du serveur de routage. La configuration de route-server-client l’interface CLI pour un pair supprime la préintération du numéro AS local dans les publicités. En outre, la show route advertising-protocol bgp peer commande CLI est modifiée pour les pairs qui sont des clients 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é comme reçu.
Tous les attributs de la communauté, y compris les communautés étendues non-publicitaires, non exportatrices et non transitives, doivent être propagés comme reçus.
L’attribut IGP (AIGP) accumulé (facultatif, non transitif) doit être propagé au fur et à mesure de sa réception.
REMARQUE :Junos OS prend en charge l’AIGP uniquement pour les familles d’adresses BGP-LU (IPv4 et IPv6).
RIB client de routage BGP
Un RIB spécifique au client de routage est une vue distincte d’un BGP Loc-RIB qui peut contenir différentes routes pour la même destination que les autres vues. Les clients serveurs de routage, par le biais de leurs groupes d’homologues, peuvent s’associer à une vue spécifique au client individuel ou à un RIB commun partagé.
Afin de permettre la publicité de différents itinéraires vers différents clients pour la même destination, il est théoriquement nécessaire de permettre la sélection de plusieurs instances du chemin BGP pour la même destination, mais dans différents contextes de clients/groupes.
Pour mettre en œuvre l’exigence de haut niveau d’un contrôle des stratégies flexible avec la sélection des chemins par client/groupe, le serveur de routage BGP utilise des instances de routage non-transfert (NFIs) pour multi-instance du pipeline BGP, y compris la sélection des chemins BGP, Loc-RIB et la stratégie. Le serveur de routage est configuré pour regrouper les clients de serveurs de routage au sein de groupes BGP configurés dans des instances de routage distinctes sans transfert. Cette approche exploite le fait que BGP s’exécutant dans une instance de routage sélectionne les chemins et dispose d’un RIB distinct de BGP exécuté dans d’autres instances de routage.
Exigences et considérations de stratégie
Pour propager des routes entre les clients de serveurs de routage, les routes fuient 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 comprend les considérations suivantes :
Les clients serveurs de routage doivent être configurés au sein de la même instance principale ou de l’instance de routage pour recevoir la même vue Loc-RIB.
Les clients serveurs de routage doivent être configurés au sein de leur propre instance de routage pour recevoir des vues Loc-RIB totalement uniques.
Les clients serveurs de routage doivent être configurés dans différents groupes d’homologues 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 serveur de routage 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 de nombreuses instances de routage et de groupes d’homologues a un impact sur l’échelle et les performances.
La configuration CLI 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 CLI BGPforwarding-contextprend également en charge l’instance non-transfert avec des pairs BGP configurés commeroute-server-clientoù l’instance spécifiée est toute instance capable de transférer une instance principale ou une instance de routage qui n’est pas du type no-forwarding.
Voir également
no-install entre le daemon 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).