Border Gateway Protocol Optimal Route Reflection (BGP ORR)
Sommario
Introduzione
In questo documento viene descritto come influenzare il routing quando vi sono uno o più Route Reflector (RR) nella rete per evitare una mesh completa tra i router iBGP.
Premesse
Il passo 8 dell'algoritmo di selezione del miglior percorso BGP consiste nel preferire il percorso con la metrica IGP più bassa all'hop successivo BGP. Pertanto, se tutti i passaggi precedenti al passaggio 8 sono uguali, il passaggio 8 può essere il fattore decisivo per stabilire quale sia il percorso migliore per il record di risorse. Il costo IGP tra il router RR e il router iBGP pubblicitario viene quindi determinato dal posizionamento del router RR. Per impostazione predefinita, il record di risorse annuncia solo il miglior percorso ai propri client. A seconda della posizione in cui si trova il record di risorse, il costo IGP per il router pubblicitario può essere minore o maggiore. Se tutti i costi IGP dei percorsi sono gli stessi, è probabile che si verifichi un errore del router pubblicitario con l'ID del router BGP più basso.
Esempio di rete
I router PE1, PE2 e PE3 annunciano il prefisso 172.16.2.0/24. Se tutti i costi IGP dei collegamenti sono uguali, il record di risorse visualizzerà il percorso da PE1, PE2 e PE3 con un costo IGP pari a 2. Alla fine, il record di risorse sceglie il percorso da PE1 come migliore perché ha l'ID del router BGP più basso. Questo è il passo 11 nell'algoritmo di selezione del miglior percorso BGP. Di conseguenza, tutti i router PE, incluso PE4, sceglieranno PE1 come router PE in uscita per il prefisso 172.16.2.0/24. Dal punto di vista di PE4, il percorso IGP più breve per qualsiasi router PE in uscita è il percorso verso PE3, con un costo IGP di 1. Il costo IGP per qualsiasi altro router PE è 2. Per molte reti, è importante trasportare il traffico attraverso la rete di transito nel modo più breve possibile. Questo processo è noto come instradamento delle patate bollenti.
Esiste un altro motivo possibile per cui RR ha scelto il percorso migliore da PE1. Se nell'immagine il costo IGP (Interior Gateway Protocol) del collegamento P2-PE3 è 10 e tutti gli altri collegamenti hanno ancora un costo IGP pari a 1, RR non sceglierebbe il percorso da PE3 come il migliore, anche se PE3 aveva l'ID router BGP più basso.
Se l'amministratore di questa rete desidera utilizzare il routing tra patate a caldo, deve essere installato un meccanismo in modo che, quando nella rete sono presenti RR, il router in entrata possa continuare a conoscere il percorso al router in uscita più vicino nella rete iBGP. La funzione BGP Add Path può raggiungere questo obiettivo. Tuttavia, con questa funzionalità, i router RR e i router dei bordi devono avere codice più recente che la comprenda. Con la funzionalità BGP Optimal Route Reflection, questo non è un requisito. Questa funzione consente all'RR di inviare il miglior percorso al router di confine BGP in entrata, in base a ciò che l'RR ritiene essere il percorso migliore dal punto di vista del router BGP in entrata.
Un'altra soluzione che consentirebbe il routing delle patate bollenti durante l'installazione delle RR è il posizionamento in linea delle RR. Questi RR non sono RR dedicati, che eseguono solo BGP e IGP. Questi RR in linea si trovano nel percorso di inoltro e vengono collocati nella rete in modo che dispongano del proprio set di client RR, in modo che possano riflettere il miglior percorso verso ogni client RR, che è anche il miglior percorso dal punto di vista di quel client RR.
Come mostrato in questa immagine, i RR vengono posizionati nella rete in modo da poter servire un piccolo gruppo di client RR vicini. A causa della progettazione della rete, i client RR ricevono i percorsi migliori che sono i percorsi migliori dal loro punto di vista, dagli RR in modo che ci possa essere instradamento della patata calda nella rete.
Teoria
La reflection della route ottimale BGP è descritta in IETF draft-ietf-idr-bgp-optimal-route-reflection.
La soluzione BGP Optimal Route Reflection consente all'RR di inviare un percorso ottimale specifico a un router di confine BGP specifico. L'RR può scegliere di inviare un percorso migliore diverso a router di confine BGP diversi o a un set di router di confine. I router di confine devono essere client RR di RR. L'obiettivo è che ogni router di confine BGP in entrata possa avere un router BGP di uscita o di uscita diverso per lo stesso prefisso. Se il router di confine in entrata può sempre inoltrare il traffico al router di uscita AS chiuso, ciò consente il routing delle patate calde.
Il problema è che normalmente il record RR invia solo lo stesso percorso migliore a ciascun router di confine BGP, impedendo il routing delle patate bollenti. Per risolvere questo problema, è necessario che l'RR sia in grado di calcolare diversi percorsi ottimali per lo stesso prefisso, a seconda del router di confine BGP in entrata. Il calcolo del miglior percorso sul router di confine BGP viene eseguito in base alla posizione del router di confine BGP in entrata. Il router di confine eseguirà quindi il calcolo del miglior percorso BGP dalla prospettiva del router di confine in entrata. L'RR che può solo fare questo è quello che ha il quadro completo della topologia della rete dal punto di vista IGP dove si trovano l'RR e i router di confine in entrata. Affinché questo requisito sia soddisfatto, l'IGP deve essere un protocollo di routing dello stato del collegamento.
In questo caso, il record di risorse può eseguire un calcolo SPF (Shortest Path First) con il router di confine in entrata come radice della struttura e calcolare il costo per ogni altro router. In questo modo, si conosceranno i costi sostenuti dal router di confine in entrata per tutti gli altri router di confine in uscita. Questo calcolo speciale di SPF, in cui un altro router è la radice, è detto reverse SPF (rSPF). Questa operazione può essere eseguita solo se il router RR apprende tutti i percorsi BGP da tutti i router di confine BGP. È possibile eseguire un numero di rSPF pari al numero di client RR. In questo modo il carico della CPU aumenta leggermente sul RR.
La soluzione permette di calcolare il miglior percorso basandosi sull'algoritmo di selezione del miglior percorso BGP, in modo che il record RR scelga il percorso migliore dal punto di vista del router di confine in entrata al quale invia il percorso. Ciò significa che verrà scelto il percorso migliore in base al costo IGP più breve per l'hop successivo BGP. La soluzione consente inoltre di scegliere il percorso migliore in base ad alcuni criteri configurati. I router di confine in entrata potrebbero scegliere i percorsi migliori in base ad alcune policy configurate, e non al costo IGP più basso. La soluzione consente all'RR di implementare la riflessione ottimale del percorso sia sul costo IGP (posizione sulla rete) o su alcuni criteri configurati, o entrambi. Se vengono distribuiti entrambi, il criterio viene applicato per primo, quindi la riflessione ottimale della route basata su IGP si verificherà sui percorsi rimanenti.
Implementazione di IOS-XR
L'implementazione IOS-XR consente di utilizzare fino a tre nodi radice per il calcolo rSPF. Se in un gruppo di aggiornamento sono presenti più client RR, non è necessario eseguire un calcolo rSPF per ogni client RR se tali client RR avranno la stessa policy e/o gli stessi costi IGP per i diversi router di confine BGP in uscita. Quest'ultimo significa in genere che i client di RR sono ubicati nello stesso punto (probabilmente nello stesso POP). In questo caso, non è necessario configurare ogni client RR come root. L'implementazione di IOS-XR consente di configurare tre, la principale, la secondaria e la terza radice, per set di client RR, a scopo di ridondanza. Affinché la funzionalità BGP OR venga applicata a qualsiasi client RR, è necessario che tale client sia configurato per far parte di un gruppo di criteri ORR.
La funzionalità BGP OR è abilitata per ciascuna famiglia di indirizzi.
È necessario un protocollo dello stato del collegamento. Può essere OSPF o IS-IS.
IOS XR implementa la funzionalità BGP OR solo in base al costo IGP per l'hop successivo BGP e non in base ad alcune policy configurate.
I peer BGP con lo stesso criterio in uscita vengono inseriti nello stesso gruppo di aggiornamento. Questo è generalmente il caso di iBGP su RR. Quando la funzionalità BGP OR è abilitata, i peer di gruppi ORR diversi si troveranno in gruppi di aggiornamento diversi. Ciò è logico, in quanto gli aggiornamenti inviati dal record di risorse ai client di risorse di risorse di risorse in gruppi BGP OR diversi saranno diversi, in quanto il miglior percorso BGP è diverso.
Il risultato dei calcoli rSPF viene memorizzato in un database.
ORSPF è il nuovo componente di IOS-XR necessario per la funzione BGP OR. ORRSPF si occupa di:
- Raccolta delle informazioni sullo stato del collegamento e gestione del database sullo stato del collegamento
- Esecuzione di rSPF e gestione degli SPT per gruppo di criteri
- Scaricamento dei prefissi dall'SPT alla RIB con le metriche
Il database ottiene le informazioni sullo stato del collegamento direttamente dall'IGP o dal BGP-LS.
I calcoli rSPF generano una topologia che mostra il percorso più breve tra il client RR e qualsiasi altro router dell'area o del livello.
Le route che si trovano su ogni router della topologia vengono archiviate in una tabella RIB speciale per i criteri di gruppo ORR e per AFI/SAFI. Questa tabella viene creata da RSI. Nella tabella vengono inserite le route calcolate dagli rSPF con la radice primaria come radice. Se la radice primaria diventa non disponibile, la radice secondaria è la radice e popola le route nella tabella RIB OR. Lo stesso vale per la radice terziaria.
Configurazione
Configurazione minima richiesta:
- La funzione ORR deve essere abilitata per la famiglia di indirizzi BGP, per gruppi specifici di vicini BGP
- Per ogni gruppo di vicini BGP, è necessario configurare almeno una radice. Facoltativamente, è possibile configurare una radice secondaria e terziaria.
- La ridistribuzione delle route ORR dall'IGP al BGP deve essere abilitata.
Esempio di configurazione
Come mostrato nella prima immagine, il router RR è un router IOS-XR con la funzionalità BGP ORR.
Tutti gli altri router eseguono IOS. Questi router non dispongono della funzionalità BGP OR.
PE1, PE2 e PE3 annunciano il prefisso 172.16.2.0/24 in AFI/SAFI 1/1 (unicast IPv4). Il record di risorse è simile a PE1 e PE2 che a PE3. Il costo IGP di tutti i collegamenti è 1. Il percorso migliore per questo prefisso è quello con R1 come hop successivo a causa dell'ID del router BGP più basso.
RP/0/0/CPU0:RR#show bgp ipv4 unicast 172.16.2.0/24 bestpath-compare
BGP routing table entry for 172.16.2.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 34 34
Last Modified: Mar 7 20:29:48.156 for 11:36:44
Paths: (3 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Local, (Received from a RR-client)
10.100.1.1 (metric 3) from 10.100.1.1 (10.100.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 34
best of local AS, Overall best
Path #2: Received by speaker 0
Not advertised to any peer
Local, (Received from a RR-client)
10.100.1.2 (metric 3) from 10.100.1.2 (10.100.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, add-path
Received Path ID 0, Local Path ID 6, version 33
Higher router ID than best path (path #1)
Path #3: Received by speaker 0
ORR bestpath for update-groups (with more than one peer):
0.1
Local, (Received from a RR-client)
10.100.1.3 (metric 5) from 10.100.1.3 (10.100.1.3)
Origin IGP, metric 0, localpref 100, valid, internal, add-path
Received Path ID 0, Local Path ID 7, version 34
Higher IGP metric than best path (path #1)
PE4 riceverà il percorso con PE1 come hop successivo. Per questo motivo, non è previsto il routing delle patate bollenti per PE4.
Se si desidera che il routing delle patate a caldo venga eseguito su PE4, per i prefissi pubblicizzati da PE1, PE2 e PE3 (ad esempio il prefisso 172.16.2.0/24), PE1 deve avere PE3 come punto di uscita. Ciò significa che il percorso in PE4 deve essere quello con PE3 come hop successivo. Con questa configurazione ORR, è possibile fare in modo che l'RR invii il percorso con l'hop successivo da PE3 a PE4.
router ospf 1
distribute bgp-ls
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
!
router bgp 1
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group 10.100.1.4
!
address-family vpnv4 unicast
!
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 unicast
route-reflector-client
!
!
neighbor 10.100.1.2
remote-as 1
update-source Loopback0
address-family ipv4 unicast
route-reflector-client
!
!
neighbor 10.100.1.3
remote-as 1
update-source Loopback0
address-family ipv4 unicast
route-reflector-client
!
!
neighbor 10.100.1.4
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group
route-reflector-client
!
!
neighbor 10.100.1.5
remote-as 1
update-source Loopback0
address-family ipv4 unicast
route-reflector-client
!
!
!
Se IGP è IS-IS:
router isis 1
net 49.0001.0000.0000.0008.00
distribute bgp-ls
address-family ipv4 unicast
metric-style wide
!
interface Loopback0
address-family ipv4 unicast
!
!
interface GigabitEthernet0/0/0/0
address-family ipv4 unicast
!
!
!
Progettazione del traffico MPLS sul router radice
Per eseguire l'rSPF, l'RR deve trovare l'indirizzo radice configurato nel database IGP. Nell'ISIS, l'ID del router è presente nel database ISIS. Per OSPF, non è presente alcun ID router negli LSA OSPF. La soluzione consiste nel fare in modo che i router radice dichiarino MPLS (Multi Protocol Label Switching), l'ID del router corrispondente all'indirizzo radice configurato sul record di risorse.
Per il protocollo OSPF, i router radice necessitano di una configurazione aggiuntiva per il funzionamento di BGP OR. Per annunciare questo ID router MPLS TE è necessaria una configurazione MPLS TE minima su qualsiasi router radice. L'esatto insieme minimo di comandi dipende dal sistema operativo del router principale. La configurazione MPLS TE sul router radice deve avere la configurazione minima per MPLS TE abilitata in modo che OSPF annunci l'ID del router MPLS TE in una LSA area opaca (tipo 10).
Se il router dispone di un LSA a area opaca con MPLS TE router-ID corrispondente all'indirizzo del router radice configurato, il router rSPF può essere eseguito e il protocollo BGP sul router può annunciare il percorso ottimale.
La configurazione minima richiesta per OSPF sul router radice se è un router IOS è:
!
interface GigabitEthernet0/2
ip address 10.1.34.4 255.255.255.0
ip ospf network point-to-point
mpls traffic-eng tunnels
!
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
router-id 10.200.1.155
network 10.0.0.0 0.255.255.255 area 0
!
Si noti che:
- MPLS TE è abilitato nell'area OSPF specifica
- MPLS TE router-ID è configurato in modo corrispondente all'indirizzo radice configurato nell'RR
- MPLS TE è configurato su almeno un'interfaccia
- non è necessario configurare RSVP-TE
- non è necessario configurare MPLS TE su alcun altro router dell'area
La configurazione minima richiesta per OSPF sul router radice se è un router IOS-XR è:
!
router ospf 1
router-id 5.6.7.8
area 0
mpls traffic-eng
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
mpls traffic-eng router-id 10.100.1.11
!
mpls traffic-eng
!
Se la configurazione precedente è presente sul router principale, RR deve avere MPLS TE router-ID nel database OSPF.
RP/0/0/CPU0:RR#show ospf 1 database
OSPF Router with ID (10.100.1.99) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.12.1 10.1.12.1 1297 0x8000002b 0x006145 3
10.100.1.2 10.100.1.2 646 0x80000025 0x00fb6f 7
10.100.1.3 10.100.1.3 1693 0x80000031 0x003ba9 5
10.100.1.99 10.100.1.99 623 0x8000001e 0x00ade1 3
10.200.1.155 10.200.1.155 28 0x80000002 0x009b2e 5
Type-10 Opaque Link Area Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Opaque ID
1.0.0.0 10.200.1.155 34 0x80000001 0x00a1ad 0
1.0.0.3 10.200.1.155 34 0x80000001 0x0057ff 3
RP/0/0/CPU0:RR#show ospf 1 database opaque-area adv-router 10.200.1.155
OSPF Router with ID (10.100.1.99) (Process ID 1)
Type-10 Opaque Link Area Link States (Area 0)
LS age: 184
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.0
Opaque Type: 1
Opaque ID: 0
Advertising Router: 10.200.1.155
LS Seq Number: 80000001
Checksum: 0xa1ad
Length: 28
MPLS TE router ID : 10.100.1.4
Number of Links : 0
LS age: 184
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.3
Opaque Type: 1
Opaque ID: 3
Advertising Router: 10.200.1.155
LS Seq Number: 80000001
Checksum: 0x57ff
Length: 132
Link connected to Point-to-Point network
Link ID : 10.100.1.3 (all bandwidths in bytes/sec)
Interface Address : 10.1.34.4
Neighbor Address : 10.1.34.3
Admin Metric : 1
Maximum bandwidth : 125000000
Maximum reservable bandwidth global: 0
Number of Priority : 8
Priority 0 : 0 Priority 1 : 0
Priority 2 : 0 Priority 3 : 0
Priority 4 : 0 Priority 5 : 0
Priority 6 : 0 Priority 7 : 0
Affinity Bit : 0
IGP Metric : 1
Number of Links : 1
Si noti che l'ID router MPLS TE (10.100.1.4) e l'ID router OSPF sono diversi.
PE4 ha PE3 come hop successivo per il prefisso (con la metrica IGP corretta per l'hop successivo):
PE4#show bgp ipv4 unicast 172.16.2.0
BGP routing table entry for 172.16.2.0/24, version 37
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.100.1.3 (metric 2) from 10.100.1.8 (10.100.1.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.3, Cluster list: 10.100.1.8
rx pathid: 0, tx pathid: 0x0
PE5 ha ancora PE1 come hop successivo per il prefisso (con la metrica IGP corretta per l'hop successivo):
PE5#show bgp ipv4 unicast 172.16.2.0/24
BGP routing table entry for 172.16.2.0/24, version 13
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.100.1.1 (metric 3) from 10.100.1.8 (10.100.1.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.1, Cluster list: 10.100.1.8
rx pathid: 0, tx pathid: 0x0
Risoluzione dei problemi
Verificare il prefisso sul record di risorse:
RP/0/0/CPU0:RR#show bgp ipv4 unicast 172.16.2.0
BGP routing table entry for 172.16.2.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 19 19
Last Modified: Mar 7 16:41:20.156 for 03:07:40
Paths: (3 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Local, (Received from a RR-client)
10.100.1.1 (metric 3) from 10.100.1.1 (10.100.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 14
Path #2: Received by speaker 0
Not advertised to any peer
Local, (Received from a RR-client)
10.100.1.2 (metric 3) from 10.100.1.2 (10.100.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, add-path
Received Path ID 0, Local Path ID 4, version 14
Path #3: Received by speaker 0
ORR bestpath for update-groups (with more than one peer):
0.1
Local, (Received from a RR-client)
10.100.1.3 (metric 5) from 10.100.1.3 (10.100.1.3)
Origin IGP, metric 0, localpref 100, valid, internal, add-path
Received Path ID 0, Local Path ID 5, version 19
Si noti che add-path è stato aggiunto agli altri percorsi non ottimali, in modo che possano essere annunciati, oltre al percorso migliore. La funzione di aggiunta del percorso non viene utilizzata tra RR e i relativi client: i percorsi non vengono annunciati con un identificatore di percorso.
Verificare che le route siano (ancora) annunciate agli specifici router BGP adiacenti.
Per il sistema PE4 adiacente, l'hop successivo è PE3 per il prefisso 172.16.2.0/24:
RP/0/0/CPU0:RR#show bgp ipv4 unicast neighbors 10.100.1.4 advertised-routes
Network Next Hop From AS Path
172.16.1.0/24 10.100.1.5 10.100.1.5 i
172.16.2.0/24 10.100.1.3 10.100.1.3 i
Processed 2 prefixes, 2 paths
Per il router adiacente PE5, l'hop successivo è PE1 per il prefisso 172.16.2.0/24:
RP/0/0/CPU0:RR#show bgp ipv4 unicast neighbors 10.100.1.5 advertised-routes
Network Next Hop From AS Path
172.16.1.0/24 10.100.1.8 10.100.1.5 i
172.16.2.0/24 10.100.1.1 10.100.1.1 i
Il router adiacente 10.100.1.4 si trova nel proprio gruppo di aggiornamento a causa dei criteri ORR in vigore:
RP/0/0/CPU0:RR#show bgp ipv4 unicast update-group
Update group for IPv4 Unicast, index 0.1:
Attributes:
Neighbor sessions are IPv4
Internal
Common admin
First neighbor AS: 1
Send communities
Send GSHUT community if originated
Send extended communities
Route Reflector Client
ORR root (configured): ipv4-orr-group; Index: 0
4-byte AS capable
Non-labeled address-family capable
Send AIGP
Send multicast attributes
Minimum advertisement interval: 0 secs
Update group desynchronized: 0
Sub-groups merged: 0
Number of refresh subgroups: 0
Messages formatted: 8, replicated: 8
All neighbors are assigned to sub-group(s)
Neighbors in sub-group: 0.1, Filter-Groups num:1
Neighbors in filter-group: 0.3(RT num: 0)
10.100.1.4
Update group for IPv4 Unicast, index 0.3:
Attributes:
Neighbor sessions are IPv4
Internal
Common admin
First neighbor AS: 1
Send communities
Send GSHUT community if originated
Send extended communities
Route Reflector Client
4-byte AS capable
Non-labeled address-family capable
Send AIGP
Send multicast attributes
Minimum advertisement interval: 0 secs
Update group desynchronized: 0
Sub-groups merged: 1
Number of refresh subgroups: 0
Messages formatted: 12, replicated: 42
All neighbors are assigned to sub-group(s)
Neighbors in sub-group: 0.3, Filter-Groups num:1
Neighbors in filter-group: 0.1(RT num: 0)
10.100.1.1 10.100.1.2 10.100.1.3 10.100.1.5
Il comando show orrspf database mostra il gruppo ORR e le relative radici,
RP/0/0/CPU0:RR#show orrspf database
ORR policy: ipv4-orr-group, IPv4, RIB tableid: 0xe0000012
Configured root: primary: 10.100.1.4, secondary: NULL, tertiary: NULL
Actual Root: 10.100.1.4
Number of mapping entries: 1
Lo stesso comando con la parola chiave detail fornisce il costo della radice dell'rSPF per ciascun router/prefisso nella stessa area OSPF:
RP/0/0/CPU0:RR#show orrspf database detail
ORR policy: ipv4-orr-group, IPv4, RIB tableid: 0xe0000012
Configured root: primary: 10.100.1.4, secondary: NULL, tertiary: NULL
Actual Root: 10.100.1.4
Prefix Cost
10.100.1.6 2
10.100.1.1 3
10.100.1.2 3
10.100.1.3 2
10.100.1.4 0
10.100.1.5 3
10.100.1.7 3
10.100.1.8 4
Number of mapping entries: 9
L'ID tabella è stato assegnato da RSI per il gruppo ORR e per AFI/SAFI:
RP/0/0/CPU0:RR#show rsi table-id 0xe0000012
TBL_NAME=ipv4-orr-group, AFI=IPv4, SAFI=Ucast TBL_ID=0xe0000012 in VRF=default/0x60000000 in VR=default/0x20000000
Refcnt=1
VRF Index=4 TCM Index=1
Flags=0x0 LST Flags=(0x0) NULL
RP/0/0/CPU0:RR#show rib tables
Codes: N - Prefix Limit Notified, F - Forward Referenced
D - Table Deleted, C - Table Reached Convergence
VRF/Table SAFI Table ID PrfxLmt PrfxCnt TblVersion N F D C
default/default uni 0xe0000000 5000000 22 128 N N N Y
**nVSatellite/default uni 0xe0000010 5000000 2 4 N N N Y
default/ipv4-orr-grou uni 0xe0000012 5000000 9 27 N N N Y
default/default multi 0xe0100000 5000000 0 0 N N N Y
Il costo della radice (R4/10.100.1.4) dell'rSPF per il router è lo stesso del costo rilevato con show ip route ospf su PE4:
PE4#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 20 subnets, 2 masks
O 10.100.1.1/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1
O 10.100.1.2/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1
O 10.100.1.3/32 [110/2] via 10.1.8.3, 4d06h, GigabitEthernet0/2
O 10.100.1.5/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1
O 10.100.1.6/32 [110/2] via 10.1.7.6, 4d05h, GigabitEthernet0/1
O 10.100.1.7/32 [110/3] via 10.1.8.3, 4d06h, GigabitEthernet0/2
[110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1
O 10.100.1.8/32 [110/4] via 10.1.8.3, 4d05h, GigabitEthernet0/2
[110/4] via 10.1.7.6, 4d05h, GigabitEthernet0/1
RIB per il gruppo BGP OR:
RP/0/0/CPU0:RR#show route afi-all safi-all topology ipv4-orr-group
IPv4 Unicast Topology ipv4-orr-group:
-------------------------------------
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, (!) - FRR Backup path
Gateway of last resort is not set
o 10.100.1.1/32 [255/3] via 0.0.0.0, 14:14:52, Unknown
o 10.100.1.2/32 [255/3] via 0.0.0.0, 14:14:52, Unknown
o 10.100.1.3/32 [255/2] via 0.0.0.0, 00:04:53, Unknown
o 10.100.1.4/32 [255/0] via 0.0.0.0, 14:14:52, Unknown
o 10.100.1.5/32 [255/3] via 0.0.0.0, 14:14:52, Unknown
o 10.100.1.6/32 [255/2] via 0.0.0.0, 14:14:52, Unknown
o 10.100.1.7/32 [255/3] via 0.0.0.0, 14:14:52, Unknown
o 10.100.1.8/32 [255/4] via 0.0.0.0, 14:14:52, Unknown
RP/0/0/CPU0:RR#show rsi table name ipv4-orr-group
VR=default:
TBL_NAME=ipv4-orr-group, AFI=IPv4, SAFI=Ucast TBL_ID=0xe0000012 in VRF=default/0x60000000 in VR=default/0x20000000
Refcnt=1
VRF Index=4 TCM Index=1
Flags=0x0 LST Flags=(0x0) NULL
Il comando show bgp neighbors mostra se il peer è una radice OR:
RP/0/0/CPU0:RR#show bgp neighbor 10.100.1.4
BGP neighbor is 10.100.1.4
Remote AS 1, local AS 1, internal link
Remote router ID 10.100.1.4
Cluster ID 10.100.1.8
BGP state = Established, up for 01:17:41
NSR State: None
Last read 00:00:52, Last read before reset 01:18:30
Hold time is 180, keepalive interval is 60 seconds
Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
Last write 00:00:34, attempted 19, written 19
Second last write 00:01:34, attempted 19, written 19
Last write before reset 01:17:43, attempted 19, written 19
Second last write before reset 01:18:43, attempted 19, written 19
Last write pulse rcvd Mar 8 10:20:13.779 last full not set pulse count 12091
Last write pulse rcvd before reset 01:17:42
Socket not armed for io, armed for read, armed for write
Last write thread event before reset 01:17:42, second last 01:17:42
Last KA expiry before reset 01:17:43, second last 01:18:43
Last KA error before reset 00:00:00, KA not sent 00:00:00
Last KA start before reset 01:17:43, second last 01:18:43
Precedence: internet
Non-stop routing is enabled
Multi-protocol capability received
Neighbor capabilities:
Route refresh: advertised (old + new) and received (old + new)
4-byte AS: advertised and received
Address family IPv4 Unicast: advertised and received
Received 6322 messages, 0 notifications, 0 in queue
Sent 5782 messages, 4 notifications, 0 in queue
Minimum time between advertisement runs is 0 secs
Inbound message logging enabled, 3 messages buffered
Outbound message logging enabled, 3 messages buffered
For Address Family: IPv4 Unicast
BGP neighbor version 41
Update group: 0.1 Filter-group: 0.1 No Refresh request being processed
Route-Reflector Client
ORR root (configured): ipv4-orr-group; Index: 0
Route refresh request: received 0, sent 0
0 accepted prefixes, 0 are bestpaths
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
AIGP is enabled
An EoR was received during read-only mode
Last ack version 41, Last synced ack version 0
Outstanding version objects: current 0, max 2
Additional-paths operation: None
Send Multicast Attributes
Advertise VPNv4 routes enabled with option
Advertise VPNv6 routes is enabled with Local with stitching-RT option
Connections established 6; dropped 5
Local host: 10.100.1.8, Local port: 25176, IF Handle: 0x00000000
Foreign host: 10.100.1.4, Foreign port: 179
Last reset 01:17:42, due to User clear requested (CEASE notification sent - administrative reset)
Time since last notification sent to neighbor: 01:17:42
Error Code: administrative reset
Notification data sent:
None
Come mostrato nell'immagine, sono stati configurati più set di client di ripristino
A PE3 è connesso un gruppo di client di ripristino e a P1 un altro gruppo. Ogni client di ripristino di ogni gruppo si trova alla stessa distanza da qualsiasi router di confine BGP in uscita.
router bgp 1
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-1 10.100.1.4 10.100.1.209 10.100.1.210
optimal-route-reflection ipv4-orr-group-2 10.100.1.5 10.100.1.106 10.100.1.107
!
…
neighbor 10.100.1.4
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-1
route-reflector-client
!
!
neighbor 10.100.1.5
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-2
route-reflector-client
!
!
neighbor 10.100.1.106
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-2
route-reflector-client
!
!
neighbor 10.100.1.107
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-2
route-reflector-client
!
!
neighbor 10.100.1.108
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-2
route-reflector-client
!
!
neighbor 10.100.1.209
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-1
route-reflector-client
!
!
neighbor 10.100.1.210
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-1 route-reflector-client
!
!
neighbor 10.100.1.211
remote-as 1
update-source Loopback0
address-family ipv4 unicast
optimal-route-reflection ipv4-orr-group-1
route-reflector-client
!
!
!
Database orrspf per entrambi i gruppi:
RP/0/0/CPU0:RR#show orrspf database detail
ORR policy: ipv4-orr-group-1, IPv4, RIB tableid: 0xe0000012
Configured root: primary: 10.100.1.4, secondary: 10.100.1.209, tertiary: 10.100.1.210
Actual Root: 10.100.1.4
Prefix Cost
10.100.1.1 3
10.100.1.2 3
10.100.1.3 2
10.100.1.4 0
10.100.1.5 3
10.100.1.6 2
10.100.1.7 3
10.100.1.8 4
10.100.1.106 3
10.100.1.107 3
10.100.1.108 3
10.100.1.209 3
10.100.1.210 3
10.100.1.211 3
ORR policy: ipv4-orr-group-2, IPv4, RIB tableid: 0xe0000013
Configured root: primary: 10.100.1.5, secondary: 10.100.1.106, tertiary: 10.100.1.107
Actual Root: 10.100.1.5
Prefix Cost
10.100.1.1 3
10.100.1.2 3
10.100.1.3 4
10.100.1.4 3
10.100.1.5 0
10.100.1.6 2
10.100.1.7 3
10.100.1.8 4
10.100.1.106 3
10.100.1.107 3
10.100.1.108 3
10.100.1.209 5
10.100.1.210 5
10.100.1.211 5
Number of mapping entries: 30
Se per un gruppo la radice primaria è inattiva o non raggiungibile, la radice secondaria sarà la radice effettivamente utilizzata. Nell'esempio, la radice primaria del gruppo ipv4-or-group-1 non è raggiungibile. La radice secondaria diventa la radice effettiva:
RP/0/0/CPU0:RR#show orrspf database ipv4-orr-group-1
ORR policy: ipv4-orr-group-1, IPv4, RIB tableid: 0xe0000012
Configured root: primary: 10.100.1.4, secondary: 10.100.1.209, tertiary: 10.100.1.210
Actual Root: 10.100.1.209
Prefix Cost
10.100.1.1 4
10.100.1.2 5
10.100.1.3 2
10.100.1.5 5
10.100.1.6 4
10.100.1.7 3
10.100.1.8 4
10.100.1.106 5
10.100.1.107 5
10.100.1.108 5
10.100.1.209 0
10.100.1.210 3
10.100.1.211 3
Number of mapping entries: 14
Conclusioni
La funzionalità BGP Optimal Route Reflection (ORR) consente il routing delle patate a caldo in una rete iBGP quando sono presenti riflettori di percorso, senza la necessità di nuovi software di sistema operativo sui router di confine. Il prerequisito è che l'IGP sia un protocollo di routing allo stato del collegamento.
Feedback