Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Vue d'ensemble des attributs de métrique AIGP

Modifications apportées à l'algorithme de sélection du meilleur chemin BGP

Considérations importantes

Solution pour les anciens routeurs

Configuration

Activer la transmission de l'attribut AIGP

Origine de l'AIGP

Noter pour désactiver la coupure de jonction AIGP

Solution pour les anciens routeurs

Traduction de l'AIGP vers la communauté des coûts

Traduction de l'AIGP en MED

Vérification

Dépannage

Introduction

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

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

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.

Informations générales

Cette section fournit une vue d'ensemble de l'attribut de métrique AIGP et quelques considérations importantes concernant son utilisation.

Vue d'ensemble des attributs de métrique AIGP

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.

Modifications apportées à l'algorithme de sélection du meilleur chemin BGP

Lorsque le protocole AIGP est utilisé, les modifications suivantes sont apportées à l'algorithme de sélection du meilleur chemin BGP :

- L'algorithme de sélection du meilleur chemin BGP est modifié afin de comparer l'AIGP immédiatement après l'étape 3 (Routes annoncées localement) et après vérification du saut suivant est valide.

- Lorsque le routeur considère un chemin AIGP par rapport à un chemin AIGP, la valeur de la métrique AIGP est ajoutée à la métrique vers le tronçon suivant.

- Lorsque le routeur considère un chemin AIGP par rapport à un chemin non AIGP, le BGP préfère le chemin avec l'attribut AIGP par défaut.

- Lorsque la métrique IGP la plus basse est comparée au saut suivant BGP, le coût AIGP est pris en compte.

- Si la route vers le tronçon suivant a une métrique AIGP, la métrique est ajoutée à la métrique IGP vers le tronçon suivant. Cette somme correspond à la nouvelle métrique IGP (coût intérieur) de la route. Cela se produit lorsqu'une route BGP est récursive à une autre route BGP.

Considérations importantes

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.

Solution pour les anciens routeurs

Si des routeurs du réseau ne sont pas compatibles avec le protocole AIGP (anciens routeurs), il existe deux solutions possibles :

- Un routeur peut traduire le protocole AIGP en une communauté de coûts, le joindre à la route et annoncer la route au routeur hérité.

- Un routeur peut traduire l'AIGP en MED, le joindre à la route et annoncer la route au routeur hérité.

Configuration

Cette section décrit comment configurer l'attribut de métrique AIGP.

Activer la transmission de l'attribut 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

Origine de l'AIGP

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

Noter pour désactiver la coupure de jonction AIGP

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

Solution pour les anciens routeurs

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.

Traduction de l'AIGP vers la communauté des coûts

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.

Traduction de l'AIGP en MED

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

Vérification

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

Dépannage

Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.