Contenu

Conditions préalables

Conditions requises

Components Used

Introduction

Échange de capacités

Spécifications d'implémentation IOS-XR

Configuration de U ou de LU

Table BGP

Activation de l'allocation d'étiquette locale

Nouvelle implémentation sur IOS-XR

Groupes de mises à jour

Propagation de route

Attribution d'une étiquette locale

Allouer une étiquette pour les chemins non étiquetés

Calcul du meilleur chemin d'accès

Vérification du comportement dans BGP

iBGP et next-hop-self - MPLS unifié

Solutions

Exemple de configuration pour IOS-XR.

Ce document décrit le comportement de réception et d'annonce de chemins non étiquetés et étiquetés sur une session BGP dans Cisco IOS® XR.

Conditions préalables

Conditions requises

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

Components Used

Ce document est spécifique à Cisco IOS® XR, mais il n'est pas limité à une version logicielle ou à un matériel spécifique.

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.

Introduction

L'identificateur de famille d'adresses (AFI) est une indication du type de route BGP. Exemples : 1 pour IPv4 et 2 pour IPv6.

L’identificateur de famille d’adresses suivant (SAFI) est une autre indication du type de route. Exemple : 1 pour une route non étiquetée et 4 pour une route étiquetée.

La monodiffusion non étiquetée pour IPv4 est AFI 1 et SAFI 1.

La monodiffusion étiquetée pour IPv4 est AFI 1 et SAFI 4.

La monodiffusion non étiquetée pour IPv6 est AFI 2 et SAFI 1.

La monodiffusion étiquetée pour IPv6 est AFI 2 et SAFI 4.

La monodiffusion étiquetée (LU) est souvent appelée RFC 3107 “ informations d'étiquette dans BGP-4. ”

Par la suite, U fait référence à la monodiffusion non étiquetée, de sorte que SAFI 1 et LU font référence à la monodiffusion étiquetée, de sorte que SAFI 4.

Notez que Cisco IOS® XR a besoin “ étiquette d'allocation all| route-policy ... ” ou la route ne sera pas initiée ou propagée au prochain haut-parleur BGP comme SAFI 4.

La monodiffusion IPv4/v6 et la monodiffusion étiquetée sur une session BGP n'ont pas été prises en charge sur Cisco IOS® XR .

Sur Cisco IOS® XR, la prise en charge d'une session BGP non étiquetée et étiquetée a été effectuée dans 6.2.1.

Lorsque l'exécution des deux sur une session n'est pas prise en charge, il est problématique car la dernière mise à jour/suppression reçue remplace la précédente, même si elle a été reçue sur une autre SAFI.

Lorsque vous configurez SAFI 1 et 4 sur la même session BGP sur un routeur exécutant le code IOS-XR avant IOS-XR 6.2.1, le routeur émet l'avertissement suivant :

bgp[1051]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.

Ce message d'avertissement a été introduit dans IOS-XR 5.3.0 et IOS-XR 5.2.2.

Échange de capacités

Les fonctionnalités échangées entre homologues BGP doivent correspondre. Sinon, la session BGP ne s'affiche pas.

Il s'agit d'une capture Wireshark de la capacité échangée pour AFI 1/SAFI 1 et AFI 1/SAFI 4 dans le message d'ouverture BGP :

Image 1

Voici un exemple pour IOS-XR configuré avec LU uniquement sur une session à IOS configurée avec U uniquement.

IOS-XR :

RP/0/0/CPU0:R4#show bgp neighbor 10.100.1.8

BGP neighbor is 10.100.1.8

Remote AS 65003, local AS 65003, internal link

Remote router ID 0.0.0.0

BGP state = Idle

…

Connections established 0; dropped 0

Local host: 10.100.1.4, Local port: 179, IF Handle: 0x00000000

Foreign host: 10.100.1.8, Foreign port: 33396

Last reset 00:00:14, due to BGP Notification sent: unsupported/disjoint capability

Time since last notification sent to neighbor: 00:00:14

Error Code: unsupported/disjoint capability

Notification data sent:

None

Le routeur IOS imprime un message syslog pour cette erreur de configuration :

*Aug  8 12:40:44.719: %BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 active 2/7 (unsupported/disjoint capability) 0 by

Spécifications d'implémentation IOS-XR

Configuration de U ou de LU

Vous configurez “ adresse-family ipv4 unicast ” sous la commande BGP neighbor pour activer la monodiffusion ipv4 pour la session BGP.

Vous configurez “ adresse-family ipv6 unicast ” sous la commande BGP neighbor pour activer la monodiffusion ipv6 pour la session BGP.

Vous configurez “ address-family ipv4 labellisé-unicast ” sous la commande BGP neighbor pour activer ipv4 étiqueté unicast pour la session BGP.

Vous configurez “ adresse-family ipv6 labellisé-unicast ” sous la commande BGP neighbor pour activer la monodiffusion étiquetée ipv6 pour la session BGP.

Dans IOS-XR, la combinaison AFI/SAFI est configurée par homologue BGP.

Voici un exemple pour une session BGP avec SAFI 1 et 4 :

router bgp 65003

address-family ipv4 unicast

redistribute connected

allocate-label all unlabeled-path

…

neighbor 10.100.1.7

remote-as 65003

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

address-family ipv4 labeled-unicast

route-reflector-client

Notez qu'il n'y a toujours que la monodiffusion de la famille d'adresses et non la monodiffusion de la famille d'adresses sous le routeur BGP. Les chemins SAFI 1 et 4 sont stockés dans cette table BGP unique.

Table BGP

Que l'IOS-XR soit plus ancien ou plus récent que 6.2.1, il n'y a qu'une seule table BGP pour stocker les routes U et LU. Ceci est évident par le fait que vous pouvez seulement configurer (activer) « address-family ipv4 unicast » ou « address-family ipv6 unicast » sous router bgp. Vous ne pouvez pas configurer « address-family ipv4 label-unicast » ou « address-family ipv6 label-unicast » sous router bgp.

Le chemin U et LU peut être identique. Avant IOS-XR 6.2.1, la réception du même chemin, mais cette fois avec ou sans étiquette, remplacerait le chemin précédemment reçu. Après IOS-XR 6.2.1, les deux chemins identiques sont considérés comme différents s'ils diffèrent uniquement par l'étiquette. Les ajouts, suppressions ou modifications de chemin sont effectués par les différentes SAFI.

Voici un exemple de route dans la table BGP avec AFI 1/SAFI 4. Comme l'allocation d'étiquette est activée pour tous les préfixes, ce chemin d'accès sera stocké avec une étiquette locale. Comme il n'y a qu'une seule table BGP pour stocker les routes U et LU, le préfixe apparaît avec les deux commandes “ show bgp ipv4 unicast ” et “ show bgp ipv4 labellisé unicast ”!

RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  5           5

Local Label: 24000

Last Modified: Aug  6 15:03:59.574 for 16:06:13

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.3 0.4

Advertised to peers (in unique update groups):

10.1.45.5

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3 0.4

Advertised to peers (in unique update groups):

10.1.45.5

65002 65001

10.1.24.2 from 10.1.24.2 (10.100.1.2)

Received Label 24003

Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 0, version 5

Origin-AS validity: not-found

Notez que le chemin est marqué avec “ ” de monodiffusion.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  5           5

Local Label: 24000

Last Modified: Aug  6 15:03:59.574 for 16:08:41

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.3 0.4

Advertised to peers (in unique update groups):

10.1.45.5

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3 0.4

Advertised to peers (in unique update groups):

10.1.45.5

65002 65001

10.1.24.2 from 10.1.24.2 (10.100.1.2)

Received Label 24003

Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 0, version 5

Origin-AS validity: not-found

Notez que le chemin est marqué avec “ ” de monodiffusion.

Si le chemin d'accès est présent en tant que U et LU, l'ID de chemin local est différent.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 30          30

Local Label: 24003 (no rewrite);

Flags: 0x00003028+0x00010000;

Last Modified: Aug 30 10:45:50.502 for 00:01:59

Paths: (2 available, best #1)

Advertised IPv4 Unicast paths to peers (in unique update groups):

10.100.1.8      10.100.1.9

Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):

0.8

Path #1: Received by speaker 0

Flags: 0x4000000009060205, import: 0x20

Advertised IPv4 Unicast paths to peers (in unique update groups):

10.100.1.8      10.100.1.9

Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):

0.8

65001, (Received from a RR-client)

10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)

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

Received Path ID 0, Local Path ID 1, version 29

Path #2: Received by speaker 0

Flags: 0x4080000008020205, import: 0x20

Not advertised to any peer

65001, (Received from a RR-client)

10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)

Received Label 24001

Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast

Received Path ID 0, Local Path ID 0, version 0

Activation de l'allocation d'étiquette locale

Vous devez configurer la commande “ l'” d'étiquette d'allocation afin que les chemins d'accès reçus ou sources dans BGP aient une étiquette MPLS locale. Sans cette commande, les routes n'ont pas d'étiquette locale.

RP/0/0/CPU0:R4#conf t

RP/0/0/CPU0:R4(config)#router bgp 65003

RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast

RP/0/0/CPU0:R4(config-bgp-af)#allocate-label ?

all           Allocate labels for all prefixes

route-policy  Use a route policy to select prefixes for label allocation

L'allocation d'étiquette se produit pour toutes les routes ou selon la stratégie de route configurée.

Nouvelle implémentation sur IOS-XR

Dans l'ancienne implémentation sur IOS-XR, un avertissement est donné lors de la configuration de l'U et de la LU sur la même session BGP. L'avertissement est introduit dans les versions 5.3.0 et 5.2.2 d'IOS-XR. L'avertissement est supprimé dans IOS-XR version 6.2.1, car les étiquettes et les étiquettes non étiquetées sont prises en charge sur la même session BGP.

Exemple :

RP/0/0/CPU0:ios#conf t

RP/0/0/CPU0:ios(config)#router bgp 65001

RP/0/0/CPU0:ios(config-bgp)#add ipv4 unicast

RP/0/0/CPU0:ios(config-bgp-af)#exit

RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1

RP/0/0/CPU0:ios(config-bgp-nbr)#remote-as 65001

RP/0/0/CPU0:ios(config-bgp-nbr)#exit

RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1

RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 unicast

RP/0/0/CPU0:ios(config-bgp-nbr-af)#exit

RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 labeled-unicast

RP/0/0/CPU0:ios(config-bgp-nbr-af)#commit

RP/0/0/CPU0:Aug 21 14:14:22.222 : bgp[1052]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.

L'explication de ce message d'erreur :

Ce message indique que l'utilisateur a configuré les familles d'adresses IPv4 Unicast et IPv4 Labeled-unicast ou IPv6 Unicast et IPv6 Labeled-unicast ensemble sous le même voisin. Cette configuration particulière n'est pas prise en charge.

Action recommandée : configurez deux sessions voisines sur le routeur. Configurez la famille d'adresses de monodiffusion sous la première session de voisinage et configurez la famille d'adresses de monodiffusion sous la deuxième session de voisinage.

Exemple de configuration de deux sessions BGP entre deux routeurs IOS-XR. Utilisez une adresse de bouclage différente pour chaque session BGP.

hostname R1

interface Loopback0

ipv4 address 10.100.1.1 255.255.255.255

!

interface Loopback1

ipv4 address 10.100.1.101 255.255.255.255

!

router bgp 65001

address-family ipv4 unicast

!

neighbor 10.100.1.2

remote-as 65001

update-source Loopback0

address-family ipv4 unicast

!

!

neighbor 10.100.1.102

remote-as 65001

update-source Loopback1

address-family ipv4 labeled-unicast

!

!

hostname R2

interface Loopback0

ipv4 address 10.100.1.2 255.255.255.255

!

interface Loopback1

ipv4 address 10.100.1.102 255.255.255.255

!

router bgp 65001

address-family ipv4 unicast

!

neighbor 10.100.1.1

remote-as 65001

update-source Loopback0

address-family ipv4 unicast

!

!

neighbor 10.100.1.101

remote-as 65001

update-source Loopback1

address-family ipv4 labeled-unicast

!

!

Dans IOS-XR 6.2.1, U et LU sont pris en charge sur la même session BGP sur le VRF par défaut !

Peu importe que la session BGP soit interne ou externe.

U et LU sur la même session ne sont pas pris en charge pour les haut-parleurs BGP dans les VRF non par défaut.

Groupes de mises à jour

Avant IOS-XR 6.2.1, tous les haut-parleurs U, LU et U + LU BGP étaient conservés dans des groupes de mise à jour distincts. Après la version 6.2.1 d'IOS-XR, ce n'est plus le cas. Certains haut-parleurs BGP d'un groupe de mise à jour peuvent être uniquement U, ou uniquement LU, ou U et LU.

Propagation de route

Le tableau suivant présente le comportement d'annonce et de retrait pour différents scénarios. Il y a 16 scénarios.

Tout s'applique à IOS-XR version 6.2.1 et ultérieure, sauf mention contraire dans la colonne des commentaires.

Cas

Type de chemin d'accès/d'adressage

Étiquette locale présente ?

NHS ou NHU

Update-group SAFI

Annoncer ou retirer ?

Commentaires

1

Chemin non étiqueté, c'est-à-dire pas d'étiquette RX

Oui

NHS

SAFI-1

Annoncer par défaut

Retirer avec advertise local-label-route (safi-unicast) disable, commande

Uniquement possible après le 6.5.1.

2

SAFI-4

Annoncer

Uniquement possible après le 6.5.1.

Itinéraires redist IPv4/v6 et 6PE : NHS implicite toujours

3

NHU

SAFI-1

Annoncer

Uniquement possible après le 6.5.1.

4

SAFI-4

Retirer

Uniquement possible après le 6.5.1.

Itinéraires redist IPv4/v6 et 6PE : NHU ignorée ; NHS implicite toujours

5

Non

NHS

SAFI-1

Annoncer

6

SAFI-4

Retirer

7

NHU

SAFI-1

Annoncer

8

SAFI-4

Retirer

9

Chemin étiqueté, c'est-à-dire avec étiquette rx

Oui

NHS

SAFI-1

Annoncer par défaut

Retirer avec la commande advertise local-labeled-route (safi-unicast) disable

Avant 6.2.1 : le comportement par défaut est Annoncer.

10

SAFI-4

Annoncer

11

NHU

SAFI-1

Retirer

Avant 6.2.1 :  le comportement est de faire de la publicité.

12

SAFI-4

Annoncer

13

Non

NHS

SAFI-1

Annoncer

14

SAFI-4

Retirer

15

NHU

SAFI-1

Retirer

Avant 6.2.1 :  le comportement est de faire de la publicité.

16

SAFI-4

Annoncer

Tableau 1 Comportement d'annonce pour les sessions iBGP et eBGP

NHS = Prochain saut auto

NHU = tronçon suivant non modifié.

Si la NHU est en vigueur, cela signifie que le saut suivant auto n'est pas configuré pour une session iBGP.

Notez que NHS est toujours le cas lorsque le haut-parleur BGP envoie à un homologue eBGP.

Il peut y avoir NHS ou NHU vers un haut-parleur iBGP, selon la configuration du saut suivant. Le comportement par défaut vis-à-vis des homologues iBGP est NHU.

Pour la deuxième colonne : notez que le chemin est considéré comme non étiqueté ou étiqueté uniquement si le meilleur chemin ou l'un des chemins marqués avec add-path n'est pas étiqueté ou étiqueté.

Pour la propagation de la route, il importe de connaître les caractéristiques du meilleur chemin. En fonction des caractéristiques (colonnes 2 à 4), il détermine si le chemin est annoncé en tant que U, LU ou les deux.

Si la fonctionnalité Chemins supplémentaires (ADD-PATH) est activée et qu'un chemin est marqué par « chemin supplémentaire », les caractéristiques de ce chemin jouent également un rôle dans la façon dont ce chemin sera annoncé.

Étiquette locale “ présente ? : No ” signifie ce qui suit : il est possible qu'une étiquette soit reçue avec la mise à jour reçue, mais l'étiquette n'est pas installée. L'étiquette locale n'est pas installée si la commande “ la ” d'étiquette d'allocation n'est pas présente.

Vous pouvez vérifier si l'étiquette locale est présente en examinant le préfixe en détail. Utilisez “ show bgp <prefix> detail ” ou “ show route <prefix> detail ”.

Dans l'exemple suivant, le préfixe est reçu sans étiquette (par exemple sur une homologue SAFI 1) et aucune étiquette locale n'est attribuée :

RP/0/0/CPU0:R2#show bgp ipv4 labeled-unicast 10.100.1.5/32 detail

BGP routing table entry for 10.100.1.5/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  3           3

Flags: 0x04001001+0x00000000;

Last Modified: Sep  5 03:44:45.647 for 01:01:27

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Path #1: Received by speaker 0

Flags: 0x4000000001040207, import: 0x00

Advertised to update-groups (with more than one peer):

0.3

Local, (Received from a RR-client)

10.100.1.1 (metric 2) from 10.100.1.1 (10.100.1.1)

Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 3

RP/0/0/CPU0:R2#show route 10.100.1.5/32 detail

Routing entry for 10.100.1.5/32

Known via "bgp 65001", distance 200, metric 0, type internal

Installed Sep  5 03:44:45.480 for 01:01:37

Routing Descriptor Blocks

10.100.1.1, from 10.100.1.1

Route metric is 0

Label: None

Tunnel ID: None

Extended communities count: 0

NHID:0x0(Ref:0)

Route version is 0x23 (35)

No local label

IP Precedence: Not Set

QoS Group ID: Not Set

Flow-tag: Not Set

Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_LOCAL

Download Priority 4, Download Version 52

No advertising protos.

Attribution d'une étiquette locale

Allouer une étiquette pour les chemins non étiquetés

Par défaut, les chemins non étiquetés (SAFI 1) ne sont jamais étiquetés, même lorsque la commande “ allocation-label ” est configurée.

Depuis la version 6.5.1 de IOS-XR, il existe le mot clé “ unlabel-path ” pour la commande “ allolabel-label ”, de sorte que les chemins non labellisés puissent également recevoir une étiquette.

RP/0/0/CPU0:R4#conf t

RP/0/0/CPU0:R4(config)#router bgp 65003

RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast

RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all ?

unlabeled-path  Allocate label for unlabeled paths too

<cr>

RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path ?

<cr>

RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path

RP/0/0/CPU0:R4(config-bgp-af)#commit

Le chemin est un chemin SAFI 1, il n'y a donc pas d'étiquette reçue.

En raison de la commande “ unlabel-path ” il existe maintenant une étiquette locale.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 16          16

Local Label: 24003 (no rewrite);

Flags: 0x01303028+0x00000000;

Last Modified: Aug 27 19:08:47.502 for 00:00:59

Paths: (1 available, best #1)

Advertised IPv4 Unicast paths to update-groups (with more than one peer):

0.3

Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):

0.7

Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):

10.1.45.5

Path #1: Received by speaker 0

Flags: 0x4000000009040207, import: 0x20

Advertised IPv4 Unicast paths to update-groups (with more than one peer):

0.3

Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):

0.7

Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):

10.1.45.5

65001, (Received from a RR-client)

10.100.1.10 (metric 2) from 10.100.1.10 (10.100.1.10)

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

Received Path ID 0, Local Path ID 1, version 16

RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32

Known via "bgp 65003", distance 200, metric 0

…

Route version is 0x4 (4)

Local Label: 0x5dc3 (24003)

IP Precedence: Not Set

…

Cela permettra de traiter les cas 1 à 4 du tableau 1.

Pour comprendre pourquoi une étiquette locale est toujours attribuée lors de la suppression de la commande ” d'allocation de “, exécutez la ” d'étiquette debug “ bgp.

Voici un exemple :

RP/0/0/CPU0:R4#debug bgp label

RP/0/0/CPU0:R4#show debug

####  debug flags set from tty 'con0_0_CPU0'  ####

ip-bgp default label flag is ON with value '##########'

Il est préférable d'activer ce débogage pour un préfixe ou un groupe de préfixes spécifiques. Voici un exemple :

RP/0/0/CPU0:R4#sh running-config route-policy match-prefix

route-policy match-prefix

if destination in (10.100.1.1/32) then

pass

else

drop

endif

end-policy

!

RP/0/0/CPU0:R4#debug bgp label route-policy match-prefix

RP/0/0/CPU0:R4#show debug

####  debug flags set from tty 'con0_0_CPU0'  ####

ip-bgp default label flag is ON with value '######match-prefix####'

RP/0/0/CPU0:R4#con t

RP/0/0/CPU0:R4(config)#router bgp 65003

RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast

RP/0/0/CPU0:R4(config-bgp-af)#no   allocate-label all

RP/0/0/CPU0:R4(config-bgp-af)#commit

RP/0/0/CPU0:Aug 23 12:43:02.786 : bgp[1048]: [default-lbl] (ip4u): Label computation done: table=TBL:default (1/1), net=10.100.1.1/32: netfl=0x05043001, path=0x1073ed5c(10.1.24.2/32,10.1.24.2,0,0x400000000d060001), pathrcvdlabel=24002: asbr=1, rr=0/1, nhselfcount=1: result="label required"

Vous pouvez voir que ce routeur a reçu une étiquette pour le préfixe 10.100.1.1/32, est un ASBR, n'est pas un RR et a le saut suivant pour au moins une session BGP. Ce préfixe a donc besoin d'une étiquette locale.

L'étiquette locale reste :

RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32 detail

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 13          13

Local Label: 16002 (no rewrite);

Flags: 0x05043001+0x00000200;

Last Modified: Aug 23 12:37:11.133 for 00:05:53

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.6

Advertised to peers (in unique update groups):

10.1.46.6       10.100.1.8      10.100.1.7

Path #1: Received by speaker 0

Flags: 0x400000000d060001, import: 0x1f

Advertised to update-groups (with more than one peer):

0.6

Advertised to peers (in unique update groups):

10.1.46.6       10.100.1.8      10.100.1.7

65002 65001

10.1.24.2 from 10.1.24.2 (10.100.1.2)

Received Label 24002

Origin IGP, localpref 100, valid, external, best, group-best, import-candidate

Received Path ID 0, Local Path ID 1, version 13

Origin-AS validity: not-found

RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32

Known via "bgp 65003", distance 20, metric 0, [ei]-bgp, labeled unicast (3107)

Tag 65002, type external

Installed Aug 23 12:37:11.440 for 00:06:02

Routing Descriptor Blocks

10.1.24.2, from 10.1.24.2, BGP external

Route metric is 0

Label: 0x5dc2 (24002)

Tunnel ID: None

Extended communities count: 0

NHID:0x0(Ref:0)

Route version is 0x4 (4)

Local Label: 0x3e82 (16002)

IP Precedence: Not Set

QoS Group ID: Not Set

Route Priority: RIB_PRIORITY_NON_RECURSIVE_LOW (11) SVD Type RIB_SVD_TYPE_LOCAL

Download Priority 4, Download Version 28

No advertising protos.

Le débogage affiche le message suivant lorsqu'une étiquette locale n'est pas requise :

RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: Prefix 10.100.1.1/32:()doesn't require label, releasing

RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: bgp_label_release_label: perform label release onnet 10.100.1.1/32net retain 0 label_retain 0

Si le préfixe est dans la LFIB dépend si le préfixe a été reçu étiqueté ou non et si l'étiquette d'allocation s'applique à ce préfixe.

L'étiquette reçue est 24002 pour le préfixe suivant.  Il n'est pas installé dans la LFIB, car BGP ne dispose pas de la commande allolabel.

RP/0/0/CPU0:R4#show bgp ipv4 unicast  10.100.1.1/32

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  4           4

Local Label: 24002

Last Modified: Aug  8 13:52:57.276 for 00:00:36

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.6

Advertised to peers (in unique update groups):

10.100.1.7

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.6

Advertised to peers (in unique update groups):

10.100.1.7

65002 65001

10.1.24.2 from 10.1.24.2 (10.100.1.2)

Received Label 24002

Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 0, version 4

Origin-AS validity: not-found

router bgp 65003

bgp unsafe-ebgp-policy

address-family ipv4 unicast

!

RP/0/0/CPU0:R4# show mpls forwarding

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24000  Aggregate   10.1.24.0/24       default                      0

24001  Aggregate   10.1.45.0/24       default                      0

Si la commande allocation-label est présente, l'étiquette locale est présente dans la LFIB :

router bgp 65003

bgp unsafe-ebgp-policy

address-family ipv4 unicast

allocate-label all

!

RP/0/0/CPU0:R4#show mpls forwarding

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24000  Aggregate   10.1.24.0/24       default                      0

24001  Aggregate   10.1.45.0/24       default                      0

24002  24002       10.100.1.1/32                   10.1.24.2       0

Même si le préfixe BGP est reçu sur une session LU, mais qu'aucune étiquette locale n'est attribuée, la route n'est pas annoncée sur une autre session LU si NHS est terminé. Ceci est le cas 14 dans le tableau 1.Ceci est le cas si la session BGP sortante est eBGP.

Exemple :

RP/0/0/CPU0:R2#show bgp ipv4 unicast 10.100.1.1/32 detail

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  3           3

Flags: 0x00001001+0x00000000;

Last Modified: Aug 22 09:00:20.646 for 00:10:56

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0x4080000001060001, import: 0x20

Not advertised to any peer

65001

10.1.12.1 from 10.1.12.1 (10.100.1.1)

Received Label 3

Origin IGP, metric 0, localpref 100, valid, external, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 0, version 3

Origin-AS validity: not-found

RP/0/0/CPU0:R2#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32

Known via "bgp 65002", distance 20, metric 0, labeled unicast (3107)

Tag 65001, type external

Installed Aug 22 09:00:20.416 for 00:10:59

Routing Descriptor Blocks

10.1.12.1, from 10.1.12.1, BGP external

Route metric is 0

Label: 0x100004 (1048580)

Tunnel ID: None

Binding Label: None

Extended communities count: 0

NHID:0x0(Ref:0)

Route version is 0x1 (1)

No local label

IP Precedence: Not Set

…

Cela est probablement dû à l'absence de la commande “ allocation-label ” pour la monodiffusion de la famille d'adresses sous le routeur BGP.

Vous devez redémarrer le processus BGP lors de la suppression de la commande “ allolabel ” afin que le routeur supprime les étiquettes locales pour les routes BGP.

La nouvelle commande advertise local-labeled-route du tableau 1 est une nouvelle commande qui indique qu'une route avec une étiquette locale ne doit pas être annoncée comme route non étiquetée via SAFI-1.

Cette commande est la suivante :

advertise local-label-route [disable]

Cette commande est configurée sous la famille d'adresses voisines. La fonction de cette commande est d'indiquer si une route IPv4/v6 avec une étiquette locale doit être annoncée ou non au voisin BGP via la monodiffusion IPv4/v6 (SAFI 1).

Le comportement par défaut consiste à annoncer les routes avec une étiquette locale.

La nouvelle commande peut également être configurée comme suit :

advertise local-label-route safi-unicast [disable]

Cette commande est configurée sous le groupe af de la section BGP. Sa fonction est identique à celle ci-dessus et s'applique à tous les voisins BGP.

Le comportement par défaut consiste à annoncer les routes avec une étiquette locale.

La ligne “ Annoncer les routes avec étiquette locale via “ SAFI de monodiffusion ou “ Ne pas annoncer les routes avec étiquette locale via ” SAFI de monodiffusion est présente sur la commande » show bgp neighbor » sous la famille d'adresses IPv4 Unicast pour indiquer que le haut-parleur BGP autorise l'annonce des routes avec étiquette locale ou non.

Exemple de comportement par défaut :

RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5

…

For Address Family: IPv4 Unicast

BGP neighbor version 5

Update group: 0.1 Filter-group: 0.5  No Refresh request being processed

Extended Nexthop Encoding: advertised and received

Route refresh request: received 0, sent 0

0 accepted prefixes, 0 are bestpaths

Exact no. of prefixes denied : 0.

Cumulative no. of prefixes denied: 0.

Prefix advertised 2, suppressed 0, withdrawn 0

Maximum prefixes allowed 1048576

Threshold for warning message 75%, restart interval 0 min

An EoR was not received during read-only mode

Last ack version 5, Last synced ack version 0

Outstanding version objects: current 0, max 1, refresh 0

Additional-paths operation: None

Advertise routes with local-label via Unicast SAFI

…

ou

RP/0/0/CPU0:R4# conf t

RP/0/0/CPU0:R4(config)#router bgp 65003

RP/0/0/CPU0:R4(config-bgp)# neighbor 10.1.45.5

RP/0/0/CPU0:R4(config-bgp-nbr)#  address-family ipv4 unicast

RP/0/0/CPU0:R4(config-bgp-nbr-af)#advertise local-labeled-route disable

RP/0/0/CPU0:R4(config-bgp-nbr-af)#commit

RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5

BGP neighbor is 10.1.45.5

…

For Address Family: IPv4 Unicast

BGP neighbor version 5

Update group: 0.1 Filter-group: 0.5 (Update-group Change

pending)

No Refresh request being processed

Extended Nexthop Encoding: advertised and received

Route refresh request: received 0, sent 0

0 accepted prefixes, 0 are bestpaths

Exact no. of prefixes denied : 0.

Cumulative no. of prefixes denied: 0.

Prefix advertised 2, suppressed 0, withdrawn 0

Maximum prefixes allowed 1048576

Threshold for warning message 75%, restart interval 0 min

An EoR was not received during read-only mode

Last ack version 5, Last synced ack version 0

Outstanding version objects: current 0, max 1, refresh 0

Additional-paths operation: None

Do not advertise routes with local-label via Unicast SAFI

Calcul du meilleur chemin d'accès

Il n'y a aucune modification dans le processus de calcul du meilleur chemin. Si un chemin est SAFI 1 ou SAFI 4 ou si le chemin a une étiquette ou non, ne fait aucune différence dans le processus de calcul du meilleur chemin. Par conséquent, il n'y a aucune préférence entre un chemin SAFI 1 ou SAFI 4. Ceci est différent s'il y a SAFI 1/SAFI 4 sur la même session BGP ou sur des sessions différentes. Ainsi, si une session BGP est SAFI 1 et 4, et qu'un préfixe est reçu sur les deux familles d'adresses, le meilleur calcul de chemin en choisira un comme meilleur chemin, puisque tous les attributs sont identiques. Si tous les attributs BGP sont identiques entre le chemin U et le chemin LU, le chemin reçu en dernier devient le meilleur chemin.

Si les chemins SAFI 1 et SAFI 4 sont reçus de différents homologues BGP, il y a toujours une différence dans les chemins menant à BGP qui choisissent toujours le même chemin parmi les deux chemins. Même si dans ce cas tous les attributs sont identiques, l'adresse du voisin est différente. En examinant l'algorithme de sélection du meilleur chemin BGP, le chemin du voisin avec l'adresse de voisin la plus basse (dernière étape 13) est sélectionné comme meilleur chemin.

Utilisez la commande “ show bgp <AFI> <SAFI> <prefix> bestpath-compare ” pour vérifier la raison pour laquelle le meilleur chemin est le meilleur.

Cette préférence peut être obtenue par l'utilisateur, en utilisant RPL.

Voici un exemple de RPL.

RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 detail

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                682         682

Flags: 0x00003001+0x00010000;

Last Modified: Aug 28 13:16:26.826 for 00:00:10

Paths: (2 available, best #2)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0x4000000000020005, import: 0x20

Not advertised to any peer

65001

10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)

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

Received Path ID 1, Local Path ID 0, version 0

Originator: 10.100.1.10, Cluster list: 10.100.1.4

Path #2: Received by speaker 0

Flags: 0x4080000001060005, import: 0x20

Not advertised to any peer

65001

10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)

Received Label 24003

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

Received Path ID 1, Local Path ID 0, version 682

Originator: 10.100.1.10, Cluster list: 10.100.1.4

Le chemin d’accès au LU est le meilleur.

RPL avec poids est utilisé pour préférer le chemin U.

route-policy weight

if destination in (10.100.1.1/32) then

set weight 60000

endif

end-policy

router bgp 65003

address-family ipv4 unicast

additional-paths receive

additional-paths send

!

neighbor 10.100.1.4

remote-as 65003

update-source Loopback0

address-family ipv4 unicast

route-policy weight in

!

address-family ipv4 labeled-unicast

!

!

RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 bestpath-compare

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                726         726

Last Modified: Aug 28 13:39:27.826 for 00:04:54

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65001

10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)

Origin IGP, metric 0, localpref 100, weight 60000, valid, internal, best, group-best

Received Path ID 1, Local Path ID 0, version 726

Originator: 10.100.1.10, Cluster list: 10.100.1.4

best of AS 65001, Overall best

Path #2: Received by speaker 0

Not advertised to any peer

65001

10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)

Received Label 24003

Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast

Received Path ID 1, Local Path ID 0, version 0

Originator: 10.100.1.10, Cluster list: 10.100.1.4

Lower weight than best path (path #1)

Le chemin de l'U est maintenant le meilleur.

Il n'existe pas de nouvelle commande pour préférer les chemins étiquetés aux chemins non étiquetés. Vous pouvez simplement configurer la liste de contrôle d'accès sous la forme de monodiffusion de la famille d'adresses ou de monodiffusion étiquetée sous un voisin BGP.

Vérification du comportement dans BGP

Pour déboguer la propagation de la mise à jour BGP dans IOS-XR, vous pouvez activer la commande debug suivante : debug bgp update <voisin BGP> in | sortant.

Cette opération affiche la mise à jour BGP entrante ou sortante depuis ou vers ce haut-parleur BGP. La famille d'adresses est affichée en tant que (ip4u) pour l'uncast IPv4 non étiqueté (AFI 1/SAFI 1) ou en tant que (ipv4lu) pour l'unicast IPv4 étiqueté (AFI 1/SAFI 4). L'équivalent se produit pour IPv6.

Il existe un nouveau champ “ appelé ” de monodiffusion qui indique que le chemin est appris via SAFI 4.

Exemple :

RP/0/0/CPU0:R1#show bgp ipv4 unicast 10.100.1.7/32

BGP routing table entry for 10.100.1.7/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 26          26

Last Modified: Sep  4 10:45:44.551 for 00:29:11

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.4 (metric 3) from 10.100.1.102 (10.100.1.4)

Received Label 24000

Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 1, version 26

Originator: 10.100.1.4, Cluster list: 10.100.1.2

Pour vérifier si le préfixe est annoncé, vous pouvez utiliser la commande “ show bgp ... neighbors ” avec le mot clé ” advertise-routes ” à la fin.

Exemple :

R4 annonce 10.100.1.1/32 au voisin 10.100.1.7 deux fois, car le chemin d'accès supplémentaire est activé (les deux chemins sont différents).

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast neighbors 10.100.1.7 advertised-routes

Network            Next Hop        From            AS Path

10.1.24.0/24       10.100.1.4      Local           ?

10.1.34.0/24       10.100.1.4      Local           ?

10.1.45.0/24       10.100.1.4      Local           ?

10.1.46.0/24       10.100.1.4      Local           ?

10.1.47.0/24       10.100.1.4      Local           ?

10.1.48.0/24       10.100.1.4      Local           ?

10.1.49.0/24       10.100.1.4      Local           ?

10.1.104.0/24      10.100.1.4      Local           ?

10.1.114.0/24      10.100.1.4      Local           ?

10.100.1.1/32      10.100.1.4      10.100.1.9      65001i

10.100.1.10     65001i

10.100.1.4/32      10.100.1.4      Local           ?

Processed 11 prefixes, 12 paths

iBGP et next-hop-self - MPLS unifié

Les règles du tableau 1 s'appliquent. Avec Unified MPLS ou Seamless MPLS, un routeur ABR (Area Border Router) fait office de réflecteur de route mais est également le tronçon suivant pour les routes iBGP. Les ABR se trouvent dans le chemin de transfert du trafic étiqueté. Les ABR doivent avoir la configuration explicite pour le saut suivant.

Solutions

- S'il n'y a aucune prise en charge de U et LU sur une session BGP, une solution de contournement consiste à avoir deux sessions BGP entre une paire de routeurs. Deux interfaces (bouclage) doivent être utilisées sur chaque routeur.

Exemple de configuration pour IOS-XR.

interface Loopback0

ipv4 address 10.100.1.7 255.255.255.255

!

interface Loopback1

ipv4 address 10.100.1.107 255.255.255.255

!

router bgp 65003

address-family ipv4 unicast

!

neighbor 10.100.1.4   -> towards loopback0 on peer

remote-as 65003

update-source Loopback0

address-family ipv4 unicast

!

!

neighbor 10.100.1.104  -> towards loopback1 on peer

remote-as 65003

update-source Loopback1

address-family ipv4 labeled-unicast

!

Les chemins U et LU sont envoyés/reçus sur deux sessions BGP différentes.

RP/0/0/CPU0:R7#show bgp ipv4 unicast 10.100.1.1/32 detail

BGP routing table entry for 10.100.1.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                753         753

Flags: 0x00001001+0x00010000;

Last Modified: Aug 28 14:06:40.826 for 00:22:10

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0x4000000001060005, import: 0x20

Not advertised to any peer

65001

10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)

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

Received Path ID 1, Local Path ID 0, version 753

Originator: 10.100.1.10, Cluster list: 10.100.1.4

Path #2: Received by speaker 0

Flags: 0x4080000000020005, import: 0x20

Not advertised to any peer

65001

10.100.1.104 (metric 2) from 10.100.1.104 (10.100.1.10)

Received Label 24003

Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast

Received Path ID 1, Local Path ID 0, version 0

Originator: 10.100.1.10, Cluster list: 10.100.1.4