Condividi tramite

Rete in più aree con il server di route di Azure

  • Articolo

Le applicazioni con requisiti di disponibilità elevata o ripristino di emergenza richiedono spesso la distribuzione in più aree di Azure. In questi casi, le reti virtuali spoke in aree diverse devono comunicare tra loro. Un modo per abilitare questa comunicazione consiste nel eseguire il peering di tutte le reti virtuali spoke necessarie tra loro. Tuttavia, questo approccio ignora qualsiasi appliance virtuale di rete centrale, ad esempio firewall negli hub. Un'alternativa consiste nell'usare route definite dall'utente nelle subnet in cui vengono distribuite appliance virtuali di rete dell'hub, ma la gestione delle route definite dall'utente può risultare complessa. Il server di route di Azure offre un'alternativa dinamica che si adatta automaticamente alle modifiche della topologia, senza richiedere l'intervento manuale.

Topologia

Il diagramma seguente illustra un'architettura a due aree, in cui esiste una topologia hub-spoke in ogni area e le reti virtuali hub vengono sottoposte a peering tra loro tramite peering globale reti virtuali:

Diagram showing multi-region design with Azure Route Server.

L'appliance virtuale di rete in ogni area apprende i prefissi delle reti virtuali hub e spoke locali tramite il server di route di Azure e le condivide con l'appliance virtuale di rete nell'altra area usando BGP. Per evitare cicli di routing, è fondamentale stabilire questa comunicazione tra le appliance virtuali di rete usando una tecnologia di incapsulamento, ad esempio IPsec o VXLAN (Virtual eXtensible LAN).

Per consentire al server di route di Azure di annunciare i prefissi delle reti virtuali spoke alle appliance virtuali locali e inserire le route apprese nelle reti virtuali spoke, è essenziale usare l'impostazione Usare il gateway della rete virtuale remota o il server di route per il peering tra le reti virtuali spoke e la rete virtuale dell'hub.

Le appliance virtuali di rete annunciano le route apprese dall'area remota al server di route locale, che configurerà quindi queste route nelle reti virtuali spoke locali, attirando di conseguenza il traffico. Nei casi in cui esistono più appliance virtuali di rete nella stessa area (il server di route supporta fino a otto peer BGP), è possibile usare il percorso AS prepending per rendere una delle appliance virtuali di rete preferite rispetto alle altre, stabilendo in modo efficace una topologia di appliance virtuale di rete attiva/standby.

Importante

Per assicurarsi che il server di route locale possa apprendere le route annunciate dall'appliance virtuale di rete dall'area remota, l'appliance virtuale di rete deve rimuovere il numero di sistema autonomo (ASN) 65515 dal percorso AS delle route. Questa tecnica viene talvolta definita "override AS" o "riscrittura del percorso AS" in determinate piattaforme BGP. In caso contrario, il meccanismo di prevenzione del ciclo BGP impedirà al server di route locale di apprendere tali route perché impedisce l'apprendimento delle route che contengono già l'ASN locale.

ExpressRoute

La progettazione in più aree può essere combinata con i gateway ExpressRoute o VPN. Il diagramma seguente illustra una topologia che include un gateway ExpressRoute connesso a una rete locale in una delle aree di Azure. In questo caso, una rete di sovrapposizione sul circuito ExpressRoute consente di semplificare la rete, in modo che i prefissi locali vengano visualizzati solo in Azure come annunciato dall'appliance virtuale di rete (e non dal gateway ExpressRoute).

Diagram showing multi-region design with Route Server and ExpressRoute.

Progettazione senza sovrapposizioni

I tunnel tra aree tra le appliance virtuali di rete sono necessari perché in caso contrario viene creato un ciclo di routing. Ad esempio, esaminare l'appliance virtuale di rete nell'area 1:

  • L'appliance virtuale di rete nell'area 1 apprende i prefissi dall'area 2 e li annuncia al server di route nell'area 1.
  • Il server di route nell'area 1 inserirà le route per tali prefissi in tutte le subnet nell'area 1, con l'appliance virtuale di rete nell'area 1 come hop successivo.
  • Per il traffico dall'area 1 all'area 2, quando l'appliance virtuale di rete nell'area 1 invia il traffico all'altra appliance virtuale di rete, la propria subnet eredita così come le route programmate dal server di route, che puntano a se stesso (appliance virtuale di rete). Il pacchetto viene quindi restituito all'appliance virtuale di rete e viene visualizzato un ciclo di routing.

Se le route definite dall'utente sono un'opzione, è possibile disabilitare la propagazione della route BGP nelle subnet delle appliance virtuali di rete e configurare route definite dall'utente statiche anziché una sovrimpressione, in modo che Azure possa instradare il traffico alle reti virtuali spoke remote.

Contenuto correlato