Come ottimizzare il percorso BGP utilizzando AIGP

Introduzione

Questo documento descrive la metrica AIGP (Accumulated Interior Gateway Protocol) nel Border Gateway Protocol (BGP) e i relativi casi di utilizzo.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• BGP
• Rete MPLS (Perfect Multiprotocol Label Switching)

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Premesse

In questa sezione viene fornita una panoramica della metrica AIGP e alcune importanti considerazioni relative all'utilizzo di tale metrica.

Come è noto, IGP è l'acronimo di Interior Gateway Protocol e rappresenta un gruppo di protocolli di routing in esecuzione all'interno di un singolo dominio amministrativo. IGP decide la selezione del percorso in base al valore della metrica.

BGP è progettato per fornire il routing su un ampio numero di sistemi autonomi indipendenti (AS) con coordinamento limitato o nullo tra le rispettive amministrazioni. Non prende decisioni sulla selezione del percorso tramite l'uso di una metrica. Tuttavia, ci sono implementazioni in cui una singola amministrazione esegue diverse reti BGP contigue. In questi casi, può essere desiderabile, all'interno di quel singolo dominio amministrativo, che BGP selezioni i percorsi in base a una metrica, proprio come farebbe un IGP.

Attributo Accumulated Interior Gateway Protocol

La metrica AIGP (definita tramite RFC7311) è un attributo di percorso BGP non transitivo facoltativo. Il campo del valore dell'attributo AIGP è definito come un insieme di elementi Type/Length/Value (TLV). Il TLV BGP AIGP contiene la metrica IGP accumulata.

Casi di utilizzo di esempio

1. Rete ASN multipla

Attualmente esistono molte reti che si trovano in un unico dominio amministrativo, suddivise in più ASN per vari motivi. Le ragioni possono essere molteplici:

• Scala IGP
• Una rete di provider è stata acquistata da un altro provider di rete ma, tuttavia, non hanno unito internamente le loro ASN BGP
• Diverse divisioni aziendali hanno la loro rete separata internamente
• Confederazioni BGP con Sub-AS
• MPLS, ecc.

In reti come queste, può essere utile consentire a BGP di prendere le proprie decisioni in base alla metrica IGP, in modo che BGP scelga il percorso end-to-end più breve tra due nodi, anche se i nodi si trovano in due ASN diverse.

Ad esempio: rete ABC, suddivisa in due ASN BGP, ASN 1 e ASN 2. Stanno sbirciando ad ASBR e i costi IGP del collegamento rappresentano la larghezza di banda. L'obiettivo è quello di ottenere un percorso ottimale completo tra PE11 e PE21.

Rete multi-ASN senza AIGP

PE11#sh bgp ipv4 unicast 10.0.21.21/32
BGP routing table entry for 10.0.21.21/32, version 20
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 3
  2
    192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 192.168.0.12, Cluster list: 192.168.11.11
      rx pathid: 0x1, tx pathid: 0
  Refresh Epoch 3
  2
    192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 192.168.0.11, Cluster list: 192.168.11.11
      rx pathid: 0x0, tx pathid: 0x0

Con AiGP abilitato nella topologia (su PE11, PE32, ASBR1x, ASBR2x, RR1, RR2), PE11 ora sceglie il percorso con il costo IGP end-to-end più basso.

Rete multi-ASN con AIGP

Configurazione

PEx, ASBRx, RRn:

Configurazione delle funzionalità AIGP:

router bgp ASN
 neighbor <NBR_IP> aigp
!

Annunciare la metrica AIGP per un prefisso.

PE21:

route-map SET_AIGP permit 10
 set aigp-metric igp-metric
!
router bgp 2
 address-family {ipv4|ipv6} unicast
  network 10.0.21.21 mask 255.255.255.255 route-map SET_AIGP
!

Verifica

PE11#sh bgp ipv4 unicast 10.0.21.21/32    
BGP routing table entry for 10.0.21.21/32, version 21
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 3
  2
    192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)
      Origin IGP, aigp-metric 501, metric 0, localpref 100, valid, internal
      Originator: 192.168.0.11, Cluster list: 192.168.11.11
      rx pathid: 0x1, tx pathid: 0
  Refresh Epoch 3
  2
    192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)
Origin IGP, aigp-metric 201, metric 0, localpref 100, valid, internal, best
      Originator: 192.168.0.12, Cluster list: 192.168.11.11
      rx pathid: 0x0, tx pathid: 0x0

2. MPLS (singolo ASN)

In una rete di base di un grande provider di servizi, la rete di trasporto è generalmente suddivisa in domini IGP diversi, uniti mediante l'uso di BGP Labeled Unicast per fornire un LSP (Label Switched Path) end-to-end. I router di confine eseguono l'NHS (Next Hop Self) in BGP LU AF.

IGP/LDP trasporta le informazioni del prefisso/etichetta solo nell'area/dominio locale. Quindi, BGP invia il prefisso/etichetta a tutte le aree/domini remoti ridistribuendo le route in BGP ai limiti dell'area. Le route/etichette vengono quindi annunciate utilizzando i provider di servizi di traduzione. L'hop successivo del percorso viene modificato a ogni ABR sul router locale, eliminando la necessità di perdere i percorsi IGP oltre i limiti dell'area o del dominio.

In questo diagramma della topologia è presente un singolo dominio BGP diviso in 2 domini IGP (CORE e Access-1). Il numero visualizzato accanto a ciascun collegamento rappresenta il costo/la metrica IGP del collegamento.

Perfetta rete MPLS senza AIGP

Sfida: il traffico verso il basso da PS-Core a eNB/gNB (connesso a CSR15) sta prendendo un percorso asimmetrico e sub-ottimale rispetto al traffico verso l'alto da eNB/gNB (connesso a CSR15) verso PS-Core, che sta causando problemi di latenza nel traffico di mobilità.

Osservazioni

1. Osservato principalmente negli scenari di confine geografici in cui lo stesso router di aggregazione agisce come router di confine comune per più domini di accesso (ad esempio, AGG102 nell'immagine sopra menzionata).
2. Per il traffico in entrata, il router CSR (Cell-Site Router) sta scegliendo il router di confine più vicino. Ad esempio, CSR15 seleziona AGG102 come NextHop.
3. Per il traffico verso il basso, il router di aggregazione dei servizi (SAR) sceglie anche il router di confine più vicino. Ad esempio, SAR150 seleziona AGG101 (costo 180 < 200).

Registri dispositivo - Iniziale

Traffico in upstream - Da CSR15 a SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 so 10.0.2.15
Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]
L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 0 ms                !!!! AGG102
. 2 *                                                                 !!!! P112 does not have a route to CSR15
! 3 10.112.150.150 20 ms                                              !!!! SAR150

Traffico a valle - Da SAR150 a CSR15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 source 10.0.2.150
Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.101.150.150 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0]
L 1 10.101.150.101 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                 !!! AGG101
L 2 10.11.101.11 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                   !!! CSR11
L 3 10.11.12.12 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                    !!! CSR12
L 4 10.12.13.13 MRU 1500 [Labels: 16015 Exp: 0] 20 ms                    !!! CSR13             
L 5 10.13.14.14 MRU 1500 [Labels: explicit-null Exp: 0] 30 ms            !!! CSR14
! 6 10.14.15.15 30 ms                                                    !!! CSR15

Soluzione AIGP

L'obiettivo è quello di ottenere un percorso ottimale end-to-end tra i router ASR e i router CSR. La specifica BGP Labeled Unicast (RFC 3107) viene utilizzata per calcolare la distanza dai router ASR ai router CSR. La larghezza di banda disponibile su ciascuno dei collegamenti principali è mappata al costo IGP, quindi BGP deve sostenere questo costo correttamente tra ciascun PPE. Questa funzionalità è resa possibile dall'utilizzo di AiGP.

Rete MPLS perfetta con AIGPSRete MPLS senza problemi con AIGP

Configurazione

La funzionalità Attributo percorso AiGP deve essere concordata tra peer BGP. Le metriche AiGP sono incluse solo negli annunci di prefissi tra peer abilitati per AiGP. La funzionalità AIGP è configurata per un singolo peer BGP e una famiglia di indirizzi BGP specifica.

router bgp ASN
 neighbor <NBR_IP>
  address-family ipv4 unicast
   aigp [disable]

La metrica AIGP è un valore a 32 bit (da 0 a 4.294.967.295). Può essere impostato durante la ridistribuzione, la creazione del percorso tramite un rendiconto di rete o durante la ricezione di un prefisso con una mappa del percorso/policy del percorso.

route-policy AIGP_POLICY
  set aigp-metric igp-cost
end-policy
!
router bgp ASN
 address-family {ipv4|ipv6} unicast
  network <NETWORK/MASK> route-policy AIGP_POLICY
  or
  redistribute {ospf|isis} {process-id} route-policy AIGP_POLICY metric VALUE
!

Esempio di configurazione

CSR15:
! Additional config lines related to AIGP are marked in RED color
route-policy SID($SID)
 set label-index $SID
 set aigp-metric igp-cost
end-policy
!
router bgp 1
 address-family ipv4 unicast
  network 10.0.2.15/32 route-policy SID(15)
 neighbor-group RR
  address-family ipv4 labeled-unicast
   aigp
  !
 !
!

Log dispositivi - Dopo l'implementazione di AIGP

Traffico a valle - Da SAR150 a CSR15

RP/0/0/CPU0:SAR150#sh bgp ipv4 labeled-unicast 10.0.2.15/32
BGP routing table entry for 10.0.2.15/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 411 411
Local Label: 16015
Last Modified: Oct 24 11:05:26.796 for 00:00:04
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.0.2.102 (metric 200) from 10.0.2.100 (10.0.2.15)
Received Label 16015 
Origin IGP, metric 0, localpref 100, aigp metric 20, valid, internal, best, group-best, labeled-unicast
Received Path ID 1, Local Path ID 1, version 410
Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.102
Total AIGP metric 220
Label-Index: 15
Path #2: Received by speaker 0
Not advertised to any peer
Local
10.0.2.101 (metric 180) from 10.0.2.100 (10.0.2.15)
Received Label 16015 
Origin IGP, metric 0, localpref 100, aigp metric 60, valid, internal, backup, add-path, labeled-unicast
Received Path ID 8, Local Path ID 7, version 411
Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.101
Total AIGP metric 240
Label-Index: 15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 so 10.0.2.150
Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.112.150.150 MRU 1500 [Labels: 16102/16015 Exp: 0/0]
L 1 10.112.150.112 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0] 10 ms          !!! P112
L 2 10.102.112.102 MRU 1500 [Labels: explicit-null Exp: 0] 10 ms                  !!! AGG102
! 3 10.15.102.15 20 ms                                                            !!! CSR15

Traffico in upstream - Da CSR15 a SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 source 10.0.2.15
Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]
L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 10 ms                 !!! AGG102
. 2 *                                                                   !!! P112 does not have a route to CSR15
! 3 10.112.150.150 30 ms                                                !!! SAR150

Fattori da considerare

• Con le modifiche nei costi IGP (ad esempio, le modifiche nella topologia fisica a causa del taglio dei collegamenti e altro ancora), ci sono modifiche corrispondenti anche in BGP. Ciò potrebbe causare il cambiamento della route BGP. Questa convergenza dipende anche dal valore del ritardo BGP Next Hop Trigger configurato per gli eventi non critici.
• Con l'introduzione di AiGP, la selezione del miglior percorso di BGP viene modificata. BGP AIGP viene inserito dopo la preferenza locale BGP e prima dell'attributo AS_PATH. Pertanto, se sono presenti criteri esistenti relativi alla preminenza di AS_PATH, potrebbe essere necessario modificarli.
• Quando sono presenti due percorsi, uno con la metrica AIGP e l'altro senza, BGP preferisce sempre un percorso con la metrica AIGP.

Ignora AIGP

Inoltre, è possibile configurare un dispositivo che esegue il Border Gateway Protocol (BGP) in modo da ignorare la metrica AIGP durante il miglior processo di selezione dei percorsi tra due percorsi quando un percorso non dispone della metrica AIGP. Usare il comandobgp bestpath aigp ignore in modalità di configurazione del router. Per ripristinare il funzionamento predefinito del dispositivo, utilizzare la forma no di questo comando.

[no] bgp bestpath aigp ignore

Per impostazione predefinita, BGP preferisce sempre un percorso con la metrica AIGP. Se sono presenti due percorsi, uno con la metrica AIGP e l'altro senza, l'esecuzione del bgp bestpath aigp ignore comando consente a BGP di eseguire il calcolo del percorso migliore come se nessuno dei due percorsi avesse la metrica AIGP.

Conclusioni

L'attributo BGP AIGP è certamente sviluppato per risolvere alcuni casi di utilizzo di nicchia, ma deve essere utilizzato con cautela.

Informazioni correlate

• Configurare l'attributo della metrica AIGP per BGP
• Supporto tecnico Cisco e download