Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Attribut de protocole de passerelle intérieure cumulé

Exemples de cas d'utilisation

1. Réseau multi-ASN

Configuration

Vérification

2. MPLS transparent (ASN unique)

Observations

Journaux des périphériques - Initial

Solution AIGP

Configuration

Exemple de configuration

Journaux des périphériques - Après l'implémentation AIGP

Éléments à prendre en compte

Ignorer AIGP

Conclusion

Informations connexes

Introduction

Ce document décrit ce qu'est la métrique du protocole AIGP (Accumulated Interior Gateway Protocol) dans le protocole BGP (Border Gateway Protocol) et ses exemples d'utilisation.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- BGP

- Réseau MPLS (Multiprotocol Label Switching) transparent

Composants utilisés

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. Si votre réseau est actif, assurez-vous de comprendre l'impact potentiel de toute commande.

Informations générales

Cette section fournit un aperçu de la métrique AIGP et quelques considérations importantes concernant son utilisation.

Comme vous le savez, IGP est l'acronyme de Interior Gateway Protocol et représente un groupe de protocoles de routage qui s'exécutent au sein d'un domaine administratif unique. Le protocole IGP prend une décision de sélection de chemin basée sur la valeur métrique.

Le protocole BGP est conçu pour fournir un routage sur un grand nombre de systèmes autonomes indépendants (AS) avec une coordination limitée ou inexistante entre les administrations respectives. Il ne prend pas ses décisions de sélection de chemin à l'aide d'une métrique. Cependant, dans certains déploiements, une seule administration exécute plusieurs réseaux BGP contigus. Dans de tels cas, il peut être souhaitable dans ce domaine administratif unique, pour BGP de sélectionner des chemins basés sur une métrique, tout comme un IGP le ferait.

Attribut de protocole de passerelle intérieure cumulé

La métrique AIGP (définie via RFC7311) est un attribut de chemin BGP non transitif facultatif. Le champ de valeur de l'attribut AIGP est défini comme un ensemble d'éléments Type/Length/Value (TLV). Le TLV AIGP BGP contient la métrique IGP accumulée.

Remarque : les routeurs BGP qui ne prennent pas en charge les attributs facultatifs non transitifs (par exemple, AIGP) doivent supprimer ces attributs et ne doivent pas les transmettre à d'autres homologues BGP. La métrique AIGP n'est pas conçue pour être transitive entre des systèmes autonomes complètement distincts (uniquement au-delà des frontières internes du système autonome).

Exemples de cas d'utilisation

1. Réseau multi-ASN

Aujourd’hui, de nombreux réseaux se trouvent dans un domaine administratif unique, qui sont subdivisés en plusieurs ASN pour diverses raisons. Il pourrait y avoir de nombreuses raisons possibles à cela :

- échelle IGP

- Un réseau de fournisseur a été acheté par un autre fournisseur de réseau, mais ils n'ont toujours pas fusionné leurs ASN BGP en interne

- Différentes divisions commerciales ont leur propre réseau en interne

- Confédérations BGP avec Sub-AS

- MPLS transparent, etc.

Dans des réseaux comme ceux-ci, il peut être utile de permettre à BGP de prendre ses décisions en fonction de la métrique IGP, de sorte que BGP choisisse le chemin de bout en bout le plus court entre deux noeuds, même si les noeuds sont dans deux ASN différents.

Par exemple : le réseau ABC, qui est subdivisé en deux ASN BGP, ASN 1 et ASN 2. Ils sont en appairage au niveau ASBR et les coûts de liaison IGP représentent la bande passante. L'objectif ici est d'avoir un chemin optimal de bout en bout entre PE11 et PE21.

Réseau multi-ASN sans AIGP

Remarque :

1. En supposant que Add-path est activé sur R1/2 pour annoncer les deux NH vers PEx.

2. Les périphériques utilisés dans le scénario mentionné précédemment fonctionnent tous avec Cisco IOS-XE.

PE11#sh bgp ipv4 unicast 10.0.21.21/32

BGP routing table entry for 10.0.21.21/32, version 20

Paths: (2 available, best #2, table default)

Not advertised to any peer

Refresh Epoch 3

2

192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)

Origin IGP, metric 0, localpref 100, valid, internal

Originator: 192.168.0.12, Cluster list: 192.168.11.11

rx pathid: 0x1, tx pathid: 0

Refresh Epoch 3

2

192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 192.168.0.11, Cluster list: 192.168.11.11

rx pathid: 0x0, tx pathid: 0x0

Avec AiGP activé dans la topologie (sur PE11, PE32, ASBR1x, ASBR2x, RR1, RR2), PE11 choisit maintenant le chemin avec le coût IGP de bout en bout le plus faible.

Réseau multi-ASN avec AIGP

Configuration

PEx, ASBRx, Rn :

Configuration de la fonctionnalité AIGP :

router bgp ASN

neighbor <NBR_IP> aigp

!

Remarque : l'appairage BGP abandonne et rétablit pour négocier cette nouvelle fonctionnalité. Il est donc conseillé de l'effectuer dans une fenêtre de maintenance.

Annoncez la métrique AIGP pour un préfixe.

PE21 :

route-map SET_AIGP permit 10

set aigp-metric igp-metric

!

router bgp 2

address-family {ipv4|ipv6} unicast

network 10.0.21.21 mask 255.255.255.255 route-map SET_AIGP

!

Vérification

PE11#sh bgp ipv4 unicast 10.0.21.21/32

BGP routing table entry for 10.0.21.21/32, version 21

Paths: (2 available, best #2, table default)

Not advertised to any peer

Refresh Epoch 3

2

192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)

Origin IGP, aigp-metric 501, metric 0, localpref 100, valid, internal

Originator: 192.168.0.11, Cluster list: 192.168.11.11

rx pathid: 0x1, tx pathid: 0

Refresh Epoch 3

2

192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)

Origin IGP, aigp-metric 201, metric 0, localpref 100, valid, internal, best

Originator: 192.168.0.12, Cluster list: 192.168.11.11

rx pathid: 0x0, tx pathid: 0x0

2. MPLS transparent (ASN unique)

Dans un grand réseau principal de fournisseur de services, le réseau de transport est généralement subdivisé en différents domaines IGP, assemblés à l'aide de la monodiffusion étiquetée BGP pour fournir un chemin commuté étiqueté de bout en bout (LSP). Les routeurs périphériques exécutent le protocole NHS (Next Hop Self) dans BGP LU AF.

IGP/LDP transporte les informations de préfixe/étiquette uniquement dans la zone/le domaine local. Ensuite, BGP transporte le préfixe/étiquette vers toutes les zones/domaines distants en redistribuant les routes dans BGP aux limites de zone. Les routes/étiquettes sont ensuite annoncées à l’aide de LSP. Le saut suivant pour la route est changé à chaque ABR en routeur local, ce qui élimine le besoin de laisser des routes IGP à travers les limites de zone/domaine.

Dans ce schéma de topologie, il y a un seul domaine BGP divisé en 2 domaines IGP (CORE et Access-1). Le numéro affiché à côté de chaque liaison représente le coût/la mesure IGP de cette liaison.

Réseau MPLS transparent sans AIGP

Défi : le trafic descendant de PS-Core vers eNB/gNB (connecté à CSR15) emprunte un chemin asymétrique et sous-optimal par rapport au trafic ascendant de eNB/gNB (connecté à CSR15) vers PS-Core, ce qui entraîne des problèmes de latence dans le trafic de mobilité.

Observations

1. Principalement observé dans les scénarios de limite géographique où le même routeur d'agrégation agit comme un routeur de limite commun pour plusieurs domaines d'accès (par exemple, AGG102 dans l'image mentionnée précédemment).

2. Pour le trafic ascendant, le routeur de site de cellules (CSR) choisit le routeur de périphérie le plus proche. Par exemple, CSR15 sélectionne AGG102 comme NextHop.

3. Pour le trafic descendant, le routeur d'agrégation de services (SAR) choisit également le routeur frontalier le plus proche. Par exemple, SAR150 sélectionne AGG101 (coût 180 < 200).

Journaux des périphériques - Initial

Trafic en amont - CSR15 à SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 so 10.0.2.15

Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]

L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 0 ms                !!!! AGG102

. 2 *                                                                 !!!! P112 does not have a route to CSR15

! 3 10.112.150.150 20 ms                                              !!!! SAR150

Trafic en aval - SAR150 à CSR15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 source 10.0.2.150

Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.101.150.150 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0]

L 1 10.101.150.101 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                 !!! AGG101

L 2 10.11.101.11 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                   !!! CSR11

L 3 10.11.12.12 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                    !!! CSR12

L 4 10.12.13.13 MRU 1500 [Labels: 16015 Exp: 0] 20 ms                    !!! CSR13

L 5 10.13.14.14 MRU 1500 [Labels: explicit-null Exp: 0] 30 ms            !!! CSR14

! 6 10.14.15.15 30 ms                                                    !!! CSR15

Solution AIGP

L’objectif est d’avoir un chemin optimal de bout en bout entre les routeurs SAR et les routeurs CSR. La monodiffusion étiquetée BGP (RFC 3107) est utilisée pour calculer la distance entre les routeurs SAR et CSR. La bande passante disponible sur chacune des liaisons principales est mappée au coût IGP, par conséquent le protocole BGP doit transporter ce coût correctement entre chacun des PE. Cette fonctionnalité est obtenue en utilisant l'AiGP.

Réseau MPLS transparent avec

AIPSRéseau MPLS transparent avec AIGP

Remarque :

1. En supposant que Add-path est activé sur les périphériques RR1/2, AGG, CSR et SAR pour annoncer les deux NH.

2. Tous les périphériques utilisés dans le scénario mentionné précédemment sont basés sur Cisco IOS-XR.

Configuration

La capacité d'attribut de chemin AiGP doit être convenue entre les homologues BGP. Les métriques AiGP sont uniquement incluses dans les annonces de préfixe entre les homologues compatibles AiGP. La fonctionnalité AIGP est configurée pour un homologue BGP individuel et une famille d'adresses BGP spécifique.

router bgp ASN

neighbor <NBR_IP>

address-family ipv4 unicast

aigp [disable]

La métrique AIGP est une valeur de 32 bits (0 à 4 294 967 295). Il peut être défini lors de la redistribution, de l'origine de la route via une instruction réseau ou lors de la réception d'un préfixe avec une carte de route/route-policy.

route-policy AIGP_POLICY

set aigp-metric igp-cost

end-policy

!

router bgp ASN

address-family {ipv4|ipv6} unicast

network <NETWORK/MASK> route-policy AIGP_POLICY

or

redistribute {ospf|isis} {process-id} route-policy AIGP_POLICY metric VALUE

!

Remarque :

1. Pour les routes redistribuées, la valeur attribuée à l'attribut AiGP est la valeur du saut suivant iGP vers la route ou telle qu'elle est définie par une stratégie de route.

2. Pour les routes statiques redistribuées dans BGP, la valeur attribuée est la valeur du tronçon suivant vers la route ou telle qu'elle est définie par une stratégie de route.

3. La route est importée dans BGP via une instruction network. La valeur attribuée est la valeur du tronçon suivant de la route ou telle qu'elle est définie par une stratégie de route.

Exemple de configuration

CSR15:

! Additional config lines related to AIGP are marked in RED color

route-policy SID($SID)

set label-index $SID

set aigp-metric igp-cost

end-policy

!

router bgp 1

address-family ipv4 unicast

network 10.0.2.15/32 route-policy SID(15)

neighbor-group RR

address-family ipv4 labeled-unicast

aigp

!

!

!

Remarque : une configuration similaire a été effectuée sur tous les périphériques d'appairage BGP respectifs.

Journaux des périphériques - Après l'implémentation AIGP

Trafic en aval - SAR150 à CSR15

RP/0/0/CPU0:SAR150#sh bgp ipv4 labeled-unicast 10.0.2.15/32

BGP routing table entry for 10.0.2.15/32

Versions:

Process bRIB/RIB SendTblVer

Speaker 411 411

Local Label: 16015

Last Modified: Oct 24 11:05:26.796 for 00:00:04

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.0.2.102 (metric 200) from 10.0.2.100 (10.0.2.15)

Received Label 16015

Origin IGP, metric 0, localpref 100, aigp metric 20, valid, internal, best, group-best, labeled-unicast

Received Path ID 1, Local Path ID 1, version 410

Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.102

Total AIGP metric 220

Label-Index: 15

Path #2: Received by speaker 0

Not advertised to any peer

Local

10.0.2.101 (metric 180) from 10.0.2.100 (10.0.2.15)

Received Label 16015

Origin IGP, metric 0, localpref 100, aigp metric 60, valid, internal, backup, add-path, labeled-unicast

Received Path ID 8, Local Path ID 7, version 411

Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.101

Total AIGP metric 240

Label-Index: 15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 so 10.0.2.150

Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.112.150.150 MRU 1500 [Labels: 16102/16015 Exp: 0/0]

L 1 10.112.150.112 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0] 10 ms          !!! P112

L 2 10.102.112.102 MRU 1500 [Labels: explicit-null Exp: 0] 10 ms                  !!! AGG102

! 3 10.15.102.15 20 ms                                                            !!! CSR15

Trafic en amont - CSR15 à SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 source 10.0.2.15

Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]

L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 10 ms                 !!! AGG102

. 2 *                                                                   !!! P112 does not have a route to CSR15

! 3 10.112.150.150 30 ms                                                !!! SAR150

Éléments à prendre en compte

- Avec les changements dans le coût IGP (par exemple, les changements dans la topologie physique à cause de la coupure de liaison et plus), il y a des changements correspondants dans BGP aussi bien. Cela peut provoquer le désactivation de la route BGP. Cette convergence dépend également de la valeur de délai du déclencheur de tronçon suivant BGP configurée pour les événements non critiques.

- En présentant AiGP, la meilleure sélection de chemin de BGP est modifiée. Il place BGP AIGP après la préférence locale BGP et avant l'attribut AS_PATH. Par conséquent, s'il existe des stratégies existantes concernant AS_PATH en attente, elles peuvent nécessiter une révision.

- Quand il y a deux chemins, l'un avec la métrique AIGP et l'autre sans, BGP préfère toujours un chemin avec la métrique AIGP.

Ignorer AIGP

Un périphérique qui exécute le protocole BGP (Border Gateway Protocol) peut également être configuré pour ignorer la métrique AIGP lors du meilleur processus de sélection de chemin entre deux chemins lorsqu'un chemin n'a pas la métrique AIGP. Utilisation de la commandebgp bestpath aigp ignore en mode de configuration du routeur Pour rétablir le fonctionnement par défaut du périphérique, utilisez la forme no de cette commande.

[no] bgp bestpath aigp ignore

Par défaut, BGP préfère toujours un chemin avec la métrique AIGP. S'il y a deux chemins, l'un avec la métrique AIGP et l'autre sans, alors l'exécution de la bgp bestpath aigp ignore commande entraîne BGP effectuant le meilleur calcul de chemin comme si aucun des chemins n'avait la métrique AIGP.

Conclusion

L'attribut BGP AIGP est certainement développé pour résoudre certains cas d'utilisation de niche, mais il doit être utilisé avec prudence.

Informations connexes

- Configurer l'attribut de mesure AIGP pour BGP

- Assistance technique de Cisco et téléchargements