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).
Questo documento descrive il problema che si verifica con una progettazione della ridondanza quando la selezione del percorso OMP (Overlay Management Protocol) viene applicata su un dispositivo vEdge e non sul controller vSmart, il che causa risultati indesiderati e perdita di raggiungibilità al sito remoto in caso di errore del collegamento anche se il percorso di backup è disponibile. Questo problema è anche noto come "vSmart non tiene conto dello stato TLOC sul server vEdge remoto".
Per comprendere meglio il problema, di seguito è riportato un semplice diagramma topologico che illustra l'impostazione:
Qui è possibile trovare una breve descrizione della configurazione.
Entrambi i siti DC (DC1 e DC2) pubblicizzano la stessa rete, 198.51.100.0/24.
In ogni sito, vEdge apprende il router dal controller di dominio tramite un protocollo di routing dinamico, ad esempio Border Gateway Protocol (BGP).
Ogni sito DC contrassegna il prefisso con una metrica diversa:
Nel sito DC1 vEdge set origin-metric 32
Al sito DC2 vEdge setorigin-metric 52
hostname | id-sito | ip-sistema |
CD1 | 21 | 10.100.0.21 |
CD2 | 41 | 10.100.0.41 |
Sede centrale | 100 | 10.100.0.100 |
vSmart | 100 | 10.100.0.20 |
Al momento del funzionamento normale:
1. vSmart riceve 198.51.100.0/24 da CD1 e CD2.
vsmart1# show omp routes 198.51.100.0/24 Code: C -> chosen I -> installed Red -> redistributed Rej -> rejected L -> looped R -> resolved S -> stale Ext -> extranet Inv -> invalid Stg -> staged U -> TLOC unresolved PATH ATTRIBUTE VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE -------------------------------------------------------------------------------------------------------------------------------------- 3 198.51.100.0/24 10.100.0.21 36 1003 C,R installed 10.100.0.21 biz-internet ipsec - <===== METRIC 32 (PREFERRED) 10.100.0.21 49 1003 C,R installed 10.100.0.21 private1 ipsec - <===== METRIC 32 (PREFERRED) 10.100.0.41 36 1003 R installed 10.100.0.41 biz-internet ipsec - <===== METRIC 52 10.100.0.41 49 1003 R installed 10.100.0.41 private1 ipsec - <===== METRIC 52
2. vSmart annuncia alla sede centrale la route con destinazione DC1 (tramite private1 e biz-internet) perché ha il valore più basso nel criterio di selezione route OMP.
vsmart1# show omp routes 198.51.100.0/24 vpn 3 detail --------------------------------------------------- omp route entries for vpn 3 route 198.51.100.0/24 --------------------------------------------------- RECEIVED FROM: <================= RECEIVED FROM vEdge in DC1 in "biz-internet" color peer 10.100.0.21 path-id 36 label 1003 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.100.0.21 type installed tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 21 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set RECEIVED FROM: <================= RECEIVED FROM vEdge in DC1 in "private1" color peer 10.100.0.21 path-id 49 label 1003 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.100.0.21 type installed tloc 10.100.0.21, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 21 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set RECEIVED FROM: <================= RECEIVED FROM vEdge in DC2 in "biz-internet" color peer 10.100.0.41 path-id 36 label 1003 status R loss-reason origin-metric lost-to-peer 10.100.0.21 lost-to-path-id 49 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set RECEIVED FROM: <================= RECEIVED FROM vEdge in DC2 in "private1" color peer 10.100.0.41 path-id 49 label 1003 status R loss-reason tloc-id lost-to-peer 10.100.0.41 lost-to-path-id 36 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set ADVERTISED TO: <================= WE ADVERTISE TO HQ vEdge ONLY BEST ROUTES WITH METRIC 32 peer 10.100.0.100 Attributes: originator 10.100.0.21 label 1003 path-id 4410 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set Attributes: originator 10.100.0.21 label 1003 path-id 4439 tloc 10.100.0.21, private1, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set
3. HQ vEdge contrassegna la route con "biz-internet" TLOC come "Inv,U" perché questo vEdge non dispone di TLOC biz-internet.
4. HQ vEdge contrassegna la route con TLOC "private1" come "C,I,R" e installa la route.
Scenario errore DC1:
1. In uno scenario di errore, l'uplink DC1 vEdge a colori "private1" non riesce (l'interfaccia entra in stato di inattività) mentre "biz-internet" rimane attivo.
2. vSmart riceve 198.51.100.0/24 da DC1 (raggiungibile solo tramite biz-internet) e DC2 (biz-internet e private1).
3. vSmart annuncia alla sede centrale le route vEdge a DC1 (tramite biz-internet) perché DC1 ha la metrica più bassa.
vsmart1# show omp routes 198.51.100.0/24 detail --------------------------------------------------- omp route entries for vpn 3 route 198.51.100.0/24 --------------------------------------------------- RECEIVED FROM: peer 10.100.0.21 path-id 36 label 1003 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.100.0.21 type installed tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 21 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set RECEIVED FROM: peer 10.100.0.41 path-id 36 label 1003 status R loss-reason origin-metric lost-to-peer 10.100.0.21 lost-to-path-id 36 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set RECEIVED FROM: peer 10.100.0.41 path-id 49 label 1003 status R loss-reason tloc-id lost-to-peer 10.100.0.41 lost-to-path-id 36 Attributes: originator 10.100.0.41 type installed tloc 10.100.0.41, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 41 preference not set tag 1000030041 origin-proto eBGP origin-metric 52 as-path "65001 65001 65001 65001 65001" unknown-attr-len not set ADVERTISED TO: peer 10.100.0.31 Attributes: originator 10.100.0.21 label 1003 path-id 5906 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set ADVERTISED TO: peer 10.100.0.41 Attributes: originator 10.100.0.21 label 1003 path-id 7689 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set ADVERTISED TO: <===== THIS IS WHAT WE ADVERTISE TO HQ SITE peer 10.100.0.100 Attributes: originator 10.100.0.21 label 1003 path-id 4410 tloc 10.100.0.21, biz-internet, ipsec ultimate-tloc not set domain-id not set site-id 21 overlay-id 1 preference not set tag 1000030021 origin-proto eBGP origin-metric 32 as-path "65001 65001 65001" unknown-attr-len not set
4. HQ vEdge contrassegna la route con TLOC "biz-internet" come "Inv,U" perché questo vEdge non dispone di TLOC biz-internet.
Il risultato è che HQ vEdge non può raggiungere 198.51.100.0/24.
vSmart avrebbe potuto inviare le route verso DC2 (con metrica superiore meno preferita) e in tal caso HQ vEdge avrebbe comunque raggiunto la destinazione utilizzando il TLOC "private1" tramite DC2, ancora attivo:
VEDGE-HQ-1# show bfd sessions site-id 41 SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 10.100.0.41 41 up private1 private1 192.168.11.1 192.168.41.1 12406 ipsec 7 1000 12:04:02:25 0
Tuttavia, non è disponibile alcuna route tramite "private1" TLOC via DC2 su HQ vEdge installato perché vSmart ha già selezionato la route biz-internet con metrica inferiore come miglior percorso. vSmart non annuncia route OMP con metriche diverse per impostazione predefinita, pertanto non consente al dispositivo vEdge ricevente di decidere quale percorso utilizzare (e di prendere in considerazione i TLOC disponibili e i relativi stati). vSmart non tiene conto dei colori TLOC disponibili sul dispositivo remoto (HQ vEdge nel caso specifico) a cui viene annunciata la route e non ne tiene conto perché non esiste un meccanismo di controllo di questo tipo.
Questo è il caso ad angolo OMP che può essere visto in topologia simile con il riflettore di route iBGP e il peering su indirizzi di interfacce fisiche.
La prima opzione consiste nell'utilizzare la funzionalità di aggiunta di percorsi come (RFC7911) disponibile in OMP e denominata "send-backup-paths" su vSmart:
omp send-backup-paths
Poiché vengono annunciati tutti i percorsi disponibili, il server remoto HQ vEdge sceglie il percorso in base alla disponibilità TLOC.
La seconda opzione consiste nel rimuovere l'azione "set metric" dei criteri di route per il prefisso corrispondente nei bordi DC1 e DC2, quindi eseguire l'imposizione della selezione della route centralizzata tramite i criteri di controllo vSmart, come mostrato di seguito.
policy
lists
site-list site_11
site-id 11
!
prefix-list PREFIX
ip-prefix 198.51.100.0/24
!
control-policy SET_PREF
sequence 10
match route
prefix-list PREFIX
site-id 21
!
action accept
set
preference 200
!
!
!
sequence 20
match route
prefix-list PREFIX
site-id 41
!
action accept
set
preference 100
!
!
!
default-action accept
!
apply-policy
site-list site_11
control-policy SET_PREF out
!
In questo caso, l'ID sito 11 è il vEdge della sede centrale e il prefisso PREFIX-list contiene prefissi che si desidera preferire a un colore TLOC o a un altro. Poiché entrambi i percorsi OMP si trovano su HQ vEdge, quando vEdge non è più in grado di raggiungere Internet biz, installa un percorso tramite private1 nella base RIB (Routing Information Base) dalla tabella dei percorsi OMP.