Requisiti per il routing di ExpressRoute

Per connettersi ai servizi cloud Microsoft tramite ExpressRoute, è necessario configurare e gestire il routing. Alcuni provider di connettività offrono la configurazione e la gestione del routing come servizio gestito. Rivolgersi al proprio provider di connettività per verificare se viene offerto questo servizio. Se non è offerto, è necessario rispettare i requisiti seguenti.

Per una descrizione delle sessioni di routing che è necessario configurare per facilitare la connettività, vedere Circuiti e domini di routing.

Indirizzi IP usati per il peering

Per configurare il routing tra la propria rete e i router perimetrali Enterprise di Microsoft (MSEE, Microsoft Enterprise Edge), sarà necessario riservare alcuni blocchi di indirizzi IP. In questa sezione viene fornito un elenco dei requisiti e vengono descritte le regole relative alla modalità di acquisizione e utilizzo di questi indirizzi IP.

Indirizzi IP usati per il peering privato di Azure

Per configurare il peering, è possibile usare indirizzi IP sia privati che pubblici. L'intervallo di indirizzi usato per configurare le route non può sovrapporsi agli intervalli di indirizzi usati per le reti virtuali in Azure.

• IPv4:
  • Riserva una /29 subnet o due /30 subnet per le interfacce di routing.
  • Usare indirizzi IP privati o indirizzi IP pubblici per le subnet usate per il routing.
  • Le subnet non devono essere in conflitto con l'intervallo riservato dal cliente per l'uso in Microsoft Cloud.
  • Se si usa una subnet /29, dividerla in due subnet /30.
    • Usare la prima /30 subnet per il collegamento primario e la seconda /30 subnet per il collegamento secondario.
    • Per ognuna delle /30 sottoreti, usa il primo indirizzo IP della /30 sottorete per il router. Microsoft usa il secondo indirizzo IP della subnet /30 per configurare una sessione BGP.
    • È necessario configurare entrambe le sessioni BGP affinché il contratto di servizio per la disponibilità sia valido.
• IPv6:
  • Riservare una subnet /125 o due subnet /126 per le interfacce di routing.
  • Usare indirizzi IP privati o indirizzi IP pubblici per le subnet usate per il routing.
  • Le subnet non devono essere in conflitto con l'intervallo riservato dal cliente per l'uso in Microsoft Cloud.
  • Se si utilizza una /125 subnet, dividila in due /126 subnet.
    • Usare la prima /126 subnet per il collegamento primario e la seconda /126 subnet per il collegamento secondario.
    • Per ognuna delle /126 sottoreti, utilizzare il primo indirizzo IP della /126 sottorete per il router. Microsoft usa il secondo indirizzo IP della subnet /126 per configurare una sessione BGP.
    • È necessario configurare entrambe le sessioni BGP affinché il contratto di servizio per la disponibilità sia valido.

Esempio per il peering privato

Se si sceglie di usare a.b.c.d/29 per configurare il peering, suddividerlo in due /30 subnet. Nell'esempio seguente si noti come viene usata la subnet a.b.c.d/29:

• Suddividere a.b.c.d/29 in a.b.c.d/30 e a.b.c.d+4/30. Trasmettere queste subnet a Microsoft tramite le API di provisioning.
  • Usare a.b.c.d+1 come IP VRF per il server PE primario e Microsoft usa a.b.c.d+2 come IP VRF per il MSEE primario.
  • Usare a.b.c.d+5 come IP VRF per il pe secondario e Microsoft usa a.b.c.d+6 come IP VRF per il MSEE secondario.

Si consideri un caso in cui si seleziona l'indirizzo 192.168.100.128/29 per configurare il peering privato. 192.168.100.128/29 include gli indirizzi da 192.168.100.128 a 192.168.100.135, tra cui:

• 192.168.100.128/30 viene assegnato a link1, con il provider che usa 192.168.100.129 e Microsoft che usa 192.168.100.130.
• 192.168.100.132/30 viene assegnato a link2, con il provider che usa 192.168.100.133 e Microsoft che usa 192.168.100.134.

Indirizzi IP usati per il peering Microsoft

Per configurare le sessioni BGP, usare gli indirizzi IP pubblici di cui si è proprietari. Microsoft deve essere in grado di verificare la proprietà degli indirizzi IP tramite il Routing Internet Registry e l'Internet Routing Registry.

• Il portale elenca gli indirizzi IP per i prefissi pubblici annunciati per il peering Microsoft. Questi indirizzi IP creano elenchi di controllo di accesso per i router principali Microsoft per consentire il traffico in ingresso da questi indirizzi IP.
• Usare una subnet univoca /29 (IPv4) o /125 (IPv6) oppure due subnet /30 (IPv4) o /126 (IPv6) per configurare il peering BGP per ogni circuito ExpressRoute, se si dispone di più circuiti.
• Se si usa una subnet /29, dividerla in due subnet /30.
• Usare la prima /30 subnet per il collegamento primario e la seconda /30 subnet per il collegamento secondario.
• Per ogni subnet /30, usare il primo indirizzo IP della subnet /30 nel router. Microsoft usa il secondo indirizzo IP della subnet /30 per configurare una sessione BGP.
• Se si usa una subnet /125, dividerla in due subnet /126.
• Usare la prima /126 subnet per il collegamento primario e la seconda /126 subnet per il collegamento secondario.
• Per ogni subnet /126, usare il primo indirizzo IP della subnet /126 nel router. Microsoft usa il secondo indirizzo IP della subnet /126 per configurare una sessione BGP.
• È necessario configurare entrambe le sessioni BGP affinché il contratto di servizio per la disponibilità sia valido.

Requisito dell'indirizzo IP pubblico

Peering privato

Per il peering privato, è possibile scegliere di usare indirizzi IPv4 pubblici o privati. Azure offre l'isolamento end-to-end del vostro traffico, quindi la possibilità che si verifichi una sovrapposizione di indirizzi con altri clienti non è possibile per il peering privato. Questi indirizzi non vengono annunciati a Internet.

Peering Microsoft

Usando il percorso di peering Microsoft, è possibile connettersi ai servizi cloud Microsoft. Questo elenco di servizi include servizi di Microsoft 365, ad esempio Exchange Online, SharePoint Online e Microsoft Teams. Microsoft supporta la connettività bidirezionale nel peering Microsoft. Il traffico destinato ai servizi cloud Microsoft deve usare indirizzi IPv4 pubblici validi prima di entrare nella rete Microsoft.

Assicurarsi di essere registrati come proprietario dell'indirizzo IP e del numero AS in uno dei registri seguenti:

• ARIN
• APNIC
• AFRINIC
• LACNIC
• RIPENCC
• RADB
• ALTDB

Se i prefissi e il numero AS non sono assegnati all'utente specifico nei registri precedenti, è necessario aprire un caso di supporto per la convalida manuale di prefissi e ASN. Il supporto richiede documentazione, ad esempio una lettera di autorizzazione, che dimostri che l'utente è autorizzato a usare quel prefisso.

È possibile usare un numero AS privato con il peering Microsoft, ma richiede la convalida manuale. Inoltre, Microsoft rimuove i numeri AS privati nel percorso AS PATH per i prefissi ricevuti. Di conseguenza, non è possibile aggiungere numeri AS privati in AS PATH per influenzare il routing per il peering Microsoft. Inoltre, i numeri AS da 64496 a 64511 riservati da IANA ai fini della documentazione non sono consentiti nel percorso.

Scambio di rotte dinamico

Lo scambio di routing avviene tramite il protocollo eBGP. Le apparecchiature dei servizi gestiti (MSEE) e i router stabiliscono sessioni eBGP. L'autenticazione delle sessioni BGP non è necessaria. Se necessario, è possibile configurare un hash MD5. Per altre informazioni sulla configurazione delle sessioni BGP, vedere Configurare il routing e Flussi di lavoro di provisioning dei circuiti e stati del circuito.

Numeri di Sistema Autonomo (ASN)

Microsoft usa il numero AS 12076 per il peering pubblico di Azure, il peering privato di Azure e il peering Microsoft. Microsoft riserva ASN da 65.515 a 65.520 per uso interno. ExpressRoute supporta numeri AS a 16 bit e a 32 bit.

Non sono previsti requisiti per la simmetria del trasferimento dei dati. I percorsi forward e return possono attraversare diverse coppie di router. È necessario pubblicizzare route identiche da entrambi i lati in più coppie di circuiti appartenenti all'utente. Le metriche di route non devono essere identiche.

Aggregazione di route e limiti dei prefissi

ExpressRoute supporta fino a 4.000 prefissi IPv4 e 100 prefissi IPv6 annunciati a Microsoft tramite il peering privato di Azure. È possibile aumentare questo limite a 10.000 prefissi IPv4 abilitando il componente aggiuntivo ExpressRoute Premium. ExpressRoute accetta fino a 200 prefissi per ciascuna sessione BGP per il peering pubblico su Azure e il peering Microsoft.

La sessione BGP viene eliminata se il numero di prefissi supera il limite. ExpressRoute accetta le routes predefinite di default solo nel collegamento di peering privato. L'utente deve filtrare le route predefinite e gli indirizzi IP privati (RFC 1918) dai percorsi per il peering pubblico di Azure e il peering Microsoft.

Instradamento di transito e instradamento tra regioni

Non è possibile configurare ExpressRoute come router di transito. È necessario basarsi sul provider di connettività per i servizi di routing di transito.

Annuncio delle route predefinite

È possibile annunciare le route predefinite solo nelle sessioni di peering privato di Azure. In questa configurazione ExpressRoute instrada tutto il traffico dalle reti virtuali associate alla rete. Se si annunciano route predefinite nel peering privato, si blocca il percorso Internet da Azure. Devi fare affidamento sul tuo vantaggio aziendale per indirizzare il traffico da e verso Internet per i servizi ospitati in Azure.

Non è possibile accedere ad alcuni servizi dal perimetro aziendale. Per abilitare la connettività ad altri servizi di Azure e servizi di infrastruttura, è necessario usare il routing definito dall'utente per consentire la connettività Internet per ogni subnet che richiede la connettività Internet per questi servizi.

Supporto per le comunità BGP

Questa sezione offre una panoramica del funzionamento delle community BGP con ExpressRoute. Microsoft annuncia le route nei percorsi per il peering privato, Microsoft e pubblico (deprecato) con route contrassegnate con i valori della community appropriati. La logica per farlo e i dettagli sui valori della community sono descritti nelle sezioni seguenti. Tuttavia, Microsoft non rispetta i valori della community contrassegnati per le route annunciate a Microsoft.

Per il peering privato, se si configura un valore della community BGP personalizzato nelle reti virtuali di Azure, viene visualizzato questo valore personalizzato e un valore della community BGP a livello di area nelle route di Azure annunciate all'ambiente locale tramite ExpressRoute.

Per il peering Microsoft, ci si connette a Microsoft tramite ExpressRoute in qualsiasi posizione di peering all'interno di un'area geopolitica. Sarà anche possibile accedere a tutti i servizi cloud Microsoft in tutte le aree all'interno del confine geopolitico.

Ad esempio, se ci si connette a Microsoft ad Amsterdam tramite ExpressRoute, si ha accesso a tutti i servizi cloud Microsoft ospitati in Europa settentrionale ed Europa occidentale.

Fare riferimento alla pagina Partner e località di peering per ExpressRoute per un elenco dettagliato delle aree geopolitiche, delle regioni di Azure associate e delle corrispondenti località di peering ExpressRoute.

È possibile acquistare più di un circuito ExpressRoute per area geopolitica. Un maggior numero di connessioni offre vantaggi significativi in termini di disponibilità elevata, grazie alla ridondanza geografica. Se si hanno più circuiti ExpressRoute, si riceve lo stesso set di prefissi annunciati da Microsoft nei percorsi per il peering Microsoft. Con questa configurazione saranno disponibili più percorsi dalla propria rete a Microsoft. Questa configurazione può potenzialmente causare decisioni di routing non ottimali all'interno della rete. Di conseguenza, è possibile che si verifichino esperienze di connettività non ottimali a servizi diversi. Per prendere decisioni di routing appropriate e offrire un servizio di routing ottimale agli utenti, è possibile usare i valori della community.

Tutte le route annunciate da Microsoft includono il tag del valore comunitario appropriato.

Servizio al valore della community BGP

Oltre al tag BGP per ogni area, Microsoft contrassegna anche i prefissi in base al servizio a cui appartengono. Questo tag si applica solo al peering Microsoft. La tabella seguente fornisce un'associazione tra un servizio e un valore della community BGP. È possibile eseguire il Get-AzBgpServiceCommunity cmdlet per un elenco completo dei valori più recenti.

I servizi globali di Azure includono al momento solo Azure DevOps.

(2) È richiesta l'autorizzazione di Microsoft. Vedere Configurare i filtri di route per il peering Microsoft.

(3) Questa community pubblica anche le route necessarie per i servizi di Microsoft Teams.

(4) CRM Online supporta Dynamics v8.2 e versioni precedenti. Per le versioni successive, seleziona la community regionale per le tue distribuzioni di Dynamics.

(5) L'uso del peering Microsoft con i servizi PSTN è limitato a casi d'uso specifici. Vedere Uso di ExpressRoute per i servizi PSTN Microsoft.

Supporto della community BGP nei cloud nazionali

• Le community di Office 365 non sono supportate con il peering Microsoft per l'area di Microsoft Azure gestita da 21Vianet.

Passaggi successivi

• Configurare la connessione ExpressRoute.

  • Creare e modificare un circuito.
  • Creare e modificare la configurazione del peering.
  • Collegare una rete virtuale a un circuito ExpressRoute.