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 documento viene descritta la perdita di route tra VRF quando CE (Customer Edge) e PE (Provider Edge) eseguono il protocollo BGP (iBGP) interno. Vengono inoltre descritte le attuali limitazioni relative alla perdita di percorsi e le possibili soluzioni.
Cisco raccomanda la conoscenza base di BGP.
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.
Il supporto per iBGP come protocollo PE-CE non è stato supportato in precedenza. Tuttavia, questa funzionalità è stata integrata e iBGP può essere considerato un potenziale candidato per il routing da PE a CE. Questa funzione consente ai clienti di disporre di un unico sistema autonomo su tutti i siti. Per ottenere questo risultato è stato introdotto un nuovo attributo ATTR_SET che trasferisce gli attributi VPN BGP in modo trasparente attraverso la rete del provider di servizi. Inoltre, è necessario rendere il PE come reflector di route per la sessione iBGP con il router CE. Il nuovo comando " neighbor x.x.x.x internal vpn-client" consente di ottenere questo risultato. Quando questo singolo comando è configurato, configura automaticamente "neighbor x.x.x.x route-reflector-client" e "neighbor x.x.x.x next-hop-self".
interface Loopback10
ip address 10.10.0.1 255.255.255.0
interface Ethernet0/0
ip address 10.0.12.1 255.255.255.0
router bgp 100
bgp router-id 10.1.1.1
bgp log-neighbor-changes
neighbor 10.0.12.2 remote-as 100
!
address-family ipv4
network 10.10.0.0 mask 255.255.255.0
neighbor 10.0.12.2 activate
exit-address-family
interface Loopback10
ip address 10.20.0.1 255.255.255.0
interface Ethernet0/1
ip address 10.0.45.5 255.255.255.0
router bgp 100
bgp router-id 10.5.5.5
bgp log-neighbor-changes
neighbor 10.0.45.4 remote-as 100
!
address-family ipv4
network 10.20.0.0 mask 255.255.255.0
neighbor 10.0.45.4 activate
exit-address-family
vrf definition A
rd 10:10
route-target export 100:100
route-target import 100:100
!
address-family ipv4
exit-address-family
!
vrf definition B
rd 20:20
!
address-family ipv4
route-target import 50:50
route-target import 100:100
exit-address-family
interface Loopback0
ip address 10.2.2.2 255.255.255.255
ip ospf 100 area 0
!
interface Ethernet0/0
vrf forwarding A
ip address 10.0.12.2 255.255.255.0
!
interface Ethernet0/1
ip address 10.0.23.2 255.255.255.0
mpls ip
router bgp 100
bgp router-id 10.2.2.2
bgp log-neighbor-changes
neighbor 10.4.4.4 remote-as 100
neighbor 10.4.4.4 update-source Loopback0
!
address-family vpnv4
neighbor 10.4.4.4 activate
neighbor 10.4.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf A
neighbor 10.0.12.1 remote-as 100
neighbor 10.0.12.1 activate
neighbor 10.0.12.1 internal-vpn-client // needed to exchange routes between PEs
neighbor 10.0.12.1 next-hop-self
exit-address-family
!
address-family ipv4 vrf B
exit-address-family
vrf definition A
rd 10:10
route-target export 100:100
route-target import 100:100
!
address-family ipv4
exit-address-family
interface Loopback0
ip address 10.4.4.4 255.255.255.255
ip ospf 100 area 0
!
interface Ethernet0/0
ip address 10.0.34.4 255.255.255.0
mpls ip
!
interface Ethernet0/1
vrf forwarding A
ip address 10.0.45.4 255.255.255.0
router bgp 100
bgp router-id 10.4.4.4
bgp log-neighbor-changes
neighbor 10.2.2.2 remote-as 100
neighbor 10.2.2.2 update-source Loopback0
!
address-family vpnv4
neighbor 10.2.2.2 activate
neighbor 10.2.2.2 send-community extended
exit-address-family
!
address-family ipv4 vrf A
neighbor 10.0.45.5 remote-as 100
neighbor 10.0.45.5 activate
neighbor 10.0.45.5 internal-vpn-client //needed to exchange routes between PEs
neighbor 10.0.45.5 route-reflector-client
neighbor 10.0.45.5 next-hop-self
exit-address-family
Come descritto in precedenza, iBGP as PE to CE richiede la configurazione del peering BGP con il cliente all'interno di VRF con il comando "neighbor x.x.x internal vpn-client". In assenza di questo comando, il PE locale accetta le route dal CE locale in VRF, tuttavia queste route del cliente non vengono condivise tramite MP-BGP con altri router PR. Di seguito sono riportati gli output che sono stati acquisiti con la configurazione predefinita di "neighbor x.x.x.x internal vpn-client".
Nell'output seguente vengono illustrati i cicli di lavorazione nel file vrf A in PE1 e PE2.
PE1#show ip route vrf A
Routing Table: A
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
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.0.12.0/24 is directly connected, Ethernet0/0
L 10.0.12.2/32 is directly connected, Ethernet0/0
B 10.10.0.0/24 [200/0] via 10.0.12.1, 00:35:23
B 10.20.0.0/24 [200/0] via 10.4.4.4, 00:40:55
PE2#show ip route vrf A
Routing Table: A
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
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.0.45.0/24 is directly connected, Ethernet0/1
L 10.0.45.4/32 is directly connected, Ethernet0/1
B 10.10.0.0/24 [200/0] via 10.2.2.2, 00:00:08
B 10.20.0.0/24 [200/0] via 10.0.45.5, 00:41:55
CE1#show ip route bgp
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
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.20.0.0/24 [200/0] via 10.0.12.2, 00:03:56
CE2#show ip route bgp
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
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.10.0.0/24 [200/0] via 10.0.45.4, 00:04:21
Caso 1: è stato dimostrato lo scambio di cicli di lavorazione tra CE1 e CE2. Considerare ora un altro file vrf B che deve installare i cicli di lavorazione nel file vrf A. Il metodo normale consiste nell'utilizzare il valore della mappa di esportazione nel VRF A e importare lo stesso valore nel VRF B come illustrato di seguito.
!
vrf definition A
rd 10:10
route-target export 100:100
route-target import 100:100
!
address-family ipv4
exit-address-family
!
vrf definition B
rd 20:20
!
address-family ipv4
route-target import 100:100
exit-address-family
!
Al termine della configurazione precedente, VRF B non riesce a installare nessuna delle route BGP ricevute dal CE locale. Tuttavia, le route ricevute da altri PE tramite MP-BGP vengono installate correttamente come mostrato di seguito nell'output. 10.20.0.0/24 appartiene a CE e viene correttamente ricevuto in VRF A ed esportato anche in VRF B. Ma 10.10.0.0/24 ricevuto localmente da CE1 non riesce a entrare in VRF B.
PE1#show ip route vrf A bgp
Routing Table: A
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
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B 10.10.0.0/24 [200/0] via 10.0.12.1, 00:12:35
B 10.20.0.0/24 [200/0] via 10.4.4.4, 00:54:22
PE1#show ip route vrf B
Routing Table: B
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
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
B 10.20.0.0 [200/0] via 10.4.4.4, 00:46:38
Il problema della perdita del percorso VRF del percorso CE locale dal VRF A al VRF B è visibile solo fino alla configurazione del punto "router adiacente x.x.x.x interno vpn-client". Non appena questo comando viene rimosso da PE1, VRF B è in grado di visualizzare correttamente la route 10.10.0.0/24 locale di CE1, come mostrato di seguito.
!
router bgp 100
address-family ipv4 vrf A
no neighbor 10.0.12.1 internal-vpn-client
!
PE1#show ip route vrf B bgp
Routing Table: B
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
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
B 10.10.0.0 [200/0] via 10.0.12.1 (A), 00:00:11
B 10.20.0.0 [200/0] via 10.4.4.4, 00:58:33
E il sito remoto B, interrompe la ricezione dei percorsi del sito A (poiché il router adiacente x.x.x.x interno vpn-client è stato rimosso).
PE2#show ip route vrf A bgp
Routing Table: A
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
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.20.0.0/24 [200/0] via 10.0.45.5, 01:04:21 // 10.10.0.0/24 is missing.
Si tratta di una limitazione. Per risolvere il problema, è già stato archiviato un bug miglioramento CSCuw43489.
È disponibile una soluzione per verificare il problema descritto sopra. Questa soluzione consente di importare route dal VRF A al VRF B in presenza del comando "neighbor x.x.x.x internal vpn-client". Per risolvere questo problema, è necessario impostare una community fittizia (50:50 nell'esempio seguente) quando si importano route dal cliente. Importare la community estesa fittizia nel file VFR B.
!
route-map TEST, permit, sequence 10
Match clauses:
Set clauses:
extended community RT:50:50
Policy routing matches: 0 packets, 0 bytes
!
vrf definition B
rd 20:20
address-family ipv4
route-target import 100:100
route-target import 50:50 // match dummy community
!
router bgp 100
address-family ipv4 vrf A
neighbor 10.0.12.1 route-map TEST in // Set dummy community
!
PE1#show bgp vpnv4 uni vrf B 10.10.0.0
BGP routing table entry for 20:20:10.10.0.0/24, version 4
Paths: (1 available, best #1, table B)
Not advertised to any peer
Refresh Epoch 1
Local, (Received from ibgp-pece RR-client), imported path from 10:10:10.10.0.0/24 (A)
10.0.12.1 (via vrf A) (via A) from 10.0.12.1 (10.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:50:50
rx pathid: 0, tx pathid: 0x0
PE1#show ip route vrf B
Routing Table: B
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
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
B 10.10.0.0 [200/0] via 10.0.12.1 (A), 00:00:25
B 10.20.0.0 [200/0] via 10.4.4.4, 00:00:25
Come mostrato in precedenza, questa soluzione rende il router 10.10.0.0/24 presente nell'installazione di VRF A in VRF B.