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 du show ip bgp longer-prefixes
erasecat4000_flash:. Dans ce cas, quelques chemins ne sont pas considérés comme candidats pour le meilleur chemin. Ces chemins n'ont généralement pas l'indicateur valide dans la sortie du show ip bgp longer-prefixes
erasecat4000_flash:. Les routeurs ignorent des chemins dans ces circonstances :
Chemins marqués comme non synchronisés dans le show ip bgp longer-prefixes
sortie.
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 synchronisation à l'aide de no synchronization
Sous-commande 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 des listes d'accès, de préfixe, AS_PATH ou de communauté, sauf si vous avez configuré neighbor soft-reconfiguration inbound
pour le voisin.
Si vous avez activé bgp enforce-first-as
et UPDATE 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 le show ip bgp longer-prefixes
rendement
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 : WEIGHT 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 la valeur définie avec le bgp default local-preference
ou pour avoir une valeur de 100 par défaut.
Préférez le chemin qui a été créé localement via un network
ou aggregate
Sous-commande BGP ou par redistribution à partir d'un IGP.
Les chemins locaux qui proviennent de la network
ou redistribute
sont préférées aux agrégats locaux provenant de l' aggregate-address
erasecat4000_flash:.
Remarque : soyez conscient de ce point :
- Si AIGP est configuré ET que le 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 : tenez compte des points suivants :
- Cette étape est ignorée si vous avez configuré le bgp bestpath as-path ignore
erasecat4000_flash:.
-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 : IGP est inférieur à Exterior Gateway Protocol (EGP), et EGP est inférieur à INCOMPLETE.
Préférez le chemin avec le discriminateur de sorties multiples (MED) le plus bas.
Remarque : tenez compte des points 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ée, les 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é, les MED sont comparés pour tous les chemins qui se composent uniquement de 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.
- Les chemins reçus sans MED se voient attribuer un MED de 0, sauf si vous avez 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 attribué aux chemins.
Si vous avez activé bgp bestpath med missing-as-worst
, un MED de 4 294 967 295 est affecté aux chemins, avec effet sur les codes corrigés pour l'ID de bogue Cisco CSCef34800.
-Les 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 à 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é le bgp best path compare-routerid
erasecat4000_flash:.
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. En outre, vous pouvez utiliser la 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 d'émetteur est remplacé par l'ID de routeur dans le processus de sélection de 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 le BGP neighbor
configuration. 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. Les show ip bgp network
affiche les entrées de 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 : tenez compte des points suivants :
- Cette étape est ignorée si vous avez émis le bgp bestpath cost-community ignore
erasecat4000_flash:.
- 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é. Une valeur de numéro de coût par défaut de 2.147.483.647 est assignée aux chemins qui ne sont pas spécifiquement configurés avec la valeur du numéro de coût. Cette valeur est le point médian entre 0 et 4.294.967.295. Ces chemins sont alors évalués en conséquence par le meilleur processus de sélection de la voie d'accès. 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 :
Trajets multiples eBGP - maximum-paths n
Trajets multiples iBGP - maximum-paths ibgp n
Chemin multiple eiBGP - 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, si les trajets multiples sont désactivés, 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 : l'auto-tronçon suivant équivalent est exécuté sur le meilleur chemin qui est sélectionné parmi les chemins multiples eBGP avant qu'il ne soit transféré aux homologues internes.
Révision | Date de publication | Commentaires |
---|---|---|
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 |