Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

REMARQUE :

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.

REMARQUE :

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 : Topologie de réflecteur de route simple (un cluster)Topologie de réflecteur de route simple (un cluster)

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 : Réflexion de route de base (plusieurs clusters)Réflexion de route de base (plusieurs clusters)

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.

REMARQUE :

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 : Réflexion de route hiérarchique (clusters)Réflexion de route hiérarchique (clusters)

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.

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).

Conseil :

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.

Figure 4 : Réseau IBGP à l’aide d’un réflecteur de routeRéseau IBGP à l’aide d’un réflecteur de route

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 A

Équipement B

Équipement C

Équipement D

Équipement E

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 :

  1. Configurez les interfaces.

  2. 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.

  3. Configurez le routage statique ou un protocole IGP (Interior Gateway Protocol).

    Cet exemple utilise OSPF.

  4. Configurez la stratégie qui redistribue les routes OSPF dans BGP.

  5. Configurez l’ID du routeur et le numéro du système autonome (AS).

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.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

REMARQUE :

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 :

  1. Configurez les interfaces.

  2. Configurez la relation de voisinage BGP avec le réflecteur de route.

    Appliquez également la stratégie qui redistribue les routes OSPF dans BGP.

  3. Configurez OSPF.

  4. Configurez la stratégie qui redistribue les routes OSPF dans BGP.

  5. Configurez l’ID du routeur et le numéro AS.

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.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

REMARQUE :

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 :

  1. Configurez les interfaces.

  2. 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.

  3. Configurez OSPF.

  4. Configurez la stratégie qui redistribue les routes OSPF dans BGP.

  5. Configurez l’ID du routeur et le numéro AS.

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.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

REMARQUE :

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

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.

Vé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.

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.

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.

Comprendre 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.

Tableau 1 : Règles pour les réflecteurs de route

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.

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.

Figure 5 : Réflecteur de route dans deux clusters différents Réflecteur de route dans deux clusters différents

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

Équipement RR2

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 :

  1. Configurez la relation d’appairage avec l’équipement R3.

  2. Configurez la relation d’appairage avec l’équipement R0.

  3. Configurez la relation d’appairage avec l’équipement RR2.

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.

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 :

  1. Configurez la relation d’appairage avec l’équipement R4.

  2. Configurez la relation d’appairage avec l’équipement RR1.

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.

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

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.

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.

Sens

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]

REMARQUE :

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.

REMARQUE :

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 :

  • Pour un VPN de couche 2 ou un préfixe VPLS :

  • Pour le préfixe EVPN :

  • Pour le préfixe MVPN :

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 :

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 :

  1. Configurez une réflexion de route optimale.
  2. Configurez 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.
  3. (Facultatif) Configurez un autre nœud client en tant que nœud de sauvegarde (igp-backup), qui est utilisé lorsque le nœud principal (igp-primary) tombe en panne ou est inaccessible.

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 OSPF

  • show 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.

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

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-client configuration inclut implicitement la fonctionnalité des no-nexthop-change sessions à saut unique et multi-saut. Pour les sessions BGP multi-sauts, vous devez configurer le multihop mot-clé.

  • Le route-server-client peut être configuré au niveau du protocole, du groupe ou du voisin de la hiérarchie [edit protocol bgp].

  • La route-server-client configuration n’est applicable que lorsque le type de groupe est external. Lorsque le route-server-client fichier est configuré pour des internal groupes, une erreur de configuration est émise lors de la tentative de validation.

  • La route-server-client configuration n’a aucun paramètre.

  • Le privilège BGP normal s’applique à la route-server-client configuration.

REMARQUE :

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 :

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-change configuration CLI est implicitement imposé par la route-server-client configuration. 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-import stratégies est configuré avec instance-any. Lors de la configuration instance-import avec une stratégie contenant instance-any:

    • instance-any peut être utilisé dans :

      • policy-statement ... term ... from

      • policy-statement ... from

      • policy-statement ... term ... to

      • policy-statement ... to

    • instance-any n’a pas de paramètres.

    • L’utilisation instance-any dans des stratégies autres que instance-import n’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-context au 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 BGP forwarding-context prend également en charge l’instance non-transfert avec des pairs BGP configurés comme route-server-client où 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.

Tableau de l'historique des versions
Version
Description
15.1
À 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).
15.1
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.