Integrazione SDWAN con topologie di rete hub-spoke di Azure

Azure ExpressRoute

Gateway VPN di Azure

Rete virtuale di Azure

Questo articolo è destinato agli architetti di rete che vogliono progettare reti WAN (Software-Defined Wide Area Networks) per connettere le strutture locali tra loro e con Azure. Descrive un'architettura che consente ai clienti di Azure di usare gli investimenti esistenti nella piattaforma, creando sovrimpressioni SD-WAN globali efficienti oltre al backbone Microsoft.

Scenari applicabili

Le raccomandazioni contenute in questo articolo sono indipendenti dal fornitore e applicabili a qualsiasi tecnologia SD-WAN non Microsoft che soddisfi due prerequisiti di base:

Dipendenza da protocolli di tunneling che usano TCP (Transmission Control Protocol) o USER Datagram Protocol (UDP) come trasporto sottostante, ad esempio tramite ESP IPsec in modalità tunnel con NAT-Traversal.
Supporto BGP (Border Gateway Protocol) v4 per lo scambio di route con entità esterne. Nessun presupposto viene effettuato sul protocollo di routing usato dai dispositivi non Microsoft SD-WAN per scambiare informazioni di routing tra loro.

I clienti che rispettano queste raccomandazioni possono usare la tecnologia SD-WAN preferita per raggiungere gli obiettivi seguenti:

Integrare prodotti SD-WAN in una rete hub-spoke di Azure esistente, automatizzando lo scambio di route tra i dispositivi Azure Rete virtuale e SD-WAN.
Ottimizzare la connettività (sia per Azure che per i data center locali) per i rami con interruzioni Internet locali. La portata del backbone Microsoft, combinata con la sua capacità, la resilienza e i criteri di routing "patata fredda" suggerisce che può essere usato come componente a prestazioni elevate per sd-WAN globali.
Usare il backbone Microsoft per tutto il traffico da Azure ad Azure (tra aree e aree geografiche).
Usare le reti MPLS (Multi-Protocol-Label-Switching) esistenti come sottolay ad alte prestazioni. Può anche essere usato per sostituire una rete MPLS esistente in un approccio in più fasi che riduce al minimo l'effetto sull'azienda.

Le sezioni seguenti presuppongono che il lettore abbia familiarità con le nozioni di base del paradigmaSD-WAN e con l'architettura del backbone Microsoft. Il backbone Microsoft interconnette le aree di Azure tra loro e con la rete Internet pubblica.

Architettura

Le organizzazioni con presenza globale e un footprint di Azure in più aree usano in genere una combinazione di servizi di connettività per implementare le reti aziendali e per connettersi al backbone Microsoft:

I servizi di connettività dedicati, ad esempio MPLS Internet-Protocol-Virtual-Private-Networks (IPVPN), possono essere usati nei siti più grandi, ad esempio data center o sedi centrali.
I siti di grandi dimensioni possono includere connettività dedicata al backbone Microsoft tramite circuiti ExpressRoute, usando uno dei modelli di connettività supportati. In particolare, un sito può usare circuiti da punto a punto dedicati per connettersi alla posizione di peering ExpressRoute più vicina. In alternativa, può applicare il proprio IPVPN MPLS per accedere ai circuiti ExpressRoute forniti dal gestore MPLS.
Le succursali con connettività Internet possono usare vpn IPsec per connettersi al data center locale più vicino e usare la connessione ExpressRoute del data center per accedere alle risorse di Azure. In alternativa, è possibile usare VPN IPsec per connettersi direttamente alle reti hub e spoke di Azure.

I progetti SD-WAN possono avere ambiti diversi in termini di servizi di rete tradizionali da sostituire. Alcune organizzazioni potrebbero voler attenersi a collegamenti dedicati o MPLS per strutture di grandi dimensioni e distribuire un SD-WAN solo per sostituire vpn IPsec basate su Internet legacy in siti di piccole dimensioni. Altre organizzazioni potrebbero voler estendere la rete SD-WAN ai siti connessi a MPLS e usare la rete MPLS esistente come componente con prestazioni elevate. Infine, alcune organizzazioni potrebbero voler ignorare i MPLS IPVPN. o qualsiasi servizio di connettività dedicato, per adottare il paradigma SD-WAN. In questo modo, possono creare l'intera rete aziendale come sovrimpressione logica su sottolay pubblici o condivisi (la rete Internet pubblica e il backbone Microsoft).

L'architettura descritta in questo articolo supporta tutti gli ambiti elencati in precedenza ed è basata sui principi seguenti:

I dispositivi SD-WAN vengono distribuiti come appliance virtuali di rete (APPLIANCE virtuali di rete) nella rete hub e spoke di ogni area di Azure e configurati come hub SD-WAN che terminano i tunnel dai siti locali.
I dispositivi SD-WAN in Azure sono configurati per stabilire tunnel l'uno con l'altro, creando così una sovrimpressione da hub a hub completamente mesh in grado di trasportare in modo efficiente il traffico tra aree di Azure e inoltrare il traffico tra siti locali geograficamente distanti, oltre al backbone Microsoft.
I dispositivi SD-WAN vengono distribuiti in tutti i siti locali coperti dalla soluzione SD-WAN e configurati per stabilire tunnel per le appliance virtuali di rete SD-WAN nelle aree di Azure più vicine. Diversi siti possono usare servizi di trasporto diversi come sottosezione per i tunnel, ad esempio internet pubblico, connettività ExpressRoute e così via.
Il traffico da un sito a qualsiasi destinazione, sia in Azure che in un altro sito locale, viene instradato alle appliance virtuali di rete SD-WAN nell'area di Azure più vicina. Quindi instrada attraverso la sovrimpressione da hub a hub.

I prodotti SD-WAN possono usare protocolli e funzionalità proprietari per rilevare, una volta stabiliti dinamicamente, i tunnel diretti tra due siti possono offrire prestazioni migliori rispetto all'inoltro del traffico tramite appliance virtuali di rete SD-WAN in Azure.

L'architettura generale di una rete SD-WAN globale che usa il backbone Microsoft, la rete Internet pubblica e le connessioni ER dedicate come sottolivello è illustrata nell'immagine seguente.

Figura 1: Architettura generale di un SD-WAN globale che usa il backbone Microsoft, la rete Internet pubblica e le connessioni ER dedicate come componenti sottostanti. La linea tratteggiata nera mostra come il traffico tra due siti locali può essere instradato attraverso SD-WAN appliance virtuali di rete distribuite in aree di Azure geograficamente vicine ai siti. Il backbone Microsoft, a causa della sua portata, della capacità e dei criteri di routing "patata fredda" può portare a prestazioni notevolmente migliori/prevedibili rispetto a Internet pubblico, soprattutto per le connessioni a lungo raggio.

Prodotti SD-WAN nelle reti hub-spoke di Azure

Questa sezione fornisce suggerimenti per la distribuzione di dispositivi CPE non Microsoft SD-WAN come appliance virtuali di rete in una rete di Azure hub e spoke esistente.

Appliance virtuali di rete SD-WAN nella rete virtuale hub

Hub e Spoke è la topologia consigliata da Microsoft per la creazione di reti scalabili in un'area di Azure usando reti virtuali gestite dal cliente. La rete virtuale hub ospita componenti condivisi come appliance virtuali di rete non Microsoft e servizi nativi che forniscono funzioni di rete, ad esempio firewall, bilanciamento del carico e connettività ai siti locali tramite VPN da sito a 2 siti o ExpressRoute. La rete virtuale hub è la posizione naturale per le appliance virtuali di rete SD-WAN, che in definitiva sono gateway non Microsoft che forniscono l'accesso alle reti remote.

Le appliance virtuali di rete SD-WAN devono essere distribuite nelle reti virtuali hub come indicato di seguito:

Un singolo controller di interfaccia di rete (NIC) viene usato per tutto il traffico SD-WAN. È possibile aggiungere altre schede di interfaccia di rete, ad esempio una scheda di interfaccia di rete di gestione, per soddisfare i requisiti di sicurezza e conformità o per rispettare le linee guida del fornitore per le distribuzioni di Azure.
La scheda di interfaccia di rete usata per il traffico SD-WAN deve essere collegata a una subnet dedicata. Le dimensioni della subnet devono essere definite in base al numero di appliance virtuali di rete SD-WAN distribuite per soddisfare i requisiti di disponibilità elevata e scalabilità o velocità effettiva, descritti più avanti in questo articolo.
I gruppi di sicurezza di rete (NSG) devono essere associati alla scheda di interfaccia di rete del traffico SD-WAN, direttamente o a livello di subnet. Questa associazione consente le connessioni da siti locali remoti sulle porte TCP/UDP usate dalla soluzione SD-WAN.
L'inoltro IP deve essere abilitato nella scheda di interfaccia di rete usata per il traffico SD-WAN.

Server di route di Azure nella rete virtuale hub

Il server di route di Azure automatizza lo scambio di route tra appliance virtuali di rete SD-WAN e lo stack SDN (Software Defined Networking) di Azure. Il server di route supporta BGP come protocollo di routing dinamico. Stabilendo le ajacenciE BGP tra il server di route e le appliance virtuali di rete SD-WAN:

Le route per tutti i siti locali connessi alla rete SD-WAN vengono inserite nelle tabelle di route della rete virtuale e apprese da tutte le macchine virtuali di Azure.
Le route per tutti i prefissi IP inclusi nello spazio indirizzi delle reti virtuali vengono propagate a tutti i siti connessi a SD-WAN.

Il server di route deve essere configurato come segue.

Deve essere distribuito in una subnet dedicata nella rete virtuale hub in base alla procedura creare e configurare il server di route usando il portale di Azure.
Per abilitare lo scambio di route automatizzato per tutte le reti virtuali spoke, il peering di rete virtuale deve essere configurato per consentire alle reti virtuali spoke di usare il gateway e il server di route della rete virtuale hub. Informazioni dettagliate disponibili nelle domande frequenti sul server di route di Azure.
Poiché i server di route e le appliance virtuali di rete SD-WAN sono collegati a subnet diverse, le sessioni BGP tra il server di route e le appliance virtuali di rete SD-WAN devono essere configurate con il supporto multihop eBGP. È possibile impostare un numero qualsiasi di hop compreso tra 2 e il massimo supportato dall'appliance virtuale di rete SD-WAN. I dettagli sulla configurazione degli ajacenci BGP per il server di route sono disponibili in Creare e configurare il server di route tramite il portale di Azure.
È necessario configurare due /32 route statiche nell'appliance virtuale di rete SD-WAN per gli endpoint BGP esposti dal server di route. Questa configurazione garantisce che la tabella di route dell'appliance virtuale di rete contenga sempre route per i peer BGP multihop (non direttamente connessi).

Il server di route non si trova nel percorso dati. Si tratta di un'entità del piano di controllo. Propaga le route tra l'appliance virtuale di rete SD-WAN e lo stack SDN della rete virtuale, ma l'inoltro effettivo del traffico tra l'appliance virtuale di rete SD-WAN e le macchine virtuali nella rete virtuale viene eseguito dallo stack SDN di Azure, come illustrato nella figura seguente. Per ottenere questo comportamento di routing, il server di route inserisce tutte le route apprese dalle appliance virtuali di rete SD-WAN con hop successivo impostato sul proprio indirizzo dell'appliance virtuale di rete.

Il server di route non supporta ora IPv6. Questa architettura è solo per IPv4.

Figura 2. Il server di route supporta la propagazione delle route tra il cpe SD-WAN e lo stack SDN della rete virtuale, ma non inoltra il traffico tra il cpe SD-WAN e le macchine virtuali nella rete virtuale.

Disponibilità elevata per appliance virtuali di rete SD-WAN con server di route

Il server di route ha disponibilità elevata incorporata. Due nodi di calcolo tornano a una singola istanza del server di route. Vengono distribuiti in zone di disponibilità diverse, per le aree con supporto della zona di disponibilità o nello stesso set di disponibilità. Espongono due endpoint BGP. La disponibilità elevata per le appliance virtuali di rete SD-WAN viene ottenuta distribuendo più istanze in zone di disponibilità diverse, per le aree che le supportano o nello stesso set di disponibilità. Ogni appliance virtuale di rete SD-WAN stabilisce due sessioni BGP con entrambi gli endpoint esposti dal server di route.

L'architettura descritta in questo articolo non si basa su Azure Load Balancer. In particolare:

Nessun servizio di bilanciamento del carico pubblico espone gli endpoint del tunnel SD-WAN. Ogni appliance virtuale di rete SD-WAN espone il proprio endpoint del tunnel. I peer remoti stabiliscono più tunnel, uno per ogni appliance virtuale di rete SD-WAN in Azure.
Nessun servizio di bilanciamento del carico interno distribuisce il traffico originato dalle macchine virtuali di Azure alle appliance virtuali di rete SD-WAN. Il server di route e lo stack SDN di Azure supportano il routing ECMP (Equal-Cost Multipath). Se più appliance virtuali di rete configurano gli ajacenci BGP con il server di route e annunciano le route per le stesse destinazioni (come in, reti remote e siti connessi alla rete SD-WAN) usando lo stesso grado di preferenza, Route Server:
- Inserisce più route per tali destinazioni nella tabella di route della rete virtuale.
- Imposta ogni route per usare un'appliance virtuale di rete diversa come hop successivo.

Lo stack SDN distribuisce quindi il traffico a tali destinazioni in tutti gli hop successivi disponibili.

L'architettura a disponibilità elevata risultante è illustrata nella figura seguente:

Figura 3. Il server di route supporta Equal-Cost routing Multipath (ECMP). I servizi di bilanciamento del carico di Azure non sono necessari quando più appliance virtuali di rete di SD-WAN vengono usate a scopo di disponibilità e/o scalabilità.

Disponibilità elevata di N-active e active stand-by

Quando si usano più appliance virtuali di rete SD-WAN ed eseguirne il peering con il server di route, BGP determina il failover. Se un'appliance virtuale di rete SD-WAN passa offline, interrompe le route pubblicitarie al server di route. Le route apprese dal dispositivo non riuscito vengono quindi ritirate dalla tabella di route della rete virtuale. Pertanto, se un'appliance virtuale di rete SD-WAN non fornisce più connettività ai siti SD-WAN remoti a causa di un errore, nel dispositivo stesso o nel sottosezione, non viene più visualizzato come hop successivo possibile verso i siti remoti nella tabella di route della rete virtuale. Tutto il traffico passa ai dispositivi integri rimanenti. Per altre informazioni sulla propagazione delle route tra SD-WAN appliance virtuali di rete e server di route, vedere Route annunciate da un peer BGP al server di route.

Figura 4. Failover basato su BGP. Se SD-WAN NVA #0 diventa offline, le sessioni BGP con il server di route si chiudono. SD-WAN'appliance virtuale di rete #0 viene rimossa dalla tabella di route della rete virtuale come possibile hop successivo per il traffico che passa da Azure al sito locale.

Il failover guidato da BGP e il routing ECMP abilitano naturalmente le architetture a disponibilità elevata attive con N dispositivi che elaborano simultaneamente il traffico. Tuttavia, è anche possibile usare BGP per implementare architetture a disponibilità elevata attive e passive: configurare il dispositivo passivo per annunciare a Route Server le route con un livello di preferenza inferiore rispetto al peer attivo. Il server di route elimina le route ricevute dal dispositivo passivo se riceve dal dispositivo attivo qualsiasi route per le stesse destinazioni con un livello di preferenza superiore. E esegue il plumbing solo delle ultime route nella tabella di route della rete virtuale.

Se il dispositivo attivo non riesce o ritira alcune delle relative route, il server di route:

Seleziona le route corrispondenti annunciate dal dispositivo passivo.
Esegue il plumbing delle route nella tabella di route della rete virtuale.

Gli unici attributi BGP che le appliance virtuali di rete SD-WAN possono usare per esprimere un grado di preferenza per le route annunciate a Route Server è As Path.

È consigliabile usare le architetture a disponibilità elevata attive di N perché consentono l'uso ottimale delle risorse (non sono disponibili appliance virtuali di rete SD-WAN) e scalabilità orizzontale. Per aumentare la velocità effettiva, più appliance virtuali di rete possono essere eseguite in parallelo, fino al numero massimo di peer BGP supportati dal server di route. Per altre informazioni, vedere Peer BGP. Tuttavia, il modello a disponibilità elevata attiva N richiede che le appliance virtuali di rete SD-WAN funzionino come router senza stato, di livello 3. Quando esistono più tunnel a un sito, è possibile instradare le connessioni TCP in modo asimmetrico. Ovvero, i flussi ORIGINAL e REPLY della stessa connessione TCP possono essere instradati attraverso tunnel diversi e diverse appliance virtuali di rete. La figura seguente mostra un esempio di connessione TCP instradata asimmetricamente. Tali asimmetri di routing sono possibili per le connessioni TCP avviate nella rete virtuale o nel sito locale.

Figura 5. Routing asimmetrico nelle architetture a disponibilità elevata attiva/attiva. SD-WAN NVA #0 e SD-WAN NVA #1 annunciano la stessa route per la destinazione 192.168.1.0/24 (sito SD-WAN remoto) con la stessa lunghezza del percorso AS al server di route. Il flusso ORIGINALE (da SD-WAN sito remoto ad Azure, percorso rosso) viene instradato tramite il tunnel terminato, sul lato Azure, da SD-WAN NVA #1. L'SD-WAN CPE locale seleziona questo tunnel. Lo stack SDN di Azure instrada il flusso REPLY (da Azure a sito di SD-WAN remoto, percorso verde) a SD-WAN NVA #0, che è uno dei possibili hop successivi per 192.168.1.0/24, in base alla tabella di route della rete virtuale. Non è possibile garantire che l'hop successivo scelto dallo stack SDN di Azure sia sempre lo stesso SD-WAN CPE che ha ricevuto il flusso ORIGINAL.

Le architetture a disponibilità elevata attive e passive devono essere considerate solo quando le appliance virtuali di rete SD-WAN in Azure eseguono altre funzioni di rete che richiedono la simmetria di routing, ad esempio il firewall con stato. Questo approccio non è consigliato a causa delle implicazioni sulla scalabilità. L'esecuzione di più funzioni di rete nelle appliance virtuali di rete SD-WAN aumenta il consumo di risorse. Allo stesso tempo, l'architettura a disponibilità elevata attiva e passiva consente di avere un singolo traffico di elaborazione dell'appliance virtuale di rete in qualsiasi momento. Ovvero, l'intero livello SD-WAN può essere ridimensionato solo fino alle dimensioni massime di macchine virtuali di Azure supportate, non con scalabilità orizzontale. Eseguire funzioni di rete con stato che richiedono la simmetria del routing in cluster di appliance virtuali di rete separati che si basano su Load Balancer Standard per la disponibilità elevata n-attiva.

Considerazioni sulla connettività di ExpressRoute

L'architettura descritta in questo articolo consente ai clienti di adottare completamente il paradigma SD-WAN e di creare la propria rete aziendale come sovrimpressione logica sulla rete Internet pubblica e sul backbone Microsoft. Supporta anche l'uso di circuiti Expressroute dedicati per gestire scenari specifici, descritti più avanti.

Scenario 1: Coesistenza di ExpressRoute e SD-WAN

Le soluzioni SD-WAN possono coesistere con la connettività ExpressRoute quando i dispositivi SD-WAN vengono distribuiti solo in un subset di siti. Ad esempio, alcune organizzazioni potrebbero distribuire SD-WAN soluzioni come sostituzione delle VPN IPsec tradizionali nei siti solo con connettività Internet. Quindi usano i servizi MPLS e i circuiti ExpressRoute per siti e data center di grandi dimensioni, come illustrato nella figura seguente.

Figura 6. SD-WAN soluzioni possono coesistere con la connettività ExpressRoute quando SD-WAN dispositivi CPE vengono distribuiti solo in un subset di siti.

Questo scenario di coesistenza richiede che le appliance virtuali di rete SD-WAN distribuite in Azure siano in grado di instradare il traffico tra siti connessi alla rete SD-WAN e ai siti connessi ai circuiti ExpressRoute. Il server di route può essere configurato per propagare le route tra i gateway di rete virtuale ExpressRoute e le appliance virtuali di rete di SD-WAN in Azure abilitando la AllowBranchToBranch funzionalità, come documentato qui. La propagazione delle route tra il gateway di rete virtuale ExpressRoute e le appliance virtuali di rete SD-WAN avviene tramite BGP. Il server di route stabilisce sessioni BGP con e propaga a ogni peer le route apprese dall'altra. La piattaforma gestisce le sessioni BGP tra il server di route e il gateway di rete virtuale ExpressRoute. Gli utenti non devono configurarli in modo esplicito, ma solo per abilitare il flag durante la AllowBranchToBranch distribuzione del server di route.

Figura 7. La propagazione della route tra il gateway di rete virtuale ExpressRoute e le appliance virtuali di rete SD-WAN avviene tramite BGP. Il server di route stabilisce sessioni BGP con entrambe le route e propaga le route in entrambe le direzioni se configurate con "AllowBranchToBranch=TRUE". Il server di route funge da riflettore di route, ovvero non fa parte del percorso dati.

Questo scenario di coesistenza SD-WAN e ExpressRoute consente migrazioni da reti MPLS a SD-WAN. Offre un percorso tra i siti MPLS legacy e i siti SD-WAN appena migrati, eliminando la necessità di instradare il traffico attraverso data center locali. Questo modello può essere usato non solo durante le migrazioni, ma anche in scenari derivanti da fusioni e acquisizioni aziendali, fornendo un'interconnessione senza interruzioni di reti diverse.

Scenario 2: Expressroute come sottosezione SD-WAN

Se i siti locali hanno connettività ExpressRoute, è possibile configurare i dispositivi SD-WAN per configurare i tunnel per le appliance virtuali di rete dell'hub SD-WAN in esecuzione in Azure sopra il circuito ExpressRoute o i circuiti. La connettività ExpressRoute può essere eseguita tramite circuiti da punto a punto o una rete MPLS. È possibile usare sia il peering privato ExpressRoute che il peering Microsoft.

Peering privato

Quando si usa il peering privato di ExpressRoute come componente aggiuntivo, tutti i siti SD-WAN locali stabiliscono tunnel per le appliance virtuali di rete dell'hub SD-WAN in Azure. In questo scenario non è necessaria alcuna propagazione delle route tra le appliance virtuali di rete di SD-WAN e il gateway di rete virtuale ExpressRoute, ovvero il server di route deve essere configurato con il flag "AllowBranchToBranch" impostato su false.

Questo approccio richiede una configurazione BGP appropriata nei router lato cliente o provider che terminano la connessione ExpressRoute. Infatti, i router Microsoft Enterprise Edge (MSEE) annunciano tutte le route per le reti virtuali connesse al circuito (direttamente o tramite peering di rete virtuale). Tuttavia, per inoltrare il traffico destinato alle reti virtuali attraverso un tunnel SD-WAN, il sito locale deve apprendere tali route dal dispositivo SD-WAN, non dal circuito ER.

Di conseguenza, i router lato cliente o lato provider che terminano la connessione ExpressRoute devono filtrare le route ricevute da Azure. Le uniche route configurate nel componente inferiore devono essere quelle che consentono ai dispositivi SD-WAN locali di raggiungere le appliance virtuali di rete dell'hub SD-WAN in Azure. I clienti che vogliono usare il peering privato di ExpressRoute come underlay SD-WAN devono verificare che possano configurare i dispositivi di routing di conseguenza. Questa operazione è particolarmente rilevante per i clienti che non hanno il controllo diretto sui dispositivi perimetrali per ExpressRoute. Un esempio è quando il circuito ExpressRoute viene fornito da un gestore telefonico MPLS sopra un servizio IPVPN.

Figura 8. Peering privato di ExpressRoute come SD-WAN sottosezione. In questo scenario, i router lato cliente e provider ricevono le route per la rete virtuale che terminano la connessione ExpressRoute, nelle sessioni BGP di peering privato ER e il CPE SD-WAN. Solo l'SD-WAN CPE deve propagare le route di Azure nella LAN del sito.

Peering Microsoft

È anche possibile usare il peering Microsoft ExpressRoute come sottofondo per i tunnel SD-WAN. In questo scenario, le appliance virtuali di rete dell'hub SD-WAN in Azure espongono solo endpoint del tunnel pubblico, che vengono usati dalle CPU SD-WAN nei siti connessi a Internet, se presenti, e dalle CPU SD-WAN nei siti connessi a Expressroute. Anche se il peering Microsoft ExpressRoute presenta prerequisiti più complessi rispetto al peering privato, è consigliabile usare questa opzione come sottofondo a causa di questi due vantaggi:

Non richiede gateway di rete virtuale Expressroute nella rete virtuale hub. Rimuove la complessità, riduce i costi e consente la scalabilità della soluzione SD-WAN oltre i limiti di larghezza di banda del gateway stesso quando non si usa ExpressRoute FastPath.
Fornisce una separazione pulita tra le route sovrapposte e di sottofondo. Gli account del servizio gestito annunciano solo i prefissi pubblici della rete Microsoft al cliente o al perimetro del provider. È possibile gestire tali route in un VRF separato e propagare solo a un segmento di rete perimetrale della LAN del sito. I dispositivi SD-WAN propagano le route per la rete aziendale del cliente nella sovrimpressione, incluse le route per le reti virtuali. I clienti che prendono in considerazione questo approccio devono verificare che possano configurare i dispositivi di routing di conseguenza o richiedere il servizio appropriato al gestore MPLS.

Considerazioni su MPLS

La migrazione dalle reti aziendali MPLS tradizionali alle architetture di rete più moderne basate sul paradigma SD-WAN richiede un impegno significativo e una notevole quantità di tempo. L'architettura descritta in questo articolo abilita le migrazioni SD-WAN in più fasi. In seguito vengono illustrati due scenari di migrazione tipici.

Rimozione graduale delle autorizzazioni MPLS

I clienti che vogliono creare un SD-WAN sulla rete Internet pubblica e sul backbone Microsoft e rimuovere completamente le autorizzazioni ipVPN MPLS o altri servizi di connettività dedicati possono usare ExpressRoute e SD-WAN scenario di coesistenza descritto nella sezione precedente durante la migrazione. Consente ai siti connessi a SD-WAN di raggiungere i siti ancora connessi al modello MPLS legacy. Non appena viene eseguita la migrazione di un sito ai dispositivi SD-WAN e CPE, il collegamento MPLS può essere rimosso. Il sito può accedere all'intera rete aziendale tramite i tunnel SD-WAN alle aree di Azure più vicine.

Figura 9. Lo scenario "ExpressRoute e SD-WAN coesistenza" consente la rimozione graduale delle autorizzazioni MPLS.

Quando viene eseguita la migrazione di tutti i siti, l'IPVPN MPLS può essere rimosso, insieme ai circuiti ExpressRoute che lo connettono al backbone Microsoft. I gateway di rete virtuale ExpressRoute non sono più necessari e possono essere deprovisioning. Le appliance virtuali di rete dell'hub SD-WAN in ogni area diventano l'unico punto di ingresso nella rete hub-spoke di tale area.

Integrazione di MPLS

Le organizzazioni che non considerano attendibili le reti pubbliche e condivise per fornire le prestazioni e l'affidabilità desiderate potrebbero decidere di usare una rete MPLS esistente come componente di livello aziendale. Sono disponibili due opzioni:

Subset di siti come data center o succursali di grandi dimensioni.
Sottoinsieme di connessioni, in genere traffico critico o sensibile alla latenza.

Lo scenario Expressroute come SD-WAN sottoscrizioni descritto in precedenza abilita l'integrazione di SD-WAN e MPLS. Il peering Microsoft ExpressRoute deve essere preferito rispetto al peering privato per i motivi descritti in precedenza. Inoltre, quando viene usato il peering Microsoft, la rete MPLS e la rete Internet pubblica diventano equivalenti dal punto di vista funzionale. Forniscono l'accesso a tutti gli endpoint del tunnel SD-WAN esposti dalle appliance virtuali di rete dell'hub SD-WAN in Azure. Un CPE SD-WAN distribuito in un sito con connettività Internet e MPLS può stabilire più tunnel per gli hub SD-WAN in Azure in entrambi i componenti. Possono quindi instradare connessioni diverse attraverso tunnel diversi, in base ai criteri a livello di applicazione gestiti dal piano di controllo SD-WAN.

Figura 10. Lo scenario "ExpressRoute as an SD-WAN underlay" (ExpressRoute as an SD-WAN underlay) consente l'integrazione di SD-WAN e MPLS.

Preferenza di routing del server di route

In entrambi gli scenari MPLS illustrati nelle due sezioni precedenti, alcuni siti di succursale possono essere connessi sia all'IPVPN MPLS che alla SD-WAN. Di conseguenza, le istanze del server di route distribuite nelle reti virtuali hub possono apprendere le stesse route dai gateway ExpressRoute e dalle appliance virtuali di rete SD-WAN. La preferenza di routing del server di route consente di controllare quale percorso deve essere preferito e idraulico nelle tabelle di route delle reti virtuali. La preferenza di routing è utile quando non è possibile usare il percorso AS in sospeso. Un esempio è rappresentato dai servizi IPVPN MPLS che non supportano configurazioni BGP personalizzate nei PEs che terminano le connessioni ExpressRoute.

Considerazioni sulla progettazione e i limiti del server di route

Il server di route è la pietra angolare dell'architettura descritta in questo articolo. Propaga le route tra le appliance virtuali di rete SD-WAN distribuite nelle reti virtuali e lo stack SDN di Azure sottostante. Offre un approccio basato su BGP per l'esecuzione di più appliance virtuali di rete SD-WAN per la disponibilità elevata e la scalabilità orizzontale. Quando si progettano SD-WANs di grandi dimensioni in base a questa architettura, è necessario considerare i limiti di scalabilità del server di route.

Le sezioni seguenti forniscono indicazioni sui massimi di scalabilità e su come gestire ogni limite.

Route annunciate da un peer BGP al server di route

Il server di route non definisce un limite esplicito per il numero di route che possono essere annunciate a ExpressRoute Rete virtuale Gateway quando viene impostato il AllowBranchToBranch flag. Tuttavia, i gateway ExpressRoute propagano ulteriormente le route apprese dal server di route ai circuiti ExpressRoute a cui sono connessi.

Esiste un limite al numero di route che i gateway ExpressRoute possono annunciare ai circuiti ExpressRoute tramite il peering privato, documentati in sottoscrizione di Azure e limiti, quote e vincoli del servizio. Quando si progettano soluzioni SD-WAN in base alle indicazioni contenute in questo articolo, è fondamentale assicurarsi che le route SD-WAN non causino questo limite. In caso di riscontri, le sessioni BGP tra i gateway ExpressRoute e i circuiti ExpressRoute vengono eliminate e la connettività tra reti virtuali e reti remote connesse tramite ExpressRoute viene persa.

Il numero totale di route annunciate ai circuiti dai gateway ExpressRoute è la somma del numero di route apprese dal server di route e il numero di prefissi che costituiscono lo spazio indirizzi della rete hub di Azure e spoke. Per evitare interruzioni a causa di sessioni BGP eliminate, è consigliabile implementare le mitigazioni seguenti:

Usare le funzionalità dei dispositivi SD-WAN native per limitare il numero di route annunciate al server di route, se la funzionalità è disponibile.
Usare gli avvisi di Monitoraggio di Azure per rilevare in modo proattivo i picchi nel numero di route annunciate dai gateway ExpressRoute. La metrica da monitorare è denominata Conteggio delle route annunciate al peer, come documentato nel monitoraggio di ExpressRoute.

Peer BGP

Il server di route può stabilire sessioni BGP con un massimo di peer BGP. Questo limite determina il numero massimo di appliance virtuali di rete SD-WAN che possono stabilire adacenci BGP con il server di route e quindi la velocità effettiva di aggregazione massima che può essere supportata in tutti i tunnel SD-WAN. È previsto che questo limite venga raggiunto solo da SD-WAN di grandi dimensioni. Non esistono soluzioni alternative per superarlo, oltre alla creazione di più reti hub-spoke, ognuna con i propri gateway e server di route.

Vm partecipanti

Rete virtuale Gateway e Server di route configurano le route apprese dai peer remoti per tutte le macchine virtuali nella propria rete virtuale e nelle reti virtuali con peering diretto. Per proteggere il server di route dall'eccessivo consumo di risorse dovuto al routing degli aggiornamenti alle macchine virtuali, Azure definisce un limite per il numero di macchine virtuali che possono esistere in una singola rete hub-spoke. Non esistono soluzioni alternative per superare questo limite, oltre alla creazione di più reti hub-spoke, ognuna con i propri gateway e server di route, nella stessa area.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Federico Guerrini - Italia | Architetto senior di soluzioni cloud
Sh Kaviraj | Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Microsoft Well-Architected Framework