Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Attributo Accumulated Interior Gateway Protocol

Casi di utilizzo di esempio

1. Rete ASN multipla

Configurazione

Verifica

2. MPLS (singolo ASN)

Osservazioni

Registri dispositivo - Iniziale

Soluzione AIGP

Configurazione

Esempio di configurazione

Log dispositivi - Dopo l'implementazione di AIGP

Fattori da considerare

Ignora AIGP

Conclusioni

Informazioni correlate

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.

Nota: i router BGP che non supportano gli attributi non transitivi opzionali (ad esempio, AIGP) devono eliminare tali attributi e non devono passarli ad altri peer BGP. La metrica AIGP non deve essere transitiva tra sistemi autonomi completamente distinti (solo tra limiti AS interni).

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

Nota:

1. Supponendo che Add-path sia abilitato su RR1/2 per annunciare sia l'NH verso PEx.

2. I dispositivi utilizzati nello scenario sopra indicato sono tutti in esecuzione con Cisco IOS-XE.

PE11#sh bgp ipv4 unicast 10.0.21.21/32

BGP routing table entry for 10.0.21.21/32, version 20

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

Not advertised to any peer

Refresh Epoch 3

2

192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)

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

Originator: 192.168.0.12, Cluster list: 192.168.11.11

rx pathid: 0x1, tx pathid: 0

Refresh Epoch 3

2

192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)

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

Originator: 192.168.0.11, Cluster list: 192.168.11.11

rx pathid: 0x0, tx pathid: 0x0

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

!

Nota: il peering BGP viene interrotto e ristabilito per negoziare questa nuova funzionalità. Si consiglia quindi di eseguire l'operazione in una finestra di manutenzione.

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

Nota:

1. Supponendo che Add-path sia abilitato su RR1/2, AGG, CSR e SAR per annunciare entrambi gli NH.

2. Tutti i dispositivi utilizzati nello scenario indicato in precedenza sono basati su Cisco IOS-XR.

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

!

Nota:

1. Per le route ridistribuite, il valore assegnato all'attributo AiGP è il valore di iGP dell'hop successivo alla route o impostato da un criterio di route.

2. Per le route statiche ridistribuite in BGP, il valore assegnato è il valore dell'hop successivo alla route o come impostato da un criterio di route.

3. La route viene importata in BGP tramite un'istruzione di rete. Il valore assegnato è il valore dell'hop successivo alla route o come impostato da un criterio di route.

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

!

!

!

Nota: è stata eseguita una configurazione simile su tutti i rispettivi dispositivi peer BGP.

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