Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit la fonction de l’algorithme du meilleur chemin BGP (Border Gateway Protocol).
Les routeurs BGP reçoivent généralement plusieurs chemins vers la même destination. L'algorithme du meilleur chemin BGP décide quel est le meilleur chemin à installer dans la table de routage IP et à utiliser pour expédier du trafic.
Supposez que tous les chemins qu'un routeur reçoit pour un préfixe particulier sont arrangés dans une liste. La liste est similaire à la sortie de la commande show ip bgp longer-prefixescommand. Dans ce cas, quelques chemins ne sont pas considérés comme candidats pour le meilleur chemin. De tels chemins n'ont généralement pas d'indicateur valide dans la sortie de la commande show ip bgp longer-prefixes. Les routeurs ignorent des chemins dans ces circonstances :
Les chemins qui sont marqués comme non synchronisés dans la sortie show ip bgp longer-prefixes.
Si la synchronization BGP est activée, il doit y avoir une correspondance pour le préfixe dans la table de routage IP afin qu'un chemin interne BGP (iBGP) soit considéré comme un chemin d'accès valide. La synchronization BGP est activée par défaut dans le logiciel Cisco IOS®. Si la route qui correspond est apprise d'un voisin OSPF (Open Shortest Path First), son ID de routeur OSPF doit correspondre à l'ID de routeur BGP du voisin iBGP. La plupart des utilisateurs préfèrent désactiver la synchronization avec l'utilisation de la commande secondaire no synchronization BGP.
Remarque : La synchronisation est désactivée par défaut dans le logiciel Cisco IOS® version 12.2(8)T et ultérieure.
Chemins pour lesquels le NEXT_HOP est inaccessible.
Soyez sûr qu'il y a une route Interior Gateway Protocol (IGP) vers NEXT_HOP qui est associée au chemin.
Chemins d'un voisin BGP externe (eBGP) si le système autonome local (AS) apparaît dans l'AS_PATH.
De tels chemins sont refusés lors de l'entrée dans le routeur, et ne sont même pas installés dans la base d'informations de routage BGP (RIB). Il en va de même pour tout chemin refusé par une stratégie de routage implémentée via l'accès, le préfixe, AS_PATH ou des listes de communauté, sauf si vous avez configuré la reconfiguration logicielle entrante de voisin pour le voisin.
Si vous avez activé bgp apply-first-as et que la mise à jour ne contient pas le système autonome du voisin comme premier numéro de système autonome dans AS_SEQUENCE.
Dans ce cas, le routeur envoie un avis et ferme la session.
Chemins marqués comme (reçus uniquement) dans la show ip bgp longer-prefixes
sortie
La politique a rejeté ces chemins. Cependant, le routeur a stocké les chemins, car vous avez configuré soft-reconfiguration inbound
pour le voisin qui envoie le chemin.
BGP assigne le premier chemin d'accès valide en tant que meilleur chemin actuel. BGP compare alors le meilleur chemin avec le prochain chemin dans la liste, jusqu'à ce que BGP atteigne la fin de la liste des chemins d'accès valides. Cette liste fournit les règles qui sont utilisées afin de déterminer le meilleur chemin :
Préférez le chemin avec le plus haut POIDS.
Remarque : POIDS est un paramètre spécifique à Cisco. Il est local vis-à-vis du routeur sur lequel il est configuré.
Préférez le chemin avec le plus haut LOCAL_PREF.
Remarque : Un chemin sans LOCAL_PREF est considéré comme ayant eu la valeur définie avec la commande bgp default local-preference , ou comme ayant une valeur de 100 par défaut.
Préférez le chemin qui a été localement lancé par l'intermédiaire d'une commande secondaire BGP network ou aggregate ou de la redistribution d'un IGP.
Les chemins locaux qui sont créés par les commandesnetwork ou redistribute sont préférés aux agrégats locaux qui sont créés par la commande aggregate-address.
Remarque : Soyez conscient de cet élément :
- Si AIGP est configuré ET que la commande bgp bestpath aigp ignore n'est pas configurée, le processus de décision prend en compte la métrique AIGP. Voir Configurer l'attribut de mesure AIGP pour BGP pour plus de détails.
Préférez le chemin avec l'AS_PATH le plus court.
Remarque : Soyez conscient des éléments suivants :
-Cette étape est sautée si vous avez configuré la commande bgp bestpath as-path ignore.
-Un AS_SET compte en tant que 1, indépendamment du nombre d'AS dans l'ensemble.
-Les AS_CONFED_SEQUENCE et les AS_CONFED_SET ne sont pas inclus dans la longueur de l'AS_PATH.
Préférez le chemin avec le type d'origine le plus bas.
Remarque : L'IGP est inférieur à l'Exterior Gateway Protocol (EGP) et l'EGP est inférieur à INCOMPLETE.
Préférez le chemin avec le discriminateur de sorties multiples (MED) le plus bas.
Remarque : Soyez conscient des éléments suivants :
-Cette comparaison se produit seulement si le premier AS (le voisin) est identique dans les deux chemins. N'importe quelle confédération de sous-AS est ignorée.
En d'autres termes, les MED sont comparés seulement si le premier AS dans l'AS_SEQUENCE est identique pour plusieurs chemins. Tout AS_CONFED_SEQUENCE qui précède est ignoré.
-Si bgp always-compare-med est activé, des MED sont comparés pour tous les chemins.
Vous devez désactiver cette option sur l'AS entier. Autrement, les boucles de routage peuvent se produire.
-Si bgp bestpath med-confed est activé, des MED sont comparés pour tous les chemins qui consistent seulement en AS_CONFED_SEQUENCE.
Ces chemins ont été créés dans la confédération locale.
- Le MED des chemins qui sont reçus d'un voisin avec un MED de 4 294 967 295 est modifié avant l'insertion dans la table BGP. Le MED passe à 4 294 967 294.
- Le MED des chemins qui sont reçus d'un voisin avec un MED de 4 294 967 295 sont considérés comme valides et sont insérés dans la table BGP avec effet aux Codes corrigés pour l'ID de bogue Cisco CSCef34800.
-Des chemins reçus sans MED ont un MED assigné de 0, à moins que vous ayez activé bgp bestpath med missing-as-worst.
Si vous avez activé bgp bestpath med missing-as-worst, un MED de 4.294.967.294 est assigné aux chemins.
Si vous avez activé bgp bestpath med missing-as-pire, les chemins sont assignés à un MED de 4,294,967,295 avec effet aux Codes corrigés pour l'ID de bogue Cisco CSCef34800.
- La commande bgp deterministic-med peut également influencer cette étape.
Reportez-vous à Comment les routeurs BGP utilisent le discriminateur à sorties multiples pour la meilleure sélection de chemin pour une démonstration.
Préférez l'eBGP aux chemins d'iBGP.
Si le bestpath (meilleur chemin) est sélectionné, passez à l'étape 9 (multivoie).
Remarque : Les chemins qui contiennent AS_CONFED_SEQUENCE et AS_CONFED_SET sont locaux vis-à-vis de la confédération. Par conséquent, ces chemins sont traités en tant que chemins internes. Il n'y a aucune distinction entre la confédération externe et la confédération interne.
Préférez le chemin avec la métrique IGP la plus basse au prochain saut BGP.
Continuez, même si le bestpath (meilleur chemin) est déjà sélectionné.
Déterminez si plusieurs chemins impliquent l'installation dans la table de routage pour un trajet multiple BGP.
Continuez, si le bestpath (meilleur chemin) n'est pas encore sélectionné.
Quand les deux chemins sont externes, préférez le chemin qui a été reçu en premier (le plus ancien).
Cette étape réduit au minimum la perturbation de la route car le chemin le plus récent ne déplace pas un chemin plus ancien, même si le chemin plus récent était la route préférée basée sur les critères de décision suivants (étapes 11, 12, et 13).
Sautez cette étape si l'un de ces éléments est vrai :
Vous avez activé la commande bgp best path compare-routerid .
Remarque : Les versions du logiciel Cisco IOS® 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T et 12.1.3.E ont introduit cette commande.
L'ID du routeur est le même pour plusieurs chemins parce que les routes ont été reçues du même routeur.
Il n'y a pas de meilleur chemin actuel.
Le meilleur chemin actuel peut être détruit quand, par exemple, un voisin qui offre le chemin se désactive.
Préférez la route qui vient du routeur BGP avec l'ID du routeur le plus bas.
L'ID du routeur est la plus haute adresse IP sur le routeur, la préférence étant donnée aux adresses de bouclage. Vous pouvez également utiliser la commande bgp router-id afin de définir manuellement l'ID de routeur.
Remarque : Si un chemin contient des attributs de réflecteur de route (RR), l'ID créateur est substitué par l'ID du routeur dans le processus de sélection du chemin.
Si l'ID créateur ou du routeur est le même pour plusieurs chemins, préférez le chemin avec le minimum de longueur de liste de groupe.
Ceci est seulement présent dans des environnements BGP RR. Il permet à des clients de s'associer avec des RR ou des clients dans d'autres groupes. Dans ce scénario, le client doit se rendre compte de l'attribut BGP RR spécifique.
Préférez le chemin qui vient de la plus basse adresse du voisin.
Cette adresse est l'adresse IP qui est utilisée dans la neighbor
configuration BGP. L'adresse correspond au partenaire distant qui est utilisé dans la connexion TCP avec le routeur local.
Dans cet exemple, 9 chemins sont disponibles pour le réseau 10.30.116.0/23. La commande show ip bgp network affiche les entrées dans la table de routage BGP pour le réseau donné.
Router R1#show ip bgp vpnv4 rd 1100:1001 10.30.116.0/23 BGP routing table entry for 1100:1001:10.30.116.0/23, version 26765275 Paths: (9 available, best #6, no table) Advertised to update-groups: 1 2 3 (65001 64955 65003) 65089, (Received from a RR-client) 172.16.254.226 (metric 20645) from 172.16.224.236 (172.16.224.236) Origin IGP, metric 0, localpref 100, valid, confed-internal Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65008 64955 65003) 65089 172.16.254.226 (metric 20645) from 10.131.123.71 (10.131.123.71) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65001 64955 65003) 65089 172.16.254.226 (metric 20645) from 172.16.216.253 (172.16.216.253) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65001 64955 65003) 65089 172.16.254.226 (metric 20645) from 172.16.216.252 (172.16.216.252) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (64955 65003) 65089 172.16.254.226 (metric 20645) from 10.77.255.57 (10.77.255.57) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (64955 65003) 65089 172.16.254.226 (metric 20645) from 10.57.255.11 (10.57.255.11) Origin IGP, metric 0, localpref 100, valid, confed-external, best Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 !--- BGP selects this as the Best Path on comparing
!--- with all the other routes and selected based on lower router ID. (64955 65003) 65089 172.16.254.226 (metric 20645) from 172.16.224.253 (172.16.224.253) Origin IGP, metric 0, localpref 100, valid, confed-internal Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65003) 65089 172.16.254.226 (metric 20645) from 172.16.254.234 (172.16.254.234) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 65089, (Received from a RR-client) 172.16.228.226 (metric 20645) from 172.16.228.226 (172.16.228.226) Origin IGP, metric 0, localpref 100, valid, confed-internal Extended Community: RT:1100:1001 mpls labels in/out nolabel/278
Le protocole BGP sélectionne le meilleur chemin parmi ces 9 chemins en tenant compte des différents attributs décrits dans ce document. Dans le résultat affiché ici, BGP compare les chemins disponibles et sélectionne le chemin 6 comme meilleur chemin en fonction de son ID de routeur inférieur.
Comparing path 1 with path 2: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP The paths have different neighbor AS's so ignoring MED Both paths are internal (no distinction is made between confed-internal and confed-external) Both paths have an IGP metric to the NEXT_HOP of 20645 Path 2 is better than path 1 because it has a lower Router-ID. Comparing path 2 with path 3: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 2 is better than path 3 because it has a lower Router-ID. Comparing path 2 with path 4: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 2 is better than path 4 because it has a lower Router-ID. Comparing path 2 with path 5: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 5 is better than path 2 because it has a lower Router-ID. Comparing path 5 with path 6: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 5 because it has a lower Router-ID. Comparing path 6 with path 7: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are internal (no distinction is made between confed-internal and confed-external) Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 7 because it has a lower Router-ID. Comparing path 6 with path 8: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 8 because it has a lower Router-ID. Comparing path 6 with path 9: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP The paths have different neighbor AS's so ignoring MED Both paths are internal (no distinction is made between confed-internal and confed-external) Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 9 because it has a lower Router-ID. The best path is #6
L'attribut de la communauté étendue, qui s'appelle la Communauté de coût BGP, fournit une manière de personnaliser le meilleur processus de sélection du chemin. Une étape supplémentaire, dans laquelle les Communautés de coût sont comparées, est ajoutée à l'algorithme décrit dans la section Comment le meilleur algorithme de chemin fonctionne. Cette étape vient après l'étape requise (point de mise en place) dans l'algorithme. Le chemin avec la valeur la moins coûteuse est préféré.
Remarque : Soyez conscient des éléments suivants :
-Cette étape est sautée si vous avez émis la commande bgp bestpath cost-community ignore .
- La clause cost community set est configurée avec un numéro d'ID de communauté de coût (0 à 255) et une valeur de numéro de coût (0 à 4 294 967 295). La valeur du numéro de coût détermine la préférence pour le chemin. Le chemin avec la valeur du numéro le moins coûteux est préféré. Les chemins qui ne sont pas spécifiquement configurés avec la valeur du numéro de coût se voient attribuer une valeur de numéro de coût par défaut de 2 147 483 647. Cette valeur est le point milieu entre 0 et 4 294 967 295. Ces chemins sont ensuite évalués en conséquence par le processus de sélection du meilleur chemin. Si deux chemins sont configurés avec la même valeur de numéro de coût, le processus de sélection de la voie d'accès préfère le chemin avec l'ID de communauté le plus bas. Si les chemins ont des communautés de coût de pré-meilleur chemin inégales, le chemin avec la communauté de coût de pré-meilleur chemin inférieure est sélectionné comme meilleur chemin.
- La valeur ABSOLUE_VALUE est considérée comme la première étape afin de déterminer le degré de préférence d'un chemin. Par exemple, lorsque le protocole EIGRP est redistribué vers BGP VPNv4, le type ABSOLUTE_VALUE est utilisé pour la communauté de coût. IGB_Cost est considéré après comparaison de la distance intérieure (IGP) au saut suivant. Cela signifie que les communautés de coût avec le point d'insertion IGP_COST sont considérées après l'étape 8 de l'algorithme dans Comment fonctionne l'algorithme du meilleur chemin.
BGP par trajets multiples permet l'installation dans la table de routage IP des chemins aux BGP multiples vers la même destination. Ces chemins sont installés dans la table conjointement avec le meilleur chemin pour le partage de charge. BGP par trajets multiples n'affecte pas la sélection de bestpath (meilleur chemin). Par exemple, un routeur désigne toujours l’un des chemins comme meilleur chemin, selon l’algorithme, et annonce ce meilleur chemin à ses voisins.
Voici les fonctionnalités BGP par trajets multiples :
Multipath eBGP - maximum-paths n
iBGP Multipath - maximum-paths ibgp n
eiBGP Multipath - maximum-paths eibgp
Afin d'être candidats aux trajets multiples, les chemins vers la même destination nécessitent d'avoir ces fonctionnalités égales aux fonctionnalités de meilleur-chemin :
Poids
Préférence locale
Longueur AS-PATH (CHEMIN-AS)
Origine
MÉDICAMENT
Un de ces éléments :
Voisin AS ou sous-AS (avant l'ajout de la fonctionnalité d'eiBGP à trajets multiples)
AS-PATH (après l'ajout de la fonctionnalité multivoie d'eiBGP)
Quelques fonctionnalités BGP par trajets multiples imposent des conditions supplémentaires pour les candidats par trajets multiples.
Voici les conditions supplémentaires pour l'eBGP par trajets multiples :
Le chemin doit être appris d'un voisin externe ou d'un voisin externe de confédération (eBGP).
La métrique IGP vers le tronçon suivant BGP doit être égale à la métrique IGP du meilleur chemin.
Voici les conditions supplémentaires pour les trajets multiples iBGP :
Le chemin doit être appris d'un voisin interne (iBGP).
La métrique IGP vers le tronçon suivant BGP doit être égale à la métrique IGP du meilleur chemin, sauf si le routeur est configuré pour le multichemin iBGP de coût différent.
Le BGP insère jusqu'à n voies d'accès les plus récemment reçues des candidats par trajets multiples dans la table de routage IP. La valeur maximale de n est actuellement de 6. La valeur par défaut, lorsque le multichemin est désactivé, est de 1.
Pour l'équilibrage de charge de coût inégal, vous pouvez également utiliser la bande passante de la liaison BGP.
Remarque : Le prochain auto-saut équivalent est exécuté sur le meilleur chemin qui est sélectionné parmi des trajets multiples d'eBGP avant qu'il soit expédié aux partenaires internes.
Révision | Date de publication | Commentaires |
---|---|---|
5.0 |
02-Dec-2024 |
Formatage et liens fixes. |
4.0 |
11-Jul-2023 |
Titre, introduction et mise en forme mis à jour.
Ajout d'informations générales. |
3.0 |
22-Jun-2022 |
Mise à jour des directives de traduction automatique. |
1.0 |
10-Dec-2001 |
Première publication |