Risoluzione dei problemi relativi alla selezione del miglior percorso OMP e alle confusioni tipiche
Opzioni per il download
Linguaggio senza pregiudizi
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.
Informazioni su questa traduzione
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).
Sommario
Introduzione
In questo documento viene descritto come risolvere i problemi relativi alla selezione del miglior percorso OMP e al funzionamento tra OMP, criteri di uscita e funzionalità di limite del percorso di invio.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza della soluzione Software Defined Wide Area Network (SDWAN) di Cisco.
Componenti usati
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
Ai fini di questa dimostrazione, il laboratorio è stato configurato con tre controller vSmart e tre router Cisco IOS® XE con gli ID siti 243, 244 e 245 che pubblicizzano lo stesso prefisso 172.16.1.0/24. Alla sovrapposizione sono collegati anche altri router (ad esempio, con site-id 204). Nell'esempio, l'ultimo ottetto di qualsiasi indirizzo ip del sistema di router è uguale all'id-sito (10.10.10.<id-sito>). Per i sistemi vSmarts sono previsti i valori system-ip 10.10.10.228, .229 e .230. Nell'esempio, ogni router ha due trasporti (interfacce WAN) disponibili, da cui due Transport Locator (TLOC) con colori private1 e biz-internet. Su private1, il router di circuito ha un indirizzo IP assegnato nel formato 192.168.9.x e su internet biz ha 192.168.10.x dove x è un ID sito.
Gli scenari sono stati testati con vSmarts con software versioni 20.4.1 e 20.6.1.
Selezione del miglior percorso, criteri di uscita e ordine delle operazioni per il limite del percorso di invio
Prima di tutto, dimostrate la migliore selezione del percorso, la politica di uscita e l'ordine delle send-path-limit operazioni. I router con ID sito 247 devono ricevere il prefisso dai router con ID sito 244 o 245, ma non da 243.
Di seguito è riportata la politica per raggiungere questo obiettivo come riferimento:
policy
lists
site-list site_247
site-id 247
!
site-list sites_244_245
site-id 244
site-id 245
!
prefix-list ENK_PL
ip-prefix 172.16.1.0/24
!
!
control-policy send_2_247
sequence 10
match route
prefix-list ENK_PL
site-list sites_244_245
!
action accept
!
!
sequence 20
match route
prefix-list ENK_PL
!
action reject
!
!
default-action accept
!
!
apply-policy
site-list site_247
control-policy send_2_247 out
!
!Se si considera lo vSmart2, è possibile stabilire la connettività con altri due vSmarts (site-id 1) e router periferici con site-id 243, 244 e 247. Il sito 245 è connesso ad altri controller vSmart e vSmart2 riceve il prefisso da questi indirettamente tramite altri vSmart.
vsmart2# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.10.10.204 vedge 1 1 204 up 2:20:18:10 14/0/7
10.10.10.228 vsmart 1 1 1 up 2:20:18:06 247/0/9
10.10.10.230 vsmart 1 1 1 up 2:20:17:07 256/0/15
10.10.10.243 vedge 1 1 243 up 2:20:18:10 8/0/7
10.10.10.244 vedge 1 1 244 up 0:13:24:59 10/0/6
10.10.10.247 vedge 1 1 247 up 2:20:18:10 0/0/8
Nella tabella OMP, è possibile notare che la route viene ricevuta da altri due controller vSmart e anche direttamente dai siti 243 e 244:
vsmart2# show omp routes 172.16.1.0/24
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 172.16.1.0/24 10.10.10.228 409 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.230 7187 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.243 69 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.243 81 1001 C,R installed 10.10.10.243 private1 ipsec -
10.10.10.244 68 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.244 81 1002 C,R installed 10.10.10.244 private1 ipsec -send-path-limit - in questa dimostrazione è impostato su 1:
vsmart2# show running-config omp
omp
no shutdown
send-path-limit 1
no graceful-restart
!
Nota: da tutti i percorsi multipli uguali per un determinato prefisso selezionati come percorsi migliori e accettati dal criterio di uscita, non più del numero di percorsi specificato in limite percorso di invio annunciato.
È possibile verificare quale prefisso viene annunciato a quale peer. La route originata dal sito 243 ha il valore più basso tra system-ip originator nell'elenco route OMP. Poiché send-path-limit è impostato su 1, su due percorsi disponibili tramite TLOC private1 e biz-internet, l'unica route annunciata ai router con ID sito 204 e 244 e ad altri due controller vSmart (10.10.10.228, .230) proviene dal TLOC biz-internet perché ha un indirizzo IP privato più alto (indirizzo assegnato all'interfaccia):
vsmart2# show omp tlocs ip 10.10.10.243 received | b PUBLIC
ADDRESS PSEUDO PUBLIC PRIVATE
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT
------------------------------------------------------------------------------------------------------------------------
ipv4 10.10.10.243 biz-internet ipsec 10.10.10.228 C,R 1 192.168.10.243 12346 192.168.10.243 12346
10.10.10.230 C,R 1 192.168.10.243 12346 192.168.10.243 12346
10.10.10.243 C,I,R 1 192.168.10.243 12346 192.168.10.243 12346
10.10.10.243 private1 ipsec 10.10.10.228 C,R 1 192.168.9.243 12346 192.168.9.243 12346
10.10.10.230 C,R 1 192.168.9.243 12346 192.168.9.243 12346
10.10.10.243 C,I,R 1 192.168.9.243 12346 192.168.9.243 12346Il sito con ID 243 ottiene il percorso successivo dall'elenco (dal sito 244) ed è anche di colore biz-internet perché ha l'indirizzo IP privato TLOC più alto. Il sito 243 non ottiene la propria route a causa della regola split-horizon, sebbene abbia il valore system-IP più basso. Anche il sito 247 ottiene il percorso dal sito 244 a causa della politica di uscita.
vsmart2# show omp routes 172.16.1.0/24 detail | nomore | exclude not\ set | b ADVERTISED | include peer\|originator\|tloc
peer 10.10.10.204
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.228
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.230
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.243
originator 10.10.10.244
tloc 10.10.10.244, biz-internet, ipsec
peer 10.10.10.244
originator 10.10.10.243
tloc 10.10.10.243, biz-internet, ipsec
peer 10.10.10.247
originator 10.10.10.244
tloc 10.10.10.244, biz-internet, ipsec
Selezione del miglior percorso vSmart: route originate da router perimetrale e route ricevute tramite altro caso vSmarts 1
Per continuare la dimostrazione, aumentarla send-path-limit e impostarla su 16, attivarla debug omp policy prefix 172.16.1.0/24 level highe osservare i risultati. Ora, vSmart2 riceve anche una route dall'ID sito 245 tramite vSmart1 con system-ip 10.10.228 e vSmart3 con 10.10.230).
vsmart2# show omp routes 172.16.1.0/24
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 172.16.1.0/24 10.10.10.228 10146 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.228 10448 1001 C,R installed 10.10.10.243 private1 ipsec -
10.10.10.228 10449 1002 C,R installed 10.10.10.245 biz-internet ipsec -
10.10.10.228 10450 1002 C,R installed 10.10.10.245 private1 ipsec -
10.10.10.230 10252 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.230 10577 1002 C,R installed 10.10.10.244 private1 ipsec -
10.10.10.230 10578 1002 C,R installed 10.10.10.245 biz-internet ipsec -
10.10.10.230 10579 1002 C,R installed 10.10.10.245 private1 ipsec -
10.10.10.243 69 1001 C,R installed 10.10.10.243 public-internet ipsec -
10.10.10.243 81 1001 C,R installed 10.10.10.243 private1 ipsec -
10.10.10.244 68 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.244 81 1002 C,R installed 10.10.10.244 private1 ipsec -Ma vSmart2 pubblicizza solo le route dal sito 244, e non da 245, al sito 247 ora. Si tratta di una tipica fonte di confusione perché le route ricevute direttamente dai router perimetrali vengono preferite rispetto alle route ricevute tramite vSmarts e non annunciate a un router perimetrale e non inviate a un router perimetrale, ma solo nel caso in cui vSmart rilevi una voce della tabella di routing OMP per lo stesso prefisso da qualsiasi altro vSmart a cui il router perimetrale è già connesso:
vsmart2# show omp routes 172.16.1.0/24 detail | nomore | exclude not\ set | b ADVERTISED | include peer\|originator
peer 10.10.10.204
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.228
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.230
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.243
originator 10.10.10.244
originator 10.10.10.244
peer 10.10.10.244
originator 10.10.10.243
originator 10.10.10.243
peer 10.10.10.247
originator 10.10.10.244
originator 10.10.10.244
Questa condizione viene confermata anche dai log di debug archiviati in /var/log/tmplog/vdebug dove il motivo dell'eliminazione è vSmart Connectivityindicato.
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.243 Path: 69 suppressed due to - Policy Rejection
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.243 Path: 81 suppressed due to - Policy Rejection
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11005 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11006 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11007 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.228 Path: 11008 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.230 Path: 11186 suppressed due to - vSmart Connectivity
Oct 9 14:29:01 vsmart2 OMPD[1120]: omp_rib_out_process_entry[3792]: Peer: 10.10.10.247 NLRI: 1: 172.16.1.0/24 from 10.10.10.230 Path: 11187 suppressed due to - vSmart Connectivity
Allo stesso tempo, tenete presente che il sito 247 riceve entrambe le route alla fine, poiché per impostazione predefinita è connesso a due controller vSmart (max-control-connections 2) e vSmart3 vi annuncia entrambe le route in quanto i creatori sono direttamente connessi:
Site-247#show sdwan omp routes 172.16.1.0/24 | begin PATH
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 172.16.1.0/24 10.10.10.229 13 1002 C,I,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.229 14 1002 C,I,R installed 10.10.10.244 private1 ipsec -
10.10.10.230 13 1002 C,R installed 10.10.10.244 biz-internet ipsec -
10.10.10.230 14 1002 C,R installed 10.10.10.244 private1 ipsec -
10.10.10.230 61 1002 C,I,R installed 10.10.10.245 biz-internet ipsec -
10.10.10.230 62 1002 C,I,R installed 10.10.10.245 private1 ipsec -vsmart3# show omp routes 172.16.1.0/24 detail | nomore | exclude not\ set | b ADVERTISED | include peer\|originator | b "peer 10.10.10.247"
peer 10.10.10.247
originator 10.10.10.244
originator 10.10.10.244
originator 10.10.10.245
originator 10.10.10.245Riepilogo della selezione del miglior percorso e dell'ordine delle operazioni in incluso in questa tabella.
| 1. Preferisci route non obsoleta a route non aggiornata |
| 2. Risolvibilità della route TLOC dell'hop successivo raggiungibile (la sessione BFD del piano dati è qui) |
| 3. Preferisci preferenza ciclo di lavorazione più alta |
| 4. Preferire la preferenza TLOC più alta |
| 5. Preferire il miglior codice di origine (Connected, Static, eBGP, EIGRP Internal, OSPF Intra, OSPF Inter, OSPF External, EIGRP External iBGP, Unknown/Unset) |
| 6. Preferenza origine route. Su vSmart: preferisci route basata su router Edge a route basata su vSmart |
| 7. Preferisci route OMP con metrica di origine più bassa |
| 8. Scelta preferita della route ricevuta dal più basso IP del sistema |
| 9. Preferisci la route dall'indirizzo IP del TLOC privato più alto originato dallo stesso ID sito |
| 10. criteri di controllo in uscita |
| 11. send-path-limit |
Selezione del miglior percorso vSmart: route originate da router perimetrale e route ricevute tramite altra richiesta vSmarts 2
Questo comportamento può essere rilevato in scenari di doppio errore con la configurazione affinità dei controller e la configurazione dei criteri in uscita che discrimina alcune route da alcune origini rispetto ad altre in base ad alcuni criteri, come avviene con i criteri degli scenari precedenti. Ai fini della dimostrazione in questa sezione, è necessario aumentare la scala del percorso rispetto agli scenari precedenti, in modo da utilizzare un numero maggiore di siti con ID sito diversi. Si consideri l'installazione tipica con tre controller vSmart e tre aree geografiche proprio come nella dimostrazione della sezione precedente. Grazie all'affinità, ogni vSmart viene assegnato al gruppo corrispondente 1, 2 o 3. max-control-connections è impostato sul valore predefinito 2. vSmarts 1 e 2 sono preferiti per i router della regione A. Nell'area B sono preferibili vSmart 2 e 3. Per un'area, si preferiscono C vSmart 3 e 1.
Di seguito è riportato un esempio di configurazione per assegnare il controller vSmart al gruppo 1:
system
controller-group-id 1
!
Inoltre, è un esempio di configurazione del router della regione A che preferisce i controller dei gruppi 1 e 2. I controller del gruppo 3 vengono utilizzati come ultima risorsa per la connessione se nessuno dei controller dei gruppi 1 e 2 è disponibile perché max-control-connections è impostato su 2 per impostazione predefinita:
system
controller-group-list 1 2 3
!
Lo stesso risultato può essere ottenuto con l'altra configurazione:
vpn 0
interface ge0/0
tunnel-interface
exclude-controller-group-list 3
!
!
!
in questa dimostrazione, il valore predefinito impostato per max-control-connections è 2. il valore impostato per max-control-connections send-path-limit è 16 su tutti i router e i controller.
Ogni regione ha 2 router che ora hanno il prefisso 10.0.0.0/8. Ognuno di questi router ha cinque trasporti (interfacce WAN) con colori TLOC da private1 a private5. Gli spigoli che originano questo prefisso vengono assegnati alle aree, come mostrato nella tabella. Descrive inoltre il nuovo indirizzamento IP del sistema.
| hostname / system-ip |
vSmart1 |
vSmart2 |
vSmart3 |
|
| 169.254.206.4 |
169.254.206.5 |
169.254.206.6 |
||
| cEdge 1 |
169.254.206.11 |
Regione A |
Regione A |
|
| cEdge2 |
169.254.206.12 |
Regione A |
Regione A |
|
| cEdge |
169.254.206.13 |
Regione B |
Regione B |
|
| cEdge 4 |
169.254.206.14 |
Regione B |
Regione B |
|
| cEdge 5 |
169.254.206.15 |
Regione C |
Regione C |
|
| cEdge 6 |
169.254.206.16 |
Regione C |
Regione C |
|
Questa configurazione e scalabilità consentono a ciascun controller vSmart di ricevere 20 percorsi da router collegati direttamente (4 router x 5 TLOC) e inoltre 20 percorsi da ciascun vSmart. In totale, fornisce 60 percorsi per il prefisso specificato 10.0.0.0/8 nella tabella OMP di ciascun controller vSmart in condizioni normali. Alcune colonne non importanti sono state rimosse dall'output show omp route 10.0.0.0/8 vSmart1 per brevità.
FROM PEER STATUS TLOC IP COLOR PREFERENCE
------------------------------------------------------------------
169.254.206.5 C,R 169.254.206.11 private1 -
169.254.206.5 C,R 169.254.206.11 private2 -
169.254.206.5 C,R 169.254.206.11 private3 -
169.254.206.5 C,R 169.254.206.11 private4 -
169.254.206.5 C,R 169.254.206.11 private5 -
169.254.206.5 C,R 169.254.206.12 private1 -
169.254.206.5 C,R 169.254.206.12 private2 -
169.254.206.5 C,R 169.254.206.12 private3 -
169.254.206.5 C,R 169.254.206.12 private4 -
169.254.206.5 C,R 169.254.206.12 private5 -
169.254.206.5 C,R 169.254.206.13 private1 -
169.254.206.5 C,R 169.254.206.13 private2 -
169.254.206.5 C,R 169.254.206.13 private3 -
169.254.206.5 C,R 169.254.206.13 private4 -
169.254.206.5 C,R 169.254.206.13 private5 -
169.254.206.5 C,R 169.254.206.14 private1 -
169.254.206.5 C,R 169.254.206.14 private2 -
169.254.206.5 C,R 169.254.206.14 private3 -
169.254.206.5 C,R 169.254.206.14 private4 -
169.254.206.5 C,R 169.254.206.14 private5 -
169.254.206.6 C,R 169.254.206.13 private1 -
169.254.206.6 C,R 169.254.206.13 private2 -
169.254.206.6 C,R 169.254.206.13 private3 -
169.254.206.6 C,R 169.254.206.13 private4 -
169.254.206.6 C,R 169.254.206.13 private5 -
169.254.206.6 C,R 169.254.206.14 private1 -
169.254.206.6 C,R 169.254.206.14 private2 -
169.254.206.6 C,R 169.254.206.14 private3 -
169.254.206.6 C,R 169.254.206.14 private4 -
169.254.206.6 C,R 169.254.206.14 private5 -
169.254.206.6 C,R 169.254.206.15 private1 -
169.254.206.6 C,R 169.254.206.15 private2 -
169.254.206.6 C,R 169.254.206.15 private3 -
169.254.206.6 C,R 169.254.206.15 private4 -
169.254.206.6 C,R 169.254.206.15 private5 -
169.254.206.6 C,R 169.254.206.16 private1 -
169.254.206.6 C,R 169.254.206.16 private2 -
169.254.206.6 C,R 169.254.206.16 private3 -
169.254.206.6 C,R 169.254.206.16 private4 -
169.254.206.6 C,R 169.254.206.16 private5 -
169.254.206.11 C,R 169.254.206.11 private1 -
169.254.206.11 C,R 169.254.206.11 private2 -
169.254.206.11 C,R 169.254.206.11 private3 -
169.254.206.11 C,R 169.254.206.11 private4 -
169.254.206.11 C,R 169.254.206.11 private5 -
169.254.206.12 C,R 169.254.206.12 private1 -
169.254.206.12 C,R 169.254.206.12 private2 -
169.254.206.12 C,R 169.254.206.12 private3 -
169.254.206.12 C,R 169.254.206.12 private4 -
169.254.206.12 C,R 169.254.206.12 private5 -
169.254.206.15 C,R 169.254.206.15 private1 -
169.254.206.15 C,R 169.254.206.15 private2 -
169.254.206.15 C,R 169.254.206.15 private3 -
169.254.206.15 C,R 169.254.206.15 private4 -
169.254.206.15 C,R 169.254.206.15 private5 -
169.254.206.16 C,R 169.254.206.16 private1 -
169.254.206.16 C,R 169.254.206.16 private2 -
169.254.206.16 C,R 169.254.206.16 private3 -
169.254.206.16 C,R 169.254.206.16 private4 -
169.254.206.16 C,R 169.254.206.16 private5 -
Ora discutiamo di uno scenario di fallimento. Alcuni router spoke con ID sito 20 che appartengono all'area A non possono connettersi a entrambi i controller, per nessuna ragione, e sono connessi a un solo controller vSmart3 che è l'ultima risorsa vSmart per questa area.
Site-20# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
169.254.206.6 vsmart 1 1 1 up 0:00:26:31 10/4/0
Se non è configurato alcun criterio di controllo, è possibile che venga eseguito il routing non ottimale per il sito 20 dell'area A perché, in base all'algoritmo di selezione del miglior percorso, vSmart3 annuncia prima le route ricevute dai router perimetrali. Sono più preferibili rispetto alle route native della regione A ricevute tramite i controller vSmart vSmart1 e vSmart2:
vsmart3# show omp routes 10.0.0.0/8 advertised detail | nomore | b ADVERTISED | i originator\|peer\|\ tloc | b “peer 192.168.206.20”
peer 192.168.206.20
originator 169.254.206.14
tloc 169.254.206.14, private2, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private1, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private3, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private4, ipsec
originator 169.254.206.14
tloc 169.254.206.14, private5, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private5, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private2, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private1, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private3, ipsec
originator 169.254.206.15
tloc 169.254.206.15, private4, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private5, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private4, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private3, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private1, ipsec
originator 169.254.206.13
tloc 169.254.206.13, private2, ipsec
originator 169.254.206.16
tloc 169.254.206.16, private1, ipsec
Per evitare un routing non ottimale, vSmart deve consentire agli spoke di ricevere percorsi solo dai router della stessa regione. Di seguito è riportato un esempio di politica di controllo per ottenere questo risultato:
policy
lists
site-list hubs_A
site-id 11
site-id 12
!
site-list hubs_B
site-id 13
site-id 14
!
site-list hubs_C
site-id 15
site-id 16
!
site-list spokes_A
site-id 20
!
site-list spokes_B
site-id 21
!
site-list spokes_C
site-id 10
!
!
control-policy region_A
sequence 10
match route
site-list hubs_A
!
action accept
!
!
sequence 20
match route
!
action reject
!
!
default-action accept
!
control-policy region_B
sequence 10
match route
site-list hubs_B
!
action accept
!
!
sequence 20
match route
!
action reject
!
!
default-action accept
!
control-policy region_C
sequence 10
match route
site-list hubs_C
!
action accept
!
!
sequence 20
match route
!
action reject
!
!
default-action accept
!
!
apply-policy
site-list spokes_A
control-policy region_A out
!
site-list spokes_B
control-policy region_B out
!
site-list spokes_C
control-policy region_C out
!
!
Ma dallo scenario precedente, si sa che le route di origine Edge sono preferite rispetto alle route ricevute tramite controller vSmart. Significa che il Sito 20, nelle condizioni attuali, non può ricevere alcun percorso?
Ecco un altro concetto importante che viene spesso mancato. Le route da cEdge1 e cEdge2 (system-ip 169.254.206.11 e 169.254.206.12) vengono tuttavia mantenute nella tabella OMP vSmart3 anche se sono meno preferite e comunque contrassegnate come C ("scelte"). Tutte le fasi dell'algoritmo di selezione del miglior percorso a partire dal passaggio 8 (incluso) considerate interruzioni di tempo e route non vengono rimosse dalla tabella OMP, ma ordinate in base alla preferenza descritta per la conseguente elaborazione mediante criteri di controllo dell'uscita e send-path-limit limitazione.
Poiché vSmart3 non è in grado di trovare una voce della tabella di routing OMP per la correzione 10.0.0.0/8 da un altro vSmart a cui il router Edge è già connesso (solo sito-20 connesso a vSmart3), vengono annunciati i percorsi dal sito 11 e dal sito 12 (cEdge1 e cEdge2 corrispondenti) al router del sito 20:
vsmart3# show omp routes 10.0.0.0/8 advertised detail | nomore | b ADVERTISED | i originator\|peer\|\ tloc | b “peer 192.168.206.20”
peer 192.168.206.20
originator 169.254.206.11
tloc 169.254.206.11, private1, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private2, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private3, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private4, ipsec
originator 169.254.206.11
tloc 169.254.206.11, private5, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private1, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private2, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private3, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private4, ipsec
originator 169.254.206.12
tloc 169.254.206.12, private5, ipsec
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
3.0 |
23-Aug-2024 |
Introduzione abbreviata e 'volontà' corretta |
2.0 |
26-Oct-2021 |
Release iniziale |
1.0 |
27-Oct-2021 |
Versione iniziale |
Contributo di
- Eugene KhabarovCisco Engineering
Feedback