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 comment configurer l'attribut de mesure AIGP (Accumulated Interior Gateway Protocol) qui est transporté par le Border Gateway Protocol (BGP) dans Cisco IOS®.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Cette section fournit une vue d'ensemble de l'attribut de métrique AIGP et quelques considérations importantes concernant son utilisation.
Les entreprises peuvent souhaiter mettre en oeuvre une conception de réseau dans laquelle le réseau est divisé par plusieurs protocoles IGP (Interior Gateway Protocol), chacun avec un système autonome BGP. Ceci est utilisé pour des raisons d'évolutivité, où le réseau devient trop grand pour un IGP. Le BGP aide à évoluer lorsqu'il transporte certaines des routes qui autrement seraient transportées par l'IGP. La solution qui utilise AIGP est destinée aux réseaux avec différents systèmes autonomes BGP sous un contrôle administratif unique.
Voici un exemple :
Le service de bout en bout est le VPN MPLS (Multi-Protocol Label Switching). Lorsqu'il y a un grand nombre de routeurs de périphérie de fournisseur (PE) dans le réseau, le protocole IGP doit transporter trop de routes. La solution consiste à faire en sorte que BGP transporte les interfaces de bouclage des routeurs PE. La solution utilisée pour s'assurer que le chemin LSP (Label Switched Path) MPLS n'est pas interrompu de bout en bout consiste à utiliser l'étiquette BGP IPv4 +. Cela signifie que RFC 3107 est utilisé entre les routeurs PE et les routeurs périphériques, qui connectent les différents domaines IGP.
Le problème avec cette solution est que les routeurs périphériques ou les routeurs PE ne peuvent plus prendre de décision sur le meilleur chemin, en fonction de la métrique la plus courte de bout en bout, parce qu'il n'y a plus un protocole IGP qui s'exécute sur l'ensemble du réseau. La solution à ce problème est le nouvel attribut BGP, appelé Accumulated IGP Metric Attribute ou AIGP metric attribute. Cet attribut non transitif BGP transporte la métrique cumulée des chemins de sorte que les haut-parleurs BGP reçoivent une connaissance de la métrique de bout en bout de ces chemins.
Les haut-parleurs BGP doivent ajouter la route à la métrique de tronçon suivant à la valeur actuelle dans l'attribut de métrique AIGP avant que la route ne soit transférée.
Note: La comparaison des chemins pour une route est effectuée immédiatement après la comparaison de la préférence locale. Référez-vous au document Cisco Best Path Selection Algorithm BGP pour plus de détails sur l'Algorithme BGP Best Path Selection Algorithm.
Cette solution est similaire à la solution où le MED (Multi Exit Discriminator) est défini sur la métrique IGP. Cependant, dans ce cas, l'étape 6 (MED le plus bas) détermine le meilleur chemin. Cette étape intervient après l'étape 4, où le chemin le plus court décide du meilleur chemin. Le meilleur chemin est souvent déjà trouvé avant l'étape 6. Avec la solution AIGP, la décision BGP normale est modifiée de sorte que l'AIGP soit vérifié après l'étape 3 afin de déterminer si la route a été annoncée localement. Si différents systèmes autonomes voisins (AS) sont homologues avec le haut-parleur BGP, cela signifie que la valeur always-compare-med doit être activée.
L'attribut de métrique AIGP est spécifié dans RFC 7311, qui est l'attribut de métrique IGP cumulé pour BGP. Afin de porter la valeur de métrique AIGP dans la communauté de coûts, les procédures spécifiées dans draft-retana-idr-aigp-cost-community (Utilisation de la communauté de coûts pour porter la métrique IGP accumulée) sont utilisées.
Note: La métrique AIGP attribuée au protocole BGP fournit un routage optimal dans les réseaux où différents domaines de routage sont interconnectés via le protocole BGP.
Lorsque le protocole AIGP est utilisé, les modifications suivantes sont apportées à l'algorithme de sélection du meilleur chemin BGP :
Si les IGP du réseau sont de types différents (OSPF (Open Shortest Path First), IS-IS (Intermediate System-to-Intermediate System), EIGRP (Enhanced Interior Gateway Routing Protocol)), il est peu probable que la métrique résultant de l'utilisation de l'attribut AIGP donne des résultats cohérents ou raisonnables. Si le même protocole IGP est utilisé dans les différents domaines, les mêmes paramètres de métrique doivent être utilisés afin de garantir des résultats cohérents.
Pour que les routeurs périphériques ou les routeurs PE puissent choisir entre plusieurs chemins (en fonction de la métrique dérivée AIGP), ils doivent d’abord recevoir plusieurs chemins. Pour cette raison, vous devrez peut-être activer la fonctionnalité BGP Additional Path (ADD-Path) ou Advertise Best External.
Les homologues BGP qui sont activés pour AIGP et ceux qui ne le sont pas sont placés dans des groupes de mise à jour distincts. En outre, les homologues BGP qui sont activés pour AIGP dans la communauté de coûts sont placés dans des groupes de mises à jour distincts.
Si des routeurs du réseau ne sont pas compatibles avec le protocole AIGP (anciens routeurs), il existe deux solutions possibles :
Cette section décrit comment configurer l'attribut de métrique AIGP.
L'AIGP doit être explicitement activé pour les sessions BGP internes (iBGP) et BGP externes (eBGP) avec le neighbor ip-address aigp
erasecat4000_flash:.
Voici comment vérifier si l'AIGP est activé pour l'homologue BGP :
P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP
For address family: IPv4 Unicast
AIGP is enabled
L'AIGP peut être défini sur la métrique IGP ou sur une valeur. En outre, l'AIGP peut être défini pour certaines routes spécifiques uniquement pour un IGP via un route-map
. Lorsque l'initiateur de l'AIGP voit un changement dans la métrique IGP, il doit envoyer une nouvelle mise à jour BGP avec les nouvelles valeurs AIGP pour les routes affectées.
La métrique AIGP peut être définie automatiquement sur la métrique IGP ou sur une valeur arbitraire de 32 bits :
P1(config-route-map)#set aigp-metric ?
<0-4294967295> manual value
igp-metric metric value from rib
Cet exemple montre comment définir la métrique AIGP à la métrique de la route IGP :
ip prefix-list loopback seq 5 permit 10.100.1.1/32
!
route-map redistribute-loopback permit 10
match ip address prefix-list loopback
set aigp-metric igp-metric
Si ce bouton est activé, alors le BGP n'utilise pas le déroutement AIGP, sauf si les deux chemins ont l'attribut de métrique AIGP. Cela signifie que l'attribut AIGP n'est pas évalué lors du processus de sélection du meilleur chemin entre deux chemins lorsqu'un chemin n'a pas l'attribut AIGP.
Voici un exemple :
router bgp 65000
bgp bestpath aigp ignore
Si le routeur PE2 ne dispose pas d'un logiciel prenant en charge l'attribut de métrique AIGP (il s'agit d'un routeur hérité), vous pouvez utiliser deux solutions.
Configurez les routeurs P3 et P4 afin de traduire le coût IGP en une communauté de coûts que le routeur peut annoncer à un routeur hérité :
P3#show run | beg router bgp
router bgp 65000
address-family ipv4
neighbor 10.1.9.2 activate
neighbor 10.1.9.2 send-community both
neighbor 10.1.9.2 aigp send cost-community 100 poi igp-cost transitive
P4#show run | beg router bgp
router bgp 65000
address-family ipv4
neighbor 10.1.10.2 activate
neighbor 10.1.10.2 send-community both
neighbor 10.1.10.2 aigp send cost-community 100 poi igp-cost transitive
Vous devez autoriser le routeur qui envoie à envoyer des communautés étendues. Cela signifie que vous devez spécifier le send-community extended
ou send-community both
attributs (neighbor x.x.x.x send-community
) pour l'homologue BGP.
Voici un exemple :
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
Advertised to update-groups:
6
Refresh Epoch 2
65000 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, localpref 100, valid, external, best
Extended Community: Cost(transitive):igp:100:6
mpls labels in/out 17/16
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 15
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, localpref 100, valid, external
Extended Community: Cost(transitive):igp:100:11
mpls labels in/out 17/30
rx pathid: 0, tx pathid: 0
Comme indiqué, le routeur PE2 a choisi le chemin ayant le coût le plus bas (100:6 contre 100:11) comme meilleur chemin.
Configurez les routeurs P3 et P4 afin de traduire le coût IGP en MED que le routeur peut annoncer à un routeur hérité.
Voici la configuration du routeur P3 :
router bgp 65000
address-family ipv4
neighbor 10.1.9.2 activate
neighbor 10.1.9.2 send-community both
neighbor 10.1.9.2 aigp send med
Voici la configuration du routeur P4 :
router bgp 65000
address-family ipv4
neighbor 10.1.10.2 activate
neighbor 10.1.10.2 send-community both
neighbor 10.1.10.2 aigp send med
Le résultat de debug bgp ipv4 unicast updates in
affiche l'utilisation de l'attribut de métrique AIGP :
PE2#
BGP(0): 10.1.9.4 rcvd UPDATE w/ attr: nexthop 10.1.9.4, origin ?, aigp-metric 22,
merged path 65000 65001, AS_PATH
Lorsque vous affichez l'image fournie dans la section de ce document, vous pouvez voir que toutes les liaisons du réseau AS 6500 ont un coût OSPF de 10, les liaisons entre les routeurs P1 et P4 et entre P2 et P3 ont un coût OSPF de 100, et la liaison entre les routeurs P3 et P1 a un coût 5.
Il s’agit de la route pour 10.100.1.1/32, comme indiqué sur le routeur P3 :
P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (2 available, best #1, table default)
Additional-path-install
Path advertised to update-groups:
5
Refresh Epoch 5
65001
10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x0, tx pathid: 0x0
Path not advertised to any peer
Refresh Epoch 5
65001
10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x1, tx pathid: 0x1
Il s’agit de la route pour 10.100.1.1/32, comme indiqué sur le routeur P4 :
P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (2 available, best #2, table default)
Additional-path-install
Path not advertised to any peer
Refresh Epoch 5
65001
10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x0, tx pathid: 0x1
Path advertised to update-groups:
35
Refresh Epoch 5
65001
10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x1, tx pathid: 0x0
Il s’agit de la route pour 10.100.1.1/32, comme indiqué sur le routeur PE2 :
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 4
Paths: (2 available, best #2, table default)
Advertised to update-groups:
5
Refresh Epoch 1
65000 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, localpref 100, valid, external
mpls labels in/out 18/17
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, localpref 100, valid, external, best
mpls labels in/out 18/30
rx pathid: 0, tx pathid: 0x0
Le meilleur chemin sur le routeur P3 est le chemin avec la métrique IGP 6, avec le routeur P1 comme prochain saut. Le meilleur chemin sur le routeur P4 est le chemin avec la métrique IGP 11, avec le routeur P2 comme prochain saut. Les routeurs P3 et P4 envoient leur meilleur chemin vers le routeur PE2. Le routeur PE2 choisit le chemin du routeur P4 comme étant le meilleur, ce qui a été décidé car les deux chemins BGP sur le routeur PE2 sont très similaires et l'étape 10 était le séparateur de liaison : le plus ancien chemin externe a gagné. Cela signifie que le trafic du routeur PE2 vers le routeur PE1 emprunte le chemin PE2-P4-P2-PE1. Cependant, le chemin global le plus court, si vous considérez le coût IGP, est PE2-P3-P1-PE1.
Utilisez les informations suivantes afin de vérifier l'attribut de métrique AIGP sur les routeurs P3 et P4 vers le routeur PE2 (10.100.1.7) :
Voici le résultat pour le routeur P3 :
router bgp 65000
address-family ipv4
bgp additional-paths select all
bgp additional-paths receive
bgp additional-paths install
neighbor 10.1.9.2 activate
neighbor 10.1.9.2 aigp
neighbor 10.1.9.2 send-label
neighbor 10.100.1.7 activate
neighbor 10.100.1.7 aigp
neighbor 10.100.1.7 next-hop-self
neighbor 10.100.1.7 send-label
Voici le résultat pour le routeur P4 :
router bgp 65000
address-family ipv4
bgp additional-paths select all
bgp additional-paths receive
bgp additional-paths install
neighbor 10.1.10.2 activate
neighbor 10.1.10.2 aigp
neighbor 10.1.10.2 send-label
neighbor 10.100.1.7 activate
neighbor 10.100.1.7 aigp
neighbor 10.100.1.7 next-hop-self
neighbor 10.100.1.7 send-label
Vous pouvez voir que le routeur P3 dispose désormais des éléments suivants :
P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #2, table default)
Additional-path-install
Path not advertised to any peer
Refresh Epoch 11
65001
10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
backup/repair, all
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 28/31
rx pathid: 0x1, tx pathid: 0x1
Path advertised to update-groups:
5
Refresh Epoch 11
65001
10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 28/30
rx pathid: 0x0, tx pathid: 0x0
Le routeur P4 dispose désormais des éléments suivants :
P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #1, table default)
Additional-path-install
Path advertised to update-groups:
35
Refresh Epoch 11
65001
10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 16/31
rx pathid: 0x1, tx pathid: 0x0
Path not advertised to any peer
Refresh Epoch 11
65001
10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
backup/repair, all
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 16/30
rx pathid: 0x0, tx pathid: 0x1
La métrique IGP des chemins sur les routeurs P3 et P4 n'a pas changé, mais le routeur PE2 reçoit maintenant les routes avec l'attribut AIGP des routeurs P3 et P4.
Le routeur PE2 voit les deux chemins. Chaque chemin possède l'attribut AIGP, et le chemin avec l'attribut de métrique AIGP le plus bas gagne maintenant :
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
Advertised to update-groups:
5
Refresh Epoch 1
65000 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
mpls labels in/out 18/17
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, aigp-metric 11, localpref 100, valid, external
mpls labels in/out 18/30
rx pathid: 0, tx pathid: 0
Si le chemin reçu du routeur P3 est plus long que le chemin reçu du routeur P4 sur le routeur PE2, le routeur PE2 choisit toujours le meilleur chemin du routeur P3. Vous pouvez augmenter le chemin que le routeur P3 annonce par un seul via un route-map
et as-prepending
.
router bgp 65000
address-family ipv4
neighbor 10.1.9.2 route-map as_path out
route-map as_path permit 10
set as-path prepend last-as 1
Le routeur PE2 dispose désormais de la route à partir du routeur P3 avec un AS supplémentaire dans le chemin AS :
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 7
Paths: (2 available, best #1, table default)
Advertised to update-groups:
5
Refresh Epoch 1
65000 65001 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
mpls labels in/out 18/nolabel
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, aigp-metric 11, localpref 100, valid, external
mpls labels in/out 18/30
rx pathid: 0, tx pathid: 0
En raison de l’attribut de métrique AIGP, le routeur PE2 choisit toujours le chemin du routeur P3 comme étant le meilleur. La vérification AIGP est effectuée avant la vérification de la longueur du chemin du système autonome.
Si vous supprimez la possibilité d'envoyer l'AIGP sur le routeur P4 vers le routeur PE2, le routeur PE2 reçoit le chemin sans l'attribut de métrique AIGP du routeur P4. Cependant, le routeur PE2 a toujours le chemin du routeur P3 avec AIGP. Le routeur PE2 préfère le chemin avec AIGP sur un chemin sans AIGP, et il choisit le meilleur chemin à partir du routeur P3 :
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (2 available, best #2, table default)
Advertised to update-groups:
6
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, localpref 100, valid, external
mpls labels in/out 17/30
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65000 65001 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
mpls labels in/out 17/nolabel
rx pathid: 0, tx pathid: 0x0
Note: Si vous voulez que le routeur PE2 ignore l'AIGP lors du processus de sélection du meilleur chemin BGP, configurez la bgp bestpath aigp ignore
erasecat4000_flash:.
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
18-May-2021 |
Première publication |