Approfondimento del routing della rete WAN virtuale

Azure rete WAN virtuale è una soluzione di rete che consente di creare facilmente topologie di rete sofisticate: include il routing tra aree di Azure tra reti virtuali di Azure e posizioni locali tramite VPN da punto a sito, VPN da sito a sito, appliance ExpressRoute e SDWAN integrate, inclusa l'opzione per proteggere il traffico. Nella maggior parte degli scenari non è necessario conoscere in modo approfondito il funzionamento di rete WAN virtuale routing interno, ma in determinate situazioni può essere utile comprendere rete WAN virtuale concetti di routing.

Questo documento illustra gli scenari di esempio rete WAN virtuale che illustrano alcuni dei comportamenti che le organizzazioni potrebbero riscontrare durante l'interconnessione delle reti virtuali e dei rami in reti complesse. Gli scenari illustrati in questo articolo non sono indicazioni di progettazione, ma sono solo topologie di esempio progettate per illustrare determinate funzionalità rete WAN virtuale.

Scenario 1: topologia con preferenza di routing predefinita

Il primo scenario di questo articolo analizza una topologia con due hub rete WAN virtuale, ExpressRoute, VPN e connettività SDWAN. In ogni hub sono presenti reti virtuali connesse direttamente (reti virtuali 11 e 21) e indirettamente tramite un'appliance virtuale di rete (reti virtuali 121, 122, 221 e 222). La rete virtuale 12 scambia informazioni di routing con l'hub 1 tramite BGP (vedere peering BGP con un hub virtuale) e la rete virtuale 22 include route statiche configurate, in modo che sia possibile visualizzare le differenze tra entrambe le opzioni.

In ogni hub, le appliance VPN e SDWAN servono a doppio scopo: da un lato annunciano i propri prefissi individuali ( tramite VPN nell'hub 1 e tramite SDWAN nell'hub 2) e dall'altro annunciano gli stessi prefissi dei circuiti ExpressRoute nella stessa area (10.4.1.0/2410.4.2.0/24 nell'hub 1 e 10.5.3.0/24 10.5.2.0/24 nell'hub 2). Questa differenza verrà usata per illustrare il funzionamento delle preferenze di routing dell'hub rete WAN virtuale.

Tutte le connessioni di rete virtuale e di succursale sono associate e propagate alla tabella di route predefinita. Anche se gli hub sono protetti (c'è un Firewall di Azure distribuito in ogni hub), non sono configurati per proteggere il traffico privato o Internet. In questo modo tutte le connessioni vengono propagate alla None tabella di route, che rimuoverebbe tutte le route non statiche dalla Default tabella di route e sconfisse lo scopo di questo articolo perché il pannello di route effettivo nel portale sarebbe quasi vuoto (ad eccezione delle route statiche per inviare il traffico al Firewall di Azure).

Per impostazione predefinita, gli hub rete WAN virtuale scambiano informazioni tra loro in modo che la comunicazione tra aree sia abilitata. È possibile esaminare le route valide in rete WAN virtuale tabelle di route: ad esempio, l'immagine seguente mostra le route valide nell'hub 1:

Queste route valide verranno quindi annunciate da rete WAN virtuale ai rami e le inseriranno nelle reti virtuali connesse agli hub virtuali, rendendo superfluo l'uso delle route definite dall'utente. Quando si esaminano le route valide in un hub virtuale, i campi "Tipo hop successivo" e "Origine" indicano da dove provengono le route. Ad esempio, un tipo di hop successivo "Rete virtuale Connection" indica che il prefisso è definito in una rete virtuale direttamente connessa a rete WAN virtuale (reti virtuali 11 e 12 nello screenshot precedente)

L'appliance virtuale di rete nella rete virtuale 12 inserisce la route 10.1.20.0/22 su BGP, perché il tipo di hop successivo "HubBgpConnection" implica (vedere Peering BGP con un hub virtuale). Questa route di riepilogo riguarda sia la rete virtuale spoke indiretti 121 (10.1.21.0/24) che la rete virtuale 122 (10.1.22.0/24). Le reti virtuali e i rami nell'hub remoto sono visibili con un hop successivo di hub2e possono essere visualizzati nel percorso AS che il numero 65520 di sistema autonomo è stato anteporto due volte a queste route interhub.

Nell'hub 2 è presente un'appliance virtuale di rete SDWAN integrata. Per altre informazioni sulle appliance virtuali di rete supportate per questa integrazione, vedere Informazioni sulle appliance virtuali di rete in un hub rete WAN virtuale. Si noti che la route al ramo 10.5.3.0/24 SDWAN ha un hop successivo di VPN_S2S_Gateway. Questo tipo di hop successivo può indicare oggi le route provenienti da un gateway di azure Rete virtuale o da appliance virtuali di rete integrate nell'hub.

Nell'hub 2, la route per 10.2.20.0/22 la rete virtuale spoke indiretti 221 (10.2.21.0/24) e la rete virtuale 222 (10.2.22.0/24) viene installata come route statica, come indicato dall'origine defaultRouteTable. Se si archiviano le route valide per l'hub 1, la route non è presente. Il motivo è che le route statiche non vengono propagate tramite BGP, ma devono essere configurate in ogni hub. Di conseguenza, una route statica è necessaria nell'hub 1 per fornire connettività tra le reti virtuali e i rami nell'hub 1 agli spoke indiretti nell'hub 2 (reti virtuali 221 e 222):

Dopo aver aggiunto la route statica, l'hub 1 conterrà anche la 10.2.20.0/22 route:

Scenario 2: Copertura globale e preferenza di routing dell'hub

Anche se l'hub 1 conosce il prefisso ExpressRoute dal circuito 2 (10.5.2.0/24) e l'hub 2 conosce il prefisso ExpressRoute dal circuito 1 (10.4.2.0/24), le route ExpressRoute dalle aree remote non vengono annunciate ai collegamenti ExpressRoute locali. Di conseguenza, La copertura globale di ExpressRoute è necessaria per consentire alle posizioni di ExpressRoute di comunicare tra loro:

Come illustrato in Preferenze di routing dell'hub virtuale, rete WAN virtuale favorisce le route provenienti da ExpressRoute per impostazione predefinita. Poiché le route vengono annunciate dall'hub 1 al circuito ExpressRoute 1, dal circuito ExpressRoute 1 al circuito 2 e dal circuito ExpressRoute 2 all'hub 2 (e viceversa), gli hub virtuali preferiscono questo percorso rispetto al collegamento tra hub più diretto ora. Le route valide nell'hub 1 mostrano quanto segue:

Come si può notare nelle route, Copertura globale di ExpressRoute antepone il numero di sistema autonomo ExpressRoute (12076) più volte prima di inviare le route ad Azure per rendere queste route meno preferibili. Tuttavia, rete WAN virtuale precedenza di routing hub predefinita di ExpressRoute ignora la lunghezza del percorso AS quando si prende la decisione di routing.

Le route valide nell'hub 2 saranno simili:

La preferenza di routing può essere modificata in VPN o AS-Path, come illustrato in Preferenze di routing dell'hub virtuale. Ad esempio, è possibile impostare la preferenza su VPN.

Con una preferenza di routing hub di VPN, le route valide nell'hub 1 hanno un aspetto simile al seguente:

L'immagine precedente mostra che la route a 10.4.2.0/24 ha ora un hop successivo di VPN_S2S_Gateway, mentre con la preferenza di routing predefinita di ExpressRoute era ExpressRouteGateway. Tuttavia, nell'hub 2 la route a 10.5.2.0/24 verrà comunque visualizzata con un hop successivo di ExpressRoute, perché in questo caso la route alternativa non proviene da un Gateway VPN ma da un'appliance virtuale di rete integrata nell'hub:

Tuttavia, il traffico tra hub è ancora preferibile alle route in arrivo tramite ExpressRoute. Per usare la connessione diretta più efficiente tra gli hub virtuali, è possibile impostare la preferenza di route su "Percorso AS" in entrambi gli hub.

Ora le route per gli spoke remoti e i rami nell'hub 1 avranno un hop successivo di Remote Hub come previsto:

È possibile notare che il prefisso IP per l'hub 2 (192.168.2.0/23) appare ancora raggiungibile tramite il collegamento Copertura globale, ma questo non dovrebbe influire sul traffico perché non dovrebbe esserci traffico indirizzato ai dispositivi nell'hub 2. Questa route potrebbe essere un problema, tuttavia, se sono presenti appliance virtuali di rete in entrambi gli hub che stabiliscono tunnel SDWAN tra loro.

Tuttavia, si noti che 10.4.2.0/24 è ora preferibile rispetto al Gateway VPN. Ciò può verificarsi se le route annunciate tramite VPN hanno un percorso AS più breve rispetto alle route annunciate tramite ExpressRoute. Dopo aver configurato il dispositivo VPN locale per anteporre il relativo numero di sistema autonomo (65501) alle route VPN per rendere meno preferibile l'hub 1 ora seleziona ExpressRoute come hop successivo per 10.4.2.0/24:

Hub 2 mostrerà una tabella simile per le route valide, in cui le reti virtuali e i rami nell'altro hub ora vengono visualizzati con Remote Hub come hop successivo:

Scenario 3: Connessione incrociata dei circuiti ExpressRoute a entrambi gli hub

Per aggiungere collegamenti diretti tra le aree di Azure e le posizioni locali connesse tramite ExpressRoute, è spesso consigliabile connettere un singolo circuito ExpressRoute a più hub rete WAN virtuale in una topologia, come illustrato nella topologia seguente:

rete WAN virtuale mostra che entrambi i circuiti sono connessi a entrambi gli hub:

Tornare alla preferenza di routing dell'hub predefinita di ExpressRoute, le route ai rami remoti e alle reti virtuali nell'hub 1 verranno nuovamente visualizzate come hop successivo. Anche se questa volta il motivo non è Copertura globale, ma il fatto che i circuiti ExpressRoute rimbalzano gli annunci di route che ottengono da un hub all'altro. Ad esempio, le route valide dell'hub 1 con preferenza di routing hub di ExpressRoute sono le seguenti:

Se si modifica nuovamente la preferenza di routing dell'hub in Percorso AS, le route tra hub vengono restituite al percorso ottimale usando la connessione diretta tra hub 1 e 2:

Passaggi successivi

Per altre informazioni sulle rete WAN virtuale, vedere:

• Domande frequenti su rete WAN virtuale