Réflecteurs de route BGP
Comprendre les réflecteurs de route BGP
Cette rubrique traite de l’utilisation de réflecteurs de route BGP pour simplifier la configuration et faciliter la mise à l’échelle.
Dans un système autonome (AS) BGP, les routes doivent être distribuées entre tous les routeurs de bordure AS. Le Border Gateway Protocol (BGP) y parvient grâce à des sessions d’appairage BGP (IBGP) internes. Par défaut, les routes apprises à partir d’un homologue IBGP ne sont pas annoncées aux autres homologues IBGP. Cette restriction nécessite un maillage complet de sessions IBGP entre tous les routeurs de l’AS pour garantir une visibilité complète du routage.
Cependant, le maintien d’un maillage complet augmente la complexité de la configuration et limite l’évolutivité. Chaque nouvel homologue IBGP doit établir des sessions avec tous les autres homologues de l’AS. Le nombre total de sessions nécessaires pour un maillage complet est calculé à l’aide de la formule v * (v - 1)/2, où v représente le nombre d’homologues BGP.
En plus de la surcharge de configuration, un maillage complet peut augmenter la mise à l’échelle des routes. Chaque pair IBGP reçoit toutes les routes, même si nombre d’entre elles ne sont pas optimales pour leur emplacement dans le réseau.
La réflexion de route BGP, définie dans le document RFC 4456, résout les problèmes d’évolutivité des topologies IBGP à maillage complet. La réflexion de route permet à un routeur, appelé réflecteur de route (RR), de redistribuer les routes apprises d’un homologue IBGP à d’autres homologues IBGP. Cela assouplit la règle BGP par défaut qui empêche la publication des routes d’IBGP à IBGP.
Étant donné que la réflexion de route introduit la possibilité de boucles de routage, la RFC 4456 définit deux nouveaux attributs de chemin BGP qui garantissent la prévention des boucles et une sélection cohérente des chemins :
-
ORIGINATOR_ID – Identifie l’ID routeur du voisin BGP qui a initialement annoncé la route. L’attribut ORIGINATOR_ID n’est attaché que lorsque l’itinéraire est réfléchi pour la première fois.
-
CLUSTER_LIST – Enregistre les ID cluster des réflecteurs de route qui ont reflété la route lors de sa propagation sur le réseau.
Pour plus d’informations sur la façon dont ces attributs influencent la sélection du meilleur chemin BGP, consultez Présentation de la sélection du chemin BGP.
En raison de l’exigence interne de maillage intégral de BGP (IBGP), la plupart des réseaux utilisent des réflecteurs de route pour simplifier la configuration. À l’aide d’un réflecteur de route, les routeurs sont regroupés en clusters, qui sont identifiés par des identifiants numériques propres au système autonome. Au sein du cluster, vous devez configurer une session BGP à partir d’un seul routeur (le réflecteur de route) vers chaque homologue interne. Avec cette configuration, l’exigence 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é de publier à nouveau les routes apprises d’un pair interne à d’autres homologues internes. 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 exige seulement que les réflecteurs de route soient entièrement maillés avec tous les homologues internes. Le réflecteur de route et tous ses homologues internes forment un cluster, comme illustré sur la Figure 1.
Pour certains équipements Juniper Networks, une licence de fonctionnalités BGP avancées doit être installée sur chaque équipement utilisant un réflecteur de route. Pour plus de détails sur la licence, consultez le Guide d’installation et de mise à niveau des Logiciels.
La figure 1 montre le RR du routeur configuré comme 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 au RR du routeur par tous les pairs internes. RR publie ensuite à nouveau ces routes à 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).
La figure 2 montre 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 vers les autres réflecteurs de route, qui, à leur tour, annoncent à nouveau la route vers les routeurs restants dans l’AS. La réflexion de route permet à la route d’être propagée dans tout 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 de 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 l’itinéraire vers d’autres clusters.
Un client est un routeur IBGP qui reçoit des routes du réflecteur de route. Un non-client est un autre voisin IBGP. Le réflecteur de route vérifie les routes apprises des non-clients uniquement vers ses clients, et non vers les non-clients. Cependant, un réflecteur de route annonce les routes apprises des clients aux clients et aux non-clients.
Cependant, à mesure que les clusters 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 aider à compenser ce problème, vous pouvez regrouper des clusters de routeurs en clusters de clusters pour la réflexion de route hiérarchique (voir Figure 3).
La figure 3 montre le RR 2, le RR 3 et le RR 4 comme réflecteurs de route pour les groupes 127, 19 et 45, respectivement. Au lieu 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 le RR 1 est le réflecteur de route. Lorsqu’un routeur annonce une route vers RR 2, RR 2 annonce à nouveau la route vers tous les routeurs de son propre cluster, puis annonce à nouveau la route vers RR 1. Le RR 1 annonce à nouveau la route aux routeurs de son cluster, et ces routeurs propagent la route vers le bas à travers leurs clusters.
Voir aussi
Réflecteurs de route sans transfert
Dans de nombreux réseaux, les réflecteurs de route BGP sont déployés pour améliorer l’évolutivité, mais ne sont pas directement impliqués dans le transfert du trafic. Ces réflecteurs de route maintiennent les fonctions du plan de contrôle BGP sans participer au transfert de données. Lorsqu’un réflecteur de route n’est pas dans le chemin de trafic, il n’a pas besoin d’installer les routes qu’il reflète dans sa table de transfert. Ces dispositifs sont appelés réflecteurs de route sans transfert.
Vous pouvez configurer les réflecteurs de route sans transfert de l’une des manières suivantes :
-
Utilisation de l’instruction
no-install– Introduite dans Junos OS version 15.1, l’instructionno-installempêche l’installation de routes BGP dans la table de transfert. Vous pouvez configurer cette option par famille d’adresses au niveau hiérarchique suivant :[edit protocols bgp family family-name] set no-install
-
Utilisation d’une stratégie d’exportation de table de transfert : dans les versions de Junos OS antérieures à 15.1, vous pouvez obtenir un comportement similaire en configurant une stratégie d’exportation de table de transfert qui rejette les routes apprises à partir de BGP.
Les réflecteurs de route sans transfert contribuent à réduire la charge des ressources sur les équipements qui servent principalement de routeurs de plan de contrôle, en particulier dans les réseaux des fournisseurs de services à grande échelle.
Exemple : Configuration d’un réflecteur de route
Cet exemple montre comment configurer un réflecteur de route.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.
Vue d’ensemble
En général, les équipements internes compatibles BGP (IBGP) doivent être entièrement maillés, car IBGP ne publie pas de mises à jour sur d’autres équipements compatibles IBGP. Le maillage complet est un maillage logique obtenu par 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 grands déploiements.
La figure 4 montre un réseau IBGP avec l’équipement A agissant comme réflecteur de route. L’équipement B et l’équipement C sont des clients du réflecteur de route. Les appareils D et E se trouvent en dehors du cluster et ne sont donc pas des clients.
Dans Junos OS, tout voisin d’un groupe BGP avec l’instruction cluster est traité comme un client du réflecteur de route. L’équipement D et l’équipement E ne sont pas clients, car ils sont placés dans un groupe BGP sur le réflecteur de route (équipement A) qui n’inclut pas l’instruction cluster . Pour que les clients de réflecteur de route Device D et Device E soient déplacés-les vers le rr-clients groupe qui inclut l’instruction cluster .
de route
La configuration
- Procédure
- Configuration du réflecteur de route
- Configuration des pairs clients
- Configuration d’homologues non-clients
Procédure
Configuration rapide de la CLI
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-collez les commandes dans le CLI au niveau de la [edit] hiérarchie.
Cet exemple redistribue les routes apprises par OSPF dans BGP à l’aide de la stratégie d’exportation send-ospf :
set protocols bgp group internal-peers export send-ospf
La redistribution d’OSPF en BGP n’est normalement pas nécessaire pour le fonctionnement du réflecteur de route. Il est utilisé ici uniquement pour créer des routes BGP que le réflecteur de route peut annoncer à ses clients, ce qui vous permet d’observer le comportement de la réflexion de route dans une topologie de laboratoire simple.
Dans un déploiement de production, les réflecteurs de route reflètent généralement les routes BGP apprises des clients et ne redistribuent pas les routes IGP dans BGP, sauf si ce comportement est spécifiquement souhaité.
Dans cet exemple, les routeurs D et E sont des homologues IBGP non clients et sont configurés dans un maillage complet pour assurer un échange de route cohérent en dehors du cluster client de réflecteur de route.
É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 rr-clients type internal set protocols bgp group rr-clients local-address 192.168.6.5 set protocols bgp group rr-clients export send-ospf set protocols bgp group rr-clients neighbor 192.163.6.4 set protocols bgp group rr-clients neighbor 192.168.40.4 set protocols bgp group rr-clients cluster 192.168.6.5 set protocols bgp group non-clients type internal set protocols bgp group non-clients local-address 192.168.6.5 set protocols bgp group non-clients export send-ospf set protocols bgp group non-clients neighbor 192.168.0.1 set protocols bgp group non-clients 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 neighbor 192.168.6.5 set protocols bgp group rr-clients type internal set protocols bgp group rr-clients local-address 192.163.6.4 set protocols bgp group rr-clients export send-ospf set protocols bgp group rr-clients 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 rr-clients type internal set protocols bgp group rr-clients local-address 192.168.40.4 set protocols bgp group rr-clients export send-ospf set protocols bgp group rr-clients neighbor 192.168.6.5set 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 non-clients type internal set protocols bgp group non-clients local-address 192.168.0.1 set protocols bgp group non-clients export send-ospf set protocols bgp group non-clients neighbor 192.168.6.5 set protocols bgp group non-clients 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 non-clients type internal set protocols bgp group non-clients local-address 192.168.5.5 set protocols bgp group non-clients export send-ospf set protocols bgp group non-clients neighbor 192.168.0.1 set protocols bgp group non-clients 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 la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de Junos OS.
Pour configurer IBGP dans le réseau en utilisant Juniper Networks périphérique 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 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
-
Configurez le groupe BGP pour les clients de réflecteur de route (périphérique B et périphérique C).
Configurez l’instruction de cluster avec l’identifiant de cluster pour ajouter les routeurs clients dans un cluster avec le réflecteur de route. L’identificateur de cluster peut être n’importe quelle valeur de 32 bits. Dans cet exemple, nous utilisons l’adresse IP de bouclage comme identifiant de cluster.
[edit protocols bgp group rr-clients] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set cluster 192.168.6.5 user@A# set neighbor 192.163.6.4 user@A# set neighbor 192.168.40.4
-
Configurez le groupe BGP interne pour les homologues non clients (Périphérique D et Périphérique E). Ne configurez pas l’instruction de cluster pour que les routeurs non clients restent en dehors du cluster de réflecteur de route.
[edit protocols bgp group non-clients user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
-
(Facultatif) Configurez un système IGP et une stratégie qui redistribue les routes IGP en BGP. Notez qu’il ne s’agit pas d’une exigence de production habituelle, mais seulement configurée dans cet exemple pour montrer comment le réflecteur de route fonctionne dans une topologie de laboratoire simple.
[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
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
user@A# set protocols bgp group rr-clients export send-ospf user@A# set protocols bgp group non-clients export send-ospf
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolsshow policy-options, , et 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 rr-clients {
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;
}
group non-clients {
type internal;
local-address 192.168.6.5;
export send-ospf;
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, entrez en commit mode configuration.
Répétez ces étapes pour chaque pair BGP non-client du cluster que vous configurez, si les autres appareils non-clients proviennent de Juniper Networks. Sinon, consultez la documentation de l’appareil pour obtenir des instructions.
Configuration des pairs 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 la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de 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 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
-
Configurez la relation de voisinage BGP avec le réflecteur de route.
[edit protocols bgp group rr-clients] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set neighbor 192.168.6.5
-
(Facultatif) Configurez un système IGP et une stratégie qui redistribue les routes IGP en BGP. Notez qu’il ne s’agit pas d’une exigence de production habituelle, mais seulement configurée dans cet exemple pour montrer comment le réflecteur de route fonctionne dans une topologie de laboratoire simple.
[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
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
[edit protocols bgp group rr-clients] user@B# set export send-ospf
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolsshow policy-options, , et 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 rr-clients {
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, entrez en commit mode configuration.
Répétez ces étapes pour chaque pair BGP client du cluster que vous configurez si les autres appareils 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 la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de 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 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
-
Configurez les relations de voisinage BGP avec le réflecteur de route et avec les autres homologues non clients.
[edit protocols bgp group non-clients] 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
-
(Facultatif) Configurez un système IGP et une stratégie qui redistribue les routes IGP en BGP. Notez qu’il ne s’agit pas d’une exigence de production habituelle, mais seulement configurée dans cet exemple pour montrer comment le réflecteur de route fonctionne dans une topologie de laboratoire simple.
[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
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
[edit protocols bgp group non-clients] user@D# set export send-ospf
Résultats
En mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show protocolsshow policy-options, , et 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 non-clients {
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, entrez en commit mode configuration.
Si vous avez d’autres homologues clients ou non-clients, ajoutez leurs instructions de voisinage au groupe BGP approprié : le groupe client (avec l’instruction cluster ) ou le groupe non client (sans l’instruction cluster ). Si les autres équipements ne proviennent pas de Juniper Networks, 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 de BGP
- Vérification des informations de la table de routage
Vérification des voisins BGP
Objet
Vérifiez que le protocole BGP s’exécute sur les interfaces configurées et que la session BGP est établie pour chaque adresse voisine.
Mesures à prendre
À 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 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 )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]: 0
Vérification des groupes BGP
Objet
Vérifiez que les groupes BGP sont configurés correctement.
Mesures à prendre
À 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: rr-clients Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 2 Established: 4 192.163.6.4+179 192.168.40.4+53990 inet.0: 0/26/16/0 Group Type: Internal AS: 17 Local AS: 17 Name: non-clients Index: 0 Flags: <> Export: [ send-ospf ] Holdtime: 0 Total peers: 2 Established: 4 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 2 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 de BGP
Objet
Vérifiez que la configuration de BGP est correcte.
Mesures à prendre
À partir du mode opérationnel, entrez la show bgp summary commande.
user@A> show bgp summary Groups: 2 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
Objet
Vérifiez que la table de routage contient les routes IBGP.
Mesures à prendre
À 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
MultiRecv
Comprendre un réflecteur de route appartenant à deux clusters différents
L’objectif de la réflexion de route est d’empêcher 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 de BGP : ils réannoncent les routes apprises d’un pair BGP interne à d’autres homologues BGP internes.
Normalement, un seul RR est membre d’un seul cluster. Considérez, 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 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 répercutées d’un cluster à l’autre, un seul 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 empêcher les boucles dans ce cas.
Le Tableau 1 résume les règles utilisées par les réflecteurs de route lorsqu’ils remplissent la liste des clusters d’une route réfléchie avec des ID de cluster.
|
Scénario de réflexion de route |
La configuration |
|---|---|
|
Lors de la mise en miroir d’une route 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 la route réfléchie. |
|
Lors de la mise en miroir d’une route 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 la route réfléchie. |
|
Lors de la mise en miroir d’une route 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é à client1 dans la liste des clusters avant de refléter l’ID de cluster à client2. L’ID de cluster associé au client 2 n’est pas ajouté. |
|
Lors de la mise en miroir d’une route 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 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 réfléchissez un chemin d’un système autonome à un autre. 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 la route vers l’appareil non client, car l’ID de cluster est spécifique à un système autonome. |
Voir aussi
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.
Exigences
Configurez les interfaces des appareils et un protocole de passerelle interne (IGP). Pour obtenir un exemple de configuration RR qui inclut l’interface et la configuration IGP, consultez Exemple : configuration d’un réflecteur de route.
Vue d’ensemble
Dans cet exemple, l’équipement RR1 est un réflecteur de route pour l’équipement R3 et l’équipement RR2. Le réflecteur de route RR1 a deux ID de cluster différents attribués, l’un est 10.13.1.3 pour RR1-R3 et 10.12.1.2 pour RR1-RR2.
L’appareil RR2 est un réflecteur de route pour l’équipement R4.
Considérez la figure 5.
différents
Cet exemple montre la configuration BGP sur l’appareil RR1 et l’appareil RR2.
La configuration
Conditions préalables
Avant de configurer les réflecteurs de route BGP dans plusieurs clusters, assurez-vous que l’accessibilité IP existe entre tous les homologues BGP. Dans cet exemple, un Interior Gateway Protocol (IGP), tel que OSPF ou IS-IS, assure l’accessibilité entre les interfaces de bouclage utilisées pour les sessions IBGP. L’interface et la configuration IGP sont supposées être en place et ne sont pas présentées ici.
Procédure
Configuration rapide de la CLI
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 le CLI au niveau de la [edit] hiérarchie.
RR1 de l’appareil
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’équipement 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 la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de 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, entrez en commit mode configuration.
Configuration de l’équipement 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 la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de 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, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’ID de cluster annoncé pour 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 Route 10.3.3.3
Objet
Vérifiez que le protocole BGP s’exécute sur les interfaces configurées et que la session BGP est établie pour chaque adresse voisine.
Mesures à prendre
À 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
Signification
La route 10.3.3.3/32 provient de l’homologue client de l’appareil RR1, l’appareil R3. Lorsque cette route est envoyée au client de RR1, Device RR2, l’ID de cluster 10.13.1.3, qui est l’ID de cluster de RR1-R3.
Vérification de l’ID de cluster annoncé pour Route 10.1.0.1
Objet
Vérifiez l’annonce de route de l’appareil RR1 vers l’appareil RR2.
Mesures à prendre
À 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.1
Signification
La route 10.1.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, Device RR2, l’ID de cluster 10.12.1.2 est 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 la publication sur un autre client dans un autre cluster (équipement R4).
Réflexion de route sur les routeurs de bordure AS
Dans la plupart des déploiements, les réflecteurs de route BGP fonctionnent exclusivement comme des routeurs BGP (IBGP) internes. Cependant, dans certaines conceptions de réseau, un réflecteur de route peut également fonctionner comme un ASBR (Autonomous System Border routeur) et maintenir des sessions d’appairage EBGP (BGP externes).
Lorsqu’un routeur Junos OS remplit les deux rôles et reçoit une route d’un homologue EBGP, des considérations particulières s’appliquent si le routeur annonce cette route à des homologues IBGP configurés en tant que clients réflecteur de route à l’aide de cette cluster option. Dans ce cas, Junos OS attache les attributs ORIGINATOR_ID et CLUSTER_LIST chemin lorsqu’il reflète l’itinéraire vers les clients IBGP.
La RFC 4456, qui définit la réflexion de route BGP, ne spécifie pas explicitement le comportement attendu pour les routes apprises via EBGP et ensuite réfléchies aux clients IBGP par un ASBR à double rôle et un réflecteur de route. Dans ce scénario, Junos OS applique systématiquement les attributs de réflexion de route afin d’éviter les boucles de routage et de préserver la sélection déterministe des chemins au sein du système autonome.
Lorsque vous déployez la réflexion de route sur des routeurs de bordure AS, étudiez attentivement la politique de routage, la sélection des chemins et les scénarios de défaillance pour vous assurer que les routes réfléchies n’introduisent pas de comportement de routage involontaire.
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’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
no-install interaction 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).