Configurare l'attributo della metrica AIGP per BGP

Introduzione

In questo documento viene descritto come configurare l'attributo metrico AIGP (Accumulated Interior Gateway Protocol) trasportato dal Border Gateway Protocol (BGP) in Cisco IOS^®.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

  

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 dell'attributo della metrica AIGP e alcune considerazioni importanti relative all'utilizzo di tale attributo.

Panoramica degli attributi delle metriche AIGP

Le aziende potrebbero voler implementare una progettazione di rete in cui la rete viene suddivisa con più IGP (Interior Gateway Protocol), ciascuno con un sistema autonomo BGP. Questo viene usato per ragioni di scalabilità, dove la rete diventa troppo grande per un IGP. Il BGP aiuta a scalare quando porta alcune delle rotte che altrimenti sarebbero portate dall'IGP. La soluzione che utilizza AIGP è destinata alle reti con sistemi autonomi BGP diversi sotto un unico controllo amministrativo.

Di seguito è riportato un esempio:

Il servizio end-to-end è una VPN MPLS (Multi-Protocol Label Switching). Quando nella rete è presente un numero elevato di router Provider Edge (PE), l'IGP deve supportare troppi router. La soluzione è che BGP supporti le interfacce di loopback dei router PE. Per garantire che il percorso LSP (Label Switched Path) di MPLS non venga interrotto in modalità end-to-end, è possibile usare l'etichetta BGP IPv4 +. Ciò significa che la RFC 3107 viene utilizzata tra i router PE e i router di confine, che connettono i diversi domini IGP.

Il problema di questa soluzione è che i router di confine o i router PE non possono più decidere del percorso migliore, basato sulla metrica end-to-end più breve, perché non esiste più un IGP in esecuzione sull'intera rete. La soluzione a questo problema è il nuovo attributo BGP, denominato Attributo di metrica IGP accumulato o Attributo di metrica AIGP. Questo attributo non transitivo BGP trasferisce la metrica accumulata per i percorsi in modo che gli altoparlanti BGP ricevano la conoscenza della metrica end-to-end per tali percorsi.

Prima di inoltrare la route, gli altoparlanti BGP devono aggiungere la route alla metrica dell'hop successivo al valore corrente nell'attributo della metrica AIGP.

Nota: Il confronto dei percorsi per una route viene eseguito immediatamente dopo il confronto della preferenza locale. Fare riferimento al documento Cisco sull'algoritmo di selezione del miglior percorso BGP per ulteriori dettagli sull'algoritmo di selezione del miglior percorso BGP.

Questa soluzione è simile a quella in cui il discriminatore Multi Exit (MED) è impostato sulla metrica IGP. Tuttavia, in questo caso, il passaggio 6 (il MED più basso) decide il percorso migliore. Questo passo viene dopo il passo 4, dove il percorso più breve decide il percorso migliore. Il percorso migliore è spesso già individuato prima di raggiungere il passaggio 6. Con la soluzione AIGP, la normale decisione BGP viene modificata in modo che AIGP venga controllato dopo il passaggio 3 per determinare se la route è stata annunciata localmente. Se sistemi autonomi (AS) adiacenti diversi peer con l'altoparlante BGP, il valore always-compare-med deve essere abilitato.

L'attributo della metrica AIGP è specificato nella RFC 7311, che è l'attributo della metrica IGP accumulata per BGP. Per trasportare il valore della metrica AIGP nella comunità dei costi, vengono utilizzate le procedure specificate in draft-retana-idr-aigp-cost-community (Uso della comunità dei costi per trasportare la metrica IGP accumulata).

Nota: La metrica BGP AIGP attribuita fornisce il routing ottimale nelle reti in cui diversi domini di routing sono interconnessi tramite BGP.

Modifiche all'algoritmo di selezione del miglior percorso BGP

Quando si usa AIGP, vengono apportate le seguenti modifiche all'algoritmo di selezione del miglior percorso BGP:

• L'algoritmo di selezione del miglior percorso BGP viene modificato per confrontare AIGP immediatamente dopo il passaggio 3 (Local Advertised Routes) e dopo la verifica dell'hop successivo è valido.
  
  
• Quando il router considera un percorso AIGP rispetto a un percorso AIGP, il valore della metrica AIGP viene aggiunto alla metrica verso l'hop successivo.
  
  
• Quando il router considera un percorso AIGP rispetto a un percorso non AIGP, BGP preferisce il percorso con l'attributo AIGP per impostazione predefinita.
  
  
• Quando si confronta la metrica IGP più bassa con l'hop successivo BGP, viene preso in considerazione il costo AIGP.
  
  
• Se la route verso l'hop successivo ha una metrica AIGP, la metrica viene aggiunta alla metrica IGP verso l'hop successivo. Questa somma è la nuova metrica IGP (costo interno) per la route. Questo si verifica quando una route BGP è ricorsiva per un'altra route BGP.

Considerazioni importanti

Se gli IGP nella rete sono di tipo diverso (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP)), è improbabile che la metrica risultante dall'uso dell'attributo AIGP porti a risultati coerenti o ragionevoli. Se lo stesso IGP viene utilizzato in domini diversi, è necessario utilizzare le stesse impostazioni delle metriche per garantire risultati coerenti.

Affinché i router di confine o i router PE possano decidere tra più percorsi (in base alla metrica derivata da AIGP), devono prima ricevere più percorsi. Per questo motivo, potrebbe essere necessario abilitare la funzionalità Percorso aggiuntivo (ADD-Path) o Annunciare la migliore funzionalità BGP esterna.

I peer BGP abilitati per AIGP e quelli non abilitati vengono inseriti in gruppi di aggiornamento separati. Inoltre, i peer BGP abilitati per AIGP nella community dei costi vengono inseriti in gruppi di aggiornamento separati.

Soluzione per router legacy

Se nella rete sono presenti router che non supportano AIGP (router legacy), esistono due soluzioni possibili:

• Un router può convertire l'AIGP in una community dei costi, collegarlo alla route e pubblicizzare la route sul router legacy.
  
  
• Un router può tradurre l'AIGP in MED, collegarlo alla route e annunciare la route al router legacy.

Configurazione

In questa sezione viene descritto come configurare l'attributo della metrica AIGP.

Abilita trasmissione dell'attributo AIGP

AIGP deve essere abilitato esplicitamente per le sessioni BGP (iBGP) interne ed esterne (eBGP) con neighbor ip-address aigp

In questo modo viene verificato se AIGP è abilitato per il peer BGP:

P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP

For address family: IPv4 Unicast

  AIGP is enabled

Creare AIGP

AIGP può essere impostato sulla metrica IGP o su un valore. Inoltre, l'AIGP può essere impostato per alcune rotte particolari solo per un IGP tramite un route-map. Quando il creatore di AIGP rileva una modifica nella metrica IGP, deve inviare un nuovo aggiornamento BGP con i nuovi valori AIGP per le route interessate.

La metrica AIGP può essere impostata automaticamente sulla metrica IGP o su un valore arbitrario a 32 bit:

P1(config-route-map)#set aigp-metric ?
  <0-4294967295>  manual value
  igp-metric      metric value from rib

Nell'esempio viene mostrato come impostare la metrica AIGP sulla metrica della route IGP:

ip prefix-list loopback seq 5 permit 10.100.1.1/32
!
route-map redistribute-loopback permit 10
 match ip address prefix-list loopback
 set aigp-metric igp-metric

Manopola per disabilitare la chiusura anomala di AIGP

Se questa manopola è abilitata, BGP non utilizza l'interruzione di ora AIGP a meno che entrambi i percorsi non abbiano l'attributo di metrica AIGP. Ciò significa che l'attributo AIGP non viene valutato durante il processo di selezione del miglior percorso tra due percorsi quando un percorso non dispone dell'attributo AIGP.

Di seguito è riportato un esempio:

router bgp 65000
  bgp bestpath aigp ignore

Soluzione per router legacy

Se il router PE2 non dispone di un software che supporta l'attributo di metrica AIGP (è un router legacy), è possibile utilizzare due soluzioni.

Traduzione di AIGP in Cost Community

Configurare i router P3 e P4 in modo da convertire il costo IGP in una community di costi che il router può pubblicizzare su un router legacy:

P3#show run | beg router bgp
router bgp 65000
 address-family ipv4
  neighbor 10.1.9.2 activate
  neighbor 10.1.9.2 send-community both
  neighbor 10.1.9.2 aigp send cost-community 100 poi igp-cost transitive

P4#show run | beg router bgp
router bgp 65000
 address-family ipv4
  neighbor 10.1.10.2 activate
  neighbor 10.1.10.2 send-community both
  neighbor 10.1.10.2 aigp send cost-community 100 poi igp-cost transitive

È necessario consentire al router che invia di inviare comunità estese. Ciò significa che è necessario specificare send-community extended o send-community both attributi (neighbor x.x.x.x send-community) per il peer BGP.

Di seguito è riportato un esempio:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     6        
  Refresh Epoch 2
  65000 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: Cost(transitive):igp:100:6
      mpls labels in/out 17/16
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 15
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external
      Extended Community: Cost(transitive):igp:100:11
      mpls labels in/out 17/30
      rx pathid: 0, tx pathid: 0

Come mostrato, il router PE2 ha scelto il percorso con il costo più basso (100:6 rispetto a 100:11) come migliore.

Traduzione di AIGP in MED

Configurare i router P3 e P4 in modo da convertire il costo IGP nel MED che il router può annunciare a un router legacy.

Ecco la configurazione sul router P3:

router bgp 65000
 address-family ipv4
  neighbor 10.1.9.2 activate
  neighbor 10.1.9.2 send-community both
  neighbor 10.1.9.2 aigp send med

Ecco la configurazione sul router P4:

router bgp 65000
 address-family ipv4
  neighbor 10.1.10.2 activate
  neighbor 10.1.10.2 send-community both
  neighbor 10.1.10.2 aigp send med

Verifica

L'output del debug bgp ipv4 unicast updates in Il comando mostra l'utilizzo dell'attributo della metrica AIGP:

PE2#
BGP(0): 10.1.9.4 rcvd UPDATE w/ attr: nexthop 10.1.9.4, origin ?, aigp-metric 22,
 merged path 65000 65001, AS_PATH

Quando si visualizza l'immagine fornita nella sezione di questo documento, è possibile notare che tutti i collegamenti nella rete AS 6500 hanno un costo OSPF di 10, i collegamenti tra i router P1 e P4 e tra P2 e P3 hanno un costo OSPF di 100, e il collegamento tra i router P3 e P1 ha un costo di 5.

Questo è il percorso per 10.100.1.1/32, come mostrato sul router P3:

P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (2 available, best #1, table default)
  Additional-path-install
  Path advertised to update-groups:
     5         
  Refresh Epoch 5
  65001
    10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.3, Cluster list: 10.100.1.7
      mpls labels in/out 29/16
      rx pathid: 0x0, tx pathid: 0x0
  Path not advertised to any peer
  Refresh Epoch 5
  65001
    10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all
      Originator: 10.100.1.5, Cluster list: 10.100.1.7
      mpls labels in/out 29/16
      rx pathid: 0x1, tx pathid: 0x1

Questo è il percorso per 10.100.1.1/32, come mostrato sul router P4:

P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (2 available, best #2, table default)
  Additional-path-install
  Path not advertised to any peer
  Refresh Epoch 5
  65001
    10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all
      Originator: 10.100.1.3, Cluster list: 10.100.1.7
      mpls labels in/out 29/16
      rx pathid: 0x0, tx pathid: 0x1
  Path advertised to update-groups:
     35        
  Refresh Epoch 5
  65001
    10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.5, Cluster list: 10.100.1.7
      mpls labels in/out 29/16
      rx pathid: 0x1, tx pathid: 0x0

Questo è il percorso per 10.100.1.1/32, come mostrato sul router PE2:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 4
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     5        
  Refresh Epoch 1
  65000 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, localpref 100, valid, external
      mpls labels in/out 18/17
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external, best
      mpls labels in/out 18/30
      rx pathid: 0, tx pathid: 0x0

Il miglior percorso sul router P3 è il percorso con metrica IGP 6, con il router P1 come hop successivo. Il miglior percorso sul router P4 è il percorso con la metrica IGP 11, con il router P2 come hop successivo. I router P3 e P4 inviano il miglior percorso verso il router PE2. Il router PE2 sceglie il percorso dal router P4 come migliore, il che è stato deciso perché entrambi i percorsi BGP sul router PE2 sono molto simili e il passaggio 10 è stato un punto di interruzione: ha vinto il percorso esterno più vecchio. Ciò significa che il traffico tra il router PE2 e il router PE1 assume il percorso PE2-P4-P2-PE1. Tuttavia, il percorso complessivo più breve, se si considera il costo IGP, è PE2-P3-P1-PE1.

Utilizzare le informazioni seguenti per verificare l'attributo metrico AIGP sui router P3 e P4 verso il router PE2 (10.100.1.7):

Di seguito è riportato l'output per il router P3:

router bgp 65000
 address-family ipv4
  bgp additional-paths select all
  bgp additional-paths receive
  bgp additional-paths install
  neighbor 10.1.9.2 activate
  neighbor 10.1.9.2 aigp
  neighbor 10.1.9.2 send-label
  neighbor 10.100.1.7 activate
  neighbor 10.100.1.7 aigp
  neighbor 10.100.1.7 next-hop-self
  neighbor 10.100.1.7 send-label

Di seguito è riportato l'output per il router P4:

router bgp 65000
 address-family ipv4
  bgp additional-paths select all
  bgp additional-paths receive
  bgp additional-paths install
  neighbor 10.1.10.2 activate
  neighbor 10.1.10.2 aigp
  neighbor 10.1.10.2 send-label
  neighbor 10.100.1.7 activate
  neighbor 10.100.1.7 aigp
  neighbor 10.100.1.7 next-hop-self
  neighbor 10.100.1.7 send-label

Come si può vedere, il router P3 ora ha:

P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #2, table default)
  Additional-path-install
  Path not advertised to any peer
  Refresh Epoch 11
  65001
    10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
       backup/repair, all
      Originator: 10.100.1.5, Cluster list: 10.100.1.7
      mpls labels in/out 28/31
      rx pathid: 0x1, tx pathid: 0x1
  Path advertised to update-groups:
     5         
  Refresh Epoch 11
  65001
    10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.3, Cluster list: 10.100.1.7
      mpls labels in/out 28/30
      rx pathid: 0x0, tx pathid: 0x0

Il router P4 ora ha:

P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #1, table default)
  Additional-path-install
  Path advertised to update-groups:
     35        
  Refresh Epoch 11
  65001
    10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
      Originator: 10.100.1.5, Cluster list: 10.100.1.7
      mpls labels in/out 16/31
      rx pathid: 0x1, tx pathid: 0x0
  Path not advertised to any peer
  Refresh Epoch 11
  65001
    10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
      Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
       backup/repair, all
      Originator: 10.100.1.3, Cluster list: 10.100.1.7
      mpls labels in/out 16/30
      rx pathid: 0x0, tx pathid: 0x1

La metrica IGP per i percorsi sui router P3 e P4 non è stata modificata, ma il router PE2 riceve ora le route con l'attributo AIGP dai router P3 e P4.

Il router PE2 vede i due percorsi. Ogni percorso ha l'attributo AIGP e il percorso con l'attributo di metrica AIGP più basso ha ora la precedenza:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     5        
  Refresh Epoch 1
  65000 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
      mpls labels in/out 18/17
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, aigp-metric 11, localpref 100, valid, external
      mpls labels in/out 18/30
      rx pathid: 0, tx pathid: 0

Se il percorso ricevuto dal router P3 è più lungo del percorso ricevuto dal router P4 sul router PE2, il router PE2 sceglierà comunque il percorso dal router P3 come migliore. È possibile aumentare di uno il percorso annunciato dal router P3 tramite route-map e as-prepending.

router bgp 65000
 address-family ipv4
  neighbor 10.1.9.2 route-map as_path out
 
route-map as_path permit 10
 set as-path prepend last-as 1

Il router PE2 dispone ora del percorso dal router P3 con un AS aggiuntivo nel percorso AS:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 7
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     5        
  Refresh Epoch 1
  65000 65001 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, aigp-metric 11, localpref 100, valid, external
      mpls labels in/out 18/30
      rx pathid: 0, tx pathid: 0

A causa dell'attributo della metrica AIGP, il router PE2 sceglie ancora il percorso del router P3 come migliore. Il controllo AIGP viene eseguito prima del controllo della lunghezza del percorso AS.

Se si rimuove la possibilità di inviare AIGP sul router P4 verso il router PE2, il router PE2 riceve il percorso senza l'attributo della metrica AIGP dal router P4. Tuttavia, il router PE2 ha ancora il percorso dal router P3 con AIGP. Il router PE2 preferisce il percorso con AIGP su un percorso senza AIGP e sceglie il percorso dal router P3 come il migliore:

PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     6        
  Refresh Epoch 1
  65000 65001
    10.1.10.6 from 10.1.10.6 (10.100.1.6)
      Origin incomplete, localpref 100, valid, external
      mpls labels in/out 17/30
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  65000 65001 65001
    10.1.9.4 from 10.1.9.4 (10.100.1.4)
      Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
      mpls labels in/out 17/nolabel
      rx pathid: 0, tx pathid: 0x0

Nota: Se si desidera che il router PE2 ignori AIGP durante il processo di selezione del miglior percorso BGP, configurare bgp bestpath aigp ignore

Risoluzione dei problemi

Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.