Questa sezione include una panoramica della funzionalità di routing di VMware SASE che descrive i tipi di ruote, le route connesse e statiche, nonché le route dinamiche con gli scenari di tie break e i valori preferiti in Controllo flusso overlay (OFC,Overlay Flow Control) con Calcolo dei costi distribuito (DCC, Distributed Cost Calculation).
Panoramica
Il routing di VMware SASE è basato su un protocollo proprietario denominato VCRP, che è compatibile con il percorso multiplo e protetto tramite il trasporto VCMP. Gli endpoint SD-WAN sono connessi tramite VCRP in modo simile alla mesh completa di iBGP. SD-WAN Gateway agisce come reflector di route BGP che riflette le route da un SD-WAN Edge a un altro SD-WAN Edge nell'azienda del cliente in base alle impostazioni del profilo.
Il diagramma seguente illustra una distribuzione di SD-WAN tipica con destinazioni non SD-WAN multi-cloud in cui Orchestrator esegue il calcolo della route, a differenza del metodo più recente e preferito che utilizza il calcolo dei costi dinamico (DCC).
Componenti di SD-WAN per scopi di routing
- SD-WAN Edge è un dispositivo di classe aziendale o un'istanza di cloud virtualizzata che fornisce connettività sicura e ottimizzata ad applicazioni private, pubbliche e ibride e servizi virtualizzati. Nel routing di SD-WAN, l'Edge è un Border Gateway. Un Edge può funzionare come un Edge regolare (senza configurazione di hub), come hub autonomo o come parte di un cluster oppure come spoke (quando sono configurati gli hub).
- SD-WAN Gateway è autonomo, stateless, scalabile orizzontalmente e fornito dal cloud a cui gli Edge di più tenant possono connettersi. Per qualsiasi distribuzione di SD-WAN, diversi SD-WAN Gateway vengono distribuiti come una rete distribuita geograficamente (per ridurre la latenza) e scalabile orizzontalmente (per capacità), con ciascun gateway che funge da Reflector di route per gli Edge connessi.
Tutte le route acquisite localmente in un Edge vengono inviate al gateway in base alla configurazione. Il gateway riflette quindi queste route negli altri Edge dell'azienda, consentendo una connettività VPN della mesh completa efficiente senza creare una mesh completa di tunnel.
- SASE Orchestrator è un portale di monitoraggio e configurazione basato sul cloud multi-tenant. Nel routing di SD-WAN, Orchestrator gestisce le route per tutte le aziende e può sostituire il comportamento di routing predefinito.
L'immagine seguente illustra i componenti di VMware SD-WAN utilizzati a scopo di routing.
Tipi di route
- Route locale: qualsiasi route acquisita localmente in un SD-WAN Edge. Può trattarsi di una subnet connessa, di una route configurata staticamente o di qualsiasi route acquisita tramite BGP oppure OSPF.
- Route remote (Remote Routes): qualsiasi route acquisita da VCRP. In altre parole, una route che non è localmente presente in un Edge è una route remota. Questa route proviene da un Edge diverso e viene riflessa dal gateway negli altri Edge dell'azienda del cliente in base alla configurazione.
Per instradare il traffico per le route non dinamiche (BGP e OSPF), SD-WAN utilizza un ordine rigido che non può essere modificato. In alcuni scenari, è tuttavia possibile utilizzare la tecnica Corrispondenza prefisso più lungo (Longest Prefix Match) per modificare il flusso del routing.
- Lunghezza del prefisso di rete.
- Connesso locale.
- Statico locale se è abilitata l'opzione preferita (LAN statica < WAN statica).
- Se l'opzione preferita non è abilitata, vengono preferite le route di overlay.
- Route statiche NSD locali.
- NSD IPSec ha la precedenza su NSD GRE.
- NSD remoto statico.
- Edge remoto connesso.
- Edge remoto LAN/WAN statico.
- PG statico.
- PG statico sicuro > PG statico non sicuro.
- Route dinamiche (Controllo flusso overlay (OFC) o basato sul calcolo dei costi distribuito (Distributed Cost Calculation)).
- Il sito locale (OSPF tra/intra, non uplink BGP) è preferibile rispetto alle route eccessivamente dinamiche.
- Le route all'interno dell'area o tra aree dell'OSPF locale hanno la precedenza su BGP locale.
- Il BGP locale ha la precedenza su OSPF esterno locale (OE1/OE2).
- Le route remote con costo preferito hanno la precedenza sulle route locali non preferite (OE1,OE2,UPLINK BGP).
- All'interno delle route dinamiche remote viene considerata la preferenza (la preferenza inferiore ha la precedenza).
- Se la preferenza è la stessa, vengono confrontati gli attributi BGP e le metriche OSPF).
- OSPF INTRA> INTER > OE1 > OE2
- BGP
- Preferenza locale più alta
- Lunghezza AS_PATH inferiore
- Metrica BGP inferiore
- Per ulteriori dettagli sul calcolo della preferenza, fare riferimento alla sezione DCC.
Route connesse e statiche
Questa sezione include informazioni essenziali relative alle route connesse e statiche. Una route connessa è una route configurata verso una rete direttamente collegata all'interfaccia. Una route statica è utile per i casi specifici in cui sono necessarie route statiche per i dispositivi collegati alla rete esistente, come le stampanti. Ulteriori informazioni sulle route statiche sono disponibili in Configurazione delle impostazioni di routing statiche.
Route connesse
- Per fare in modo che una route connessa sia visibile in SD-WAN, configurare le impostazioni seguenti in Orchestrator:
- La funzionalità VPN cloud (Cloud VPN) deve essere attivata.
- La route connessa deve essere configurata con un indirizzo IP valido.
- L'interfaccia dell'Edge per questa route deve essere attiva al livello 1 e funzionante ai livelli 2 e 3.
- Anche le VLAN associate a questa interfaccia dell'Edge devono essere attive.
- Il flag Annuncia (Advertise) deve essere impostato nell'interfaccia dell'Edge in Impostazioni IP interfaccia (Interface IP settings) per la route connessa configurata.
- Per fare in modo che una route statica sia visibile in SD-WAN, configurare le impostazioni seguenti in Orchestrator:
- La funzionalità VPN cloud (Cloud VPN) deve essere attivata.
- Nella configurazione della route statica deve essere selezionata l'opzione Annunciata (Advertised).
- Le route statiche possono inoltrare il traffico all'underlay WAN o alla LAN.
- Se si aggiunge una route statica, viene ignorato il NAT nell'interfaccia dell'Edge.
- Il routing ECMP (Equal-Cost Multi-Path) non è supportato con una route statica e viene utilizzata solo la prima route statica.
- Utilizzare un probe ICMP per evitare il blackholing del traffico in caso di errore nell'hop successivo.
- Una route statico con il flag Preferita (Preferred) selezionato è preferibile rispetto a qualsiasi route VPN acquisita nell'overlay.
Quando è selezionata la casella di controllo Preferita (Preferred), la route statica viene sempre associata per prima, anche se è disponibile una route VPN con un costo inferiore.
Se non si seleziona questa opzione, qualsiasi route VPN disponibile viene associata prima della route statica, anche se la route VPN ha un costo maggiore rispetto alla route statica. La route statica viene associata solo quando le route VPN corrispondenti non sono disponibili.
Quando la casella di controllo Annuncia (Advertise) è selezionata, la route statica viene annunciata per prima rispetto alla VPN e gli altri SD-WAN Edge nella rete potranno accedere alla risorsa. Ciò consente inoltre la ridistribuzione della route statica in un protocollo di routing come BGP/OSPF locale.
Non selezionare questa opzione quando una risorsa privata, come la stampante personale di un utente che lavora da remoto, è configurata come route statica e agli altri utenti deve essere impedito l'accesso alla risorsa.
Il controllo del flusso di overlay Contrassegni annunci globali (Global Advertise Flags) controlla quali route vengono aggiunte all'overlay. Per impostazione predefinita, i seguenti tipi di route non vengono annunciati nell'overlay: OSPF esterno e iBGP di destinazione non SD-WAN. Inoltre, se un Edge funge da hub e filiale, vengono utilizzati i Contrassegni annunci globali (Global Advertise Flags) configurati per la filiale, non quelli configurati per l'hub.
Una route automatica fa riferimento a un prefisso basato sull'interfaccia che utilizza la corrispondenza del prefisso IP più lungo (ad esempio: 172.16.1.10/32) che viene installato in locale nell'Edge ma non viene annunciato agli Edge remoti. Le route autonome sono denominate anche "route dell'interfaccia". Nei registri dell'Edge, le route automatiche vengono visualizzate con il flag di route "s".
Una route automatica è diversa da una route connessa perché la route connessa può essere annunciata nell'overlay in modo che i client Edge remoti possano raggiungere i client appartenenti alla route connessa sul lato dell'Edge di origine. Le route automatiche sono locali per l'Edge stesso.
Una route cloud è indicata con il flag "v" e si riferisce a una route installata in un Edge che punta a un VMware SD-WAN Gateway primario per il traffico con percorso multiplo destinato a Internet (in altre parole, il traffico Internet che utilizza l'ottimizzazione dinamica del percorso multiplo (DMPO) che utilizza un gateway prima di raggiungere Internet).L'Edge utilizza anche una route cloud tramite un Gateway corrispondente per il traffico di gestione destinato a un VMware Orchestrator che è ospitato nel cloud pubblico.
Controllo del flusso di overlay con calcolo dei costi distribuito
Panoramica del calcolo dei costi distribuito
Calcolo dei costi distribuito è una funzionalità che utilizza gli SD-WAN Edge e i gateway anziché SASE Orchestrator per il calcolo della preferenza della route. L'Edge e il Gateway inseriscono le route immediatamente dopo averle acquisite e quindi comunicano queste preferenze a Orchestrator.
Calcolo dei costi distribuito risolve un problema che si verifica nelle distribuzioni su larga scala in cui l'utilizzo del solo Orchestrator può impedire aggiornamenti tempestivi delle preferenze delle route perché Orchestrator non può essere raggiunto da un Edge o un gateway per ricevere le preferenze di routing aggiornate oppure perché Orchestrator non è in grado di fornire rapidamente gli aggiornamenti delle route quando ne sta calcolando un numero elevato contemporaneamente. La distribuzione delle responsabilità per il calcolo delle preferenze delle route agli Edge e ai gateway assicura aggiornamenti delle route veloci e affidabili.
Come viene eseguita la preferenza del calcolo dei costi distribuito
| Edge | Gateway partner/Gateway ospitato |
|---|---|
| NSD E BGP | NSD E/I BGP |
| NSD I BGP | E/I BGP |
| NSD Uplink BGP | |
| OSPF O | |
| OSPF IA | |
| E BGP | |
| I BGP | |
| OSPF OE1 | |
| OSPF OE2 | |
| Uplink BGP |
| O = OSPF interno all'area |
| IA = OSPF tra aree |
| OE1 = Tipo esterno OSPF 1 |
| OE2 = Tipo esterno OSPF 2 |
| E BGP = BGP esterno |
| I BGP = BGP interno |
| NSD = Destinazione non SD-WAN |
Ogni tipo di route ha un valore di preferenza (la preferenza può essere considerata come il costo in questo documento) e a ogni route acquisita viene assegnato un valore di preferenza in base al tipo di route. Più basso è il valore di preferenza, più alta è la priorità. Nella tabella 1-3 è indicato il valore di preferenza predefinito per ogni tipo di route.
| Dispositivo (Device) | Tipo di route (Route Type) | Preferenza predefinita (Default Preference) |
| Edge/hub | NSD E BGP | 997 |
| Edge/hub | NSD I BGP | 998 |
| Gateway | NSD E/I BGP | 999 |
| Edge/hub | NSD Uplink BGP | 1000 |
| Edge/hub | OSPF O | 1001 |
| Edge/hub | OSPF IA | 1002 |
| Edge/hub | E BGP | 1003 |
| Edge/hub | I BGP | 1004 |
| Gateway partner | E/I BGP | 1005 |
| Edge/hub | OSFP OE1 | 1001006 |
| Edge/hub | OSPF OE2 | 1001007 |
| Hub/Edge | Uplink BGP | 1001008 |
I valori di preferenza visualizzati nella tabella precedente si basano sull'ordine di priorità predefinito nella configurazione di Controllo flusso overlay (Overlay Flow Control). I valori verranno modificati di conseguenza se l'ordine predefinito viene modificato.
Workflow della route dinamica
- L'Edge o il gateway acquisisce una route dinamica.
- SD-WAN identifica internamente il tipo di route e il valore di preferenza predefinito di tale route dinamica.
- SD-WAN assegna il valore di preferenza corretto e installa la route in RIB (Routing Information Base) e FIB (Forwarding Information Base).
- SD-WAN considera l'azione di annuncio predefinita configurata per questa route. In base all'azione di annuncio, SD-WAN annuncia la route nell'azienda cliente (annunciata) o non esegue alcuna azione oltre ad aggiungere la route in locale in RIB e FIB (non annunciata).
- SD-WAN sincronizza quindi questa route con Orchestrator, che la visualizza in Orchestrator.
Punti di uscita VPN preferiti
Questa sezione illustra i punti di uscita VPN preferiti, spiega cosa sono, quali route possono appartenere a determinate categorie e come utilizzare l'aggiunta di route per sostituire i valori predefiniti.
Nel servizio SD-WAN del portale dell'azienda, quando si passa a è possibile vedere una sezione intitolata Uscite VPN preferite (Preferred VPN Exits). Questa sezione mostra le priorità predefinite e indica alcune categorie di route da preferire rispetto ad altre.
- Edge: qualsiasi route interna che può essere acquisita in un Edge hub o spoke rientra in questa categoria ed è contrassegnata con la priorità più alta. Una route interna non può essere una route di tipo OSPF OE 1/OE 2 o Uplink BGP (BGP Uplink).
- Hub: tutte le route esterne acquisite in un Edge/Hub rientrano nella categoria Hub e hanno in genere una priorità più bassa. Le route di tipo Hub includono OSPF OE1/2 e Uplink BGP.
- Gateway partner: qualsiasi route acquisita in un gateway partner.
- Router: un router rappresenta qualsiasi prefisso di route acquisito da un Edge con BGP o OSPF e determina la preferenza assegnata a una route dinamica. In genere, a tutti i punti di uscita sopra Router nell'uscita VPN viene assegnato un valore di preferenza basso (costo preferito) e hanno quindi la precedenza, mentre a tutti i punti di uscita sotto Router viene assegnato un valore di preferenza più elevato e risultano quindi meno preferiti.
- Ad esempio, quando è attivato il calcolo dei costi distribuito, tutte le route che appartengono a Punti di uscita VPN (VPN Exit Points) (Edge, Gateway partner o Hub) sopra Router ottengono un valore di preferenza inferiore a 1.000.000 e le route sotto Router ottengono un valore di preferenza superiore a 1.000.000.
- Nell'esempio seguente, i Punti di uscita VPN (VPN Exit Points) sopra Router, che sono NSD, Edge e Gateway partner riceveranno un valore di preferenza inferiore a 1.000.000 e Hub otterrà un valore di preferenza superiore a 1.000.000.
Aggiunta di una route per sostituire un valore di preferenza predefinito
- Un utente aggiunge una route nella pagina Controllo flusso overlay (Overlay Flow Control) eseguendo una delle operazioni seguenti:
- In Elenco route (Routes List), selezionare una o più route e quindi fare clic sull'opzione Aggiungi preferenza route acquisita (Pin Learned Route Preference).
- Modificare l'ordine delle Uscite VPN preferite (Preferred VPN Exits) facendo clic su Modifica (Edit) nella tabella.
- Orchestrator invia questo evento di routing agli Edge pertinenti dell'azienda del cliente.
- Gli Edge sostituiscono il valore di preferenza precedente in modo che corrisponda all'ordine aggiunto.
- I valori di preferenza assegnati alle route aggiunte iniziano da 1, 2, 3 e così via (i valori più bassi e quindi le preferenze più elevate), e questo corrisponde all'ordine delle route nella pagina Controllo flusso overlay (Overlay Flow Control).
Nota: Per ulteriori informazioni sull'aggiunta di una route, consultare Configurazione delle subnet.
Scenari di tie break per tutti i tipi di route
Che cosa succede quando un Edge riceve lo stesso prefisso per due o più origini o router adiacenti?
Uno scenario potenziale nelle distribuzioni di SD-WAN prevede che lo stesso prefisso venga annunciato da due Edge o gateway partner diversi. Con VMware SD-WAN, se le subnet appartengono alla stessa categoria (Edge, Hub o Gateway partner) e hanno lo stesso valore di preferenza, per l'ordinamento delle route vengono innanzitutto considerati gli attributi BGP o le metriche OSPF.
Se non è comunque possibile stabilire quale route preferire, SD-WAN utilizza l'ID logico, che deriva dall'UUID (Universally Unique Identifier) dell'Edge o del gateway, del dispositivo dell'hop successivo per decidere. Il dispositivo dell'hop successivo può essere un gateway o un Edge hub in base al tipo di VPN da filiale a filiale (Branch to Branch VPN) in uso. Se l'azienda del cliente utilizza la VPN da filiale a filiale tramite gateway, l'hop successivo è un gateway, mentre per un cliente che utilizza la VPN da filiale ad hub, l'hop successivo è un Edge hub.
Se più gateway annunciano lo stesso tipo di route e preferenza, esiste un criterio di selezione finale. Questo criterio di selezione finale preferisce la route meno recente acquisita. Per garantire il risultato di routing desiderato, è possibile bloccare determinate route o configurare gli attributi e i costi BGP in modo da favorire alcune route rispetto ad altre.
Vedere l'immagine seguente per un'illustrazione del calcolo delle preferenze e dell'ordinamento delle route dinamiche.
- Spoke1 e Spoke2 acquisiscono la route come route BGP (non di uplink).
- Hub1 e Hub2 acquisiscono le route come route BGP di uplink.
- Anche PG1 acquisisce la stessa route.
- Da filiale a filiale tramite Hub1 e Hub2 è abilitato nel profilo spoke.
- Poiché Spoke1 e Spoke2 acquisiscono la route come BGP, selezionano il valore del costo preferito (il valore della preferenza è definito costo in questa sezione) 1.003, in base alla tabella di mappatura delle preferenze DCC.
- La route 9.9.9.9/32 verrà installata nella FIB di Spoke1 e Spoke2 con un costo di riferimento di 1.000.000. Come sempre, la route underlay verrà installata in FIB solo con un costo di riferimento. Il costo o la preferenza derivati dalla tabella delle preferenze DCC sono destinati alle entità SD-WAN remote (Edge/Gateway) per l'ordinamento delle route.
- Spoke1 e Spoke2 ridistribuiscono la route su VCRP con un costo derivato di 1.003 al gateway e agli Edge/hub remoti. L'immagine di output seguente mostra il costo o la preferenza derivati negli spoke.
- Analogamente, Hub1 e Hub2 acquisiscono la route e ne derivano il costo non preferito (1.001.008), poiché acquisiscono la route come route di uplink. Gli hub ridistribuiscono la route ai gateway e agli altri Edge con questo costo. L'output seguente mostra il costo o la preferenza derivati negli hub.
- PG1 acquisisce la stessa route da BGP, utilizza Il costo 1.005 e lo ridistribuisce agli Edge. L'output seguente mostra il costo o la preferenza derivati in PG.
- Spoke1 riceve la route da Hub1 e Hub2 con il costo non preferito di 1.001.008. Spoke1 ha il costo preferito di 003. Di conseguenza, verrà preferita la route underlay di Spoke1 e le route Hub verranno installate sotto la route underlay (SB). All'interno delle route Hub, se la preferenza (costo) è la stessa, per l'ordinamento delle route vengono confrontati gli attributi BGP. Se anche gli attributi BGP sono uguali, per installare le route verrà utilizzato l'ordine degli hub.
- Spoke1 riceve una route da Spoke2 e PG1 con costi 1.003 e 1.005 rispettivamente. Poiché Spoke1 ha il costo preferito 1.003 e riceve route da Spoke2 e PG1 con un costo preferito (<100.000), Spoke1 aggiunge il costo di riferimento 1.000.000 al costo preferito in entrata e installa le route in FIB. In questo caso, la route di Spoke2 verrà installata con un costo di 1.001.003 e la route di PG1 verrà installata con un costo di 1.001.005.
- La stessa logica di ordinamento delle route viene applicata in Spoke2 o persino negli hub se acquisiscono la route come route non di uplink.
- Se non è presente alcuna route underlay acquisita in alcuna entità, non verrà apportata alcuna correzione alla preferenza o al costo della route ricevuta. Le route verranno installate in base alla preferenza o al costo ricevuti.
- Gli hub installano la propria route underlay (SB) con un costo di riferimento di 1.000.000 in FIB.
- Gli hub ricevono route spoke con un costo preferito di 1.003. Poiché il costo è lo stesso tra gli spoke, gli attributi BGP verranno confrontati e ordinati in base a tale valore. Se anche gli attributi BGP sono uguali, per l'ordinamento verrà utilizzato l'ID logico spoke (l'ID logico di destinazione più basso è prioritario rispetto al tie breaker). Le route dello spoke verranno installate con il costo ricevuto.
- L'Hub riceve la route di PG1 con il costo preferito. Viene quindi installato con tale costo.
- PG1 installa la propria route underlay (PB) con preferenza 100.000.
- PG1 riceve route spoke e route fi Hub con la preferenza corrispondente. Le route vengono posizionate in FIB in base al valore di preferenza. Se le preferenze sono uguali, vengono considerati gli attributi BGP. Se anche gli attributi sono uguali, per l'ordinamento verrà utilizzato l'ID logico.
- In PG non è presente alcuna preferenza/correzione dei costi.
- Se DCC non è abilitato, il verdetto dell'annuncio e il calcolo della preferenza vengono eseguiti da Orchestrator. Ogni entità (Edge o Gateway) invia le route acquisite a Orchestrator e prevede di ricevere una risposta da Orchestrator. Dopo aver ricevuto la risposta da Orchestrator, l'Edge o il Gateway inizia la ridistribuzione delle route ad altre entità SD-WAN se il flag di annuncio è "true" nella risposta.
- L'ordinamento delle route rimane invariato, come nel caso di DCC in fase di abilitazione, ma i valori di preferenza sono fissi in questo scenario in cui DCC viene disabilitato.
- La preferenza (costo) di riferimento è 512 per il calcolo della preferenza basato su Orchestrator. La preferenza (costo) < 512 è il costo preferito, mentre la preferenza (costo) > 512 viene assegnata alle route non preferite (route UPLINK, route esterne OSPF). L'altra logica di ordinamento delle route rimane quella di quando DCC è abilitato.
- Se Spoke2 acquisisce la route per primo e la invia a Orchestrator, Orchestrator inizierà ad assegnare la preferenza in base all'entità e al tipo di route. Poiché Spoke2 esegue l'acquisizione come non di uplink, Orchestrator assegnerà il valore della preferenza (ad esempio 64). Successivamente, quando Spoke1 invierà la stessa route a Orchestrator, Orchestrator confronterà l'entità, il tipo di route e gli attributi della route. Se è migliore, assegnerà la preferenza a < 64. Se è peggiore, assegnerà la preferenza a > 64.
- Gli hub acquisiscono le route come route di uplink e le inviano a Orchestrator. Orchestrator assegna un costo non preferito (> 512). In questo esempio, è 4.096. Se la preferenza è la stessa, per ordinare le route negli spoke verrà utilizzato l'ordine degli hub.
- Quando DCC è disabilitato, l'ordine delle route in Spoke1 (con una route non di uplink) sarà simile a quello dell'immagine seguente.
- L'ordine delle route negli hub con una route di uplink sarà simile a quello dell'immagine seguente.
- L'ordine delle route in PG sarà simile a quello dell'immagine seguente.
- Lunghezza del prefisso di rete.
- Route statiche NSD locali.
- NSD remoto statico.
- PG statico sicuro.
- La route statica PG a livello aziendale ha la priorità rispetto a quella statica PG a livello globale.
- Connesso/statico remoto.
- Il logical_id dell'Edge sarà il tie breaker (l'ID logico più alto ha la precedenza).
- Route dinamiche (Controllo flusso overlay (OFC) o basato sul calcolo dei costi distribuito (Distributed Cost Calculation)).
- L'ordinamento delle route dinamiche sarà basato sul valore di preferenza. La preferenza inferiore ha la precedenza.
- A differenza di un Edge, nel gateway non è presente alcuna preferenza per la correzione automatica. Per le route dinamiche, il gateway le installa con la preferenza ricevuta. La route locale verrà sempre installata con la preferenza di riferimento 1.000.000.
Nota: Per ulteriori informazioni sul calcolo della preferenza, vedere la sezione "Controllo flusso overlay (OFC) con calcolo dei costi distribuito (DCC)". - Statico PG non sicuro.
