Condividi tramite

Informazioni sui gateway di rete virtuale per ExpressRoute

Un gateway di rete virtuale connette la rete virtuale di Azure alla rete locale tramite Azure ExpressRoute. Il gateway svolge due scopi chiave: lo scambio di route IP tra reti e il routing del traffico di rete tra di essi.

Questo articolo illustra i tipi di gateway, gli SKU del gateway, le prestazioni stimate per SKU e le funzionalità principali. Illustra anche la funzione FastPath di ExpressRoute, che consente al traffico di rete proveniente dalla rete locale di ignorare il gateway di rete virtuale per migliorare le prestazioni.

Codici SKU del gateway

Quando si crea un gateway di rete virtuale è necessario specificare il codice SKU del gateway da usare. Quando si seleziona uno SKU gateway superiore, al gateway vengono allocate più CPU e larghezza di banda di rete. Di conseguenza, il gateway può supportare una velocità effettiva di rete superiore alla rete virtuale.

I gateway di rete virtuale ExpressRoute possono usare i seguenti SKU:

È possibile aggiornare il gateway a uno SKU con capacità superiore all'interno della stessa famiglia di SKU (zona non di disponibilità o abilitata per la zona di disponibilità). Per esempio:

  • Eseguire l'aggiornamento da uno SKU della zona non di disponibilità a un altro SKU di zona non di disponibilità
  • Eseguire l'aggiornamento da uno SKU abilitato per la zona di disponibilità a un altro SKU abilitato per la zona di disponibilità

Per tutti gli altri scenari, inclusi i downgrade o il passaggio tra i tipi di zona di disponibilità, è necessario eliminare e ricreare il gateway. Questo processo comporta tempi di inattività.

Subnet gateway

Prima di creare un gateway ExpressRoute, è necessario creare una subnet del gateway. La subnet del gateway contiene gli indirizzi IP usati dalle macchine virtuali e dai servizi del gateway di rete virtuale.

Quando si crea il gateway di rete virtuale, Azure distribuisce le macchine virtuali del gateway nella subnet del gateway e le configura con le impostazioni di ExpressRoute necessarie. Non distribuire mai altri elementi nella subnet del gateway. La subnet del gateway deve essere denominata GatewaySubnet affinché Azure la riconosca e distribuisca correttamente i componenti del gateway.

Note

  • Le route definite dall'utente con una destinazione 0.0.0.0/0 e i gruppi di sicurezza di rete (NSG) nella subnet del gateway non sono supportati. Le route definite dall'utente, che contengono lo spazio indirizzi di GatewaySubnet, con hop successivo impostato su "nessuno" o con hop successivo impostato su NVA (che include un criterio per eliminare il traffico), non sono supportate. I gateway con questa configurazione non vengono creati. Per il corretto funzionamento è necessario che i gateway possano accedere ai controller di gestione. La propagazione della route BGP (Border Gateway Protocol) deve essere abilitata nella subnet del gateway per garantire la disponibilità del gateway. Se la propagazione della route BGP è disabilitata, il gateway non funzionerà.

  • La diagnostica, il percorso dati e il percorso di controllo possono essere interessati se una route definita dall'utente si sovrappone all'intervallo di subnet del gateway o all'intervallo IP pubblico del gateway.

Non distribuire Resolver privato DNS di Azure in una rete virtuale che disponga di un gateway di rete virtuale ExpressRoute, con regole di carattere jolly che indirizzano tutta la risoluzione dei nomi a un server DNS specifico. Questa configurazione può causare problemi di connettività di gestione.

Dimensioni della subnet del gateway

Quando si crea la subnet del gateway, si specifica il numero di indirizzi IP che contiene. Le macchine virtuali e i servizi del gateway usano questi indirizzi IP. Alcune configurazioni richiedono più indirizzi IP di altre.

Quando si pianificano le dimensioni della subnet del gateway, vedere la documentazione relativa alla configurazione specifica. Ad esempio, le configurazioni di coesistenza del gateway ExpressRoute/VPN richiedono subnet gateway di dimensioni maggiori rispetto alla maggior parte delle altre configurazioni. È consigliabile creare una subnet del gateway in grado di supportare le possibili configurazioni future.

Raccomandazioni:

  • Creare una subnet di gateway pari a 27 o superiore per la maggior parte delle configurazioni.
  • Se si prevede di connettere 16 circuiti ExpressRoute al gateway, è necessario creare una subnet del gateway di /26 o superiore.
  • Per le subnet di gateway dual stack, raccomandiamo un intervallo IPv6 di /64 o più grande.

L'esempio seguente di PowerShell di Azure Resource Manager mostra una subnet gateway denominata GatewaySubnet. La notazione CIDR specifica un /27, che fornisce indirizzi IP sufficienti per la maggior parte delle configurazioni.

Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.3.0/27

Important

I gruppi di sicurezza di rete nella subnet del gateway non sono supportati. Se si associa un gruppo di sicurezza di rete a tale subnet, il gateway della rete virtuale (VPN e gateway Express Route) potrebbe smettere di funzionare come previsto. Per altre informazioni sui gruppi di sicurezza di rete, vedere Che cos'è un gruppo di sicurezza di rete.

Limitazioni e prestazioni del gateway

Supporto delle funzionalità per SKU del gateway

La tabella seguente illustra le funzionalità supportate da ogni SKU del gateway e il numero massimo di connessioni del circuito ExpressRoute.

SKU del gateway Coesistenza di VPN ed ExpressRoute FastPath Numero massimo di connessioni di circuito
Standard/ERGw1Az Yes No 4
Prestazioni elevate/ERGw2Az Yes No 8
Prestazioni Ultra/ErGw3Az Yes Yes 16
ErGwScale Yes Sì (minimo 10 unità di scala) 4 (minimo 1 unità di scala)
8 (minimo 2 unità di scala)
16 (minimo 10 unità di scala)

Note

Il numero massimo di circuiti ExpressRoute dallo stesso percorso di peering che può connettersi alla medesima rete virtuale è 4 per tutti i gateway.

Prestazioni stimate per SKU del gateway

Le tabelle seguenti forniscono una panoramica dei diversi tipi di gateway, delle rispettive limitazioni e delle relative metriche delle prestazioni previste.

Limiti massimi supportati

Questa tabella si applica sia ai modelli di distribuzione di Azure Resource Manager che a quelli di distribuzione classica.

SKU del gateway Megabit al secondo Pacchetti al secondo Numero di macchine virtuali supportate nella rete virtuale 1 Limite di numero di flussi Numero di route apprese dal gateway
Standard/ERGw1Az 1,000 100,000 2,000 200,000 4,000
Prestazioni elevate/ERGw2Az 2,000 200,000 4,500 400,000 9,500
Prestazioni Ultra/ErGw3Az 10,000 1,000,000 11,000 1,000,000 9,500
ErGwScale (per unità di scala 1-10) 1.000 per unità di scala 100.000 per unità di scala 2.000 per unità di scala 100.000 per unità di scala 9.500 totali per gateway
ErGwScale (per unità di scala 11-40) 1.000 per unità di scala 200.000 per unità di scala 1.000 per unità di scala 100.000 per unità di scala 9.500 totali per gateway

1 I valori nella tabella sono stime e variano a seconda dell'utilizzo della CPU del gateway. Se l'utilizzo della CPU è elevato e viene superato il numero di macchine virtuali supportate, il gateway inizierà a eliminare i pacchetti.

Note

ExpressRoute può facilitare fino a 11.000 route che si estendono su spazi di indirizzi di rete virtuale, reti locali e connessioni di peering di rete virtuale pertinenti. Per garantire la stabilità della connessione ExpressRoute, evitare di pubblicizzare più di 11.000 route a ExpressRoute. Il numero massimo di route annunciate dal gateway è 1.000 route.

Important

  • Le prestazioni dell'applicazione dipendono da più fattori, ad esempio la latenza end-to-end e il numero di flussi di traffico aperti dall'applicazione. I numeri nella tabella rappresentano il limite massimo che l'applicazione può raggiungere in teoria in un ambiente ideale. Inoltre, viene eseguita la manutenzione di routine dell'host e del sistema operativo nel gateway di rete virtuale ExpressRoute per mantenere l'affidabilità del servizio. Durante un periodo di manutenzione la capacità del piano di controllo e del percorso dati del gateway viene ridotta.
  • Durante un periodo di manutenzione, è possibile che si verifichino problemi di connettività intermittenti alle risorse dell'endpoint privato.
  • ExpressRoute supporta una dimensione massima di pacchetti TCP e UDP di 1.400 byte. I pacchetti frammentati non sono supportati dai gateway ExpressRoute. Modificare l'applicazione per evitare la frammentazione IP. Se è necessario il supporto della frammentazione IP, abilitare la funzionalità FastPath expressRoute per ignorare il gateway ExpressRoute.
  • Il server di route di Azure può supportare fino a 4.000 macchine virtuali. Questo limite include le macchine virtuali nelle reti virtuali con peering. Per altre informazioni, vedere limitazioni del server di route di Azure.
  • I valori nella tabella precedente rappresentano i limiti di ogni SKU del gateway.

IP pubblico assegnato automaticamente

La funzionalità IP pubblico assegnata automaticamente semplifica la distribuzione del gateway ExpressRoute consentendo a Microsoft di gestire l'indirizzo IP pubblico richiesto per conto dell'utente. Per PowerShell e Command-Line Interface (CLI), non è più necessario creare o gestire una risorsa IP pubblica separata per il gateway.

Screenshot della creazione di un gateway di rete virtuale per ExpressRoute.

Quando l'indirizzo IP pubblico assegnato automaticamente è abilitato, la pagina Panoramica del gateway ExpressRoute non mostra più un campo Indirizzo IP pubblico. Ciò significa che l'INDIRIZZO IP pubblico del gateway viene automaticamente sottoposto a provisioning e gestito da Microsoft.

Screenshot della panoramica del gateway di rete virtuale per ExpressRoute.

Vantaggi principali:

  • Sicurezza migliorata: L'indirizzo IP pubblico viene gestito internamente da Microsoft e non è esposto all'utente, riducendo i rischi associati alle porte di gestione aperte.
  • Complessità ridotta: Non è più necessario effettuare il provisioning o gestire una risorsa IP pubblica.
  • Distribuzione semplificata: Azure PowerShell e l'interfaccia della riga di comando non richiedono più un indirizzo IP pubblico durante la creazione del gateway.

Funzionamento:

Quando si crea un gateway ExpressRoute, Microsoft effettua automaticamente il provisioning e gestisce l'indirizzo IP pubblico in una sottoscrizione back-end sicura. Questo indirizzo IP viene incapsulato all'interno della risorsa gateway, consentendo a Microsoft di applicare criteri come i limiti della frequenza dei dati e migliorare la controllabilità. In precedenza era possibile creare la risorsa IP pubblica come risorsa di zona che assicurava che tutte le istanze del gateway in tale zona condividevano lo stesso indirizzo IP pubblico. Il nuovo comportamento è che il gateway è sempre con ridondanza di zona.

Availability:

L'indirizzo IP pubblico assegnato automaticamente non è disponibile per le distribuzioni della rete WAN virtuale (vWAN) o della zona estesa.

Connettività dalla rete virtuale alla rete virtuale e dalla rete virtuale alla rete WAN virtuale

Per impostazione predefinita, la connettività da rete virtuale a rete virtuale e da rete virtuale a rete WAN virtuale è disabilitata tramite un circuito ExpressRoute per tutti gli SKU del gateway. Per abilitare questa connettività, è necessario configurare il gateway di rete virtuale ExpressRoute per consentire questo traffico. Per altre informazioni, vedere indicazioni sulla connettività di rete virtuale tramite ExpressRoute. Per abilitare questo traffico, vedere Abilitare la connettività da rete virtuale a rete virtuale o da rete virtuale a rete WAN virtuale tramite ExpressRoute.

FastPath

ExpressRoute FastPath migliora le prestazioni del percorso dati tra la rete locale e la rete virtuale. Se abilitata, FastPath invia il traffico di rete direttamente alle macchine virtuali nella rete virtuale, ignorando il gateway.

Per altre informazioni su FastPath, incluse limitazioni e requisiti, vedere Informazioni su FastPath.

Connettività dell'endpoint privato

Il gateway di rete virtuale ExpressRoute facilita la connettività agli endpoint privati distribuiti nella stessa rete virtuale e tra reti virtuali con peering.

Important

  • La capacità del piano di controllo e velocità effettiva per la connettività alle risorse dell'endpoint privato potrebbe essere ridotta di metà rispetto alla connettività alle risorse dell'endpoint non privato.
  • Durante un periodo di manutenzione, è possibile che si verifichino problemi di connettività intermittenti alle risorse dell'endpoint privato.
  • È necessario assicurarsi che la configurazione locale, incluse le impostazioni del router e del firewall, sia configurata correttamente per assicurarsi che i pacchetti per i transiti IP a 5 tuple usino un singolo hop successivo (router Microsoft Enterprise Edge) a meno che non sia presente un evento di manutenzione. Se la configurazione del firewall o del router locale dell'utente causa spesso l'uso di un hop successivo diverso per lo stesso IP a 5 tuple, si riscontreranno problemi di connettività.
  • Assicurarsi che i criteri di rete (almeno, per il supporto UDR) siano abilitati nelle subnet in cui sono distribuiti gli endpoint privati

Connettività dell'endpoint privato ed eventi di manutenzione pianificata

La connettività dell'endpoint privato è con stato. Quando si stabilisce una connessione a un endpoint privato tramite peering privato ExpressRoute, l'infrastruttura del gateway instrada le connessioni in ingresso e in uscita attraverso una delle sue istanze back-end. Durante gli eventi di manutenzione, le istanze back-end si riavviano una alla volta, causando problemi di connettività intermittenti.

Per evitare o ridurre al minimo i problemi di connettività con gli endpoint privati durante le attività di manutenzione, impostare il valore di timeout TCP compreso tra 15 e 30 secondi nelle applicazioni locali. Testare e configurare il valore ottimale in base ai requisiti dell'applicazione.

API REST e cmdlet PowerShell

Per le risorse tecniche e requisiti di sintassi specifici quando si usano le API REST e i cmdlet di PowerShell per le configurazioni del gateway di rete virtuale, vedere:

Classic Gestore delle Risorse
PowerShell PowerShell
REST API REST API

Connettività da rete virtuale a rete virtuale

Per impostazione predefinita, la connettività tra reti virtuali è abilitata quando si collegano più reti virtuali allo stesso circuito ExpressRoute. Non è consigliabile usare il circuito ExpressRoute per la comunicazione tra reti virtuali. È invece consigliabile usare il peering di reti virtuali. Per altre informazioni sul motivo per cui la connettività da rete virtuale a rete virtuale non è consigliata tramite ExpressRoute, vedere Connettività tra reti virtuali tramite ExpressRoute.

I limiti del peering delle reti virtuali

Una rete virtuale con un gateway ExpressRoute può avere un peering di rete virtuale con un massimo di 500 altre reti virtuali. Le reti virtuali senza un gateway ExpressRoute potrebbero avere limiti di peering più elevati.

Contenuti correlati

  • Last updated on