Domande frequenti sulla rete WAN virtuale

Articolo
11/06/2024

La rete WAN virtuale di Azure è disponibile a livello generale?

Sì, la rete WAN virtuale di Azure è disponibile a livello generale. Tuttavia, la rete WAN virtuale è costituita da diverse funzionalità e diversi scenari. Per alcune funzionalità o alcuni scenari all'interno della rete WAN virtuale, Microsoft applica il tag di anteprima. In questi casi, la funzionalità specifica o lo scenario stesso è disponibile in anteprima. Se non si usa una funzionalità di anteprima specifica, si applica il normale supporto della disponibilità generale. Per altre informazioni sul supporto di anteprima, vedere Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure.

Quali località e aree sono disponibili?

Per visualizzare le aree disponibili per la rete WAN virtuale, vedere Prodotti disponibili in base all'area. Specificare WAN virtuale come nome del prodotto.

Per usare la rete WAN virtuale di Azure, è necessario avere un'architettura hub-spoke con dispositivi SD-WAN/VPN?

La rete WAN virtuale offre molte funzionalità integrate in un singolo pannello di controllo, ad esempio connettività VPN sito/da sito a sito, connettività utente/P2S, connettività ExpressRoute, connettività di rete virtuale, interconnettività VPN ExpressRoute, connettività transitiva da rete virtuale a rete virtuale, routing centralizzato, sicurezza di Firewall e Gestione firewall di Azure, monitoraggio, crittografia ExpressRoute e molte altre. Non è necessario che tutti questi casi d'uso inizino a usare la WAN virtuale. È possibile iniziare semplicemente con uno solo.

L'architettura della rete WAN virtuale è di tipo hub-spoke, con scalabilità e prestazioni predefinite in cui i rami (dispositivi VPN/SD-WAN), gli utenti (client VPN di Azure, client openVPN o IKEv2), i circuiti ExpressRoute e le reti virtuali fungono da spoke per uno o più hub virtuali. Tutti gli hub sono connessi in una mesh completa in una rete WAN virtuale standard, per cui è possibile usare il backbone Microsoft per la connettività tra qualsiasi spoke. Gli utenti possono configurare manualmente l'architettura hub-spoke con dispositivi SD-WAN/VPN nel portale della rete WAN virtuale di Azure oppure usare le apparecchiature CPE dei partner di rete WAN virtuale (SD-WAN/VPN) per configurare la connettività con Azure.

I partner di reti WAN virtuali forniscono l'automazione per la connettività, ovvero la possibilità di esportare le informazioni sui dispositivi in Azure, scaricare la configurazione di Azure e stabilire la connettività con l'hub della rete WAN virtuale di Azure. Per la connettività VPN utente/da punto a sito, sono supportati il client VPN di Azure, il client OpenVPN o il client IKEv2.

È possibile disabilitare gli hub completamente connessi in una mesh in una rete WAN virtuale?

La WAN virtuale è disponibile in due versioni: Base e Standard. Nella rete WAN virtuale Base gli hub non sono in mesh. In una rete WAN virtuale Standard, gli hub sono connessi in una mesh e vengono collegati automaticamente quando la rete WAN virtuale viene configurata per la prima volta. L'utente non deve eseguire alcuna operazione specifica. L'utente non deve anche disabilitare o abilitare la funzionalità per ottenere hub con mesh. La rete WAN virtuale offre molte opzioni di routing per indirizzare il traffico tra qualsiasi spoke (rete virtuale, VPN o ExpressRoute). Offre la facilità di hub completamente connessi in una mesh, oltre alla flessibilità di routing del traffico in base alle esigenze.

Come vengono gestite le zone di disponibilità e la resilienza nella rete WAN virtuale?

La rete WAN virtuale è un insieme di hub e servizi resi disponibili all'interno dell'hub. L'utente può avere un numero qualsiasi di reti WAN virtuali in base alle esigenze. In un hub della rete WAN virtuale sono presenti più servizi, ad esempio VPN, ExpressRoute e così via. Ognuno di questi servizi viene distribuito automaticamente in un'area di zone di disponibilità (tranne Firewall di Azure), cioè se l'area supporta le zone di disponibilità. Se un'area diventa una zona di disponibilità dopo la distribuzione iniziale nell'hub, l'utente può ricreare i gateway, il che attiverà una distribuzione nella zona di disponibilità. Il provisioning di tutti i gateway viene eseguito in un hub in modalità attiva-attiva, il che implica una resilienza incorporata all'interno di un hub. Per ottenere resilienza tra aree, gli utenti possono connettersi a più hub.

Attualmente, Firewall di Azure può essere distribuito per supportare le zone di disponibilità usando il portale di Gestione firewall di Azure, PowerShell o l'interfaccia della riga di comando. Attualmente non è possibile configurare un firewall esistente da distribuire tra le zone di disponibilità. Sarà necessario eliminare e ridistribuire Firewall di Azure.

Anche se il concetto di rete WAN virtuale è globale, la risorsa rete WAN virtuale effettiva è basata su Resource Manager e viene distribuita a livello di area. Se nell'area della rete WAN virtuale si verifica un problema, tutti gli hub al suo interno continueranno a funzionare normalmente, ma l'utente non sarà in grado di creare nuovi hub fino a quando l'area della rete WAN virtuale non sarà disponibile.

No, ogni hub virtuale di Azure deve avere il proprio firewall. La distribuzione di route personalizzate per puntare al firewall di un altro hub protetto avrà esito negativo e non verrà completata correttamente. Prendere in considerazione la possibilità di convertire tali hub in hub protetti con i propri firewall.

Quali client sono supportati dalla VPN utente (da punto a sito) della rete WAN virtuale di Azure?

La rete WAN virtuale supporta il client VPN di Azure, il client OpenVPN o qualsiasi client IKEv2. L'autenticazione di Microsoft Entra è supportata con il client VPN di Azure. È necessario un sistema operativo client Windows 10 con almeno versione 17763.0 o successiva. I client OpenVPN possono supportare l'autenticazione basata su certificato. Dopo aver selezionato l'autenticazione basata su certificato nel gateway, verrà visualizzato il file the.ovpn* da scaricare nel dispositivo. IKEv2 supporta sia l'autenticazione basata su certificato che RADIUS.

Per la VPN utente (da punto a sito), perché il pool di client P2S è diviso in due route?

Ogni gateway ha due istanze. La divisione serve a fare in modo che ogni istanza del gateway possa allocare in modo indipendente gli IP client per i client connessi e che il traffico dalla rete virtuale venga reinstradato all'istanza corretta per evitare l'hop tra istanze.

Come si possono aggiungere server DNS per i client da punto a sito?

Per aggiungere server DNS per i client da punto a sito, sono disponibili due opzioni. Il primo metodo è preferibile, perché aggiunge i server DNS personalizzati al gateway invece che al client.

Per aggiungere i server DNS personalizzati, usare lo script di PowerShell seguente. Sostituire i valori con quelli del proprio ambiente.

// Define variables
$rgName = "testRG1"
$virtualHubName = "virtualHub1"
$P2SvpnGatewayName = "testP2SVpnGateway1"
$vpnClientAddressSpaces = 
$vpnServerConfiguration1Name = "vpnServerConfig1"
$vpnClientAddressSpaces = New-Object string[] 2
$vpnClientAddressSpaces[0] = "192.168.2.0/24"
$vpnClientAddressSpaces[1] = "192.168.3.0/24"
$customDnsServers = New-Object string[] 2
$customDnsServers[0] = "7.7.7.7"
$customDnsServers[1] = "8.8.8.8"
$virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
$vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name

// Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers

// Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
$P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
$updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers 

// Re-generate VPN profile either from PS/Portal for VPN clients to have the specified dns servers

In alternativa, se si usa il client VPN di Azure per Windows 10, è possibile modificare il file XML del profilo scaricato e aggiungere i tag <dnsservers><dnsserver></dnsserver></dnsservers> prima di importarlo.
```
   <azvpnprofile>
   <clientconfig>

       <dnsservers>
           <dnsserver>x.x.x.x</dnsserver>
           <dnsserver>y.y.y.y</dnsserver>
       </dnsservers>

   </clientconfig>
   </azvpnprofile>
```

Per la VPN utente (da punto a sito), quanti client sono supportati?

La tabella seguente descrive il numero di connessioni simultanee e la velocità effettiva aggregata del gateway VPN da punto a sito supportato in unità di scala diverse.

Unità di scala	Istanze del gateway	Connessioni simultanee supportate	Velocità effettiva aggregata
1	2	500	0,5 Gbps
2	2	500	1 Gbps
3	2	500	1,5 Gbps
4	2	1000	2 Gbps
5	2	1000	2,5 Gbps
6	2	1000	3 Gbps
7	2	5000	3,5 Gbps
8	2	5000	4 Gbps
9	2	5000	4,5 Gbps
10	2	5000	5 Gbps
11	2	10000	5,5 Gbps
12	2	10000	6 Gbps
13	2	10000	6,5 Gbps
14	2	10000	7 Gbps
15	2	10000	7,5 Gbps
16	2	10000	8 Gbps
17	2	10000	8,5 Gbps
18	2	10000	9 Gbps
19	2	10000	9,5 Gbps
20	2	10000	10 Gbps
40	4	20000	20 Gbps
60	6	30000	30 Gbps
80	8	40000	40 Gbps
100	10	50000	50 Gbps
120	12	60000	60 Gbps
140	14	70000	70 Gbps
160	16	80000	80 Gbps
180	18	90000	90 Gbps
200	20	100000	100 Gbps

Si supponga, ad esempio, che l'utente scelga 1 unità di scala. Ogni unità di scala implica la distribuzione di un gateway attivo-attivo e ognuna delle istanze (in questo caso 2) supporta fino a 500 connessioni. Anche se è possibile ottenere 500 * 2 connessioni per ogni gateway, questo non significa che se ne pianificano 1000 invece di 500 per questa unità di scala. Se si supera il numero consigliato di connessioni, possono essere richiesti interventi di manutenzione per le istanze, durante i quali la connettività per le 500 connessioni aggiuntive potrebbe interrompersi.

Per i gateway con unità di scala superiori a 20, vengono distribuite coppie di istanze del gateway a disponibilità elevata aggiuntive per fornire capacità aggiuntiva per la connessione degli utenti. Ogni coppia di istanze supporta fino a 10.000 utenti aggiuntivi. Ad esempio, se si distribuisce un gateway con 100 unità di scala, vengono distribuite 5 coppie di gateway (10 istanze totali) e fino a 50.000 (10.000 utenti x 5 coppie di gateway) che gli utenti simultanei possono connettersi.

Assicurarsi anche di pianificare i tempi di inattività nel caso in cui si decida di aumentare o ridurre l'unità di scala o di cambiare la configurazione da punto a sito nel gateway VPN.

Per la VPN utente (da punto a sito), è supportata l'app registrata da Microsoft nell'autenticazione di Entra ID?

Sì, l'app registrata da Microsoft è supportata nella rete WAN virtuale. È possibile eseguire la migrazione della VPN utente dall'app registrata manualmente all'app registrata da Microsoft per una connettività più sicura.

Cosa sono le unità di scala del gateway della rete WAN virtuale?

Un'unità di scala è un'unità definita per selezionare una velocità effettiva aggregata di un gateway nell'hub virtuale. 1 unità di scala della rete VPN = 500 Mbps. 1 unità di scala di ExpressRoute = 2 Gbps. Esempio: 10 unità di scala della rete VPN corrispondono a 500 Mbps * 10 = 5 Gbps

Qual è la differenza tra un gateway di rete virtuale di Azure (gateway VPN) e un gateway VPN di rete WAN virtuale di Azure?

La rete WAN virtuale offre connettività da sito a sito su larga scala ed è ideale per velocità effettiva, scalabilità e semplicità d'uso. La connessione di un sito a un gateway VPN WAN virtuale è diversa da un normale gateway di rete virtuale che usa un gateway di tipo "VPN da sito a sito". Quando si vuole connettere utenti remoti alla rete WAN virtuale, si usa un tipo di gateway "VPN da punto a sito". I gateway VPN da punto a sito e da sito a sito sono entità separate nell'hub della rete WAN virtuale e devono essere distribuite singolarmente. Analogamente, quando si esegue la connessione di un circuito ExpressRoute a un hub WAN virtuale, viene usata una risorsa diversa per il gateway ExpressRoute rispetto al normale gateway di rete virtuale che usa il tipo di gateway "ExpressRoute".

La rete WAN virtuale supporta fino a 20 Gbps di velocità effettiva aggregata sia per VPN che per ExpressRoute. La rete WAN virtuale dispone anche di automazione per la connettività con un ecosistema di partner per dispositivi del ramo CPE. I dispositivi del ramo CPE eseguono includono automazione incorporata per il provisioning automatico e la connessione alla rete WAN virtuale di Azure. Questi dispositivi sono disponibili da un ecosistema di partner VPN e SD-WAN in continua crescita. Vedere l'elenco dei partner preferiti.

In che modo la rete WAN virtuale è diversa dal gateway di rete virtuale di Azure?

Una VPN di gateway di rete virtuale è limitata a 100 tunnel. Per le connessioni, è consigliabile usare la rete WAN virtuale per VPN su larga scala. È possibile eseguire fino a 1.000 connessioni di ramo per ogni hub virtuale con un aggregato di 20 Gbps per hub. Una connessione è un tunnel attivo-attivo dal dispositivo VPN locale all'hub virtuale. È anche possibile avere più hub virtuali per area, il che significa che è possibile connettere più di 1.000 rami a una singola area di Azure distribuendo più hub della rete WAN virtuale in tale area di Azure, ognuno con il proprio gateway VPN da sito a sito.

Qual è l'algoritmo consigliato e i pacchetti al secondo per ogni istanza da sito a sito nell'hub della rete WAN virtuale? Quanti tunnel supportano per ogni istanza? Qual è la velocità effettiva massima supportata in un singolo tunnel?

La rete WAN virtuale supporta 2 istanze del gateway VPN da sito a sito attive in un hub virtuale. Ciò significa che in un hub virtuale sono presenti 2 istanze del gateway VPN attive e attive. Durante le operazioni di manutenzione, ogni istanza viene aggiornata una a una per cui un utente potrebbe riscontrare una breve diminuzione della velocità effettiva aggregata di un gateway VPN.

Mentre la VPN della rete WAN virtuale supporta molti algoritmi, è consigliabile GCMAES256 sia per la crittografia IPSEC che per l'integrità per ottenere prestazioni ottimali. AES256 e SHA256 sono considerati meno efficienti e pertanto è possibile prevedere una riduzione delle prestazioni, ad esempio la latenza e le riduzioni dei pacchetti per tipi di algoritmo simili.

I pacchetti al secondo o PPS sono un fattore del numero totale di pacchetti e della velocità effettiva supportata per ogni istanza. È possibile comprendere meglio questo aspetto con un esempio. Si supponga che un'istanza del gateway VPN da sito a sito a 500 Mbps con unità di scala 1 venga distribuita in un hub della rete WAN virtuale. Supponendo una dimensione di pacchetto pari a 1400, previsto PPS per l'istanza del gateway VPN al massimo = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.

La rete WAN virtuale ha concetti di connessione VPN, connessione di collegamento e tunnel. Una singola connessione VPN è costituita da connessioni di collegamento. La rete WAN virtuale supporta fino a 4 connessioni di collegamento in una connessione VPN. Ogni connessione di collegamento è costituita da due tunnel IPsec che terminano in due istanze di un gateway VPN attivo-attivo distribuito in un hub virtuale. Il numero totale di tunnel che possono terminare in una singola istanza attiva è 1000, il che implica anche che la velocità effettiva per 1 istanza sarà disponibile aggregata in tutti i tunnel che si connettono a tale istanza. Ogni tunnel ha anche determinati valori di velocità effettiva. Nei casi di più tunnel connessi a un gateway di unità di scala con valore inferiore, è consigliabile valutare la necessità per tunnel e pianificare un gateway VPN che rappresenta un valore aggregato per la velocità effettiva in tutti i tunnel che terminano nell'istanza VPN.

Valori per varie unità di scala supportate nella rete WAN virtuale

Unità di scala	Velocità effettiva massima per tunnel (Mbps)	Numero massimo di PPS per tunnel	Velocità effettiva massima per istanza (Mbps)	Numero massimo di PPS per istanza
1	500	47K	500	47K
2	1000	94K	1000	94K
3	1500	140K	1500	140K
4	1500	140K	2000	187K
5	1500	140K	2500	234K
6	1500	140K	3000	281K
7	2300	215K	3500	328K
8	2300	215K	4000	374K
9	2300	215K	4500	421K
10	2300	215K	5000	468K
11	2300	215K	5500	515K
12	2300	215K	6000	562K
13	2300	215K	6500	609K
14	2300	215K	7000	655K
15	2300	215K	7500	702K
16	2300	215K	8000	749K
17	2300	215K	8500	796K
18	2300	215K	9000	843K
19	2300	215K	9500	889K
20	2300	215K	10000	936K

Nota

Tutti i numeri sono basati sull'algoritmo GCM.

Quali provider di dispositivo (partner di WAN virtuale) sono supportati?

Al momento, molti partner supportano l'esperienza di rete WAN virtuale completamente automatizzata. Per altre informazioni, vedere Virtual WAN partners(Partner di WAN virtuali).

Quali sono i passaggi di Virtual WAN partner automation (Automazione dei partner della rete WAN virtuale)?

Per i passaggi di automazione dei partner, vedere Virtual WAN partner automation (Automazione dei partner della rete WAN virtuale).

È necessario usare il dispositivo di un partner preferito?

No. È possibile usare qualsiasi dispositivo che supporti la VPN e soddisfi i requisiti di Azure per il supporto di IKEv2/IKEv1 IPsec. La rete WAN virtuale include anche soluzioni di partner CPE che automatizzano la connettività alla rete WAN virtuale di Azure semplificando la configurazione di connessioni VPN IPSec su larga scala.

In che modo i partner di WAN virtuale automatizzano la connettività con la WAN virtuale di Azure?

Soluzioni di connettività definite dal software gestiscono in genere i propri dispositivi di ramo usando un controller o un centro di provisioning dei dispositivi. Il controller può usare le API di Azure per automatizzare la connettività alla WAN virtuale di Azure. L'automazione include il caricamento di informazioni sui rami, il download della configurazione di Azure, la configurazione di tunnel IPSec in hub virtuali di Azure e la configurazione automatica della connettività dal dispositivo di ramo alla rete WAN virtuale di Azure. Quando si dispone di centinaia di rami, la connessione tramite i partner CPE di WAN virtuale è semplice poiché l'esperienza di onboarding elimina la necessità di impostare, configurare e gestire la connettività IPsec su larga scala. Per altre informazioni, vedere Virtual WAN partner automation (Automazione dei partner di WAN virtuale).

Cosa accade se un dispositivo in uso non è incluso nell'elenco dei partner della rete WAN virtuale? È comunque possibile usarlo per connettersi alla VPN della rete WAN virtuale di Azure?

Sì, purché il dispositivo supporti IPsec IKEv1 o IKEv2. I partner della rete WAN virtuale automatizzano la connettività dal dispositivo agli endpoint VPN. Ciò implica l'automazione di passaggi quali il "caricamento di informazioni sui rami", "IPsec e configurazione" e "connettività". Poiché il dispositivo in uso non proviene da un ecosistema di partner della rete WAN virtuale, sarà necessario assumersi il carico di effettuare manualmente la configurazione di Azure e aggiornare il dispositivo per configurare la connettività IPsec.

In che modo vengono accettati i nuovi partner non inclusi nell'elenco dei partner iniziale?

Tutte le API della rete WAN virtuale sono OpenAPI. Per valutare la fattibilità tecnica, vedere la documentazione sull'automazione dei partner della rete WAN virtuale. Un partner ideale è quello che ha un dispositivo di cui è possibile eseguire il provisioning per la connettività IPSec IKEv1 o IKEv2. Una volta che l'azienda ha completato l'attività di automazione per il dispositivo CPE in base alle linee guida fornite in precedenza, è possibile contattare azurevirtualwan@microsoft.com per essere inseriti nella sezione Connettività tramite partner. Se si vuole che una soluzione di una specifica azienda venga inclusa nell'elenco di partner della rete WAN virtuale, chiedere all'azienda di inviare un messaggio di posta elettronica all'indirizzo azurevirtualwan@microsoft.com.

In che modo la rete WAN virtuale supporta i dispositivi SD-WAN?

I partner della rete WAN virtuale automatizzano la connettività IPsec agli endpoint VPN di Azure. Se il partner della rete WAN virtuale è un provider di SD-WAN, il controller SD-WAN gestisce l'automazione e la connettività IPsec agli endpoint VPN di Azure. Se il dispositivo SD-WAN richiede un proprio endpoint anziché una VPN di Azure per qualsiasi funzionalità SD-WAN proprietaria, è possibile distribuire l'endpoint SD-WAN in una rete virtuale di Azure e coesistere con la rete WAN virtuale di Azure.

La rete WAN virtuale supporta il peering BGP e offre anche la possibilità di distribuire appliance virtuali di rete in un hub della rete WAN virtuale.

Quanti dispositivi VPN possono connettersi a un singolo hub?

Sono supportate fino a 1.000 connessioni per ogni hub virtuale. Ogni connessione è costituita da quattro collegamenti e ciascuna connessione del collegamento supporta due tunnel in una configurazione attivo-attivo. I tunnel terminano in un gateway VPN dell'hub virtuale di Azure. I collegamenti rappresentano il collegamento all'ISP fisico nel dispositivo ramo/VPN.

Che cosa si intende per connessione da dispositivo di ramo alla rete WAN virtuale di Azure?

Una connessione da un ramo o un dispositivo VPN alla rete WAN virtuale di Azure è una connessione VPN che si connette virtualmente al sito VPN e al gateway VPN di Azure in un hub virtuale.

Cosa accade se il dispositivo VPN locale ha solo 1 tunnel a un gateway VPN della rete WAN virtuale di Azure?

Una connessione WAN virtuale di Azure è costituita da 2 tunnel. Un gateway VPN della rete WAN virtuale viene distribuito in un hub virtuale in modalità attiva-attiva, il che implica che sono presenti tunnel separati dai dispositivi locali che terminano in istanze separate. Si tratta della raccomandazione per tutti gli utenti. Tuttavia, se l'utente sceglie di avere solo 1 tunnel a una delle istanze del gateway VPN della rete WAN virtuale, se per qualsiasi motivo (manutenzione, patch e così via) l'istanza del gateway viene portata offline, il tunnel verrà spostato nell'istanza attiva secondaria e l'utente potrebbe riscontrare una riconnessione. Le sessioni BGP non verranno spostate tra istanze.

Cosa accade durante la reimpostazione del gateway in un gateway VPN della rete WAN virtuale?

Il pulsante Reimpostazione gateway deve essere usato se i dispositivi locali funzionano tutti come previsto, ma la connessione VPN da sito a sito in Azure è in stato Disconnesso. I gateway VPN della rete WAN virtuale vengono sempre distribuiti in stato attivo-attivo per la disponibilità elevata. Ciò significa che in qualsiasi momento è presente più di un'istanza distribuita in un gateway VPN. Quando si usa il pulsante Reimpostazione gateway, riavvia le istanze nel gateway VPN in modo sequenziale in modo che le connessioni non vengano interrotte. Si verificherà un breve gap man mano che le connessioni passano da un'istanza all'altra, ma questo gap dovrebbe essere inferiore a un minuto. Si noti inoltre che la reimpostazione dei gateway non modificherà gli indirizzi IP pubblici.

Questo scenario si applica solo alle connessioni S2S.

Il dispositivo VPN locale può connettersi a più hub?

Sì. Il flusso del traffico inizialmente proviene dal dispositivo locale verso la rete perimetrale Microsoft più vicina e quindi all'hub virtuale.

Sono disponibili nuove risorse di Gestione risorse per la WAN virtuale?

Sì, la rete WAN virtuale include nuove risorse di Resource Manager. Per altre informazioni, vedere la panoramica.

È possibile distribuire e usare l'appliance virtuale di rete preferita (in una rete virtuale di appliance virtuale di rete) con la rete WAN virtuale di Azure?

Sì, è possibile connettere la rete virtuale dell'appliance virtuale di rete preferita alla rete WAN virtuale di Azure.

Posso creare un'appliance virtuale di rete all'interno dell'hub virtuale?

Un'appliance virtuale di rete può essere distribuita all'interno di un hub virtuale. Per la procedura, vedere Informazioni sulle appliance virtuali di rete in un hub della rete WAN virtuale.

Un rete virtuale spoke può avere un gateway di rete virtuale?

No. La rete virtuale spoke non può avere un gateway di rete virtuale se è connessa all'hub virtuale.

Una rete virtuale spoke può avere un server di route di Azure?

No. La rete virtuale spoke non può avere un server di route se è connesso all'hub della rete WAN virtuale.

È disponibile il supporto per BGP nella connettività VPN?

Sì, BGP è supportato. Quando si crea un sito VPN, è possibile inserirvi i parametri BGP. Ciò implica che tutte le connessioni create in Azure per tale sito verranno abilitate per BGP.

Sono disponibili informazioni sulle licenze o i prezzi per la WAN virtuale?

Sì. Vedere la pagina dei Prezzi.

È possibile costruire la rete WAN virtuale di Azure con un modello di Resource Manager?

Una semplice configurazione di una rete WAN virtuale con un hub e un sito VPN può essere creata usando un modello di avvio rapido. La rete WAN virtuale è principalmente un REST o un servizio gestito dal Portale.

Le reti virtuali spoke connesse a un hub virtuale possono comunicare tra loro (transito V2V)?

Sì. La rete WAN virtuale Standard supporta la connettività transitiva da rete virtuale a rete virtuale tramite l'hub della rete WAN virtuale a cui sono connesse le reti virtuali. Nella terminologia della rete WAN virtuale, si fa riferimento a questi percorsi come "transito locale di rete virtuale in rete WAN virtuale" per le reti virtuali connesse a un hub rete WAN virtuale e "transito globale di rete virtuale in rete WAN virtuale" per le reti virtuali connesse tramite più hub rete WAN virtuale in due o più aree.

In alcuni scenari, le reti virtuali spoke possono anche essere collegate direttamente in peering tra loro usando il peering di reti virtuali oltre al transito locale o globale della rete virtuale nella rete WAN virtuale. In questo caso, il peering di reti virtuali ha la precedenza sulla connessione transitiva tramite l'hub della rete WAN virtuale.

La connettività tra succursali è consentita nella rete WAN virtuale?

Sì, la connettività tra succursali è disponibile nella rete WAN virtuale. Il ramo è concettualmente applicabile a un sito VPN, a circuiti ExpressRoute o a utenti di VPN utente/da punto a sito. La connessione da ramo a ramo è abilitata per impostazione predefinita e può essere individuata nelle impostazioni di configurazione della rete WAN. Ciò consente ai rami VPN o agli utenti di connettersi ad altri rami VPN e la connettività di transito è abilitata anche tra gli utenti VPN ed ExpressRoute.

Il traffico da ramo a ramo passa attraverso la rete WAN virtuale di Azure?

Sì. Il traffico da ramo a ramo attraversa la rete WAN virtuale di Azure.

La rete WAN virtuale richiede ExpressRoute da ogni sito?

No. La rete WAN virtuale non richiede ExpressRoute da ogni sito. I siti potrebbero essere connessi a una rete del provider usando un circuito ExpressRoute. Per i siti connessi tramite ExpressRoute a un hub virtuale e VPN IPsec nello stesso hub, l'hub virtuale fornisce connettività di transito tra la VPN e l'utente ExpressRoute.

È previsto un limite di velocità effettiva di rete o di connessioni quando si usa la rete WAN virtuale di Azure?

La velocità effettiva della rete viene assegnata per servizio in un hub della rete WAN virtuale. In ogni hub la velocità effettiva aggregata della VPN è fino a 20 Gbps, la velocità effettiva aggregata di ExpressRoute è fino a 20 Gbps e la velocità effettiva aggregata della VPN utente/VPN da punto a sito è fino a 200 Gbps. Il router nell'hub virtuale supporta fino a 50 Gbps per i flussi di traffico da rete virtuale a rete virtuale e presuppone un totale di carico di lavoro di 2000 macchine virtuali in tutte le reti virtuali connesse a un singolo hub virtuale.

Per proteggere la capacità iniziale senza dover attendere l'aumento del numero di istanze dell'hub virtuale quando è necessaria una maggiore velocità effettiva, è possibile impostare la capacità minima o modificare in base alle esigenze. Vedere Informazioni sulle impostazioni dell'hub virtuale - Capacità dell'hub. Per implicazioni sui costi, vedere il costo unità infrastruttura di routing nella pagina Prezzi della rete WAN virtuale di Azure.

I siti VPN si connettono a un hub tramite connessioni. La rete WAN virtuale supporta fino a 1000 connessioni o 2000 tunnel IPsec per ogni hub virtuale. Quando gli utenti remoti si connettono all'hub virtuale, si connettono al gateway VPN P2S, che supporta fino a 100.000 utenti a seconda dell'unità di scala (larghezza di banda) scelta per il gateway VPN P2S nell'hub virtuale.

È possibile usare NAT-T nelle connessioni VPN?

Sì, l'attraversamento NAT (NAT-T) è supportato. Il gateway VPN della rete WAN virtuale NON eseguirà alcuna funzionalità simile a NAT nei pacchetti interni da/verso i tunnel IPsec. In questa configurazione verificare che il dispositivo locale avvii il tunnel IPsec.

Come è possibile configurare un'unità di scala per un'impostazione specifica, ad esempio 20 Gbps?

Passare al gateway VPN all'interno di un hub nel portale, quindi fare clic sull'unità di scala per passare all'impostazione appropriata.

La rete WAN virtuale consente al dispositivo locale di usare più ISP in parallelo o si tratta sempre di un singolo tunnel VPN?

Le soluzioni per dispositivi locali possono applicare criteri per distribuire il traffico tra più tunnel nell'hub della rete WAN virtuale di Azure (gateway VPN nell'hub virtuale).

Che cos'è l'architettura di transito globale?

Per informazioni, vedere Architettura di rete di transito globale e rete WAN virtuale.

In quale modo il traffico viene indirizzato sul backbone di Azure?

Il traffico segue il modello: dispositivo di succursale ->ISP->rete perimetrale microsoft->Microsoft DC (hub VNet)->rete perimetrale microsoft->ISP->dispositivo del ramo

In questo modello, cosa serve in ogni sito? Semplicemente una connessione Internet?

Sì. Una connessione a Internet e un dispositivo fisico che supporti IPsec, preferibilmente dei partner di WAN virtuale integrati Microsoft. Facoltativamente è possibile gestire manualmente la configurazione e la connettività ad Azure dal dispositivo preferito.

Come si abilita la route predefinita (0.0.0.0/0) per una connessione (VPN, ExpressRoute o rete virtuale)?

Un hub virtuale può propagare una route predefinita appresa a una connessione di rete virtuale/VPN da sito a sito/ExpressRoute se il flag è su "Abilitato" nella connessione. Questo flag è visibile quando l'utente modifica una connessione di rete virtuale, VPN o ExpressRoute. Per impostazione predefinita, questo flag è disabilitato quando un sito o un circuito ExpressRoute sono connessi a un hub. Questa funzionalità è abilitata per impostazione predefinita quando si aggiunge una connessione di rete virtuale per connettere una rete virtuale a un hub virtuale.

La route predefinita non ha origine nell'hub della rete WAN virtuale; la route predefinita viene propagata se è già stata appresa dall'hub della rete WAN virtuale a seguito della distribuzione di un firewall nell'hub o se per un altro sito connesso è abilitato il tunneling forzato. Una route predefinita non viene propagata tra hub (inter-hub).

È possibile creare più hub della rete WAN virtuale nella stessa area?

Sì. I clienti possono ora creare più di un hub nella stessa area per la stessa rete WAN virtuale di Azure.

In che modo l'hub virtuale in una rete WAN virtuale seleziona il percorso migliore per una route da più hub?

Per informazioni, vedere la pagina delle preferenze di routing dell'hub virtuale.

L'hub della rete WAN virtuale consente la connettività tra circuiti ExpressRoute?

Il transito tra ER e ER avviene sempre tramite Copertura globale. I gateway dell'hub virtuale vengono distribuiti in un controller di dominio o in aree di Azure. Quando due circuiti ExpressRoute si connettono tramite Copertura globale, non è necessario che il traffico passi direttamente dai router perimetrali al controller di dominio dell'hub virtuale.

Esiste un concetto di peso nei circuiti ExpressRoute o nelle connessioni VPN della rete WAN virtuale di Azure?

Quando più circuiti ExpressRoute sono connessi a un hub virtuale, il peso del routing sulla connessione fornisce un meccanismo che consente a ExpressRoute nell'hub virtuale di preferire un circuito rispetto all'altro. Non esiste alcun meccanismo per impostare un peso su una connessione VPN. Azure preferisce sempre una connessione ExpressRoute rispetto a una connessione VPN all'interno di un singolo hub.

La rete WAN virtuale preferisce ExpressRoute rispetto a VPN per il traffico in uscita da Azure?

Sì. La rete WAN virtuale preferisce ExpressRoute rispetto alla VPN per il traffico in uscita in Azure. Tuttavia, è possibile configurare la preferenza di routing dell'hub virtuale per modificare la preferenza predefinita. Per la procedura, vedere Configurare le preferenze di routing dell'hub virtuale.

Quando un hub della rete WAN virtuale include un circuito ExpressRoute a cui è connesso un sito VPN, per quale motivo una route di connessione VPN verrebbe preferita rispetto a ExpressRoute?

Quando un circuito ExpressRoute è connesso a un hub virtuale, i router di Microsoft Edge sono il primo nodo per la comunicazione tra l'ambiente locale e Azure. Questi router perimetrali comunicano con i gateway ExpressRoute della rete WAN virtuale, che a loro volta riconoscono le route del router dell'hub virtuale che controlla tutte le route tra qualsiasi gateway nella rete WAN virtuale. I router Microsoft Edge elaborano le route ExpressRoute dell'hub virtuale con una priorità più alta rispetto alle route riconosciute dall'ambiente locale.

Se per qualsiasi motivo la connessione VPN diventa il mezzo principale da cui l'hub virtuale riconosce le route (ad esempio negli scenari di failover tra ExpressRoute e VPN), a meno che il sito VPN non abbia un percorso di routing simmetrico più lungo, l'hub virtuale continuerà a condividere le route riconosciute dalla VPN con il gateway ExpressRoute. In questo modo i router di Microsoft Edge preferiscono le route VPN rispetto alle route locali.

ExpressRoute supporta il routing ECMP (Equal-Cost Multi-Path) nella rete WAN virtuale?

Quando più circuiti ExpressRoute sono connessi a un hub della rete WAN virtuale, ECMP consente il traffico dalle reti virtuali spoke all'ambiente locale tramite ExpressRoute per essere distribuito in tutti i circuiti ExpressRoute che annunciano le stesse route locali. ECMP non è attualmente abilitato per impostazione predefinita per gli hub rete WAN virtuale.

Quando due hub (hub 1 e 2) sono connessi e un circuito ExpressRoute è connesso a entrambi, qual è il percorso con cui una rete virtuale connessa all'hub 1 raggiunge una rete virtuale connessa all'hub 2?

Il comportamento corrente è quello di preferire il percorso del circuito ExpressRoute rispetto a quello da hub a hub per la connettività da rete virtuale a rete virtuale. Tuttavia, questa scelta non è consigliata in una configurazione di rete WAN virtuale. Per risolvere questo problema, è possibile eseguire una delle due operazioni seguenti:

Configurare più circuiti ExpressRoute (provider diversi) per connettersi a un hub e usare la connettività da hub a hub fornita dalla rete WAN virtuale per i flussi di traffico tra aree.
Configurare AS-Path come preferenza di routing hub per l'hub virtuale. In questo modo il traffico tra 2 hub attraversa il router dell'hub virtuale in ogni hub e usa il percorso da hub a hub anziché il percorso ExpressRoute (che attraversa i router di Microsoft Edge). Per altre informazioni, vedere Configurare le preferenze di routing dell'hub virtuale.

Quando è presente un circuito ExpressRoute connesso come collegamento di prua a un hub della rete WAN virtuale e a una rete virtuale autonoma, qual è il percorso della rete virtuale autonoma per raggiungere l'hub della rete WAN virtuale?

Per le nuove distribuzioni, questa connettività è bloccata per impostazione predefinita. Per consentire questa connettività, è possibile abilitare questi interruttori del gateway ExpressRoute nel pannello "Modifica hub virtuale" e nel pannello "Gateway di rete virtuale" nel portale. È tuttavia consigliabile mantenere questi interruttori disabilitati e creare invece una connessione di rete virtuale per connettere direttamente le reti virtuali autonome a un hub della rete WAN virtuale. Successivamente, il traffico da rete virtuale a rete virtuale passerà attraverso il router dell'hub della rete WAN virtuale, che offre prestazioni migliori rispetto al percorso ExpressRoute. Il percorso ExpressRoute include il gateway ExpressRoute, che ha limiti di larghezza di banda inferiori rispetto al router hub, nonché i router/MSEE di Microsoft Enterprise Edge, che è un hop aggiuntivo nel percorso dati.

Nel diagramma seguente è necessario abilitare entrambi gli interruttori per consentire la connettività tra la rete virtuale autonoma 4 e le reti virtuali connesse direttamente all'hub 2 (VNet 2 e VNet 3): Consentire il traffico dalle reti WAN virtuali remote per il gateway di rete virtuale e Consentire il traffico da reti WAN non virtuali per il gateway ExpressRoute dell'hub virtuale. Se un server di route di Azure viene distribuito nella rete virtuale autonoma 4 e il server di route è abilitato da ramo a ramo, la connettività verrà bloccata tra la rete virtuale 1 e la rete virtuale autonoma 4.

L'abilitazione o la disabilitazione dell'interruttore influirà solo sul flusso di traffico seguente: il flusso del traffico tra l'hub della rete WAN virtuale e le reti virtuali autonome tramite il circuito ExpressRoute. L'abilitazione o la disabilitazione dell'interruttore non comporta tempi di inattività per tutti gli altri flussi di traffico (ad esempio, la rete virtuale da sito locale a spoke 2 non sarà interessata, la rete virtuale dalla 2 alla rete virtuale 3 non saranno interessate e così via).

Perché la connettività non funziona quando si annunciano le route con un ASN pari a 0 nel percorso AS?

L'hub rete WAN virtuale elimina le route con un ASN pari a 0 nel percorso AS. Per assicurarsi che queste route vengano annunciate correttamente in Azure, as-path non deve includere 0.

È possibile creare hub in gruppi di risorse diversi nella rete WAN virtuale?

Sì. Questa opzione è attualmente disponibile solo tramite PowerShell. Il portale della rete WAN virtuale richiede che gli hub si trovino nello stesso gruppo di risorse della risorsa della rete WAN virtuale stessa.

Qual è lo spazio indirizzi hub consigliato durante la creazione dell'hub?

Lo spazio indirizzi dell'hub della rete WAN virtuale consigliato è /23. L'hub della rete WAN virtuale assegna subnet a vari gateway (ExpressRoute, VPN da sito a sito, VPN da punto a sito, Firewall di Azure, Router hub virtuale). Per gli scenari in cui le appliance virtuali di rete vengono distribuite all'interno di un hub virtuale, viene in genere ritagliato un /28 per le istanze dell'appliance virtuale di rete. Tuttavia, se l'utente deve effettuare il provisioning di più appliance virtuali di rete, potrebbe essere assegnata una subnet /27. Pertanto, tenendo presente un'architettura futura, mentre gli hub della rete WAN virtuale vengono distribuiti con una dimensione minima di /24, lo spazio indirizzi dell'hub consigliato in fase di creazione per l'input dell'utente è /23.

È disponibile il supporto per IPv6 nella rete WAN virtuale?

IPv6 non è supportato nell'hub della rete WAN virtuale e nei relativi gateway. Attualmente non è neanche supportata la connessione di una rete virtuale con supporto per IPv4 e IPv6 a una rete WAN virtuale.

Per lo scenario della VPN da punto a sito (utente) con breakout Internet tramite Firewall di Azure, si dovrà probabilmente disattivare la connettività IPv6 nel dispositivo client per forzare il traffico verso l'hub della rete WAN virtuale. Il motivo è che i moderni dispositivi usano gli indirizzi IPv6.

Qual è la versione consigliata dell'API da usare per gli script che automatizzano varie funzionalità della rete WAN virtuale?

È necessaria almeno la versione 05-01-2022 (1° maggio 2022).

Sono previsti limiti per la rete WAN virtuale?

Vedere la sezione Limiti della rete WAN virtuale nella pagina Limiti della sottoscrizione e del servizio.

Quali sono le differenze tra i tipi di rete WAN virtuale (Basic e Standard)?

Vedere Reti WAN virtuali Basic e Standard. Per i prezzi, vedere la pagina dei Prezzi.

La rete WAN virtuale archivia i dati dei clienti?

No. La rete WAN virtuale non archivia i dati dei clienti.

Esistono provider di servizi gestiti in grado di gestire la rete WAN virtuale per gli utenti come servizio?

Sì. Per un elenco delle soluzioni dei provider di servizi gestiti abilitate tramite Azure Marketplace, vedere Offerte di Azure Marketplace da partner MSP di rete di Azure.

In che modo il routing dell'hub della rete WAN virtuale differisce dal server di route di Azure in una rete virtuale?

Sia l'hub della rete WAN virtuale di Azure che il server di route di Azure forniscono funzionalità di peering BGP (Border Gateway Protocol) che possono essere usate dalle appliance virtuali di rete (Appliance virtuale di rete) per annunciare gli indirizzi IP dall'appliance virtuale di rete alle reti virtuali di Azure dell'utente. Le opzioni di distribuzione differiscono nel senso che il server di route di Azure viene in genere distribuito da una rete virtuale dell'hub cliente autogestito, mentre la rete WAN virtuale di Azure offre un servizio hub completamente mesh a zero a cui i clienti connettono i vari spoke end point (rete virtuale di Azure, rami locali con VPN da sito a sito o SDWAN, utenti remoti con VPN da punto a sito/connessioni private con ExpressRoute) e godono del peering BGP per le appliance virtuali di rete distribuite nella rete virtuale spoke insieme ad altre funzionalità VWAN come la connettività di transito per la rete virtuale a rete virtuale, la connettività di transito tra VPN ed ExpressRoute, il routing personalizzato/avanzato, l'associazione e la propagazione delle route personalizzate, la finalità/i criteri di routing senza problemi di sicurezza tra aree, l'hub protetto/il firewall di Azure e così via. Per altre informazioni sul peering BGP della rete WAN virtuale, vedere Come eseguire il peering BGP con un hub virtuale.

Se si usa un provider di sicurezza di terze parti (Zscaler, iBoss o Checkpoint) per proteggere il traffico Internet, perché non viene visualizzato il sito VPN associato al provider di sicurezza di terze parti nel portale di Azure?

Quando si sceglie di distribuire un provider di partner di sicurezza per proteggere l'accesso a Internet per gli utenti, il provider di sicurezza di terze parti crea un sito VPN per conto dell'utente. Poiché il provider di sicurezza di terze parti viene creato automaticamente dal provider e non è un sito VPN creato dall'utente, questo sito VPN non verrà visualizzato nel portale di Azure.

Per altre informazioni sulle opzioni disponibili provider di sicurezza di terze parti e su come configurare questa impostazione, vedere Distribuire un provider di partner di sicurezza.

Le community BGP generate dall'ambiente locale verranno mantenute nella rete WAN virtuale?

Sì, le community BGP generate dall'ambiente locale verranno mantenute nella rete WAN virtuale.

Le community BGP generate dai peer BGP (in una rete virtuale collegata) verranno mantenute nella rete WAN virtuale?

Sì, le community BGP generate dai peer BGP verranno mantenute nella rete WAN virtuale. Le community vengono mantenute nello stesso hub e tra connessioni interhub. Questo vale anche per gli scenari della rete WAN virtuale che usano criteri di finalità di routing.

Quali numeri ASN sono supportati per le reti locali collegate in remoto che eseguono BGP?

È possibile usare ASN pubblici o ASN privati per le reti locali. Non è possibile usare gli intervalli riservati da Azure o IANA:

Numeri ASN riservati da Azure:
- ASN pubblici: 8074, 8075, 12076
- ASN privati: 65515, 65517, 65518, 65519, 65520
- ASN riservati da IANA: 23456, 64496-64511, 65535-65551

Esiste un modo per modificare l'ASN per un gateway VPN?

No. La rete WAN virtuale non supporta le modifiche ASN per i gateway VPN.

Nella rete WAN virtuale quali sono le prestazioni stimate dello SKU del gateway ExpressRoute?

Unità di scala	Connessioni al secondo	Megabit al secondo	Pacchetti al secondo
1 unità di scala	14.000	2.000	200.000
2 unità di scala	28.000	4.000	400.000
3 unità di scala	42.000	6.000	600,000
4 unità di scala	56.000	8.000	800,000
5 unità di scala	70.000	10,000	1\.000.000
6 unità di scala	84.000	12,000	1,200,000
7 unità di scala	98.000	14.000	1.400.000
8 unità di scala	112.000	16.000	1,600,000
9 unità di scala	126.000	18.000	1.800.000
10 unità di scala	140.000	20.000	2,000,000

Le unità di scala 2-10, durante le operazioni di manutenzione, mantengono la velocità effettiva aggregata. Tuttavia, l'unità di scala 1, durante un'operazione di manutenzione, può visualizzare una leggera variazione dei numeri di velocità effettiva.

Se si connette un circuito Locale ExpressRoute a un hub della rete WAN virtuale, sarà possibile accedere solo alle aree nella stessa località metropolitana del circuito locale?

I circuiti locali possono essere connessi solo ai gateway ExpressRoute nella rispettiva area di Azure. Non esiste tuttavia alcuna limitazione per instradare il traffico alle reti virtuali spoke in altre aree.

Perché il router dell'hub virtuale richiede un indirizzo IP pubblico con porte aperte?

Questi endpoint pubblici sono necessari per la piattaforma SDN e la gestione sottostante di Azure per comunicare con il router dell'hub virtuale. Poiché il router dell'hub virtuale è considerato parte della rete privata del cliente, la piattaforma sottostante di Azure non è in grado di accedere direttamente e gestire il router hub tramite gli endpoint privati a causa dei requisiti di conformità. La connettività agli endpoint pubblici del router hub viene autenticata tramite certificati e Azure esegue controlli di sicurezza di routine di questi endpoint pubblici. Di conseguenza, non costituiscono un'esposizione alla sicurezza dell'hub virtuale.

Esiste un limite di route per i client OpenVPN che si connettono a un gateway P2S VPN di Azure?

Il limite di route per i client OpenVPN è 1000.

Come viene calcolato il contratto di servizio della rete WAN virtuale?

La rete WAN virtuale è una piattaforma di rete distribuita come servizio con un contratto di servizio del 99,95%. Tuttavia, la rete WAN virtuale combina molti componenti diversi, ad esempio Firewall di Azure, VPN da sito a sito, ExpressRoute, VPN da punto a sito e appliance virtuali di rete WAN virtuale/appliance virtuali di rete virtuale.

Il contratto di servizio per ogni componente viene calcolato singolarmente. Ad esempio, se ExpressRoute ha un tempo di inattività di 10 minuti, la disponibilità di ExpressRoute verrà calcolata come (Numero massimo di minuti disponibili - tempo di inattività) / Minuti massimi disponibili * 100.

È possibile modificare lo spazio degli indirizzi della rete virtuale in una rete virtuale spoke connessa all'hub?

Sì, questa operazione può essere eseguita automaticamente senza aggiornare o reimpostare la connessione di peering. Tenere presente quanto segue:

Non è necessario fare clic sul pulsante "Sincronizza" nel pannello Peering. Dopo aver modificato lo spazio degli indirizzi della rete virtuale, il peering reti virtuali verrà sincronizzato automaticamente con la rete virtuale dell'hub virtuale.
Assicurarsi che lo spazio indirizzi aggiornato non si sovrapponga allo spazio indirizzi per le reti virtuali spoke esistenti nella rete WAN virtuale.

Altre informazioni su come modificare lo spazio degli indirizzi della rete virtuale sono disponibili qui.

Qual è il numero massimo di indirizzi di rete virtuale spoke supportati per gli hub configurati con finalità di routing?

Il numero massimo di spazi indirizzi in tutte le reti virtuali direttamente connessi a un singolo hub della rete WAN virtuale è 400. Questo limite si applica singolarmente a ogni hub della rete WAN virtuale in una distribuzione della rete WAN virtuale. Gli spazi indirizzi della rete virtuale connessi a hub remoti (altri hub della rete WAN virtuale nella stessa rete WAN virtuale) non vengono conteggiati per questo limite.

Questo limite è regolabile. Per altre informazioni sul limite, la procedura per richiedere un aumento del limite e script di esempio per determinare il numero di spazi di indirizzi tra reti virtuali connesse a un hub della rete WAN virtuale, vedere i limiti dello spazio degli indirizzi della rete virtuale per la finalità di routing.

Manutenzione del gateway controllato dal cliente della rete WAN virtuale

Quali servizi sono inclusi nell'ambito della configurazione di manutenzione dei gateway di rete?

Per la rete WAN virtuale, è possibile configurare finestre di manutenzione per gateway VPN da sito a sito e gateway ExpressRoute.

Quale manutenzione è supportata o non è supportata dalla manutenzione controllata dal cliente?

I servizi di Azure passano attraverso aggiornamenti periodici di manutenzione per migliorare funzionalità, affidabilità, prestazioni e sicurezza. Dopo aver configurato una finestra di manutenzione per le risorse, la manutenzione del sistema operativo guest e del servizio vengono eseguite durante tale finestra. Questi aggiornamenti riguardano la maggior parte degli elementi di manutenzione che interessano i clienti.

Gli aggiornamenti dell'infrastruttura dell'host e del data center sottostanti non sono coperti dalla manutenzione controllata dal cliente. Inoltre, se si verifica un problema di sicurezza con gravità elevata che potrebbe compromettere i clienti, Azure potrebbe dover eseguire l'override del controllo cliente della finestra di manutenzione e implementare la modifica. Si tratta di eventi rari a cui si fa ricorso solo in casi estremi.

È possibile ricevere una notifica avanzata della manutenzione?

Al momento, la notifica avanzata non può essere abilitata per la manutenzione delle risorse del gateway di rete.

È possibile configurare una finestra di manutenzione più breve di cinque ore?

Al momento, è necessario configurare una finestra minima di cinque ore nel fuso orario preferito.

È possibile configurare una pianificazione di manutenzione che non si ripete ogni giorno?

In questo momento, è necessario configurare una finestra di manutenzione giornaliera.

Le risorse di configurazione della manutenzione devono trovarsi nella stessa area della risorsa del gateway?

Sì.

È necessario distribuire un'unità di scala gateway minima per essere idonea per la manutenzione controllata dal cliente?

No.

Quanto tempo è necessario per rendere effettivi i criteri di configurazione della manutenzione dopo l'assegnazione alla risorsa del gateway?

Potrebbero essere necessarie fino a 24 ore prima che i gateway di rete seguano la pianificazione della manutenzione dopo che i criteri di manutenzione sono stati associati alla risorsa del gateway.

Come pianificare le finestre di manutenzione quando si usa VPN ed ExpressRoute in uno scenario di coesistenza?

Quando si usano VPN ed ExpressRoute in uno scenario di coesistenza o ogni volta che si dispone di risorse che fungono da backup, è consigliabile configurare finestre di manutenzione separate. Questo approccio garantisce che la manutenzione non influisca contemporaneamente sulle risorse di backup.

È stata pianificato una finestra di manutenzione per una data futura per una risorsa. Le attività di manutenzione verranno sospese su questa risorsa fino ad allora?

No, le attività di manutenzione non verranno sospese nella risorsa durante il periodo che precede la finestra di manutenzione pianificata. Per i giorni non coperti nel programma di manutenzione, la manutenzione continua come di consueto nella risorsa.

Sono previsti limiti per i numeri di route pubblicabili?

Sì, esistono limiti. ExpressRoute supporta al massimo 4.000 prefissi per il peering privato e 200 per il peering Microsoft. Con ExpressRoute Premium è possibile aumentare il limite a 10.000 route per il peering privato. Il numero massimo di route annunciate dal peering privato di Azure tramite un gateway ExpressRoute su un circuito ExpressRoute è 1.000 e tale valore è uguale per i circuiti ExpressRoute Standard e Premium. Per altri dettagli, è possibile esaminare i limiti di route dei circuiti ExpressRoute nella pagina Limiti e quote delle sottoscrizioni di Azure. Si noti che gli annunci di route IPv6 non sono attualmente supportati con la rete WAN virtuale.

Sono previste limitazioni per gli intervalli IP pubblicabili tramite la sessione BGP?

Sì, esistono restrizioni. I prefissi privati (RFC1918) non sono accettati nella sessione BGP per il peering Microsoft. Tuttavia, qualsiasi dimensione del prefisso fino a un prefisso /32 viene accettata sia nel peering Microsoft che nel peering privato.

Cosa accade se viene superato il limite di route BGP?

Se viene superato il limite di route BGP, le sessioni BGP si disconnetteranno. Le sessioni verranno ripristinate dopo la riduzione del numero di prefissi al di sotto del limite. Per altre informazioni, vedere i limiti di route dei circuiti ExpressRoute nella pagina Limiti e quote della sottoscrizione di Azure.

È possibile monitorare il numero di route annunciate o ricevute tramite un circuito ExpressRoute?

Si, puoi. Per le procedure consigliate e la configurazione per il monitoraggio degli avvisi basati sulle metriche, fare riferimento alle procedure consigliate per il monitoraggio di Azure.

Qual è la raccomandazione per ridurre il numero di prefissi IP?

È consigliabile aggregare i prefissi prima di annunciarli tramite ExpressRoute o gateway VPN. Inoltre, è possibile usare Mappe di route per riepilogare le route annunciate da/verso la rete WAN virtuale.

È possibile usare tabelle di route definite dall'utente in Rete virtuale spoke connesse all'hub rete WAN virtuale?

Sì. Le route che rete WAN virtuale hub annunciano alle risorse distribuite nei Rete virtuale spoke connessi sono route di tipo Border Gatway Protocol (BGP). Se una tabella di route definita dall'utente è associata a una subnet connessa a rete WAN virtuale, l'impostazione "Propaga route gateway" deve essere impostata su "Sì" per rete WAN virtuale annunciare le risorse distribuite in tale subnet. La piattaforma di rete software-defined sottostante di Azure usa l'algoritmo seguente per selezionare le route in base all'algoritmo di selezione della route di Azure.

Passaggi successivi

Per altre informazioni sulla rete WAN virtuale, vedere Informazioni sulla rete WAN virtuale.

Condividi tramite