Etichettato e senza etichetta su un router BGP adiacente su IOS-XR

Questo documento descrive il comportamento di ricezione e pubblicità di percorsi senza etichetta e con etichetta durante una sessione BGP in Cisco IOS^® XR.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Questo documento è specifico per Cisco IOS^® XR, ma non è limitato a una versione software o a un hardware specifico.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Introduzione

L'identificatore della famiglia di indirizzi (AFI) indica il tipo di route BGP. Gli esempi sono 1 per IPv4 e 2 per IPv6.

Il successivo identificativo della famiglia di indirizzi (SAFI) è un’ulteriore indicazione del tipo di rotta. Gli esempi sono 1 per una route senza etichetta e 4 per una route con etichetta.

Il formato unicast senza etichetta per IPv4 è AFI 1 e SAFI 1.

Il formato unicast con etichetta per IPv4 è AFI 1 e SAFI 4.

Il formato unicast senza etichetta per IPv6 è AFI 2 e SAFI 1.

Il formato unicast con etichetta per IPv6 è AFI 2 e SAFI 4.

La tecnologia LU (Labeled unicast) viene spesso indicata come RFC 3107 "Carrying Label Information in BGP-4".

Di seguito, U si riferisce a unicast senza etichetta, quindi SAFI 1 e LU si riferisce a unicast etichettato, quindi SAFI 4.

Notare che Cisco IOS^® XR richiede "allocate-label all| route-policy ..." altrimenti la route non verrà generata o propagata al successivo altoparlante BGP come SAFI 4.

I protocolli unicast IPv4/v6 e unicast con etichetta su una sessione BGP non sono supportati su Cisco IOS^® XR.

Su Cisco IOS^® XR, il supporto per avere sia senza etichetta che con etichetta su una sessione BGP è stato eseguito nella versione 6.2.1.

Quando l'esecuzione di entrambe le sessioni non è supportata, è un problema in quanto l'ultimo aggiornamento/ritiro ricevuto ha la precedenza su quello precedente, anche se sono stati ricevuti in un altro SAFI.

Quando si configurano entrambi i protocolli SAFI 1 e 4 sulla stessa sessione BGP su un router con codice IOS-XR prima di IOS-XR 6.2.1, il router visualizza il seguente avviso:

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

Questo messaggio di avviso è stato introdotto in IOS-XR 5.3.0 e IOS-XR 5.2.2.

Capability Exchange

Le funzionalità scambiate tra peer BGP devono corrispondere. In caso contrario, la sessione BGP non viene visualizzata.

Si tratta di un'acquisizione in modalità wireshark della capacità scambiata con AFI 1/SAFI 1 e AFI 1/SAFI 4 nel messaggio BGP Open:

Immagine 1

Di seguito è riportato un esempio di IOS-XR configurato con LU solo in una sessione con IOS configurato solo con U.

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

Il router IOS stampa un messaggio syslog per questo errore di configurazione:

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

Specifiche di implementazione di IOS-XR

Configurazione U o LU

È possibile configurare "address-family ipv4 unicast" con il comando BGP neighbors per abilitare ipv4 unicast per la sessione BGP.

È possibile configurare "address-family ipv6 unicast" con il comando BGP neighbors per abilitare ipv6 unicast per la sessione BGP.

Per abilitare il protocollo unicast con etichetta ipv4 per la sessione BGP, è possibile configurare "address-family ipv4 etichettato-unicast" nel comando del router adiacente BGP.

È possibile configurare "address-family ipv6 etichettato-unicast" nel comando BGP neighbors per abilitare ipv6 etichettato unicast per la sessione BGP.

In IOS-XR la combinazione AFI/SAFI è configurata per peer BGP.

Questo è un esempio di sessione BGP con SAFI 1 e 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

Si noti che nel router BGP sono ancora presenti solo gli indirizzi unicast e non gli indirizzi unicast con etichetta famiglia. Entrambi i percorsi SAFI 1 e 4 sono memorizzati in questa tabella BGP.

Tabella BGP

Indipendentemente dal fatto che IOS-XR sia precedente o successivo alla 6.2.1, esiste una sola tabella BGP per memorizzare le route U e LU. Ciò è evidente dal fatto che è possibile configurare (abilitare) solo "address-family ipv4 unicast" o "address-family ipv6 unicast" sotto il bgp del router. non è possibile configurare "address-family ipv4 etichettato-unicast" o "address-family ipv6 etichettato-unicast" nel bgp del router.

I percorsi U e LU possono essere identici. Prima di IOS-XR 6.2.1, se si riceve nuovamente lo stesso percorso ma questa volta con o senza etichetta, il percorso ricevuto in precedenza viene ignorato. Dopo IOS-XR 6.2.1, i due percorsi identici verranno considerati diversi se si differenziano solo per l'etichetta. Le aggiunte, le eliminazioni o le modifiche dei percorsi vengono eseguite dai diversi SAFI.

Di seguito è riportato un esempio di route nella tabella BGP con AFI 1/SAFI 4. Poiché l'allocazione delle etichette è abilitata per tutti i prefissi, questo percorso verrà archiviato con un'etichetta locale. Poiché esiste una sola tabella BGP per archiviare le route U e LU, il prefisso viene visualizzato con entrambi i comandi "show bgp ipv4 unicast" e "show bgp ipv4 etichettato-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

Si noti che il percorso è contrassegnato con "etichettato-unicast".

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

Si noti che il percorso è contrassegnato con "etichettato-unicast".

Se il percorso è presente come U e LU, l'ID del percorso locale è diverso.

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

Abilitazione dell'allocazione delle etichette locali

È necessario configurare il comando "allocate-label" affinché i percorsi ricevuti o originati in BGP abbiano un'etichetta MPLS locale. Senza questo comando, le route non avranno un'etichetta 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'allocazione di etichette viene eseguita per tutte le route o in base ai criteri di route configurati.

Nuova implementazione su IOS-XR

Nell'implementazione precedente di IOS-XR, viene visualizzato un avviso quando si configurano sia la U che la LU nella stessa sessione BGP. L'avviso è stato introdotto nelle versioni 5.3.0 e 5.2.2 di IOS-XR. L'avviso è stato rimosso in IOS-XR versione 6.2.1, perché le versioni con e senza etichetta sono supportate nella stessa sessione BGP.

Esempio:

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. 

Spiegazione del messaggio di errore:

Questo messaggio indica che l'utente ha configurato entrambe le famiglie di indirizzi IPv4 unicast con etichetta o IPv6 unicast e IPv6 unicast con etichetta nello stesso router adiacente. Questa particolare configurazione non è supportata. 

Azione consigliata: configurare due sessioni adiacenti sul router. Configurare la famiglia di indirizzi unicast nella prima sessione adiacente e la famiglia di indirizzi unicast con etichetta nella seconda sessione adiacente.

Esempio di configurazione per due sessioni BGP tra una coppia di router IOS-XR. Utilizzare un indirizzo (loopback) diverso per ciascuna sessione 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
  !
 !

In IOS-XR 6.2.1, sia U che LU sono supportati sulla stessa sessione BGP sul VRF predefinito!

Non importa se la sessione BGP è interna o esterna.

U e LU nella stessa sessione non sono supportati per gli altoparlanti BGP in nessuna VRF non predefinita.

Update-groups

Prima di IOS-XR 6.2.1, tutti gli altoparlanti U, LU e U + LU BGP erano tenuti in gruppi di aggiornamento separati. Dopo IOS-XR release 6.2.1, questa condizione non è più valida. Alcuni altoparlanti BGP in un gruppo di aggiornamento possono essere solo U, o solo LU, o entrambi U e LU.

Propagazione route

Nella tabella seguente viene illustrato il comportamento relativo alla pubblicità e al ritiro in scenari diversi. Ci sono 16 scenari.

Tutto si applica a IOS-XR versione 6.2.1 e successive, se non diversamente indicato nella colonna dei commenti.

Case	Tipo Bestpath/Addpath	Etichetta locale presente?	NHS o NHU	Update-group SAFI	Annunciare o ritirare?	Commenti
1	Percorso senza etichetta, ovvero senza etichetta rx	Sì	NHS	SAFI-1	Pubblicizza per impostazione predefinita Ritira con annuncio local-label-route (safi-unicast) disable, comando	Possibile solo dopo 6.5.1.
2				SAFI-4	Pubblicizza	Possibile solo dopo 6.5.1. Route redist IPv4/v6 e 6PE: NHS implicito sempre
3			NHU	SAFI-1	Pubblicizza	Possibile solo dopo 6.5.1.
4				SAFI-4	Ritira	Possibile solo dopo 6.5.1. Route redist IPv4/v6 e 6PE: NHU ignorato; NHS implicito sempre
5		No	NHS	SAFI-1	Pubblicizza
6				SAFI-4	Ritira
7			NHU	SAFI-1	Pubblicizza
8				SAFI-4	Ritira
9	Percorso con etichetta rx	Sì	NHS	SAFI-1	Pubblicizza per impostazione predefinita Ritira con il comando annuncio local-label-route (safi-unicast) disable	Prima del 6.2.1: il comportamento predefinito è Advertise (Pubblicizza).
10				SAFI-4	Pubblicizza
11			NHU	SAFI-1	Ritira	Prima del 6.2.1:  Il comportamento è quello di pubblicizzare.
12				SAFI-4	Pubblicizza
13		No	NHS	SAFI-1	Pubblicizza
14				SAFI-4	Ritira
15			NHU	SAFI-1	Ritira	Prima del 6.2.1:  Il comportamento è quello di pubblicizzare.
16				SAFI-4	Pubblicizza

Tabella 1: comportamento dell'annuncio per le sessioni iBGP ed eBGP

NHS = Next Hop Self

NHU = Hop successivo invariato.

Se è attiva la modalità NHU, il self-hop successivo non è configurato per una sessione iBGP.

NHS è sempre presente quando il diffusore BGP invia a un peer eBGP.

Può esserci NHS o NHU verso un diffusore iBGP, a seconda della configurazione dell'hop successivo. Il comportamento predefinito nei confronti dei peer iBGP è NHU.

Per la seconda colonna: si noti che il percorso viene considerato senza etichetta o con etichetta solo se il miglior percorso o uno dei percorsi contrassegnati con add-path è senza etichetta o con etichetta.

Per la propagazione della route è importante determinare le caratteristiche del percorso migliore. A seconda delle caratteristiche (colonne da 2 a 4), determina se il percorso viene annunciato come U, LU o entrambi.

Se la funzionalità Percorsi aggiuntivi (ADD-PATH) è attivata e un percorso è contrassegnato con "add-path", anche le caratteristiche del percorso hanno un ruolo nella modalità di annuncio del percorso.

"Local Label Present?: "No" significa quanto segue: è possibile che venga ricevuta un'etichetta con l'aggiornamento ricevuto, ma l'etichetta non è installata. L'etichetta locale non viene installata se il comando "allocate-label" non è presente.

Per verificare se l'etichetta locale è presente, esaminare il prefisso in dettaglio. Utilizzare "show bgp <prefix> detail" o "show route <prefix> detail".

Nell'esempio seguente, il prefisso viene ricevuto senza etichetta (quindi su un peering SAFI 1) e non viene assegnata alcuna etichetta locale:

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.

Allocazione di un'etichetta locale

Alloca etichetta per percorsi senza etichetta

Per impostazione predefinita, i percorsi senza etichetta (SAFI 1) non vengono mai etichettati, anche quando è configurato il comando "allocate-label".

A partire dalla versione 6.5.1 di IOS-XR, per il comando "allocate-label" è presente la parola chiave "unlabel-path", in modo che anche ai percorsi senza etichetta venga assegnata un'etichetta.

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

Il percorso è un percorso SAFI 1, quindi non è presente alcuna etichetta ricevuta.

A causa del comando "unlabel-path", ora è disponibile un'etichetta 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
  …

Ciò consentirà di compilare i casi da 1 a 4 della tabella 1.

Per capire perché un'etichetta locale è ancora assegnata quando si rimuove il comando "allocate-label", eseguire il debug "debug bgp label".

Di seguito è riportato un esempio:

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 '##########'

È preferibile abilitare il debug per un prefisso o un gruppo di prefissi specifico. Di seguito è riportato un esempio:

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"

Si noti che questo router ha ricevuto un'etichetta per il prefisso 10.100.1.1/32, è un ASBR, non è un RR e ha un hop successivo-self per almeno una sessione BGP. Per questo prefisso è necessaria un'etichetta locale.

L'etichetta locale rimane:

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.

Il comando debug visualizza il seguente messaggio quando non è richiesta un'etichetta locale:

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

Se il prefisso si trova nell'LFIB dipende dal fatto che il prefisso sia stato ricevuto con o senza etichetta e se a tale prefisso si applica l'etichetta allocate-label.

L'etichetta ricevuta è 24002 per il prefisso seguente.  Non viene installato in LFIB perché BGP non dispone del comando allocate-label.

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

Se il comando allocate-label è presente, l'etichetta locale è presente nel file 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

Anche se il prefisso BGP viene ricevuto su una sessione LU, ma non viene assegnata alcuna etichetta locale, la route non viene annunciata su un'altra sessione LU in cui è stato eseguito NHS. Questo è il caso 14 nella tabella 1. Questo è il caso se la sessione BGP in uscita è eBGP.

Esempio:

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
  …

Probabilmente il comando "allocate-label" non è disponibile per il protocollo unicast della famiglia di indirizzi nel router BGP.

Quando si rimuove il comando "allocate-label", è necessario riavviare il processo BGP per consentire al router di rimuovere le etichette locali per le route BGP.

Il nuovo comando annuncio local-label-route nella tabella 1 è un nuovo comando che indica che una route con etichetta locale non deve essere annunciata come route senza etichetta tramite SAFI-1.

Questo comando è il seguente:

   annunciare route con etichetta locale [disable]

Questo comando è configurato nella famiglia di indirizzi del router adiacente. La funzione di questo comando indica se una route IPv4/v6 con etichetta locale deve essere annunciata o meno al router BGP adiacente tramite unicast IPv4/v6 (SAFI 1).

Per impostazione predefinita, le route vengono annunciate con un'etichetta locale.

Il nuovo comando può anche essere configurato come:

   annunciare la route locale safi-unicast [disable]

Questo comando è configurato nel gruppo af della sezione BGP. La sua funzione è la stessa di quella precedente e si applica a tutti i vicini BGP.

Per impostazione predefinita, le route vengono annunciate con un'etichetta locale.

La riga "Advertise route with local-label via Unicast SAFI"o "Do not advertising route with local-label via Unicast SAFI" è presente nel comando "show bgp neighbors" nella famiglia di indirizzi IPv4 Unicast per indicare che l'altoparlante BGP consente o meno la pubblicità delle route con etichetta locale.

Esempio del comportamento predefinito:

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
…

o

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

Calcolo Bestpath

Non sono presenti modifiche nel processo di calcolo del percorso ottimale. Se un percorso è SAFI 1 o SAFI 4 o se il percorso ha un'etichetta, non fa alcuna differenza nel processo di calcolo del percorso migliore. Non esiste pertanto alcuna preferenza tra un percorso SAFI 1 o SAFI 4. A prescindere dal fatto che vi sia un SAFI 1/SAFI 4 sulla stessa sessione BGP o su sessioni diverse. Pertanto, se una sessione BGP è SAFI 1 e 4 e viene ricevuto un prefisso su entrambe le famiglie di indirizzi, il miglior calcolo del percorso sceglierà uno dei due come miglior percorso, poiché tutti gli attributi sono uguali. Se tutti gli attributi BGP sono uguali tra il percorso U e il percorso LU, il percorso ricevuto per ultimo diventa il percorso migliore.

Se i percorsi SAFI 1 e SAFI 4 vengono ricevuti da peer BGP diversi, vi è sempre una differenza tra i percorsi che portano a BGP a scegliere sempre lo stesso percorso migliore dai due percorsi. Anche se in questo caso tutti gli attributi sono uguali, l'indirizzo del router adiacente è diverso. Osservando l'algoritmo di selezione del miglior percorso BGP, il percorso dal router adiacente con l'indirizzo più basso (ultimo passaggio 13) viene scelto come miglior percorso.

Utilizzare il comando "show bgp <AFI> <SAFI> <prefix> bestpath-compare" per verificare il motivo per cui il percorso migliore è quello migliore.

Questa preferenza può essere definita dall'utente utilizzando RPL.

Ecco un esempio di tali 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

Il percorso LU è il migliore.

RPL con peso viene utilizzato per preferire il percorso 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)

Il percorso U è ora il migliore.

Non esistono nuovi comandi che preferiscono i percorsi con etichetta ai percorsi senza etichetta. È possibile configurare la RPL in modalità unicast con indirizzo o unicast con etichetta con un router BGP adiacente.

Verifica del comportamento in BGP

Per eseguire il debug della propagazione degli aggiornamenti BGP in IOS-XR, è possibile attivare il seguente comando debug: debug bgp update <sistema adiacente BGP> in | fuori.

In questo modo viene mostrato l'aggiornamento BGP in entrata o in uscita da o verso quel diffusore BGP. La famiglia di indirizzi viene mostrata come (ip4u) per i pacchetti IPv4 senza etichetta (AFI 1/SAFI 1) o come (ipv4lu) per i pacchetti unicast IPv4 con etichetta (AFI 1/SAFI 4). L'equivalente si verifica per IPv6.

Esiste un nuovo campo "etichettato-unicast" che indica che il percorso viene appreso tramite SAFI 4.

Esempio:

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

Per verificare se il prefisso è stato annunciato, usare il comando "show bgp ... neighbors" con la parola chiave "advised-route" alla fine.

Esempio:

R4 annuncia 10.100.1.1/32 al router adiacente 10.100.1.7 due volte perché add-path è abilitato (i due percorsi sono diversi).

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 e next-hop-self - MPLS unificato

Si applicano le regole della tabella 1. Con MPLS unificato o MPLS senza interruzioni, un ABR (Area Border Router) funge da riflettore di route ma è anche l'hop successivo per le route iBGP. Gli ABR si trovano nel percorso di inoltro del traffico etichettato. Le funzioni ABR devono avere una configurazione esplicita per l'hop successivo.

Soluzioni

• Se non è disponibile il supporto per U e LU su una sessione BGP, per risolvere il problema, è necessario avere due sessioni BGP tra una coppia di router. Su ciascun router devono essere utilizzate due interfacce (loopback).

Esempio di configurazione di 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
  !

I percorsi U e LU vengono inviati/ricevuti in due diverse sessioni BGP.

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