La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo articolo vengono descritti diversi scenari della funzionalità Route Reflection del protocollo BGP (Border Gateway Protocol) e come usare ID cluster multipli. Si presuppone una conoscenza preliminare dei concetti BGP, in particolare dei cluster e della riflessione delle route.
Un altoparlante BGP è un router abilitato per BGP. Per impostazione predefinita, gli altoparlanti BGP non pubblicizzano i prefissi appresi da iBGP ai peer iBGP - ciò viene fatto per mantenere la prevenzione del loop. La RFC 4456 introduce la funzione di riflessione del percorso che elimina la necessità di una mesh completa tra gli altoparlanti iBGP. Quando il riflettore di route riflette un prefisso, crea/modifica un attributo non transitivo facoltativo denominato CLUSTER_LIST aggiungendovi il proprio ID cluster. Questo attributo viene utilizzato per la prevenzione dei loop: quando il router riceve l'aggiornamento che CLUSTER_LIST contiene l'ID cluster del router, l'aggiornamento viene ignorato.
Per impostazione predefinita, l'ID cluster è impostato sul valore dell'ID del router BGP, ma può essere impostato su un valore arbitrario a 32 bit. La funzionalità MCID (Multiple Cluster IDs) consente di assegnare ID cluster per router adiacente. Esistono quindi tre tipi di scenari di riflessione delle route.
Di seguito vengono riportati alcuni scenari di riflessione del router ed esempi di configurazione corrispondenti.
Figura 1
La seguente configurazione è stata eseguita sul router RR che agisce come reflector di percorso.
RR#show run | sec bgp router bgp 1 bgp log-neighbor-changes neighbor 10.0.10.2 remote-as 1 neighbor 10.0.10.2 route-reflector-client neighbor 10.0.20.2 remote-as 1 neighbor 10.0.20.2 route-reflector-client neighbor 10.0.40.2 remote-as 1
In questo caso, S1PE1 e S1PE2 sono client di RR, mentre S2PE1 non è client. Nelle progettazioni convenzionali, il router non client sarà il reflector di routing per i router nel livello gerarchico successivo, ma in questo esempio solo un altro PE viene utilizzato per semplicità.
RR#show ip bgp cluster-ids Global cluster-id: 172.16.3.3 (configured: 0.0.0.0) BGP client-to-client reflection: Configured Used all (inter-cluster and intra-cluster): ENABLED intra-cluster: ENABLED ENABLED List of cluster-ids: Cluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USE RR#sh ip bgp 172.16.1.1 BGP routing table entry for 172.16.1.1/32, version 2 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 2 Refresh Epoch 2 Local, (Received from a RR-client) 10.0.10.2 from 10.0.10.2 (172.16.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0 RR#show ip bgp update-group 1 BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast BGP Update version : 4/0, messages 0 Topology: global, highest version: 4, tail marker: 4 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 2, replicated 2, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 1, min 0 Minimum time between advertisement runs is 0 seconds Has 1 member: 10.0.40.2 RR#show ip bgp update-group 2 BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast BGP Update version : 4/0, messages 0 Route-Reflector Client Topology: global, highest version: 4, tail marker: 4 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 3, replicated 6, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 1, min 0 Minimum time between advertisement runs is 0 seconds Has 2 members: 10.0.10.2 10.0.20.2
Questi output mostrano che RR riceve il prefisso 172.16.1.1/32 da S1PE1 e lo riflette sul client S1PE2 e sul client S2PE1 non client. In questo caso particolare, anche l'aggiornamento viene inviato a S1PE1, ma accade perché S1PE1 e S1PE2 hanno lo stesso criterio di routing e, di conseguenza, formano lo stesso gruppo di aggiornamento.
Figura 2
La seguente configurazione è stata eseguita sul router RR che agisce come reflector di percorso.
RR#show run | sec bgp router bgp 1 no bgp client-to-client reflection bgp log-neighbor-changes neighbor 10.0.10.2 remote-as 1 neighbor 10.0.10.2 route-reflector-client neighbor 10.0.20.2 remote-as 1 neighbor 10.0.20.2 route-reflector-client neighbor 10.0.40.2 remote-as 1
Supponiamo che AS1 sia parzialmente mesh: S1PE1 e S1PE2 sono prodotti vicini iBGP (ad esempio, si trovano nello stesso sito e si desidera ottimizzare il modo in cui la rete elabora gli aggiornamenti). In questo caso, la reflection client-to-client è disabilitata e riflette 172.16.1.1/32 proveniente da S1PE1 solo per S2PE1 non client.
RR#show ip bgp cluster-ids Global cluster-id: 172.16.3.3 (configured: 0.0.0.0) BGP client-to-client reflection: Configured Used all (inter-cluster and intra-cluster): DISABLED intra-cluster: ENABLED DISABLED List of cluster-ids: Cluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USE RR#show ip bgp 172.16.1.1 BGP routing table entry for 172.16.1.1/32, version 5 Paths: (1 available, best #1, table default, RIB-failure(17)) Advertised to update-groups: 1 Refresh Epoch 2 Local, (Received from a RR-client) 10.0.10.2 from 10.0.10.2 (172.16.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
RR#show ip bgp update-group 1 BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast BGP Update version : 7/0, messages 0 Topology: global, highest version: 7, tail marker: 7 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 4, replicated 4, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 1, min 0 Minimum time between advertisement runs is 0 seconds Has 1 member: 10.0.40.2
Figura 3
La seguente configurazione è stata eseguita sul router RR che agisce come reflector di percorso.
RR#sh run | sec bgp router bgp 1 no bgp client-to-client reflection intra-cluster cluster-id 192.168.1.1 bgp log-neighbor-changes neighbor 10.0.10.2 remote-as 1 neighbor 10.0.10.2 cluster-id 192.168.1.1 neighbor 10.0.10.2 route-reflector-client neighbor 10.0.20.2 remote-as 1 neighbor 10.0.20.2 cluster-id 192.168.1.1 neighbor 10.0.20.2 route-reflector-client neighbor 10.0.40.2 remote-as 1 neighbor 10.0.40.2 cluster-id 192.168.2.2 neighbor 10.0.40.2 route-reflector-client neighbor 10.0.50.2 remote-as 1 neighbor 10.0.50.2 cluster-id 192.168.2.2 neighbor 10.0.50.2 route-reflector-client neighbor 10.0.70.2 remote-as 1
In questo caso, entrambi i PE nel sito 1 costituiscono il cluster 192.168.1.1, mentre entrambi i PE nel sito 2 costituiscono il cluster 192.168.2.2. S3PE1 non è un client. I server PE nel sito 1 dispongono di una sessione iBGP diretta, la reflection intra-cluster è disabilitata per il cluster 192.168.1.1, ma è ancora abilitata per il cluster 192.168.2.2. La reflection tra cluster è abilitata.
RR#show ip bgp cluster-ids Global cluster-id: 172.16.3.3 (configured: 0.0.0.0) BGP client-to-client reflection: Configured Used all (inter-cluster and intra-cluster): ENABLED intra-cluster: ENABLED ENABLED List of cluster-ids: Cluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USE 192.168.1.1 2 DISABLED DISABLED 192.168.2.2 2 ENABLED ENABLED RR#show ip bgp 172.16.1.1 BGP routing table entry for 172.16.1.1/32, version 5 Paths: (1 available, best #1, table default, RIB-failure(17)) Advertised to update-groups: 3 5 Refresh Epoch 9 Local, (Received from a RR-client) 10.0.10.2 from 10.0.10.2 (172.16.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
RR#show ip bgp update-group 3 BGP version 4 update-group 3, internal, Address Family: IPv4 Unicast BGP Update version : 11/0, messages 0 Topology: global, highest version: 11, tail marker: 11 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 20, replicated 20, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 1, min 0 Minimum time between advertisement runs is 0 seconds Has 1 member: 10.0.70.2
RR#show ip bgp update-group 5 BGP version 4 update-group 5, internal, Address Family: IPv4 Unicast BGP Update version : 11/0, messages 0 Route-Reflector Client Configured with cluster-id 192.168.2.2 Topology: global, highest version: 11, tail marker: 11 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 22, replicated 34, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 3, min 0 Minimum time between advertisement runs is 0 seconds Has 2 members: 10.0.40.2 10.0.50.2
Il prefisso 172.16.1.1/32 ricevuto da S1PE1 viene applicato ai client nel cluster 192.168.2.2 e ai non client. Allo stesso tempo, il prefisso 172.16.4.4/32 ricevuto da S2PE1 viene applicato a tutti i client e non client.
RR#show ip bgp 172.16.4.4 BGP routing table entry for 172.16.4.4/32, version 9 Paths: (1 available, best #1, table default, RIB-failure(17)) Advertised to update-groups: 3 4 5 Refresh Epoch 6 Local, (Received from a RR-client) 10.0.40.2 from 10.0.40.2 (172.16.4.4) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0 RR#show ip bgp update-group 3 BGP version 4 update-group 3, internal, Address Family: IPv4 Unicast BGP Update version : 11/0, messages 0 Topology: global, highest version: 11, tail marker: 11 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 20, replicated 20, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 1, min 0 Minimum time between advertisement runs is 0 seconds Has 1 member: 10.0.70.2 RR#show ip bgp update-group 4 BGP version 4 update-group 4, internal, Address Family: IPv4 Unicast BGP Update version : 11/0, messages 0 Route-Reflector Client Configured with cluster-id 192.168.1.1 Topology: global, highest version: 11, tail marker: 11 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 26, replicated 47, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 3, min 0 Minimum time between advertisement runs is 0 seconds Has 2 members: 10.0.10.2 10.0.20.2 RR#show ip bgp update-group 5 BGP version 4 update-group 5, internal, Address Family: IPv4 Unicast BGP Update version : 11/0, messages 0 Route-Reflector Client Configured with cluster-id 192.168.2.2 Topology: global, highest version: 11, tail marker: 11 Format state: Current working (OK, last not in list) Refresh blocked (not in list, last not in list) Update messages formatted 22, replicated 34, current 0, refresh 0, limit 1000 Number of NLRIs in the update sent: max 3, min 0 Minimum time between advertisement runs is 0 seconds Has 2 members: 10.0.40.2 10.0.50.2
È possibile disabilitare anche la riflessione delle route all'interno del sito per il cluster 192.168.2.2, ma in questo caso i client del cluster devono avere una mesh completa di sessioni iBGP:
RR(config-router)#no bgp client-to-client reflection intra-cluster cluster-id 192.168.2.2
RR#sh ip bgp cluster-ids
Global cluster-id: 172.16.3.3 (configured: 0.0.0.0)
BGP client-to-client reflection: Configured Used
all (inter-cluster and intra-cluster): ENABLED
intra-cluster: ENABLED ENABLED
List of cluster-ids:
Cluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USE
192.168.1.1 2 DISABLED DISABLED
192.168.2.2 2 DISABLED DISABLED
La riflessione all'interno del sito può essere disabilitata anche per tutti i cluster:
RR(config-router)#no bgp client-to-client reflection intra-cluster cluster-id any
Figura 4
La seguente configurazione è stata eseguita sul router RR che agisce come reflector di percorso.
RR#show run | sec bgp router bgp 1 no bgp client-to-client reflection bgp log-neighbor-changes neighbor 10.0.10.2 remote-as 1 neighbor 10.0.10.2 cluster-id 192.168.1.1 neighbor 10.0.10.2 route-reflector-client neighbor 10.0.20.2 remote-as 1 neighbor 10.0.20.2 cluster-id 192.168.1.1 neighbor 10.0.20.2 route-reflector-client neighbor 10.0.40.2 remote-as 1 neighbor 10.0.40.2 cluster-id 192.168.2.2 neighbor 10.0.40.2 route-reflector-client neighbor 10.0.50.2 remote-as 1 neighbor 10.0.50.2 cluster-id 192.168.2.2 neighbor 10.0.50.2 route-reflector-client neighbor 10.0.70.2 remote-as 1
È possibile disabilitare la riflessione sia all'interno del cluster che tra cluster. In questo caso, verrà eseguita solo la reflection tra client e non client.
RR#show ip bgp cluster-ids Global cluster-id: 172.16.3.3 (configured: 0.0.0.0) BGP client-to-client reflection: Configured Used all (inter-cluster and intra-cluster): DISABLED intra-cluster: ENABLED DISABLED List of cluster-ids: Cluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USE 192.168.1.1 2 ENABLED DISABLED 192.168.2.2 2 ENABLED DISABLED
RR#show ip bgp 172.16.1.1
BGP routing table entry for 172.16.1.1/32, version 5
Paths: (1 available, best #1, table default, RIB-failure(17))
Advertised to update-groups:
3
Refresh Epoch 9
Local, (Received from a RR-client)
10.0.10.2 from 10.0.10.2 (172.16.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
RR#show ip bgp 172.16.4.4
BGP routing table entry for 172.16.4.4/32, version 9
Paths: (1 available, best #1, table default, RIB-failure(17))
Advertised to update-groups:
3
Refresh Epoch 6
Local, (Received from a RR-client)
10.0.40.2 from 10.0.40.2 (172.16.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
RR#show ip bgp update-group 3
BGP version 4 update-group 3, internal, Address Family: IPv4 Unicast
BGP Update version : 11/0, messages 0
Topology: global, highest version: 11, tail marker: 11
Format state: Current working (OK, last not in list)
Refresh blocked (not in list, last not in list)
Update messages formatted 20, replicated 20, current 0, refresh 0, limit 1000
Number of NLRIs in the update sent: max 1, min 0
Minimum time between advertisement runs is 0 seconds
Has 1 member:
10.0.70.2
I prefissi 172.16.1.1/32 e 172.16.4.4/32 sono stati creati dai cluster 192.168.1.1 e 192.168.2.2, rispettivamente. Entrambi questi prefissi sono riflessi solo su S3PE1 non client. In questo caso, tutti i client devono avere una mesh completa. In genere, in questo particolare scenario, gli MCID non hanno alcun senso (lo stesso comportamento potrebbe essere ottenuto con un singolo cluster), ma possono comunque essere utilizzati se si desidera disporre di elenchi di cluster diversi per route da vicini diversi.
Nota: Non è possibile abilitare la riflessione all'interno del cluster (per un cluster specifico o per tutti i cluster) mentre la riflessione tra cluster è disabilitata.
Quando RR riflette un prefisso, aggiunge l'ID cluster all'attributo facoltativo non transitivo CLUSTER_LIST. Inoltre, imposta l'attributo non transitivo facoltativo ORIGINATOR_ID sull'ID router del peer che ha annunciato il prefisso all'RR.
Quando si utilizzano MCID e RR riflette il prefisso, utilizza l'ID cluster configurato per il peer che ha annunciato il prefisso all'RR. Se per il peer non è configurato un ID cluster specifico, verrà utilizzato l'ID cluster globale.
Vediamo alcuni esempi. In RR tutte le forme di riflessione route sono abilitate. L'ID cluster globale è 172.16.3.3, gli ID cluster 192.168.1.1 e 192.168.2.2 sono impostati rispettivamente su PE nel sito 1 e nel sito 2 (fare riferimento al diagramma della topologia riportato sopra).
RR#show ip bgp cluster-ids Global cluster-id: 172.16.3.3 (configured: 0.0.0.0) BGP client-to-client reflection: Configured Used all (inter-cluster and intra-cluster): ENABLED intra-cluster: ENABLED ENABLED List of cluster-ids: Cluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USE 192.168.1.1 2 ENABLED ENABLED 192.168.2.2 2 ENABLED ENABLED
S2PE3#show ip bgp 172.16.1.1 BGP routing table entry for 172.16.1.1/32, version 2 Paths: (1 available, best #1, table default, RIB-failure(17)) Not advertised to any peer Refresh Epoch 1 Local 10.0.10.2 (metric 20) from 10.0.70.1 (172.16.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 172.16.1.1, Cluster list: 192.168.1.1 rx pathid: 0, tx pathid: 0x0
S2PE3#show ip bgp 172.16.4.4 BGP routing table entry for 172.16.4.4/32, version 4 Paths: (1 available, best #1, table default, RIB-failure(17)) Not advertised to any peer Refresh Epoch 1 Local 10.0.40.2 (metric 20) from 10.0.70.1 (172.16.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 172.16.4.4, Cluster list: 192.168.2.2 rx pathid: 0, tx pathid: 0x0
Il prefisso 172.16.1.1/32 ricevuto da S2PE3 non client originato dal cluster 192.168.1.1 - l'ID cluster 192.168.1.1 viene aggiunto all'elenco dei cluster. Riceve inoltre il prefisso 172.16.4.4/32 originato dal cluster 192.168.2.2 - l'ID cluster 192.168.2.2 viene aggiunto all'elenco dei cluster.
S1PE1#show ip bgp 172.16.6.6 BGP routing table entry for 172.16.6.6/32, version 5 Paths: (1 available, best #1, table default, RIB-failure(17)) Not advertised to any peer Refresh Epoch 1 Local 10.0.70.2 (metric 20) from 10.0.10.1 (172.16.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 172.16.6.6, Cluster list: 172.16.3.3 rx pathid: 0, tx pathid: 0x0
Il client S1PE1 riceve il prefisso 172.16.6.6/32 originato da un non client. L'ID cluster globale 172.16.3.3 viene aggiunto all'elenco dei cluster.
S1PE2#show ip bgp 172.16.1.1/32 BGP routing table entry for 172.16.1.1/32, version 8 Paths: (1 available, best #1, table default, RIB-failure(17)) Not advertised to any peer Refresh Epoch 1 Local 10.0.10.2 (metric 20) from 10.0.20.1 (172.16.3.3) Origin IGP, metric 0, localpref 100, valid, internal Originator: 172.16.1.1, Cluster list: 192.168.1.1 rx pathid: 0, tx pathid: 0
S1PE2 appartiene al cluster 192.168.1.1 e riceve il prefisso 172.16.1.1/32 originato da S1PE1 che appartiene anche al cluster 192.168.1.1. L'ID cluster 192.168.1.1 viene aggiunto all'elenco dei cluster.
S2PE1#show ip bgp 172.16.1.1/32 BGP routing table entry for 172.16.1.1/32, version 4 Paths: (1 available, best #1, table default, RIB-failure(17)) Not advertised to any peer Refresh Epoch 1 Local 10.0.10.2 (metric 20) from 10.0.40.1 (172.16.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 172.16.1.1, Cluster list: 192.168.1.1 rx pathid: 0, tx pathid: 0x0 S1PE1#sh ip bgp 172.16.4.4/32 BGP routing table entry for 172.16.4.4/32, version 4 Paths: (1 available, best #1, table default, RIB-failure(17)) Not advertised to any peer Refresh Epoch 1 Local 10.0.40.2 (metric 20) from 10.0.10.1 (172.16.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 172.16.4.4, Cluster list: 192.168.2.2 rx pathid: 0, tx pathid: 0x0
S2PE1 appartiene al cluster 192.168.2.2 e riceve il prefisso 172.16.1.1/32 creato dal cluster 192.168.1.1 - l'ID del cluster è impostato su 192.168.1.1.
S1PE1 appartiene al cluster 192.168.1.1 e riceve il prefisso 172.16.4.4/32 creato dal cluster 192.168.2.2 - l'ID del cluster è impostato su 192.168.2.2.
Se il router riceve l'aggiornamento per il prefisso che l'elenco di cluster contiene l'ID cluster del router, l'aggiornamento viene ignorato. Se vengono utilizzati MCID, l'aggiornamento che contiene uno qualsiasi degli ID cluster configurati (globali o per router adiacenti) verrà ignorato.