Integrazione SD-WAN con topologie di rete hub-and-spoke di Azure

Questo articolo descrive come progettare reti WAN definite dal software (SD-WANs) che connettono i data center locali tra loro e con Azure. Presenta un'architettura che consente ai clienti di Azure di usare i propri investimenti esistenti nella piattaforma creando sovrimpressioni di SD-WAN globali efficienti oltre al backbone Microsoft.

Scenari applicabili

Le raccomandazioni contenute in questo articolo sono indipendenti dal fornitore e applicabili alle tecnologie SD-WAN che soddisfano due prerequisiti di base:

  • I tunnel che utilizzano il Transmission Control Protocol (TCP) o il User Datagram Protocol (UDP) come trasporto di base, ad esempio IPsec Encapsulating Security Payload (ESP) in modalità tunnel con attraversamento della traduzione degli indirizzi di rete (NAT traversal), implementano l'overlay SD-WAN.

  • Border Gateway Protocol (BGP) v4 scambia le route tra i dispositivi edge SD-WAN e le reti collegate all'SD-WAN. Non vengono fatte ipotesi sul protocollo di routing usato dai dispositivi perimetrali SD-WAN per scambiare informazioni di routing.

È possibile usare SD-WAN prodotti che soddisfano questi prerequisiti per raggiungere gli obiettivi seguenti:

  • Connetti le reti hub-and-spoke di Azure alle reti SD-WAN che si estendono tra ambienti cloud e infrastrutture locali, con scambio dinamico di route tra le reti virtuali di Azure e i dispositivi edge SD-WAN.

  • Ottimizzare la connettività a Azure e ai data center locali per i rami con interruzioni Internet locali. L’estensione del backbone Microsoft, combinata con la sua capacità, resilienza e il criterio di instradamento cold potato, può farne un’infrastruttura sottostante ad alte prestazioni per le SD-WAN globali.

  • Usare il backbone Microsoft per tutto il traffico da Azure a Azure (tra aree e aree geografiche).

  • Usare le reti MPLS (MultiProtocol Label Switching) esistenti come sottolay ad alte prestazioni.

  • Passare dalle reti MPLS alla connettività Internet in un approccio graduale che riduce al minimo l'effetto sull'azienda.

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

Architecture

Le organizzazioni che hanno una presenza globale e un footprint Azure multiregione usano più servizi di connettività per creare le reti aziendali e connettersi al backbone Microsoft.

  • I servizi di connettività dedicati, ad esempio le reti private virtuali IPMPLS (IPVPN), vengono in genere distribuiti nei siti più grandi.

  • I circuiti Azure ExpressRoute si connettono al backbone Microsoft tramite le infrastrutture dei data center usando il modello di connettività da punto a punto o direttamente alla rete MPLS usando il modello di connettività any-to-any.

  • 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 Azure. Oppure possono usare VPN IPsec per connettersi direttamente alle reti hub-spoke Azure.

I progetti SD-WAN possono differire per quanto riguarda i servizi di connettività che intendono sostituire. Alcune organizzazioni potrebbero voler continuare a usare collegamenti dedicati o MPLS per strutture di grandi dimensioni e distribuire 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. Alcune organizzazioni potrebbero anche ritirare la rete MPLS e creare l'intera rete aziendale come sovrimpressione logica sopra i sottolay pubblici o condivisi, ad esempio la rete Internet pubblica e il backbone Microsoft.

L'architettura supporta tutti gli ambiti di questo articolo ed è basata sui principi seguenti:

  • I dispositivi SD-WAN vengono distribuiti come appliance virtuali di rete (NVA) nella rete hub-and-spoke di ogni regione di Azure e configurati come hub SD-WAN che terminano i tunnel provenienti dai siti on-premises.

  • I dispositivi SD-WAN in Azure sono configurati per stabilire tunnel tra loro e creare un overlay hub-to-hub full mesh che trasporta in modo efficiente il traffico tra le regioni di Azure. Questa rete overlay inoltra anche il traffico tra siti locali on-premises geograficamente distanti tramite il backbone di Microsoft.

  • I dispositivi SD-WAN vengono distribuiti in tutte le sedi locali coperte dalla soluzione SD-WAN e sono configurati per stabilire tunnel verso le NVA SD-WAN nell'area di Azure più vicina o nelle aree di Azure più vicine. Diversi siti possono usare servizi di trasporto underlay diversi, ad esempio la connettività Internet pubblica o ExpressRoute.

  • Il traffico proveniente da un sito viene instradato verso le NVA SD-WAN nell'area di Azure più vicina, indipendentemente dal fatto che la destinazione sia in Azure o in un altro sito on-premises. Il traffico attraversa quindi la rete overlay tra hub.

SD-WAN prodotti possono usare protocolli e funzionalità proprietari per creare tunnel diretti tra due siti e ottenere prestazioni migliori rispetto all'inoltro del traffico attraverso appliance virtuali di rete SD-WAN in Azure.

Il diagramma seguente illustra l'architettura generale di un SD-WAN globale che usa il backbone Microsoft, la rete Internet pubblica e le connessioni ExpressRoute dedicate come sottolay.

Diagramma che mostra l'architettura SD-WAN di alto livello.

Scaricare un file PowerPoint di questa architettura.

Connettere le reti hub-and-spoke di Azure alle reti SD-WAN

Questa sezione fornisce raccomandazioni per la distribuzione di dispositivi perimetrali SD-WAN come appliance virtuali di rete (NVA) in una rete Azure hub-and-spoke esistente.

Apparati virtuali di rete SD-WAN nella rete virtuale hub

È consigliabile usare la topologia hub-spoke per la creazione di reti scalabili in un'area Azure usando reti virtuali gestite dal cliente. La rete virtuale hub ospita componenti condivisi come appliance virtuali di rete e servizi nativi che forniscono funzioni di rete, ad esempio firewall, bilanciamento del carico e connettività ai siti locali tramite VPN da sito a sito o ExpressRoute. La rete virtuale hub è la posizione logica per le appliance virtuali di rete SD-WAN perché centralizza le funzioni di rete condivise e fornisce accesso coerente alle reti remote. Queste appliance virtuali di rete (NVA) sono gateway non Microsoft che collegano l'hub a quelle reti remote.

Distribuire le NVA SD-WAN nelle reti virtuali dell'hub nei modi seguenti:

  • Usare un controller di interfaccia di rete (NIC) 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 seguire le linee guida del fornitore per le distribuzioni Azure.

  • Collegare la scheda di rete utilizzata per il traffico SD-WAN a una subnet dedicata. Definire le dimensioni della subnet in base al numero di NVA SD-WAN distribuite per soddisfare i requisiti di alta disponibilità (HA), scalabilità o throughput. Per altre informazioni, vedere Connettere le reti hub-and-spoke di Azure alle SD-WAN e Limiti di Server di route Azure e considerazioni sulla progettazione.

  • Associare i gruppi di sicurezza di rete (NSG) alla scheda di rete del traffico SD-WAN, direttamente oppure a livello di subnet, per consentire le connessioni dalle sedi locali remote tramite le porte TCP/UDP usate dalla soluzione SD-WAN.

  • Abilitare l'inoltro IP sulla scheda di rete utilizzata per il traffico SD-WAN.

Server di route nella rete virtuale hub

Route Server automatizza lo scambio delle route tra le appliance virtuali di rete SD-WAN e lo stack di rete definita dal software (SDN) di Azure. Il server di route supporta BGP come protocollo di routing dinamico. Stabilendo le adiacenze BGP tra il Route Server e le NVA SD-WAN:

  • Il server di route inserisce le route per tutti i siti locali connessi alla SD-WAN nelle tabelle di route della rete virtuale e tutte le macchine virtuali (VM) Azure imparano tali route.

  • Il server di route propaga le route per tutti i prefissi IP nello spazio indirizzi delle reti virtuali a tutti i siti connessi a SD-WAN.

Configurare il server di route con i requisiti seguenti:

  • Distribuire il server di route in una subnet dedicata nella rete virtuale hub. Impostare la capacità del server di route in base al numero di macchine virtuali nella rete hub-spoke.

  • Per abilitare lo scambio dinamico delle route per tutte le reti virtuali spoke, configurate il peering di rete virtuale in modo da consentire alle reti virtuali spoke di usare il gateway e il Route Server della rete virtuale hub. Per ulteriori informazioni, vedere le FAQ di Route Server.

  • Il server di route e le appliance virtuali di rete SD-WAN si collegano a subnet diverse, quindi configurare le sessioni BGP tra il server di route e le appliance virtuali di rete SD-WAN per l'uso del supporto multihop eBGP. È supportato qualsiasi numero di hop compreso tra due e il numero massimo supportato dall'NVA SD-WAN. Per altre informazioni su come configurare gli ajacencies BGP per il server di route, vedere Creare e configurare il server di route tramite il portale di Azure.

  • Configurare due /32 route statiche nell'NVA SD-WAN per gli endpoint BGP che Route Server espone. 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 che propaga le route tra le appliance virtuali di rete SD-WAN e lo stack SDN della rete virtuale. Lo stack SDN Azure gestisce l'inoltro effettivo del traffico tra le appliance virtuali di rete SD-WAN e le macchine virtuali nella rete virtuale, 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 impostando l'hop successivo sull'indirizzo dell'appliance virtuale di rete.

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

Diagramma che mostra il funzionamento del server di route.

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

Il Route Server ha alta disponibilità incorporata. Due risorse di calcolo supportano una singola istanza del server di route e Azure distribuisce queste risorse di calcolo in zone di disponibilità diverse (in aree con zone di disponibilità) o nello stesso set di disponibilità (nelle aree senza zone di disponibilità). Di conseguenza, un'istanza del server di route espone due endpoint BGP, un endpoint per ogni risorsa di calcolo. È possibile ottenere l'alta disponibilità per le NVA SD-WAN distribuendo più istanze in zone di disponibilità diverse o all'interno dello stesso set di disponibilità. Ogni appliance virtuale di rete SD-WAN (NVA) stabilisce due sessioni BGP, una per ciascun endpoint esposto da Route Server.

Questa architettura non si basa su Azure servizi di bilanciamento del carico. Le caratteristiche sono le seguenti:

  • Nessun servizio di bilanciamento del carico pubblico espone gli endpoint del tunnel SD-WAN. Ogni NVA SD-WAN espone il proprio endpoint del tunnel. I peer remoti stabiliscono più tunnel, uno per ogni NVA SD-WAN in Azure.

  • Non sono necessari servizi di bilanciamento del carico interni per distribuire il traffico dalle macchine virtuali Azure tra più dispositivi perimetrali SD-WAN. Il server di route e lo stack SDN Azure supportano il routing ECMP (Equal-Cost Multi-Path). Se più dispositivi perimetrali annunciano una route per la stessa destinazione, il server di route inserisce più route nella tabella di route della rete virtuale, con una route per ogni dispositivo perimetrale che ha annunciato la destinazione. Ogni percorso ha un hop successivo diverso, che corrisponde all'indirizzo IP del dispositivo perimetrale che lo ha annunciato nella tabella di routing della rete virtuale. Lo stack SDN distribuisce quindi il traffico per la destinazione in tutti gli hop successivi disponibili.

La figura seguente mostra l'architettura HA risultante.

Diagramma che illustra l'alta disponibilità del Route Server.

Disponibilità elevata attiva e attiva/standby

Quando si utilizzano più NVAs SD-WAN e si effettua il peering con il Route Server, BGP determina il failover. Se un'appliance virtuale di rete SD-WAN va offline, interrompe la pubblicità delle route al Server di Route. Il server di route ritira quindi le route apprese dal dispositivo dalla tabella di route della rete virtuale. Di conseguenza, se una NVA SD-WAN non fornisce più connettività ai siti SD-WAN remoti a causa di un guasto del dispositivo o della rete sottostante, non compare più come possibile next hop verso tali siti nella tabella di routing della rete virtuale. Tutto il traffico passa ai dispositivi integri rimanenti. Per altre informazioni sulla propagazione delle route tra le NVA SD-WAN e Route Server, vedere Route pubblicate da un peer BGP a Route Server.

Il diagramma seguente illustra questo comportamento di failover.

Diagramma che mostra il failover del Route Server guidato da BGP.

Il failover guidato da BGP e il routing ECMP consentono architetture HA N-active con N dispositivi che elaborano simultaneamente il traffico. Le architetture attive-passive possono essere implementate anche perché Route Server tiene conto degli attributi AS Path di BGP. Se diversi dispositivi edge SD-WAN annunciano rotte per le stesse destinazioni con lunghezze AS Path diverse, il dispositivo edge SD-WAN che annuncia le rotte con il percorso più breve diventa il next hop preferito. Se il dispositivo ha esito negativo o ritira alcune delle relative route, il server di route estende le route con valori di percorso AS più lunghi annunciati da altri dispositivi. L'unico attributo BGP che le appliance virtuali di rete SD-WAN possono usare per esprimere un certo grado di preferenza per i percorsi che annunciano a Route Server è AS Path.

Consigliamo le architetture HA N-active perché consentono un utilizzo ottimale delle risorse senza NVA SD-WAN in standby e offrono scalabilità orizzontale. Per aumentare la capacità effettiva, più NVAs possono essere eseguiti in parallelo, fino al numero massimo di peer BGP supportati da Route Server. Il modello HA N-active richiede che le NVA SD-WAN operino come router stateless di livello 3. Quando esistono più tunnel a un sito, il sistema può instradare le connessioni TCP in modo asimmetrico. I flussi originali e di risposta 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. Questi asimmetri di routing sono possibili per le connessioni TCP avviate nella rete virtuale o in un sito locale.

Diagramma che illustra il routing asimmetrico nelle configurazioni active-active.

Considerare le architetture HA attive-passive solo quando le NVA SD-WAN in Azure svolgono funzioni di rete che richiedono la simmetria del routing, ad esempio l'ispezione stateful del firewall. Evitare questo approccio a causa delle implicazioni di scalabilità. L'esecuzione di più funzioni di rete nelle appliance virtuali di rete SD-WAN aumenta il consumo di risorse. Le architetture HA attive-passive consentono a una sola NVA (appliance virtuale di rete) di elaborare il traffico in un dato momento. Di conseguenza, l'intero livello SD-WAN può essere scalato solo fino alle dimensioni massime supportate della VM di Azure, non in orizzontale. Implementare funzioni di rete con stato che richiedono la simmetria di routing in cluster NVA (appliance virtuali di rete) separati che si basano su Azure Load Balancer per l'alta disponibilità n-attiva.

Considerazioni sulla connettività di ExpressRoute

Questa architettura supporta un approccio completo SD-WAN, quindi è possibile creare la rete aziendale come sovrimpressione logica sopra la rete Internet pubblica e il backbone Microsoft. È anche possibile usare circuiti ExpressRoute dedicati per gestire scenari specifici descritti nelle sezioni seguenti.

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 soluzioni SD-WAN come sostituzione delle VPN IPsec tradizionali nei siti con connettività Internet e usare i servizi MPLS e i circuiti ExpressRoute per siti e data center di grandi dimensioni, come illustrato nella figura seguente.

Diagramma che mostra SD-WAN e la coesistenza di ExpressRoute.

Questo scenario di coesistenza richiede che le appliance virtuali di rete SD-WAN (NVA) distribuite in Azure instradino il traffico tra i siti collegati alla rete SD-WAN e quelli collegati ai circuiti ExpressRoute. È possibile configurare Route Server per propagare i percorsi tra i gateway di rete virtuale ExpressRoute e le NVA SD-WAN in Azure abilitando la funzionalità AllowBranchToBranch. La propagazione delle route tra il gateway di rete virtuale ExpressRoute e le NVA SD-WAN avviene tramite BGP. Il server di route stabilisce sessioni BGP con il gateway di rete virtuale ExpressRoute e con le appliance virtuali di rete SD-WAN e propaga a ogni peer le route apprese dall'altro peer. La piattaforma gestisce le sessioni BGP tra il server di route e il gateway di rete virtuale ExpressRoute. Gli utenti non devono configurare tali sessioni in modo esplicito. Devono abilitare il AllowBranchToBranch flag solo quando distribuiscono il server di route.

Diagramma che mostra la propagazione della route quando il server di route è configurato con AllowBranchToBranch impostato su true.

Questo scenario di coesistenza SD-WAN e ExpressRoute consente migrazioni da reti MPLS a SD-WAN. Fornisce un percorso tra i siti MPLS legacy e i siti di SD-WAN appena migrati ed elimina la necessità di instradare il traffico attraverso data center locali. Usare questo modello durante le migrazioni e negli scenari che si verificano dalle fusioni e dalle acquisizioni aziendali per interconnettere reti diverse.

Scenario #2: ExpressRoute come rete underlay per SD-WAN

Se i siti on-premises dispongono di connettività ExpressRoute, è possibile configurare i dispositivi SD-WAN per stabilire tunnel verso le NVA dell'hub SD-WAN in esecuzione in Azure tramite ExpressRoute. È possibile usare sia il peering privato ExpressRoute che il peering Microsoft.

Peering privato

Quando si utilizza il peering privato di ExpressRoute come rete di trasporto sottostante, tutti i siti SD-WAN locali stabiliscono tunnel verso le NVA dell'hub SD-WAN in Azure. Questo scenario non richiede la propagazione della route tra le appliance virtuali di rete di SD-WAN e il gateway di rete virtuale ExpressRoute, pertanto è necessario configurare il server di route con il AllowBranchToBranch flag impostato su false.

Questo approccio richiede una configurazione BGP appropriata nei router lato cliente o provider che terminano la connessione ExpressRoute. I router Microsoft Enterprise Edge (MSEEs) annunciano tutte le rotte delle reti virtuali connesse al circuito, direttamente o tramite il peering di reti virtuali. 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 ExpressRoute.

Di conseguenza, i router lato cliente o lato provider che terminano la connessione ExpressRoute devono filtrare le route ricevute da Azure. Le uniche route nella rete underlay devono consentire ai dispositivi SD-WAN on-premises di raggiungere gli NVA dell'hub SD-WAN in Azure. I clienti che intendono usare il peering privato di ExpressRoute come rete underlay SD-WAN devono verificare che i dispositivi di routing supportino questa configurazione. Questo requisito è particolarmente rilevante per i clienti che non controllano i dispositivi perimetrali usati per ExpressRoute, ad esempio quando un gestore MPLS fornisce il circuito ExpressRoute su un servizio IPVPN.

Diagramma che illustra il peering privato di ExpressRoute come rete underlay SD-WAN.

Peering di Microsoft

È anche possibile usare il peering Microsoft ExpressRoute come rete di sottosezione per i tunnel SD-WAN. In questo scenario, le appliance virtuali di rete dell'hub SD-WAN in Azure espongono solo endpoint di tunnel pubblici, utilizzati dalle apparecchiature locali (CPE) SD-WAN dei clienti sia nei siti connessi a Internet sia nei siti connessi a ExpressRoute. Il peering Microsoft ExpressRoute presenta prerequisiti più complessi rispetto al peering privato, ma è consigliabile usare questa opzione come rete sottostante per i due motivi seguenti:The ExpressRoute Microsoft peering has more complex prerequisites than private peering, but we recommend this option as an underlay network for the following two reasons:

  • Non richiede gateway di rete virtuale ExpressRoute nella rete virtuale dell'hub. Rimuove la complessità, riduce i costi e consente la scalabilità della soluzione SD-WAN oltre i limiti di larghezza di banda del gateway quando non si usa ExpressRoute FastPath.

  • Questo approccio offre una netta separazione tra le route sovrapposte e di sottofondo. Gli MSEE annunciano solo i prefissi pubblici della rete Microsoft al bordo del cliente o del provider. È possibile posizionare tali route in un'istanza VRF (Virtual Routing and Forwarding) separata e propagarle solo in un segmento di rete perimetrale della LAN del sito. I dispositivi SD-WAN propagano le route per la rete aziendale del cliente nell'overlay, incluse le route per le reti virtuali. I clienti che considerano questo approccio devono verificare che possano configurare i dispositivi di routing di conseguenza o richiedere il servizio appropriato dal gestore MPLS.

Considerazioni su MPLS

La migrazione dalle reti aziendali MPLS tradizionali alle architetture di rete più moderne basate sul paradigma di SD-WAN richiede un impegno e un tempo significativi. Usare questa architettura per implementare migrazioni in più fasi da MPLS a SD-WAN. Le sezioni seguenti descrivono due scenari di migrazione tipici.

Disattivazione graduale di MPLS

I clienti che vogliono realizzare una SD-WAN sfruttando Internet pubblico e il backbone Microsoft e dismettere completamente le MPLS IPVPN o altri servizi di connettività dedicata possono usare lo scenario di coesistenza tra ExpressRoute e SD-WAN durante la migrazione. In questo scenario, i siti connessi a SD-WAN possono raggiungere i siti connessi al servizio MPLS legacy. Dopo aver migrato un sito alla SD-WAN e distribuito i dispositivi CPE, è possibile rimuovere il collegamento MPLS. Il sito può accedere all'intera rete aziendale tramite i suoi tunnel SD-WAN alle regioni Azure più vicine.

Diagramma che mostra l'architettura di dismissione MPLS.

Una volta migrati tutti i siti, è possibile dismettere la MPLS IPVPN insieme ai circuiti ExpressRoute che la collegano al backbone Microsoft. Non hai più bisogno dei gateway di rete virtuale di ExpressRoute e puoi rimuoverne il provisioning. Le NVA dell'hub SD-WAN in ogni regione diventano l'unico punto di ingresso nella rete hub-and-spoke della regione.

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 per siti o applicazioni specifici.

Lo scenario di ExpressRoute come underlay SD-WAN supporta l'integrazione di SD-WAN e MPLS. Preferire ExpressRoute Microsoft peering rispetto al peering privato. Quando si usa Microsoft peering, la rete MPLS e la rete Internet pubblica diventano sottostanti funzionalmente equivalenti. Forniscono l'accesso a tutti gli endpoint dei tunnel SD-WAN esposti dagli NVA dell'hub SD-WAN in Azure. Un dispositivo CPE SD-WAN distribuito in un sito che dispone sia di connettività Internet sia di connettività MPLS può stabilire più tunnel verso gli hub SD-WAN in Azure su entrambi gli underlay. Il CPE può quindi instradare connessioni diverse attraverso tunnel diversi in base ai criteri a livello di applicazione che il piano di controllo SD-WAN gestisce.

Diagramma che mostra l'architettura di integrazione MPLS.

Preferenza di routing del server di instradamento

In entrambi gli scenari MPLS nelle due sezioni precedenti, alcuni siti di succursali possono essere connessi sia a IPVPN MPLS che a SD-WAN. Di conseguenza, le istanze di Route Server distribuite nelle reti virtuali hub possono apprendere le stesse route dai gateway ExpressRoute e dalle appliance virtuali di rete (NVA) SD-WAN.

Usare la preferenza di routing di Route Server per controllare quale route privilegiare ed estendere nelle tabelle di route delle reti virtuali.

La preferenza di routing è utile quando non è possibile usare il prepending del percorso AS. Un esempio è rappresentato dai servizi IPVPN MPLS che non supportano configurazioni BGP personalizzate. A seconda di come la rete MPLS aggrega le route, del livello di controllo che hai sugli attributi delle route MPLS e della preferenza che hai tra SD-WAN e MPLS durante la migrazione, potrebbe essere necessario forzare Route Server a privilegiare le route MPLS rispetto alle route SD-WAN oppure le route SD-WAN rispetto alle route MPLS.

Considerazioni sulla progettazione e i limiti del server di route

Il server di route è fondamentale per questa architettura. Propaga le rotte tra le NVA SD-WAN distribuite nelle reti virtuali e lo stack SDN Azure sottostante. Offre un approccio basato su BGP per eseguire più appliance virtuali di rete SD-WAN per l'alta disponibilità e la scalabilità orizzontale. Quando progettate reti SD-WAN di grandi dimensioni basate su questa architettura, tenete conto dei limiti di scalabilità di Route Server.

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 ai gateway di rete virtuale ExpressRoute quando viene impostato il AllowBranchToBranch flag. Tuttavia, i gateway ExpressRoute propagano ulteriormente le route apprese dal server di route ai circuiti ExpressRoute a cui si connettono.

Azure limita il numero di rotte che i gateway ExpressRoute possono annunciare ai circuiti ExpressRoute tramite il peering privato. Quando progettate soluzioni SD-WAN seguendo le indicazioni contenute in questo articolo, assicuratevi che le rotte SD-WAN non raggiungano questo limite. Se si raggiunge il limite, 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 rotte che i gateway ExpressRoute annunciano ai circuiti è la somma delle rotte apprese da Route Server e dei prefissi che costituiscono lo spazio di indirizzi della rete hub-and-spoke di Azure. Per evitare interruzioni del servizio dovute a sessioni BGP interrotte, raccomandiamo le seguenti misure di mitigazione:

  • Usare le funzionalità native del dispositivo SD-WAN (riepilogo delle route e filtro) per limitare il numero di route annunciate al server di route, se disponibile.

  • Usare gli avvisi Monitoraggio di Azure per rilevare in modo proattivo i picchi nel numero di route annunciate dai gateway ExpressRoute. Monitorare la metrica numero di rotte annunciate al peer.

Peer BGP

Route Server può stabilire sessioni BGP fino a un numero massimo di peer BGP. Questo limite determina quante NVA SD-WAN possono stabilire adiacenze BGP con Route Server. Definisce anche la velocità effettiva di aggregazione massima che può essere supportata in tutti i tunnel SD-WAN. Si prevede che solo SD-WANs di grandi dimensioni raggiungano questo limite. Non esiste alcuna soluzione alternativa oltre alla creazione di più reti hub-spoke con gateway e server di route propri.

VM partecipanti

I gateway di rete virtuale ExpressRoute e il 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 dagli aggiornamenti del routing alle macchine virtuali, Azure definisce un limite per il numero di macchine virtuali in una rete hub-spoke singola. Regolare la capacità del Route Server in funzione del numero previsto di VM nella rete virtuale hub che ospita il Route Server e in tutte le reti virtuali spoke direttamente connesse tramite peering.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

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

Passo successivo

  • Last updated on