Training
Modulo
Connettere la rete locale alla rete globale Microsoft con ExpressRoute - Training
Connettere sistemi e utenti locali ad Azure e Office 365 con ExpressRoute per una connettività privata, dedicata e con velocità effettiva garantita.
Domande frequenti su ExpressRoute
ExpressRoute è un servizio di Azure che consente di creare connessioni private tra i data center Microsoft e l'infrastruttura presente nella struttura locale o in una struttura di condivisione.
Le connessioni ExpressRoute non passano attraverso la rete Internet pubblica. Esse offrono un livello di sicurezza superiore, maggiore affidabilità, velocità più elevate e latenze minori e coerenti rispetto alle connessioni Internet tradizionali. In alcuni casi, l'uso di connessioni ExpressRoute per trasferire dati tra dispositivi locali e Azure può produrre vantaggi significativi in termini di costi.
Per informazioni sulla località e la disponibilità del servizio, vedere Partner e località per ExpressRoute.
In che modo è possibile usare ExpressRoute per connettersi a Microsoft in assenza di una relazione con uno dei partner del gestore ExpressRoute?
È possibile selezionare un gestore telefonico regionale e creare connessioni Ethernet in una delle località supportate dal provider di Exchange e quindi eseguire il peering con Microsoft nella località del provider. Vedere Connessione tramite un altro provider di servizi per verificare se il provider di servizi è presente in una delle località di Exchange. È possibile ordinare un circuito ExpressRoute tramite il provider di servizi per connettersi ad Azure.
Per una suddivisione dei costi di ExpressRoute vedere i Dettagli sui prezzi.
La larghezza di banda per ExpressRoute è allocata separatamente per il traffico in ingresso e in uscita?
Sì, la larghezza di banda del circuito ExpressRoute è duplex. Ad esempio, acquistando un circuito ExpressRoute da 200 Mbps, si dispone di 200 Mbps per il traffico in ingresso e 200 Mbps per il traffico in uscita.
È necessario acquistare una connessione privata con la stessa velocità del circuito ExpressRoute acquistato?
No. È possibile acquistare una connessione privata di qualsiasi velocità dal provider di servizi. Tuttavia, la connessione ad Azure è limitata alla larghezza di banda del circuito ExpressRoute acquistato.
È possibile usare una altra larghezza di banda oltre a quella acquistata per il circuito ExpressRoute?
Sì, è possibile usare fino a due volte il limite di larghezza di banda acquistato distribuendo il traffico in entrambi i collegamenti del circuito ExpressRoute; così si può usare la larghezza di banda ridondante disponibile. La ridondanza predefinita del circuito viene configurata usando i collegamenti ridondanti, ognuno con la larghezza di banda acquistata, ai due router Microsoft Enterprise Edge (MSEE). La larghezza di banda disponibile tramite il collegamento secondario può essere usata per altro traffico, se necessario. Poiché il secondo collegamento è pensato per la ridondanza, non è garantito e non deve essere usato per il traffico aggiuntivo per un periodo di tempo prolungato. Per altre informazioni su come usare entrambe le connessioni per trasmettere il traffico, vedere Anteposizione percorso di routing asimmetrico.
Se si prevede di usare solo il collegamento primario per trasmettere il traffico, la larghezza di banda per la connessione è fissa e il tentativo di ricorrere all’oversubscription comporta maggiori rilasci di pacchetti. Se il traffico passa attraverso un gateway ExpressRoute, la larghezza di banda per lo SKU del gateway è fissa e non consente il burst. Per la larghezza di banda di ciascuno SKU del gateway vedere Informazioni sui gateway della rete virtuale ExpressRoute.
Acquistando il piano dati senza limiti, si disporrà di un trasferimento dei dati in uscita senza limiti anche per le connessioni ai servizi tramite peering Microsoft?
Se ci si connette a un servizio tramite peering Microsoft con un piano dati senza limiti, ExpressRoute non addebiterà solo i dati in uscita. I dati in uscita verranno comunque addebitati per servizi come il calcolo, l’archiviazione o altri servizi a cui si accede tramite peering Microsoft, anche se la destinazione è un indirizzo IP pubblico del peering Microsoft.
Si possono usare contemporaneamente la stessa connessione di rete privata con la rete virtuale e altri servizi di Azure?
Sì. Dopo l'installazione, il circuito ExpressRoute consente di accedere ai servizi all'interno di una rete virtuale e ad altri servizi di Azure contemporaneamente. La connessione alle reti virtuali viene eseguita tramite il percorso di peering privato e ad altri servizi tramite il percorso di peering Microsoft.
Il gateway ExpressRoute annuncia gli Spazi indirizzi della rete virtuale di Azure e non è possibile includere/escludere a livello di subnet. Viene annunciato sempre lo spazio indirizzi della rete virtuale. Se viene usato il peering di rete virtuale e nella rete virtuale con peering è abilitato "Usa gateway remoto", vengono annunciati anche gli spazi indirizzi della rete virtuale con peering.
Quanti prefissi possono essere annunciati da una rete virtuale alla rete locale nel peering privato ExpressRoute?
Possono essere annunciati fino a un massimo di 1000 prefissi IPv4 in una connessione ExpressRoute singola o tramite peering di rete virtuale usando il transito tramite gateway. Se, ad esempio si dispone di 999 spazi indirizzi in una singola rete virtuale connessa a un circuito ExpressRoute, tutti i 999 prefissi vengono annunciati nella rete locale. In alternativa, se è abilitata una rete virtuale per consentire il transito tramite gateway con 1 spazio indirizzi e 500 reti virtuali spoke abilitate con l'opzione "Consenti gateway remoto", la rete virtuale distribuita con il gateway annuncia 501 prefissi nella rete locale.
Se si usa un circuito dual stack, è previsto un numero massimo di 100 prefissi IPv6 in una connessione ExpressRoute singola o tramite peering di rete virtuale usando il transito tramite gateway. Questo limite si aggiunge ai limiti descritti in precedenza.
La connessione tra il circuito ExpressRoute e il gateway si interrompe, inclusa la rete virtuale con peering che usa il transito tramite gateway. La connettività viene ristabilita quando il limite di prefissi non viene più superato.
Come è possibile modificare il numero di prefissi annunciati al gateway per assicurarsi che sia entro il limite massimo?
ExpressRoute supporta fino a 11.000 route, che coprono spazi di indirizzi di rete virtuale, reti locali e connessioni di peering di rete virtuale. Se il gateway ExpressRoute supera questo limite, aggiornare i prefissi in modo che siano compresi nell'intervallo consentito.
Per apportare questa modifica nel portale di Azure:
- Passare alla risorsa advisor e selezionare il pilastro "Prestazioni".
- Fare clic sul suggerimento "Max prefix reached for ExpressRoute Gateway" (Numero massimo di prefisso raggiunto per il gateway ExpressRoute).
- Selezionare il gateway con questa raccomandazione.
- Nella risorsa Gateway selezionare la "rete virtuale" a cui è collegato il gateway
- Nella risorsa Rete virtuale selezionare il pannello "Spazio indirizzi" in Impostazioni nel menu a sinistra
- Ridurre lo spazio indirizzi annunciato entro il limite
L'unico modo per filtrare/includere le route è nel router della rete perimetrale locale. Alla rete virtuale è possibile aggiungere route definite dall'utente che interessano un routing specifico, ma è un'operazione statica e non fa parte dell'annuncio BGP.
Per informazioni vedere il Contratto di servizio di ExpressRoute.
ExpressRoute supporta due domini di routing per vari tipi di servizi: peering privato e peering Microsoft.
Supportati:
- Reti virtuali, incluse tutte le macchine virtuali e i servizi cloud, ad esempio RDP Shortpath per Desktop virtuale Azure
Se il circuito ExpressRoute è abilitato per il peering Azure Microsoft, è possibile accedere agli intervalli di indirizzi IP pubblici usati in Azure nel circuito. Il peering Azure Microsoft fornisce l’accesso ai servizi attualmente ospitati in Azure (con restrizioni geografiche in base allo SKU del circuito). Per verificare la disponibilità di un servizio specifico, è possibile controllare la documentazione relativa a tale servizio e verificare se è stato pubblicato un intervallo riservato per tale servizio. Quindi cercare gli intervalli di indirizzi IP del servizio di destinazione e confrontarli con quelli elencati in Azure IP Ranges and Service Tags – Public Cloud XML file. In alternativa, è possibile aprire un ticket di supporto per il servizio in questione per ottenere chiarimenti.
Supportati:
- Microsoft 365
- Power BI - Disponibile tramite una community regionale di Azure. Vedere qui per trovare informazioni su come scoprire la regione del tenant Power BI.
- Microsoft Entra ID
- Azure DevOps (community di Servizi globali di Azure)
- Servizi PSTN Microsoft
- Indirizzi IP pubblici di Azure per IaaS (macchine virtuali, gateway di rete virtuale, servizi di bilanciamento del carico e così via)
- È supportata anche la maggior parte degli altri servizi di Azure. Contattare direttamente il servizio che si vuole usare per verificarne il supporto.
Non supportati:
- Rete CDN
- Frontdoor di Azure
- Server di autenticazione a più fattori (legacy)
- Gestione traffico
- App per la logica
- Intune
Perché durante la configurazione del peering Microsoft sullo stato di Prefissi pubblici annunciati viene visualizzato Convalida necessaria?
Microsoft verifica se i Prefissi pubblici annunciati e l’ ASN peer o l’ ASN cliente specificati vengono assegnati all'utente nel registro di routing Internet. Se si ricevono prefissi pubblici da un'altra entità e l'assegnazione non viene registrata nel registro di routing, la convalida automatica non viene completata. È necessaria la convalida manuale. Se la convalida automatica ha esito negativo, viene visualizzato il messaggio Convalida necessaria.
Se viene visualizzato il messaggio Convalida necessaria, raccogliere i documenti che dimostrano che i prefissi pubblici vengono assegnati all'organizzazione dall'entità elencata come proprietario dei prefissi nel registro di routing. Inviare quindi questi documenti per la convalida manuale aprendo un ticket di supporto.
Gli ambienti Dynamics 365 e Common Data Service (CDS) sono ospitati in Azure, di conseguenza i clienti traggono vantaggio dal supporto ExpressRoute sottostante per le risorse di Azure. È possibile connettersi agli endpoint servizio se il filtro del router include le aree di Azure in cui sono ospitati gli ambienti Dynamics 365/CDS.
Nota
ExpressRoute Premiumnon è obbligatorio per la connettività di Dynamics 365 tramite Azure ExpressRoute, se il circuito ExpressRoute viene distribuito nella stessa area geopolitica.
Non ci sono limiti alla quantità di dati trasferibili. Per informazioni sulle tariffe relative alle velocità della larghezza di banda, vedere Dettagli prezzi .
Offerte relative alle larghezze di banda supportate:
50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps
Nota
ExpressRoute supporta una coppia di connessioni incrociate con ridondanza. Se si supera la larghezza di banda configurata del circuito ExpressRoute in una connessione incrociata, il traffico sarà soggetto a una limitazione della velocità all'interno di tale connessione incrociata.
ExpressRoute supporta la MTU Internet standard di 1500 byte. Vedere Ottimizzazione delle prestazioni TCP/IP per le macchine virtuali di Azure per l'ottimizzazione dell'unità massima di trasmissione (MTU) delle macchine virtuali.
Per l'elenco dei provider di servizi e delle relative località, vedere Partner e località per ExpressRoute .
Per informazioni sui requisiti, vedere la pagina dei prerequisiti di ExpressRoute.
Sì. Ogni circuito ExpressRoute ha una coppia ridondante di connessioni incrociate configurate per garantire una disponibilità elevata.
In caso di errore di una delle connessioni incrociate, la connettività non verrà persa. È attualmente disponibile una connessione ridondante per supportare il carico della rete e offrire disponibilità elevata per il circuito ExpressRoute. Per ottenere resilienza a livello di circuito, è possibile anche creare un circuito in una sede di peering diversa.
È possibile connettere più circuiti ExpressRoute da località di peering diverse o fino a quattro connessioni dalla stessa località di peering per offrire disponibilità elevata nel caso in cui non sia più disponibile un circuito singolo. A questo punto è possibile assegnare pesi maggiori a una delle connessioni locali, affinché preferisca un circuito specifico. Si consiglia di configurare almeno due circuiti ExpressRoute per evitare singoli punti di guasto.
Vedere qui per la progettazione della disponibilità elevata e qui per la progettazione del ripristino di emergenza.
Si consiglia di usare il peering Microsoft per accedere ai servizi pubblici di Azure come Archiviazione di Azure, Azure SQL o il peering Microsoft per Microsoft 365 che aiuta a implementare più circuiti in località di peering diverse per evitare singoli punti di guasto. È possibile annunciare lo stesso prefisso in entrambi i circuiti e usare Anteposizione percorso di routing asimmetrico o annunciare prefissi diversi per determinare il percorso dalla rete locale.
Per la progettazione per la disponibilità elevata, vedere qui.
È possibile raggiungere la disponibilità elevata connettendo fino a 4 circuiti ExpressRoute nella stessa località di peering alla rete virtuale. È anche possibile connettere fino a 16 circuiti ExpressRoute in località di peering diverse alla rete virtuale. Ad esempio, Singapore e Singapore2. Se un circuito ExpressRoute si disconnette, la connettività esegue il failover su un altro circuito ExpressRoute. Per impostazione predefinita, il traffico in uscita dalla rete virtuale viene instradato sul routing ECMP (Equal-Cost-Multi-Path). È possibile usare il peso della connessione per preferire un circuito a un altro. Per altre informazioni, vedere Optimizing ExpressRoute Routing (Ottimizzazione del routing di ExpressRoute).
Nota
- Anche se è possibile connettere fino a 16 circuiti alla rete virtuale, il traffico in uscita dalla rete virtuale verrà sottoposto al bilanciamento del carico con Equal-Cost Multipath (ECMP) in un massimo di 4 circuiti.
- Equal-Cost Multipath (ECMP) in ExpressRoute usa il metodo di bilanciamento del carico per flusso (basato sul modello con tupla a cinque). Di conseguenza, al flusso di traffico tra una coppia di host di origine e di destinazione specificata viene garantito di fare lo stesso percorso, anche se sono disponibili più percorsi ECMP.
Come assicurarsi che il traffico destinato ai servizi pubblici di Azure come Archiviazione e SQL di Azure nel peering Microsoft o nel peering pubblico sia quello preferito nel percorso ExpressRoute?
Per assicurarsi che il percorso da locale ad Azure sia sempre il preferito nel circuito ExpressRoute, è necessario implementare l'attributo Preferenza locale nei router.
Per altre informazioni vedere Selezione del percorso BGP e configurazioni comuni del router.
Se non si condivide il percorso per Cloud Exchange e il provider di servizi offre una connessione punto a punto, è necessario ordinare due connessioni fisiche tra la rete locale e Microsoft?
Se il provider di servizi è in grado di stabilire due circuiti virtuali Ethernet sulla connessione fisica, è sufficiente una connessione fisica. La connessione fisica, ad esempio una fibra ottica, viene terminata su un dispositivo di livello 1 (L1) (vedere l'immagine). I due circuiti virtuali Ethernet sono contrassegnati con ID VLAN diversi, uno per il circuito primario e uno per quello secondario. Gli ID VLAN sono nell'intestazione Ethernet 802.1Q esterna. L'intestazione Ethernet 802.1Q interna, non indicata nella figura, viene mappata a un dominio di routing ExpressRoutespecifico.
No. Non sono supportate estensioni alla connettività di livello 2 in Azure.
Sì. La sottoscrizione può includere più di un circuito ExpressRoute. Il limite predefinito è impostato su 50. Se necessario, contattare il supporto tecnico Microsoft per aumentare il limite.
Sì. È possibile usare i circuiti ExpressRoute con molti provider di servizi. Ogni circuito ExpressRoute è associato a un solo provider di servizi.
Sono presenti due località di peering per ExpressRoute nella stessa area metropolitana, ad esempio Singapore e Singapore2. Quale località di peering devo scegliere per creare il mio circuito ExpressRoute?
Se il provider di servizi offre ExpressRoute in entrambe le località, è possibile contattare il provider e selezionare uno dei due siti per configurare ExpressRoute.
È possibile avere più circuiti ExpressRoute nella stessa area metropolitana? È possibile collegarli alla stessa rete virtuale?
Sì. È possibile avere più circuiti ExpressRoute con provider di servizi uguali o diversi. Se nell'area metropolitana sono presenti più località peer per ExpressRoute e i circuiti vengono creati in località peer diverse, è possibile collegarli alla stessa rete virtuale. Se i circuiti vengono creati nella stessa località di peering, è possibile collegare fino a 4 circuiti alla stessa rete virtuale.
I passaggi di base sono:
- Stabilire un circuito ExpressRoute e richiedere al provider di servizi di abilitarlo.
- L'utente o il provider deve configurare i peering BGP.
- Collegare la rete virtuale al circuito ExpressRoute.
Per altre informazioni, vedere Flussi di lavoro e stati di provisioning di un circuito ExpressRoute.
Sì. L'articolo Partner e località per ExpressRoute offre una panoramica dei limiti di connettività per un circuito ExpressRoute. La connettività per un circuito ExpressRoute è limitata a una singola area geopolitica. È possibile espandere la connettività per superare le aree geopolitiche abilitando la funzionalità Premium di ExpressRoute.
Sì. È possibile avere fino a 10 connessioni di reti virtuali in un circuito ExpressRoute Standard e fino a 100 in un circuito ExpressRoute Premium.
Sono disponibili più sottoscrizioni di Azure che contengono reti virtuali. È possibile connettere reti virtuali di sottoscrizioni distinte a un singolo circuito ExpressRoute?
Sì. È possibile collegare fino a 10 reti virtuali nella stessa sottoscrizione del circuito o diverse sottoscrizioni usando un singolo circuito ExpressRoute. Per aumentare questo limite, abilitare la funzionalità Premium di ExpressRoute. I costi relativi alla connettività e alla larghezza di banda per il circuito dedicato vengono addebitati al proprietario del circuito ExpressRoute e tutte le reti virtuali condividono la stessa larghezza di banda.
Per altre informazioni vedere Condivisione di un circuito ExpressRoute tra più sottoscrizioni.
Sono presenti più sottoscrizioni di Azure associate a diversi tenant Microsoft Entra o registrazioni Enterprise Agreement. È possibile connettere reti virtuali presenti in tenant separati e registrazioni a un singolo circuito ExpressRoute che non si trova nello stesso tenant o registrazione?
Sì. Le autorizzazioni di ExpressRoute possono estendersi a sottoscrizioni, tenant e registrazioni, senza richiedere alcuna configurazione aggiuntiva. I costi relativi alla connettività e alla larghezza di banda per il circuito dedicato vengono addebitati al proprietario del circuito ExpressRoute e tutte le reti virtuali condividono la stessa larghezza di banda.
Per altre informazioni vedere Condivisione di un circuito ExpressRoute tra più sottoscrizioni.
No. Dalla prospettiva del routing, tutte le reti virtuali collegate allo stesso circuito ExpressRoute appartengono allo stesso dominio di routing e non sono isolate le une dalle altre. Se è necessario l'isolamento delle route, creare un circuito ExpressRoute separato.
Sì. È possibile collegare una rete virtuale singola con un massimo di quattro circuiti ExpressRoute nella stessa località o fino a 16 circuiti ExpressRoute in località di peering diverse.
La configurazione di un criterio di endpoint di servizio (SEP) nella subnet del gateway non è consigliabile a causa di potenziali problemi, tra cui:
- Errori nella distribuzione del servizio gateway
- Problemi relativi alla scalabilità e alla correzione dei servizi
Sì. Se le route predefinite (0.0.0.0/0) o i prefissi di route Internet non vengono annunciati tramite la sessione BGP, è possibile connettersi a Internet da una rete virtuale collegata a un circuito ExpressRoute.
Sì. È possibile annunciare una route predefinita 0.0.0.0/0 per bloccare tutta la connettività Internet alle macchine virtuali distribuite all’interno di una rete virtuale e instradare tutto il traffico in uscita attraverso il circuito ExpressRoute.
Nota
Se la route annunciata 0.0.0.0/0 viene ritirata dalle route annunciate a causa di un'interruzione o di una configurazione errata, Azure fornirà una route di sistema alle risorse nella rete virtuale connessa per fornire accesso a Internet. Per garantire che il traffico in uscita verso Internet venga bloccato, si consiglia di posizionare un gruppo di sicurezza di rete in tutte le subnet con una regola di Negazione in uscita per il traffico Internet.
Se si pubblicano route predefinite, il traffico verso i servizi offerti tramite peering Microsoft, ad esempio l'archiviazione di Azure e database SQL, viene forzato verso l'istanza locale. È necessario configurare i router in modo che restituiscano il traffico ad Azure tramite il percorso di peering Microsoft o su Internet. Se è stato abilitato un endpoint di servizio per il servizio, il traffico verso il servizio non viene forzato in locale, ma rimane all'interno della rete backbone di Azure. Per altre informazioni sugli endpoint del servizio, vedere Endpoint servizio di rete virtuale.
Sì. Le macchine virtuali distribuite in reti virtuali connesse allo stesso circuito ExpressRoute possono comunicare tra loro. Si consiglia di configurare il Peering di reti virtuali in modo che faciliti questa comunicazione.
È possibile configurare una connessione VPN da sito a sito alla rete virtuale insieme a ExpressRoute?
Sì. ExpressRoute può coesistere con VPN da sito a sito. Vedere Configurare connessioni coesistenti ExpressRoute e da sito a sito.
Per abilitare il routing tra i rami connessi a ExpressRoute e i rami connessi a una connessione VPN da sito a sito, è necessario configurare Server di route di Azure.
L'indirizzo IP pubblico viene usato solo per la gestione interna e non costituisce un rischio per la sicurezza della rete virtuale.
Sì. ExpressRoute accetta al massimo 4000 prefissi per il peering privato e 200 per il peering Microsoft. È possibile aumentare il limite a 10.000 route per il peering privato quando si usa ExpressRoute Premium.
Nota
I prefissi pubblicitari ricevuti tramite peering Microsoft al peering privato comportano il rischio di superare i limiti di prefisso, poiché i prefissi Microsoft vengono aggiornati mensilmente e possono crescere in modo significativo. Per gestire questo problema, configurare Integrità dei servizi per esaminare gli aggiornamenti dei prefissi, implementare il monitoraggio per rilevare le modifiche e prendere in considerazione l'aggiornamento dello SKU o il riepilogo delle route per controllare il numero di prefissi annunciati dall'ambiente locale.
Nella sessione BGP per il peering Microsoft non vengono accettati i prefissi privati (RFC1918). Si accetta qualsiasi dimensione di prefisso (fino a 32) sia nel peering Microsoft che nel peering privato.
Le sessioni BGP si disconnettono. Le sessioni BGP vengono ripristinate dopo che il conteggio dei prefissi scende al di sotto del limite.
Il timer di blocco BGP è di 180 secondi. I messaggi keep-alive vengono inviati ogni 60 secondi. Questi valori sono fissi sul lato Microsoft e non è possibile modificarli. È possibile configurare diversi timer, e i parametri della sessione BGP verranno negoziati di conseguenza.
Sì, è possibile provare ad aumentare la larghezza di banda del circuito ExpressRoute nel portale di Azure o con PowerShell. Se è disponibile una capacità sufficiente sulla porta fisica in cui è stato creato il circuito, la modifica ha esito positivo.
Se la modifica ha esito negativo, significa che non è disponibile una capacità sufficiente sulla porta corrente ed è necessario creare un nuovo circuito ExpressRoute con una larghezza di banda superiore. Può anche significare che non è disponibile una capacità sufficiente in quella località e in questo caso non è possibile aumentare la larghezza di banda.
È necessario contattare il provider di connettività, affinché aggiornino le limitazioni all'interno delle reti e supportino l'incremento della larghezza di banda. Tuttavia, non è possibile ridurre la larghezza di banda del circuito ExpressRoute. È necessario creare un nuovo circuito ExpressRoute con larghezza di banda inferiore ed eliminare il circuito precedente.
È possibile aggiornare la larghezza di banda del circuito ExpressRoute tramite il portale di Azure, l'API REST, PowerShell o l'interfaccia della riga di comando di Azure.
Ricevimento di una notifica relativa alla manutenzione nel circuito ExpressRoute. Qual è l'effetto tecnico di questa manutenzione?
Se si utilizza il circuito in modalità attivo/attivo, si hanno interruzioni minime o nulle durante la manutenzione. La manutenzione viene eseguita sulle connessioni primarie e secondarie del circuito separatamente. Durante la manutenzione è possibile vedere un percorso di routing asimmetrico anteposto a una delle connessioni. La ragione è quella di spostare il traffico gradualmente da una connessione a un'altra. Non è necessario ignorare il percorso di routing asimmetrico più lungo, perché può causare un'interruzione del servizio. Si consiglia di configurare BFD per un failover BGP più veloce tra la connessione primaria e secondaria nel caso in cui venga rilevato un errore BGP durante la manutenzione. La manutenzione pianificata viene eseguita al di fuori dell'orario di ufficio nel fuso orario della località di peering e non è possibile selezionare i tempi di manutenzione.
Ricevimento di una notifica relativa a un aggiornamento software o alla manutenzione nel gateway ExpressRoute. Qual è l'effetto tecnico di questa manutenzione?
Si hanno interruzioni minime o nulle durante un aggiornamento software o una manutenzione nel gateway. Il gateway ExpressRoute è composto da più istanze che durante gli aggiornamenti vengono portate offline una alla volta. La velocità effettiva della rete potrebbe essere temporaneamente inferiore alla rete virtuale, ma il gateway stesso non subisce tempi di inattività.
Sono necessarie per la comunicazione dell'infrastruttura di Azure. Sono protette dai certificati di Azure. Senza certificati appropriati non è possibile stabilire una connessione alle porte.
Un gateway ExpressRoute è fondamentalmente un dispositivo multihomed con una scheda di interfaccia di rete connessa alla rete privata del cliente e una scheda di interfaccia di rete connessa alla rete pubblica. Le entità dell'infrastruttura di Azure non possono utilizzare le reti private del cliente per motivi di conformità, pertanto devono utilizzare gli endpoint pubblici per la comunicazione dell'infrastruttura. Gli endpoint pubblici vengono analizzati periodicamente dal controllo di sicurezza di Azure.
Il diagramma seguente mostra l'ambito di connettività di diversi SKU del circuito ExpressRoute. In questo esempio la rete locale è connessa a un sito di peering ExpressRoute a Londra. Con un circuito ExpressRoute con SKU locale è possibile connettersi alle risorse nelle aree di Azure nella stessa area metropolitana del sito di peering. In questo caso la rete locale può accedere alle risorse di Azure del Regno Unito meridionale tramite ExpressRoute. Per altre informazioni vedere Che cos'è ExpressRoute Local?. Quando si configura uno SKU standard del circuito ExpressRoute la connettività alle risorse di Azure si espande a tutte le aree di Azure in un'area geopolitica. Come mostra il diagramma, la rete locale può connettersi alle risorse in Europa occidentale e Francia centrale. Per consentire alla rete locale di accedere alle risorse a livello globale in tutte le aree di Azure, è necessario configurare uno SKU del circuito ExpressRoute Premium. Per altre informazioni vedere Che cos'è ExpressRoute Premium?.
ExpressRoute Premium è una raccolta delle funzionalità seguenti:
Aumento del limite delle tabelle di routing da 4000 a 10.000 route per il peering privato.
Incremento del numero di reti virtuali e connessioni di Copertura globale di ExpressRoute che possono essere abilitate per un circuito ExpressRoute (il valore predefinito è 10). Per altre informazioni, vedere la tabella Limiti di ExpressRoute.
Connettività a Microsoft 365
Connettività globale sulla rete di base Microsoft. È ora possibile collegare una VNet in un'area geopolitica a un circuito ExpressRoute in un'altra area.
Esempi:- È possibile collegare una VNet creata in Europa occidentale a un circuito ExpressRoute creato a Silicon Valley.
- Nel peering Microsoft vengono pubblicati i prefissi di altre aree geopolitiche, in modo che sia possibile, ad esempio, connettersi a SQL Azure in Europa occidentale da un circuito di Silicon Valley.
Quante reti virtuali e connessioni di Copertura globale di ExpressRoute è possibile abilitare su un circuito ExpressRoute se è stato abilitato ExpressRoute Premium?
Le tabelle seguenti illustrano i limiti di ExpressRoute e il numero di reti virtuali e connessioni di Copertura globale di ExpressRoute per ogni circuito ExpressRoute:
| Conto risorse | Limite |
|---|---|
| Circuiti ExpressRoute per ogni sottoscrizione | 50 (Inviare una richiesta di supporto per aumentare il limite) |
| Circuiti ExpressRoute per ogni area per sottoscrizione con Azure Resource Manager | 10 |
| Numero massimo di circuiti nella stessa posizione di peering collegata alla stessa rete virtuale | 4 |
| Numero massimo di circuiti ExpressRoute collegati alla stessa rete virtuale in diverse posizioni di peering | Standard/ERGw1Az - 4 High Perf / ERGw2Az - 8 Ultra Performance / ErGw3Az - 16 |
| Numero massimo di indirizzi IP per il circuito del provider ExpressRoute con Fastpath | 25,000 |
| Numero massimo di indirizzi IP per ExpressRoute Direct 10 Gbps con Fastpath | 100,000 |
| Numero massimo di indirizzi IP per ExpressRoute Direct 100 Gbps con Fastpath | 200.000 |
| Numero massimo di flussi per l'agente di raccolta traffico di ExpressRoute | 300.000 |
| Conto risorse | SKU locale/standard | SKU Premium |
|---|---|---|
| Numero massimo di route IPv4 locali annunciate tramite il peering privato di Azure al circuito ExpressRoute | 4.000 | 10,000 |
| Numero massimo di route locali IPv6 annunciate tramite il peering privato di Azure al circuito ExpressRoute | 100 | 100 |
| Numero massimo di route IPv4 Rete virtuale annunciate dal gateway al circuito ExpressRoute tramite peering privato di Azure | 1.000 | 1,000 |
| Numero massimo di route IPv6 Rete virtuale annunciate dal gateway al circuito ExpressRoute tramite peering privato di Azure | 100 | 100 |
| Numero massimo di route IPv4 annunciate al peering Microsoft dall'ambiente locale | 200 | 200 |
| Numero massimo di route IPv6 annunciate al peering Microsoft dall'ambiente locale | 200 | 200 |
| Dimensioni del circuito | SKU locale/standard | SKU Premium |
|---|---|---|
| 50 Mbps | 10 | 20 |
| 100 Mbps | 10 | 25 |
| 200 Mbps | 10 | 25 |
| 500 Mbps | 10 | 40 |
| 1 Gbps | 10 | 50 |
| 2 Gbps | 10 | 60 |
| 5 Gbps | 10 | 75 |
| 10 Gbps | 10 | 100 |
| 40 Gbps* | 10 | 100 |
| 100 Gbps* | 10 | 100 |
* Solo ExpressRoute Direct a 100 Gbps
Nota
Le connessioni di tipo Copertura globale vengono conteggiate rispetto al limite di connessioni di rete virtuale per ogni circuito ExpressRoute. Un circuito Premium a 10 Gbps, ad esempio, consentirebbe 5 connessioni di tipo Copertura globale e 95 connessioni ai gateway ExpressRoute oppure 95 connessioni di tipo Copertura globale connessioni e 5 connessioni ai gateway ExpressRoute o qualsiasi altra combinazione fino al limite di 100 connessioni per il circuito.
Le tabelle seguenti forniscono una panoramica dei diversi tipi di gateway, delle rispettive limitazioni e delle relative metriche delle prestazioni previste.
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-40) | 1.000 per unità di scala | 100.000 per unità di scala | 2.000 per unità di scala | 100.000 per unità di scala | 60.000 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.
Nota
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.
Importante
- 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 è 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. Le dimensioni dei pacchetti maggiori di 1.400 byte verranno frammentate.
- 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.
Le funzionalità di ExpressRoute Premium possono essere abilitate quando si attiva la funzionalità e possono essere arrestate tramite l'aggiornamento dello stato del circuito. È possibile abilitare ExpressRoute Premium in fase di creazione del circuito oppure chiamare l'API REST o il cmdlet di PowerShell.
È possibile disabilitare ExpressRoute Premium chiamando l'API REST o il cmdlet di PowerShell. È necessario assicurarsi di avere ridimensionato le esigenze di connettività per soddisfare i limiti predefiniti, prima di disabilitare ExpressRoute Premium. Se l'uso supera i limiti predefiniti, la richiesta di disabilitazione di ExpressRoute Premium avrà esito negativo.
No. Non è possibile selezionare le funzionalità. Quando si attiva ExpressRoute Premium, vengono abilitate tutte le funzionalità.
Per informazioni sui costi, vedere Dettagli prezzi .
È necessario un pagamento aggiuntivo per ExpressRoute Premium, oltre agli addebiti per la versione standard di ExpressRoute?
Sì. Gli addebiti per ExpressRoute Premium vengono sommati agli addebiti per ExpressRoute e agli addebiti richiesti dal provider di connettività.
ExpressRoute Local è uno SKU del circuito ExpressRoute che si aggiunge agli SKU Standard e Premium. Una funzionalità chiave di Local è che questo circuito in una località di peering ExpressRoute fornisce accesso solo a una o due aree di Azure nella stessa metropolitana o in una vicina. Al contrario, un circuito Standard offre accesso a tutte le aree di Azure in un'area geopolitica, mentre un circuito Premium fornisce accesso a tutte le aree di Azure a livello globale. In particolare, con uno SKU locale è possibile annunciare solo le route tramite Microsoft e il peering privato dall'area locale corrispondente del circuito ExpressRoute. Non si riceveranno route per altre aree diverse dall'area locale definita.
ExpressRoute Local può non essere disponibile per una località ExpressRoute. Per la località di peering e l'area locale di Azure supportata, vedere Località e provider di connettività.
Anche se per il circuito ExpressRoute Standard o Premium è necessario pagare il trasferimento dei dati in uscita, per il circuito ExpressRoute Local non occorre farlo separatamente. In altre parole, il prezzo di ExpressRoute Local include le tariffe per il trasferimento dei dati. ExpressRoute Local è una soluzione economica, se si dispone di grandi quantità di dati da trasferire e si vuole trasferirli tramite una connessione privata a una posizione di peering ExpressRoute vicino alle aree di Azure desiderate.
Un circuito ExpressRoute Local ha la stessa serie di funzionalità del circuito Standard, tranne:
- L'ambito di accesso alle aree di Azure è limitato a una o due aree di Azure vicino o nella stessa area metropolitana della località di peering ExpressRoute.
- Copertura globale di ExpressRoute non è disponibile nel circuito Local
ExpressRoute Local ha gli stessi limiti per quanto riguarda le risorse del circuito Standard.
Dove è disponibile ExpressRoute Local e a quali aree di Azure viene mappata ogni località di peering?
ExpressRoute Local è disponibile nelle località di peering in cui ci sono una o due aree di Azure vicine. Non è disponibile in località di peering di stati, province, paesi o regioni dove non sono presenti aree di Azure. Vedere i mapping esatti nella pagina Località di ExpressRoute.
Microsoft 365 è stato progettato per essere accessibile in modo sicuro e affidabile tramite Internet. Per questo motivo è consigliabile l'uso di ExpressRoute per scenari specifici. Per informazioni sull'uso di ExpressRoute per accedere a Microsoft 365, vedere Azure ExpressRoute per Microsoft 365.
- Per assicurarsi di soddisfare i requisiti previsti, vedere la pagina sui prerequisiti di ExpressRoute.
- Per assicurarsi di soddisfare le esigenze specifiche a livello di connettività, vedere l'elenco di provider di servizi e località nell'articolo Partner e località per ExpressRoute.
- Per pianificare i requisiti relativi alla capacità, esaminare la pagina relativa alla Pianificazione e ottimizzazione delle prestazioni di rete per Microsoft 365.
- Seguire la procedura indicata nei flussi di lavoro per configurare la connettività dei flussi di lavoro ExpressRoute per provisioning e stati di un circuito.
Importante
Assicurarsi di aver abilitato il componente aggiuntivo ExpressRoute Premium durante la configurazione della connettività ai servizi di Microsoft 365.
Sì. È possibile configurare i circuiti ExpressRoute esistenti per supportare la connettività ai servizi di Microsoft 365. Assicurarsi di avere una capacità sufficiente a connettersi ai servizi di Microsoft 365 e che sia stato abilitato il componente aggiuntivo Premium. Pianificazione e ottimizzazione delle prestazioni di rete per Microsoft 365 aiuta a pianificare le esigenze di connettività. Vedere inoltre Creare e modificare un circuito ExpressRoute.
Per un elenco aggiornato dei servizi supportati da ExpressRoute, vedere la pagina URL e intervalli di indirizzi IP per Microsoft 365.
Per i servizi di Microsoft 365 è necessario abilitare il componente aggiuntivo premium. Vedere la pagina dei dettagli sui prezzi per informazioni sui prezzi.
Vedere Partner e località di peering per Azure ExpressRoute per ottenere informazioni.
È possibile accedere a Microsoft 365 tramite Internet anche se ExpressRoute è stato configurato per una organizzazione specifica?
Sì. Gli endpoint del servizio di Microsoft 365 sono raggiungibili tramite Internet, anche se ExpressRoute è stato configurato per una rete specifica. Verificare con il team di rete dell'organizzazione, se la rete della propria località è configurata per la connessione ai servizi di Microsoft 365 attraverso ExpressRoute.
Come pianificare una disponibilità elevata per il traffico di rete di Microsoft 365 in Azure ExpressRoute?
Per consigli, vedere Disponibilità elevata e failover con Azure ExpressRoute.
È possibile accedere ai servizi US Government Community (GCC) di Office 365 tramite un circuito ExpressRoute di Azure per enti pubblici statunitensi?
Sì. Gli endpoint del servizio GCC di Office 365 sono raggiungibili tramite ExpressRoute di Azure US Gov. Tuttavia, è innanzitutto necessario aprire un ticket di supporto nel portale di Azure per fornire i prefissi che si desidera segnalare a Microsoft. Verrà stabilita la connettività ai servizi GCC di Office 365 dopo aver risolto il ticket di supporto.
È possibile disporre del peering privato expressRoute in un ambiente Azure per enti pubblici con gateway Rete virtuale nel cloud commerciale di Azure?
No, non è possibile stabilire il peering privato ExpressRoute in un ambiente Azure per enti pubblici con un gateway di rete virtuale in ambienti cloud commerciali di Azure. Inoltre, l'ambito del peering Microsoft di ExpressRoute per enti pubblici è limitato solo agli indirizzi IP pubblici all'interno delle aree di Azure per enti pubblici e non si estende agli intervalli più ampi degli indirizzi IP pubblici commerciali.
Le route del servizio di Azure vengono annunciate quando si configura il peering Microsoft per la prima volta?
Non vengono visualizzate route, finché non si collega un filtro di route al circuito per avviare gli annunci di prefisso. Per altre informazioni vedere Configurare i filtri di route per il peering Microsoft.
Non è possibile selezionare Exchange Online quando si crea un filtro di route per il peering Microsoft. Qual è il motivo?
Quando si usano i filtri di route, chiunque può attivare il peering Microsoft. Tuttavia, per l'utilizzo dei servizi di Microsoft 365 è comunque necessario essere autorizzati da Microsoft 365.
Il peering Microsoft è stato abilitato prima del 1° agosto 2017. Come posso usare al meglio i filtri di route?
Il circuito esistente continua ad annunciare i prefissi per Microsoft 365. Per aggiungere annunci di prefissi pubblici di Azure tramite lo stesso peering Microsoft, è possibile creare un filtro di route, selezionare i servizi che si vuole annunciare e collegare il filtro al peering Microsoft. Per altre informazioni vedere Configurare i filtri di route per il peering Microsoft.
Il peering Microsoft è disponibile in un'unica posizione; se si tenta di abilitarlo in un'altra località non vengono visualizzati prefissi.
Il peering Microsoft dei circuiti ExpressRoute che sono stati configurati prima del 1° agosto 2017, avranno tutti i prefissi di servizio annunciati tramite il peering Microsoft, anche se non sono definiti i filtri di route.
Il peering Microsoft dei circuiti ExpressRoute che vengono configurati il 1° agosto 2017 e successivamente, non avranno prefissi annunciati fino a quando non viene collegato un filtro di route al circuito. Per impostazione predefinita non verrà visualizzati prefissi.
Se più reti virtuali sono connesse allo stesso circuito ExpressRoute, è possibile usare ExpressRoute per configurare la connettività tra reti virtuali?
La connettività tra reti virtuali tramite ExpressRoute non è consigliata. Configurare, invece, il Peering di reti virtuali.
ExpressRoute Direct offre ai clienti la possibilità di connettersi direttamente alla rete globale di Microsoft in località peer distribuite in modo strategico in tutto il mondo. ExpressRoute Direct fornisce doppia connettività a 100 Gbps o a 10 Gbps, che supporta la connettività attiva-attiva su larga scala.
I clienti dovranno collaborare con i gestori telefonici locali e i provider di coubicazione per ottenere la connettività ai router di ExpressRoute e poter sfruttare ExpressRoute Direct.
Controllare la disponibilità nella pagina delle località.
ExpressRoute Direct utilizza lo stesso livello aziendale di ExpressRoute.
ExpressRoute Direct fornisce ai clienti coppie di porte dirette a 100 Gbps o 10 Gbps nel backbone globale di Microsoft. Gli scenari che offrono i maggiori vantaggi ai clienti includono: inserimento di grandi quantità di dati, isolamento fisico per i mercati regolamentati e capacità dedicata agli scenari continui, come il rendering.
Per la coppia di porte verrà addebitato un importo fisso a ExpressRoute Direct. I circuiti standard sono inclusi senza costi aggiuntivi, mentre i circuiti premium prevedono un piccolo addebito aggiuntivo. Il traffico in uscita è fatturato in base al circuito a seconda della zona in cui si trova la località di peering.
Le coppie di porte di ExpressRoute Direct vengono fatturate 45 giorni dopo la creazione della risorsa di ExpressRoute Direct o quando uno o entrambi i collegamenti vengono abilitati, a seconda della condizione che si verifica prima. Il periodo di prova di 45 giorni è garantito per consentire ai clienti di completare il processo di Cross Connection con il provider del servizio di condivisione del percorso.
Una volta eliminate le porte dirette e rimosso la connessione incrociata, le coppie di porte di ExpressRoute Direct non saranno più addebitate.
Come richiedere una porta diretta ExpressRoute, se la larghezza di banda non è disponibile in una località di peering?
Se la larghezza di banda non è disponibile nella località di peering di destinazione, aprire una Richiesta di supporto nel portale di Azure e selezionare l'argomento di supporto ExpressRoute Direct.
Copertura globale di ExpressRoute è un servizio di Azure che connette le reti locali tramite il servizio ExpressRoute sulla rete globale di Microsoft. Ad esempio, se si dispone di un data center privato in California connesso a ExpressRoute nella Silicon Valley e di un altro data center privato in Texas connesso a ExpressRoute a Dallas, con Copertura globale di ExpressRoute, è possibile connettere tra loro i data center privati tramite le due connessioni ExpressRoute e far passare il traffico tra i data center attraverso la rete backbone di Microsoft.
Per abilitare Copertura globale di ExpressRoute, connettere i circuiti ExpressRoute. Per disabilitare la funzionalità, disconnettere i circuiti. Vedere la configurazione.
Se i circuiti ExpressRoute sono nella stessa area geopolitica, non occorre ExpressRoute Premium per collegarli tra loro. Se due circuiti ExpressRoute si trovano in aree geopolitiche diverse, è necessario ExpressRoute Premium per entrambi i circuiti per abilitare la connettività tra di essi.
ExpressRoute abilita la connettività dalla rete locale ai servizi cloud Microsoft. Copertura globale di ExpressRoute abilita la connettività tra le reti locali tramite i circuiti ExpressRoute esistenti, sfruttando la rete globale di Microsoft. Il servizio Copertura globale di ExpressRoute viene fatturato separatamente dal servizio ExpressRoute esistente. È previsto un corrispettivo aggiuntivo per abilitare questa funzionalità su ogni circuito ExpressRoute. Il traffico tra le reti locali abilitato da Copertura globale di ExpressRoute verrà fatturato all'origine in base alla velocità in uscita e alla destinazione in base alla velocità in ingresso. Le tariffe si basano sulla zona in cui si trovano i circuiti.
Il servizio Copertura globale di ExpressRoute è supportato in specifici luoghi o paesi/aree. I circuiti ExpressRoute devono essere creati in località di peering in questi luoghi o paesi/aree.
Se esistono più di due reti locali, ciascuna connessa a un circuito ExpressRoute, è possibile abilitare Copertura globale di ExpressRoute per connettere tra loro tutte le reti locali?
Si è possibile, purché i circuiti si trovino nei paesi/aree supportati. È necessario connettere due circuiti ExpressRoute alla volta. Per creare una rete di peer completa, è necessario enumerare tutte le coppie di circuiti e ripetere la configurazione.
È possibile abilitare Copertura globale di ExpressRoute tra due circuiti ExpressRoute nella stessa località di peering?
No. I due circuiti devono appartenere a posizioni di peering diverse. Se un'area metropolitana in un paese/area supportato include più di una località di peering di ExpressRoute, è possibile connettere tra loro i circuiti ExpressRoute creati in località di peering diverse in tale area metropolitana.
Se la Copertura globale di ExpressRoute viene abilitata tra il circuito A e il circuito B e tra il circuito B e il circuito C, le reti locali connesse al circuito A e al circuito C comunicano tra loro tramite la rete Microsoft?
No. Per abilitare la connettività tra due delle reti locali, è necessario connettere in modo esplicito i circuiti ExpressRoute corrispondenti. Nell'esempio precedente è necessario connettere il circuito A al circuito C.
Quale velocità effettiva della rete ci si può aspettare tra le reti locali dopo l'abilitazione di Copertura globale di ExpressRoute?
La velocità effettiva di rete tra le reti locali, abilitata da Copertura globale di ExpressRoute, è limitata dal più piccolo dei due circuiti ExpressRoute. Il traffico da locale ad Azure e da locale a locale condivide lo stesso circuito ed è soggetto agli stessi limiti di larghezza di banda.
Con Copertura globale di ExpressRoute qual è il numero massimo di route che è possibile annunciare e ricevere?
Il numero di route che è possibile annunciare a Microsoft nel peering privato di Azure è fissato a 4000 su un circuito Standard o 10.000 su un circuito Premium. Il numero di route che si riceve da Microsoft nel peering privato di Azure è la somma delle route delle reti virtuali di Azure e delle route dalle altre reti locali connesse tramite Copertura globale di ExpressRoute. Verificare di aver impostato un limite massimo di prefissi appropriato sul router locale.
Il supporto IPv6 per Copertura globale di ExpressRoute è ora disponibile in anteprima pubblica. Per altre informazioni vedere Abilitare Copertura globale.
Copertura globale di ExpressRoute fornisce lo stesso contratto di servizio relativo alla disponibilità del normale servizio ExpressRoute.
L'agente di raccolta traffico ExpressRoute non archivia i dati dei clienti.
L'agente di raccolta traffico ExpressRoute usa una frequenza di campionamento di 1:4096, il che significa che viene acquisito 1 pacchetto su 4096.
L'agente di raccolta traffico ExpressRoute può gestire fino a 300.000 flussi al minuto. Nei casi in cui si raggiunge tale limite, i flussi in eccesso vengono eliminati. Per altre informazioni vedere Conteggio di metriche dei flussi in un circuito.
Sì, è possibile usare l'agente di raccolta traffico con i circuiti ExpressRoute usati nella distribuzione della rete WAN virtuale.
Sì. L'agente di raccolta traffico ExpressRoute supporta sia il provider di ExpressRoute che i circuiti ExpressRoute Direct con una larghezza di banda di 1 Gbps o superiore.
Si hanno interruzioni minime o nulle durante la manutenzione nell'agente di raccolta traffico ExpressRoute. L’agente di raccolta traffico ExpressRoute ha più istanze in domini di aggiornamento diversi, durante un aggiornamento, le istanze vengono portate offline una alla volta. Nonostante ci sia un minore inserimento di flussi di campioni nell'area di lavoro Log Analytics, l'agente di raccolta traffico ExpressRoute non avrà tempi di inattività. La perdita di flussi campionati durante la manutenzione non influisce sull'analisi del traffico di rete, quando i dati campionati vengono aggregati in un intervallo di tempo più lungo.
Per impostazione predefinita, la distribuzione dell'agente di raccolta traffico ExpressRoute include zone di disponibilità abilitate nelle aree in cui è disponibile. Per informazioni sulla disponibilità dell'area vedere Zone di disponibilità supportate.
È possibile associare un circuito ExpressRoute Direct singolo a più agenti di raccolta traffico ExpressRoute distribuiti in diverse aree di Azure all'interno di una determinata area geopolitica. Si consiglia di associare il circuito ExpressRoute Direct a più agenti di raccolta traffico ExpressRoute come parte del piano di ripristino di emergenza e del piano di disponibilità elevata.
Il circuito ExpressRoute avrà tempi di inattività durante la configurazione dell'agente di raccolta traffico ExpressRoute?
No. La configurazione dell'agente di raccolta traffico ExpressRoute non causa tempi di inattività del circuito ExpressRoute.
L'agente di raccolta traffico ExpressRoute deve essere distribuito nella stessa sottoscrizione del circuito ExpressRoute?
No. L'agente di raccolta traffico ExpressRoute può essere distribuito in una sottoscrizione diversa dal circuito ExpressRoute. Tuttavia, l'agente di raccolta traffico ExpressRoute deve essere distribuito nella stessa area geopolitica della località di peering del circuito ExpressRoute.
L'ambito Gateway di rete include le risorse del gateway nei servizi di rete. Nell'ambito Gateway di rete sono disponibili quattro tipi di risorse:
- Gateway di rete virtuale nel servizio ExpressRoute.
- Gateway di rete virtuale nel servizio Gateway VPN.
- Gateway VPN (da sito a sito) nel servizio Rete WAN virtuale di Azure.
- Gateway ExpressRoute nel servizio Rete WAN virtuale
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. La manutenzione controllata dal cliente non copre gli aggiornamenti host (oltre gli aggiornamenti host per Power, ad esempio) e gli aggiornamenti critici della sicurezza.
Al momento non è possibile ricevere notifiche avanzate per la manutenzione delle risorse del gateway di rete.
Al momento, è necessario configurare una finestra minima di cinque ore nel fuso orario preferito.
In questo momento, è necessario configurare una finestra di manutenzione giornaliera.
La manutenzione controllata dal cliente supporta gli aggiornamenti del sistema operativo guest e del servizio. Questi aggiornamenti riguardano la maggior parte degli elementi di manutenzione che interessano i clienti. Alcuni altri tipi di aggiornamenti, inclusi gli aggiornamenti host, non rientrano nell'ambito della manutenzione controllata dal cliente.
Se si verifica un problema di sicurezza con gravità elevata che potrebbe compromettere i clienti, Azure potrebbe dover eseguire l'override del controllo del cliente della finestra di manutenzione ed eseguire il push della modifica. Queste modifiche sono rare occorrenze usate solo in casi estremi.
Le risorse di configurazione della manutenzione devono trovarsi nella stessa area della risorsa del gateway?
Sì.
Quali SKU del gateway possono essere configurati per l'uso della manutenzione controllata dal cliente?
Tutti gli SKU di Gateway VPN di Azure (ad eccezione dello SKU Basic) possono essere configurati per l'uso della manutenzione controllata dal cliente.
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.
Esistono limitazioni sull'uso della manutenzione controllata dal cliente in base all'indirizzo IP pubblico dello SKU Basic?
Sì. La manutenzione controllata dal cliente non funziona per le risorse che usano indirizzi IP pubblici dello SKU Basic, tranne nel caso degli aggiornamenti dei servizi. Per questi gateway, la manutenzione del sistema operativo guest non segue il programma di manutenzione controllato dal cliente a causa delle limitazioni dell'infrastruttura.
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 distinte. Questo approccio garantisce che la manutenzione non influisca contemporaneamente sulle risorse di backup.
Per una risorsa è stata pianificata una finestra di manutenzione per una data futura. Le attività di manutenzione verranno sospese su questa risorsa fino ad allora?
No, le attività di manutenzione non vengono 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.
Come è possibile ottenere altre informazioni sulla manutenzione del gateway controllata dal cliente?
Per altre informazioni vedere l'articolo Manutenzione del gateway ExpressRoute controllato dal cliente.
No.