Étiqueté et non étiquetée ensemble sur un voisin BGP sur 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