Routing con ExpressRoute per Office 365

Importante :  Il presente articolo è stato tradotto automaticamente, vedere la dichiarazione di non responsabilità. Per visualizzare la versione inglese dell'articolo, fare clic qui.

Per comprendere pienamente il routing del traffico a Office 365 con Azure ExpressRoute, è necessario conoscere a fondo i requisiti per il routing di ExpressRoute e i circuiti e domini di routing ExpressRoute. Si tratta di nozioni fondamentali per l'uso di ExpressRoute su cui faranno affidamento i clienti di Office 365.

Ecco alcuni dei punti chiave illustrati negli articoli citati sopra che è necessario comprendere:

  • I circuiti ExpressRoute non sono mappati ad alcuna entità fisica ma rappresentano una connessione logica effettuata in un'unica località di peering da Microsoft e un provider di peering per conto dell'utente.

  • Esiste un mapping 1:1 tra un circuito ExpressRoute e la chiave di servizio di un cliente.

  • Per un circuito ExpressRoute sono previsti fino a tre peering indipendenti: pubblico di Azure, privato di Azure e Microsoft. Office 365 richiede il peering Microsoft.

  • Ogni circuito ha una larghezza di banda fissa che è condivisa tra tutte le relazioni di peering.

  • Qualsiasi indirizzo IPv4 pubblico e numero AS pubblico che viene usato dal circuito ExpressRoute deve essere convalidato come appartenente all'utente oppure assegnato in esclusiva all'utente dal proprietario dell'intervallo di indirizzi.

  • I circuiti ExpressRoute sono ridondanti a livello globale e seguiranno le procedure di routing BGP standard.

Per altre informazioni sui servizi supportati, sui costi e sui dettagli di configurazione, vedere la pagina delle domande frequenti. Per informazioni sull'elenco dei provider di connettività che offrono supporto per il peering Microsoft, vedere l'articolo sulle località per ExpressRoute. Abbiamo registrato anche una serie di 10 video relativa alla Formazione su Azure ExpressRoute per Office 365 disponibile su Channel 9 per spiegare più approfonditamente questi concetti.

Nota : Azure ExpressRoute per Office 365 non è ancora compatibile con IPv6. È necessario disattivare IPv6, altrimenti verrà usato per impostazione predefinita invece della connessione ExpressRoute.

L'infrastruttura che accetta il traffico dei clienti per le applicazioni di Office 365 è accessibile su Internet e su ExpressRoute oppure su più circuiti ExpressRoute. Il traffico di rete da Office 365 alla rete del cliente transiterà per ExpressRoute quando sono disponibili sia Internet che ExpressRoute. Questo introduce il rischio di asimmetria delle route se il traffico proveniente dalla rete del cliente preferisce la route Internet. Le route asimmetriche sono un problema perché i dispositivi che eseguono l'ispezione dei pacchetti con stato possono bloccare il traffico di ritorno che segue un percorso diverso rispetto ai pacchetti in uscita.

Quando il computer di un cliente avvia una connessione a Office 365 su Internet, gli endpoint del cliente associati alla richiesta devono essere instradabili pubblicamente. Lo stesso vale per le connessioni avviate dal cliente su ExpressRoute. Dato che molti clienti usano il peering diretto con Microsoft, la presenza di indirizzi privati con possibile duplicazione tra i clienti non è un'opzione percorribile.

Negli scenari seguenti viene avviata la comunicazione da Office 365 alla rete locale:

Per il routing di ritorno da Microsoft alla rete per questi flussi di traffico bidirezionale, le route BGP ai dispositivi locali devono essere condivise con Microsoft.

Per connettersi a Office 365 su un circuito ExpressRoute, è necessario configurare una relazione di peering usando il dominio di routing di peering Microsoft. Il peering pubblico e privato di Azure non sono richiesti per Office 365 Esistono però servizi correlati a Office 365 che richiedono il dominio di routing privato di Azure. Ad esempio, Azure RemoteApp e Office 365 Management Pack sono basati su Microsoft Azure; trattandosi di un'applicazione compilata in Azure, alcuni degli endpoint sono disponibili su peering pubblico di Azure.

Altre applicazioni, come Office 365 Video, sono applicazioni Office 365, ma Office 365 Video è costituito da tre diversi componenti, ovvero il portale, il servizio di streaming e la rete per la distribuzione di contenuti. Il portale risiede in SharePoint Online, il servizio di streaming risiede in Servizi multimediali di Azure e la rete per la distribuzione di contenuti risiede nella rete CDN di Azure. Questi componenti sono illustrati nella tabella seguente.

Componente

Applicazione sottostante

Dominio di routing

Uso

Portale di Office 365 Video

SharePoint Online

Peering Microsoft

Configurazione, caricamento

Servizio di streaming di Office 365 Video

Servizi multimediali di Microsoft Azure

Peering pubblico di Azure

Servizio di streaming, usato nel caso in cui il video non sia disponibile dalla rete CDN

Rete per la distribuzione di contenuti di Office 365 Video

Rete CDN di Azure

Nessuno

Origine principale di download/streaming video. Altre informazioni sulla rete di Office 365 Video.

Mentre Azure RemoteApp, Office 365 Management Pack e Office 365 Video sono le uniche applicazioni con dipendenze dal dominio di routing pubblico di Azure, questo potrebbe essere richiesto da altre applicazioni in futuro. Per comprendere quali caratteristiche e applicazioni di Office 365 sono disponibili, vedere l'articolo sugli endpoint di Office 365. È presente una colonna per ognuna delle applicazioni elencate, in cui è indicato se la caratteristica è disponibile usando il peering Microsoft.

Ognuna delle caratteristiche Office 365 disponibili tramite Microsoft peering sono elencati nell' articolo di Office 365 endpoint per tipo di applicazione e nome di dominio completo. Il motivo per utilizzare il FQDN nelle tabelle è per consentire agli utenti di gestire il traffico scegliendo file PAC o altre configurazioni proxy, vedere la Guida per la gestione di Office 365 endpoint PAC, ad esempio file. Gli indirizzi IP ogni delle applicazioni, è necessario suddividere il livello di applicazione e non la caratteristica. Per ogni applicazione che è disponibile su ExpressRoute, gli intervalli di indirizzi IP indicati in una tabella separata e gli intervalli di indirizzi IP disponibili tramite internet solo e internet ed ExpressRoute in dettaglio.

Questi indirizzi IP sono raggruppati in tag di community BGP per semplificare di gestione del routing. I tag di community in uso includono:

Tag stringa di community

Applicazioni incluse

Exchange

Exchange Online

Exchange Online Protection

Skype for Business

Skype for Business online

SharePoint

SharePoint Online

Servizi di Office 365

Portale e condivisione

Autenticazione e identità

Office Online

La maggior parte dei nomi elencati come viene annunciato ExpressRoute e internet sono inclusivo tutti. In alcuni casi è stato utilizzato un carattere jolly in un nome di dominio completo in situazioni in cui uno o più sub-FQDN vengono inseriti in modo diverso rispetto al livello superiore carattere jolly FQDN. Questo accade in genere quando il carattere jolly rappresenta un lungo elenco di server annunciato ExpressRoute e a internet e c'è un piccolo gruppo secondari di server o CNAME solo annunciati a internet o viceversa. Fare riferimento alla tabella riportata di seguito per scoprire dove sono le differenze.

Questa tabella visualizza gli FQDN con carattere jolly annunciati sia a Internet che ad Azure ExpressRoute, insieme agli FQDN secondari annunciati solo a Internet.

FQDN con carattere jolly annunciati a ExpressRoute e Internet

FQDN secondari annunciati solo a Internet

*.microsoftonline.com

click.email.microsoftonline.com

portal.microsoftonline.com

provisioningapi.microsoftonline.com

adminwebservice.microsoftonline.com

*.officeapps.live.com

NexusRules.officeapps.live.com

Nexus.officeapps.live.com

odc.officeapps.live.com

odc.officeapps.live.com

cdn.odc.officeapps.live.com

ols.officeapps.live.com

ocsredir.officeapps.live.com

ocws.officeapps.live.com

ocsa.officeapps.live.com

In genere file PAC sono destinati a inviare richieste di rete ExpressRoute annunciato endpoint direttamente al circuito e tutte le altre richieste di rete per i proxy. Se si sta configurando un file PAC come questo, scrivere il file PAC nell'ordine seguente:

  1. Includere gli FQDN secondari della seconda colonna della tabella riportata sopra all'inizio del file PAC, inviando il traffico verso il proxy. È stato creato un file PAC di esempio da usare, disponibile nell'articolo Gestione degli endpoint di Office 365.

  2. Includere tutti gli FQDN contrassegnati come annunciati a ExpressRoute in questo articolo sotto la prima sezione, inviando il traffico direttamente al circuito ExpressRoute.

  3. Includere qualsiasi altro endpoint di rete o regola sotto queste due voci, inviando il traffico verso il proxy.

In questa tabella consente di visualizzare il carattere jolly FQDN vengono inseriti a internet solo insieme a sub-FQDN posti annunciato Azure ExpressRoute e internet. Per il file PAC sopra, i nomi nella colonna due la tabella seguente sono elencate come viene annunciato a ExpressRoute il collegamento a cui fa riferimento, vale a dire da includere nel secondo gruppo di voci del file.

FQDN con carattere jolly annunciati solo a Internet

FQDN secondari annunciati a ExpressRoute e Internet

*.office.com

*.outlook.office.com

home.office.com

portal.office.com

www.office.com

*.office.net

agent.office.net

*.office365.com

outlook.office365.com

smtp.office365.com

*.outlook.com

*.protection.outlook.com

*.mail.protection.outlook.com

*.windows.net

login.windows.net

Per il routing all'applicazione di Office 365 prescelta è necessario determinare alcuni fattori chiave.

  1. Quanta larghezza di banda richiederà l'applicazione. Campionamento utilizzo esistente è il metodo solo affidabile per determinare ciò all'interno dell'organizzazione. Utilizzare il calcolo solo per convalidare i test.

  2. Quali posizioni di uscita si useranno per il traffico di rete in uscita dalla rete. È consigliabile prevedere di ridurre al minimo la latenza della rete per la connettività a Office 365 in quanto incide sulle prestazioni. Dato che Skype for Business usa audio e video in tempo reale, è particolarmente suscettibile ai problemi di latenza della rete.

  3. Se ExpressRoute verrà sfruttato da tutti i percorsi di rete o solo da alcuni.

  4. Quali sono le località da cui il provider di rete offre ExpressRoute.

Dopo aver determinato le risposte a queste domande, è possibile eseguire il provisioning di un circuito ExpressRoute che soddisfa le esigenze di larghezza di banda e la posizione. Per assistenza di pianificazione della rete più, consultare la rete di Office 365 ottimizzazione Guida e case study sulla modalità di punti di manipolazione di Microsoft rete pianificazione delle prestazioni.

Esempio 1: Singola posizione geografica

Lo scenario in questo esempio riguarda un'azienda fittizia che ha una singola posizione geografica.

I dipendenti di Trey Research sono autorizzati a connettersi solo ai servizi e ai siti Web su Internet consentiti esplicitamente dal reparto sicurezza sulla coppia di proxy in uscita che risiedono tra la rete aziendale e il relativo ISP.

Interruppe prevede di usare Azure ExpressRoute per Office 365 e riconosce tale parte del traffico, ad esempio il traffico destinato reti non sarà possibile inviare in ExpressRoute Office 365 connessione per la distribuzione di contenuti. Dal momento che tutto il traffico già route per i dispositivi di proxy per impostazione predefinita, le richieste continuerà a lavorare come in precedenza. Dopo avere interruppe determinato che soddisfano i requisiti di routing Azure ExpressRoute, vengano procedere per creare un circuito, configurare routing e il collegamento nuovo circuito di ExpressRoute a una rete. Dopo la configurazione di Azure ExpressRoute fondamentale è presente, interruppe aggiunge i punti finali Office 365 supportati da ExpressRoute per Office 365 a un file di configurazione (PAC) automatica del proxy o un URL per instradare il traffico dati dei clienti specifici su diretto ExpressRoute per le connessioni Office 365.

Come mostrato nella figura seguente, Trey Research riesce a soddisfare il requisito di instradare il traffico Office 365 su Internet e un subset del traffico su ExpressRoute usando una combinazione di routing e modifiche alla configurazione proxy in uscita.

  1. Un URL o un file di configurazione (PAC) automatica del proxy viene utilizzato per indirizzare il traffico attraverso un punto di uscita internet separato per Azure ExpressRoute per Office 365.

  2. I client sono configurati con una route predefinita verso i proxy di Trey Research.

In questo scenario di esempio Trey Research usa un dispositivo proxy in uscita. Analogamente, i clienti che non usano Azure ExpressRoute per Office 365 possono decidere di usare questa tecnica per instradare il traffico in base al costo di verifica del traffico destinato a noti endpoint a volumi elevati.

I nomi di dominio completi per Exchange Online e SharePoint Online e Skype for Business Online a volumi più elevati sono i seguenti:

Rete perimetrale cliente ExpressRoute
  • outlook.office365.com

  • outlook.office.com

  • <nome-tenant>.sharepoint.com

  • <nome-tenant>-my.sharepoint.com

  • <nome-tenant>-<app>.sharepoint.com

  • *.Lync.com

Ulteriori informazioni sulla distribuzione e gestione di impostazioni del proxy in Windows 8 e garantire che Office 365 non è limitata dal proxy.

Un unico circuito ExpressRoute non offre disponibilità elevata a Trey Research. In caso di errore nella coppia ridondante di dispositivi perimetrali di Trey Research che servono la connettività ExpressRoute, non è presente un circuito ExpressRoute aggiuntivo su cui eseguire il failover. Questo mette in difficoltà Trey Researc perché il failover su Internet richiede la riconfigurazione manuale e in alcuni casi nuovi indirizzi IP. Per aggiungere la disponibilità elevata, la soluzione più semplice consiste nell'aggiungere altri circuiti ExpressRoute.

Nell'ultimo scenario il routing del traffico di Office 365 su ExpressRoute costituisce la base per un'architettura di routing ancora più complessa. Indipendentemente dal numero di posizioni, dal numero di continenti in cui si trovano, dal numero di circuiti ExpressRoute e così via, sarà necessario poter instradare una parte del traffico su Internet e una parte su ExpressRoute.

Ecco alcune altre domande a cui rispondere per i clienti con più posizioni in più aree geografiche:

  1. È necessario un circuito ExpressRoute in ogni posizione? Se viene usato Skype for Business o se la sensibilità alla latenza per SharePoint Online o Exchange Online è un aspetto rilevante per il cliente, è consigliabile un circuito ExpressRoute in ogni continente in cui il cliente ha una sede. Per informazioni più dettagliate, vedere la guida alla qualità dei contenuti multimediali e alla connettività di rete per Skype for Business.

  2. Se un circuito ExpressRoute non è disponibile in un'area specifica, come deve essere instradato il traffico di Office 365?

  3. Qual è il metodo ottimale per consolidare il traffico nel caso di reti con molte posizioni di piccole dimensioni?

Ognuna di queste situazioni presenta una problematica specifica che richiede la valutazione della propria rete e delle opzioni messe a disposizione da Microsoft.

Considerazione

Componenti di rete da valutare

Circuiti in più posizioni

Occorre confrontare costo, latenza ed esigenza di larghezza di banda.

Usare il costo della route BGP, i file PAC e NAT per gestire il routing con più circuiti.

Routing da posizioni senza un circuito ExpressRoute

È possibile usare l'inoltro DNS per consentire agli uffici remoti di rilevare l'endpoint appropriato.

I client nell'ufficio remoto devono avere a disposizione una route che fornisce accesso al circuito ExpressRoute.

Consolidamento di piccoli uffici

È necessario confrontare con attenzione la larghezza di banda disponibile e l'utilizzo dei dati.

Nota : Microsoft preferirà ExpressRoute a Internet se la route è disponibile, indipendentemente dalla posizione fisica.

Per ogni rete specifica è necessario tenere conto di ognuna di queste considerazioni. Di seguito è riportato un esempio.

Esempio 2: Posizioni in più aree geografiche

Lo scenario in questo esempio riguarda Humongous Insurance, un'azienda fittizia che ha più posizioni geografiche.

Humongous Insurance è un'azienda con uffici dislocati in diverse parti del mondo, che implementerà Azure ExpressRoute per Office 365 per mantenere la maggior parte del traffico di Office 365 su connessioni di rete dirette. Humongous Insurance ha anche sedi in altri due continenti. I dipendenti nell'ufficio remoto in cui ExpressRoute non è fattibile dovranno essere reinstradati a una delle due strutture principali per usare una connessione ExpressRoute.

Il principio è quello di far pervenire il traffico destinato a Office 365 a un data center Microsoft nel più breve tempo possibile. In questo esempio Humongous Insurance deve decidere se gli uffici remoti devono usare il routing su Internet per raggiungere un data center Microsoft su qualsiasi connessione nel più breve tempo possibile oppure il routing su una rete interna per raggiungere un data center Microsoft su una connessione ExpressRoute nel più breve tempo possibile.

I data center, le reti e l'architettura delle applicazioni Microsoft sono progettati per accettare comunicazioni distribuite a livello globale e gestirle con la massima efficienza. Le richieste destinate a Office 365 che rimangono nelle reti dei clienti più del necessario non riusciranno a sfruttare i vantaggi di questa architettura.

Nel caso di Humongous Insurance, il processo deve dipendere dalle applicazioni che intende usare su ExpressRoute. Ad esempio, se è cliente di Skype for Business Online o se prevede di sfruttare la connettività ExpressRoute per la connessione a riunioni di Skype for Business Online esterne, la progettazione consigliata nella guida alla qualità dei contenuti multimediali e alla connettività di rete per Skype for Business Online prevede il provisioning di un ulteriori circuito ExpressRoute per la terza posizione. Può essere più costoso dal punto di vista della rete, ma le richieste di routing da un continente a un altro prima del recapito a un data center Microsoft possono determinare un'esperienza di basso livello o inutilizzabile durante le riunioni e le comunicazioni su Skype for Business Online.

Se Humongous Insurance non usa o non prevede di usare Skype for Business Online in alcun modo, il reinstradamento del traffico di rete destinato a Office 365 verso un continente con una connessione ExpressRoute può risultare possibile. In entrambi i casi, è consigliato l'instradamento del traffico destinato a Internet sulla rete Internet nel sito locale per sfruttare le reti per la distribuzione di contenuti su cui si basa Office 365.

Pluralità geografica ExpressRoute

Quando Humongous Insurance pianifica la propria strategia basata su diverse aree geografiche, deve tenere in considerazione molti aspetti per quanto riguarda le dimensioni del circuito (qui illustrate), il numero di circuiti, il failover e così via.

Con ExpressRoute in una singola posizione e più aree geografiche che tentano di usare il circuito, Humongous Insurance vuole assicurarsi che le connessioni in ingresso e in uscita di Office 365 dell'ufficio remoto vengano inviate al data center di Office 365 più vicino alla sede centrale e vengano ricevute dalla sede centrale. A questo scopo, Humongous Insurance implementa l'inoltro DNS per ridurre il numero di roundtrip e di ricerche DNS necessario per stabilire la connessione appropriata con l'ambiente di Office 365 più vicino al punto di uscita Internet della sede centrale. Sono anche disponibili informazioni su come assegnare un server di inoltro condizionale per un nome di dominio.

In questo scenario il traffico dall'ufficio remoto risolve l'infrastruttura front-end di Office 365 in Nord America e sfrutta Office 365 per connettersi ai server back-end in base all'architettura dell'applicazione di Office 365. Ad esempio, Exchange Online termina la connessione in Nord America e quei server front-end si connettono al server delle cassette postali back-end ovunque si trovi il tenant. Vedere l'argomento sulla connettività dei client per altre informazioni sulla progettazione delle singole applicazioni per la gestione della connettività dei clienti.

Se Humongous Insurance ha sedi principali in più continenti, è consigliabile almeno un circuito per continente per ridurre la latenza per le applicazioni sensibili, come Skype for Business. Se tutte le sedi si trovano in un unico continente o se non viene usata la collaborazione in tempo reale, la presenza di un punto di uscita consolidato o distribuito è una decisione specifica del cliente che dipende dal numero di persone per posizione, dall'utilizzo dell'applicazione in ogni posizione, dai requisiti di disponibilità elevata e così via. Quando sono disponibili più circuiti, il routing BGP garantirà il failover in caso di mancata disponibilità di uno dei circuiti.

Leggere altre informazioni sulle configurazioni di routing di esempio e vedere https://azure.microsoft.com/it-it/documentation/articles/expressroute-config-samples-nat/.

Il routing selettivo con ExpressRoute può essere necessario per diversi motivi, ad esempio per i test o per la distribuzione di ExpressRoute a un subset di utenti. Sono disponibili vari strumenti che i clienti possono usare per instradare in modo selettivo il traffico di rete di Office 365 su ExpressRoute:

  1. Filtro/separazione delle route: consentire le route BGP a Office 365 su ExpressRoute a un subset di subnet o router. Questo assicura l'instradamento selettivo in base al segmento di rete del cliente o all'ubicazione fisica della sede. Si tratta di un approccio comune per l'implementazione scaglionata di ExpressRoute per Office 365.

  2. File PAC/URL: indirizzare il traffico di rete destinato a Office 365 per specifici nomi di dominio completi su un percorso specifico. Questo assicura l'instradamento selettivo in base al computer client, come identificato dall'implementazione del file PAC.

  3. Community BGP: il filtraggio in base ai tag di community BGP consente al cliente di stabilire quali applicazioni di Office 365 transiteranno per ExpressRoute e quali per Internet.

Ecco un collegamento breve per tornare alla pagina: https://aka.ms/erorouting

Argomenti correlati

Connettività a Office 365 di rete
Azure ExpressRoute per Office 365
Gestione ExpressRoute per Office 365 connettività
pianificazione della rete con ExpressRoute per Office 365
Implementazione ExpressRoute per Office 365
qualità Media e le prestazioni di connettività di rete in Skype for Business Online
ottimizzare la rete per Skype for Business Online
ExpressRoute e QoS in Skype for Business Online
chiamata flusso usando ExpressRoute
Comunità utilizzando BGP ExpressRoute per gli scenari di Office 365
ottimizzazione delle prestazioni di Office 365 con le previsioni e la cronologia delle prestazioni
piano di risoluzione dei problemi di prestazioniper Office 365
URL di Office 365 e intervalli di indirizzi IP
Office 365 rete e ottimizzazione delle prestazioni

Nota : Dichiarazione di non responsabilità per la traduzione automatica: Il presente articolo è stato tradotto tramite un software di traduzione automatica e non da una persona. Microsoft offre le traduzioni automatiche per consentire a coloro che non conoscono la lingua inglese di leggere gli articoli sui prodotti, sui servizi e sulle tecnologie Microsoft. Dal momento che l'articolo è stato tradotto automaticamente, potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli.

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa al programma Office Insider

Queste informazioni sono risultate utili?

Grazie per i tuoi commenti e suggerimenti

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×