Implementera ExpressRoute för Microsoft 365
Den här artikeln gäller för Microsoft 365 Enterprise.
ExpressRoute för Microsoft 365 tillhandahåller en alternativ routningsväg till många Internetriktade Microsoft 365-tjänster. Arkitekturen för ExpressRoute för Microsoft 365 baseras på annonsering av offentliga IP-prefix för Microsoft 365-tjänster som redan är tillgängliga via Internet till dina etablerade ExpressRoute-kretsar för efterföljande omdistribution av dessa IP-prefix till nätverket. Med ExpressRoute aktiverar du effektivt flera olika routningsvägar, via Internet och via ExpressRoute, för många Microsoft 365-tjänster. Det här tillståndet för routning i nätverket kan innebära en betydande ändring av hur din interna nätverkstopologi utformas.
Obs!
Vi rekommenderar inte ExpressRoute för Microsoft 365 eftersom det inte tillhandahåller den bästa anslutningsmodellen för tjänsten under de flesta omständigheter. Därför krävs Microsoft-auktorisering för att använda den här anslutningsmodellen. Vi granskar varje kundbegäran och godkänner endast ExpressRoute för Microsoft 365 i de sällsynta scenarier där det är nödvändigt. Läs expressroute för Microsoft 365-guiden för mer information och efter en omfattande granskning av dokumentet med dina produktivitets-, nätverks- och säkerhetsteam kan du samarbeta med ditt Microsoft-kontoteam för att skicka in ett undantag om det behövs. Obehöriga prenumerationer som försöker skapa flödesfilter för Microsoft 365 får ett felmeddelande.
Du måste noggrant planera din ExpressRoute för Microsoft 365-implementering för att hantera nätverkskomplexiteterna med routning tillgänglig via både en dedikerad krets med vägar som matas in i ditt kärnnätverk och Internet. Om du och ditt team inte utför den detaljerade planeringen och testningen i den här guiden finns det en hög risk att du upplever en tillfällig eller total förlust av anslutning till Microsoft 365-tjänster när ExpressRoute-kretsen är aktiverad.
För att få en lyckad implementering måste du analysera dina infrastrukturkrav, gå igenom detaljerad nätverksutvärdering och design, noggrant planera distributionen på ett mellanlagrat och kontrollerat sätt och skapa en detaljerad validerings- och testplan. För en stor, distribuerad miljö är det inte ovanligt att se implementeringar som sträcker sig över flera månader. Den här guiden är utformad för att hjälpa dig att planera framåt.
Stora lyckade distributioner kan ta sex månader i planeringen och omfattar ofta teammedlemmar från många områden i organisationen, inklusive nätverks-, brandväggs- och proxyserveradministratörer, Microsoft 365-administratörer, säkerhet, slutanvändarsupport, projekthantering och sponsring av chefer. Din investering i planeringsprocessen minskar sannolikheten för distributionsfel som resulterar i driftstopp eller komplex och dyr felsökning.
Vi förväntar oss att följande förutsättningar slutförs innan den här implementeringsguiden startas.
Du har slutfört en nätverksutvärdering för att avgöra om ExpressRoute rekommenderas och godkänns.
Du har valt en ExpressRoute-nätverkstjänstleverantör. Hitta information om ExpressRoute-partner och peeringplatser.
Du har redan läst och förstått ExpressRoute-dokumentationen och ditt interna nätverk kan uppfylla ExpressRoute-kraven från slutpunkt till slutpunkt.
Ditt team har läst all offentlig vägledning och dokumentation på , https://aka.ms/ertoch tittat på https://aka.ms/expressrouteoffice365Azure ExpressRoute for Microsoft 365 Training-serien på Channel 9 för att få en förståelse för viktig teknisk information, inklusive:
Internetberoenden för SaaS-tjänster.
Så här undviker du asymmetriska vägar och hanterar komplex routning.
Så här införlivar du kontroller för perimetersäkerhet, tillgänglighet och programnivå.
Börja med att samla in krav
Börja med att avgöra vilka funktioner och tjänster du planerar att införa i din organisation. Du måste bestämma vilka funktioner i de olika Microsoft 365-tjänsterna som ska användas och vilka platser i nätverket som ska vara värdar för personer som använder dessa funktioner. Med katalogen med scenarier måste du lägga till de nätverksattribut som var och en av dessa scenarier kräver. till exempel inkommande och utgående nätverkstrafikflöden och om Microsoft 365-slutpunkterna är tillgängliga via ExpressRoute eller inte.
Så här samlar du organisationens krav:
Katalogisera inkommande och utgående nätverkstrafik för de Microsoft 365-tjänster som din organisation använder. Mer information om flöden som olika Microsoft 365-scenarier kräver finns på sidan med URL:er och IP-adressintervall för Microsoft 365.
Samla in dokumentation om befintlig nätverkstopologi som visar information om ditt interna WAN-stamnät och topologi, anslutning till satellitplatser, senaste milens användaranslutning, routning till utgående nätverksperimeterpunkter och proxytjänster.
Identifiera inkommande tjänstslutpunkter i nätverksdiagrammen som Microsoft 365 och andra Microsoft-tjänster ansluter till, med både Internet och föreslagna ExpressRoute-anslutningssökvägar.
Identifiera alla geografiska användarplatser och WAN-anslutningar mellan platser tillsammans med vilka platser som för närvarande har en utgående trafik till Internet och vilka platser som föreslås ha en utgående till en ExpressRoute-peeringplats.
Identifiera alla gränsenheter, till exempel proxyservrar, brandväggar och så vidare, och katalogisera deras relation till flöden som går via Internet och ExpressRoute.
Dokumentera om slutanvändare kommer åt Microsoft 365-tjänster via direktdirigering eller indirekt programproxy för både Internet- och ExpressRoute-flöden.
Lägg till platsen för din klientorganisation och mötesplatsen i nätverksdiagrammet.
Beräkna förväntade och observerade egenskaper för nätverksprestanda och svarstider från viktiga användarplatser till Microsoft 365. Tänk på att Microsoft 365 är en global och distribuerad uppsättning tjänster och att användarna ansluter till platser som kan skilja sig från platsen för deras klientorganisation. Därför rekommenderar vi att du mäter och optimerar svarstiden mellan användaren och den närmaste gränsen för Microsofts globala nätverk via ExpressRoute och Internetanslutningar. Du kan använda dina resultat från nätverksutvärderingen för att hjälpa till med den här uppgiften.
Lista företagets nätverkssäkerhet och krav på hög tillgänglighet som måste uppfyllas med den nya ExpressRoute-anslutningen. Till exempel hur fortsätter användarna att få åtkomst till Microsoft 365 i händelse av fel i Internet-utgående eller ExpressRoute-krets.
Dokument som inkommande och utgående Microsoft 365-nätverksflöden använder Internetsökvägen och som använder ExpressRoute. Specifika geografiska platser för dina användare och information om din lokala nätverkstopologi kan kräva att planen skiljer sig från en användarplats till en annan.
Katalogisera utgående och inkommande nätverkstrafik
För att minimera routning och andra nätverkskomplexiteter rekommenderar vi att du endast använder ExpressRoute för Microsoft 365 för de nätverkstrafikflöden som krävs för att gå över en dedikerad anslutning på grund av regelkrav eller som ett resultat av nätverksutvärderingen. Dessutom rekommenderar vi att du mellanlagrar omfattningen för ExpressRoute-routning och närmar dig utgående och inkommande nätverkstrafikflöden som olika och distinkta steg i implementeringsprojektet. Distribuera ExpressRoute för Microsoft 365 för just användarinitierade utgående nätverkstrafikflöden och lämna inkommande nätverkstrafikflöden över Internet kan hjälpa till att kontrollera den ökade topologiska komplexiteten och riskerna med att införa ytterligare asymmetriska routningsmöjligheter.
Nätverkstrafikkatalogen bör innehålla listor över alla inkommande och utgående nätverksanslutningar som du har mellan ditt lokala nätverk och Microsoft.
Utgående nätverkstrafikflöden är scenarier där en anslutning initieras från din lokala miljö, till exempel från interna klienter eller servrar, med ett mål för Microsoft-tjänsterna. Dessa anslutningar kan vara direkt till Microsoft 365 eller indirekta, till exempel när anslutningen går via proxyservrar, brandväggar eller andra nätverksenheter på vägen till Microsoft 365.
Inkommande nätverkstrafikflöden är alla scenarier där en anslutning initieras från Microsoft-molnet till en lokal värd. Dessa anslutningar måste vanligtvis gå igenom brandväggen och annan säkerhetsinfrastruktur som kundens säkerhetsprincip kräver för externt ursprungade flöden.
Läs avsnittet Säkerställa routningssymmetri för att avgöra vilka tjänster som ska skicka inkommande trafik och leta efter kolumnen med namnet ExpressRoute för Microsoft 365 i referensartikeln för Microsoft 365-slutpunkter för att fastställa resten av anslutningsinformationen.
För varje tjänst som kräver en utgående anslutning vill du beskriva den planerade anslutningen för tjänsten, inklusive nätverksroutning, proxykonfiguration, paketgranskning och bandbreddsbehov.
För varje tjänst som kräver en inkommande anslutning behöver du ytterligare information. Servrar i Microsoft-molnet upprättar anslutningar till ditt lokala nätverk. För att säkerställa att anslutningarna görs korrekt bör du beskriva alla aspekter av den här anslutningen, inklusive; de offentliga DNS-posterna för de tjänster som accepterar dessa inkommande anslutningar, de CIDR-formaterade IPv4 IP-adresserna, vilken ISP-utrustning som ingår och hur inkommande NAT eller käll-NAT hanteras för dessa anslutningar.
Inkommande anslutningar bör granskas oavsett om de ansluter via Internet eller ExpressRoute för att säkerställa att asymmetrisk routning inte har introducerats. I vissa fall kan lokala slutpunkter som Microsoft 365-tjänster initierar inkommande anslutningar till också behöva nås av andra Microsoft- och icke-Microsoft-tjänster. Det är av största vikt att det inte går att aktivera ExpressRoute-routning till dessa tjänster för Microsoft 365-syften. I många fall kan kunder behöva implementera specifika ändringar i sitt interna nätverk, till exempel källbaserad NAT, för att säkerställa att inkommande flöden från Microsoft förblir symmetriska när ExpressRoute har aktiverats.
Här är ett exempel på den detaljnivå som krävs. I det här fallet dirigerar Exchange Hybrid till det lokala systemet via ExpressRoute.
| Anslutningsegenskap | Värde |
|---|---|
| Nätverkstrafikriktning |
Inkommande |
| Tjänst |
Exchange-hybrid |
| Offentlig Microsoft 365-slutpunkt (källa) |
Exchange Online (IP-adresser) |
| Offentlig lokal slutpunkt (mål) |
5.5.5.5 |
| Offentlig DNS-post (Internet) |
Autodiscover.contoso.com |
| Kommer den här lokala slutpunkten att användas av andra (icke-Microsoft 365) Microsoft-tjänster |
Nej |
| Kommer den här lokala slutpunkten att användas av användare/system på Internet |
Ja |
| Interna system som publicerats via offentliga slutpunkter |
Exchange Server klientåtkomstroll (lokalt) 192.168.101, 192.168.102, 192.168.103 |
| IP-annons för den offentliga slutpunkten |
Till Internet: 5.5.0.0/16 till ExpressRoute: 5.5.5.0/24 |
| Säkerhets-/perimeterkontroller |
Internetsökväg: DeviceID_002 ExpressRoute-sökväg: DeviceID_003 |
| Hög tillgänglighet |
Aktiv/aktiv över 2 geo-redundanta/ExpressRoute-kretsar – Chicago och Dallas |
| Sökvägssymmetrikontroll |
Metod: Nat-källsökväg: Nat-källanslutningar för inkommande nat till 192.168.5.5 ExpressRoute-sökväg: Nat-källanslutningar till 192.168.1.0 (Chicago) och 192.168.2.0 (Dallas) |
Här är ett exempel på en tjänst som endast är utgående:
| Anslutningsegenskap | Värde |
|---|---|
| Nätverkstrafikriktning |
Utgående |
| Tjänst |
SharePoint |
| Lokal slutpunkt (källa) |
Användararbetsstation |
| Offentlig Microsoft 365-slutpunkt (mål) |
SharePoint (IP-adresser) |
| Offentlig DNS-post (Internet) |
*.sharepoint.com (och fler FQDN) |
| CDN-hänvisningar |
cdn.sharepointonline.com (och fler FQDN) – IP-adresser som underhålls av CDN-leverantörer) |
| IP-annons och NAT används |
Internetsökväg/KÄLL-NAT: 1.1.1.0/24 ExpressRoute-sökväg/KÄLL-NAT: 1.1.2.0/24 (Chicago) och 1.1.3.0/24 (Dallas) |
| Anslutningsmetod |
Internet: via layer 7 proxy (.pac-fil) ExpressRoute: direktroutning (ingen proxy) |
| Säkerhets-/perimeterkontroller |
Internetsökväg: DeviceID_002 ExpressRoute-sökväg: DeviceID_003 |
| Hög tillgänglighet |
Internetsökväg: Redundant internetutgång ExpressRoute-sökväg: Aktiv/aktiv "het potatis" routning över 2 geo-redundanta ExpressRoute-kretsar - Chicago och Dallas |
| Sökvägssymmetrikontroll |
Metod: Käll-NAT för alla anslutningar |
Din nätverkstopologidesign med regional anslutning
När du förstår tjänsterna och deras associerade nätverkstrafikflöden kan du skapa ett nätverksdiagram som införlivar dessa nya anslutningskrav och illustrerar de ändringar du gör för att använda ExpressRoute för Microsoft 365. Diagrammet bör innehålla:
Alla användarplatser där Microsoft 365 och andra tjänster kommer att nås från.
Alla utgående internet- och ExpressRoute-utgående punkter.
Alla utgående och inkommande enheter som hanterar anslutningar in och ut ur nätverket, inklusive routrar, brandväggar, programproxyservrar och intrångsidentifiering/skydd.
Interna mål för all inkommande trafik, till exempel interna ADFS-servrar som accepterar anslutningar från ADFS-webbprogramproxyservrarna.
Katalog över alla IP-undernät som ska annonseras
Identifiera varje plats där personer kommer åt Microsoft 365 från och lista de meet-me-platser som ska användas för ExpressRoute.
Platser och delar av din interna nätverkstopologi, där Microsofts IP-prefix som lärts från ExpressRoute accepteras, filtreras och sprids till.
Nätverkstopologin bör illustrera den geografiska platsen för varje nätverkssegment och hur den ansluter till Microsoft-nätverket via ExpressRoute och/eller Internet.
Diagrammet nedan visar varje plats där personer kommer att använda Microsoft 365 från tillsammans med annonserna för inkommande och utgående routning till Microsoft 365.
För utgående trafik får användarna åtkomst till Microsoft 365 på något av tre sätt:
Genom en meet-me plats i Nordamerika för folket i Kalifornien.
Genom en meet-me plats i Hong Kong Special Administrative Region för folket i Hong Kong SAR.
Via Internet i Bangladesh där det finns färre personer och ingen ExpressRoute-krets etableras.
På samma sätt returnerar den inkommande nätverkstrafiken från Microsoft 365 på något av tre sätt:
Genom en meet-me plats i Nordamerika för folket i Kalifornien.
Genom en meet-me plats i Hong Kong Special Administrative Region för folket i Hong Kong SAR.
Via Internet i Bangladesh där det finns färre personer och ingen ExpressRoute-krets etableras.
Fastställa lämplig meet-me-plats
Valet av meet-me-platser, som är den fysiska plats där ExpressRoute-kretsen ansluter ditt nätverk till Microsoft-nätverket, påverkas av de platser där personer kommer åt Microsoft 365 från. Som ett SaaS-erbjudande fungerar Inte Microsoft 365 enligt den regionala IaaS- eller PaaS-modellen på samma sätt som Azure gör. I stället är Microsoft 365 en distribuerad uppsättning samarbetstjänster, där användare kan behöva ansluta till slutpunkter över flera datacenter och regioner, som kanske inte nödvändigtvis finns på samma plats eller region där användarens klient finns.
Det innebär att det viktigaste du behöver tänka på när du väljer meet-me-platser för ExpressRoute för Microsoft 365 är där personerna i din organisation kommer att ansluta från. Den allmänna rekommendationen för optimala Microsoft 365-anslutningar är att implementera routning, så att användarförfrågningar till Microsoft 365-tjänster lämnas ut i Microsoft-nätverket via den kortaste nätverkssökvägen. Detta kallas också ofta för "hot potato"-routning. Om de flesta Microsoft 365-användare till exempel befinner sig på en eller två platser, kommer optimal design att skapas om du väljer meet-me-platser som ligger närmast platsen för dessa användare. Om ditt företag har stora användarpopulationer i många olika regioner kan det vara bra att ha flera ExpressRoute-kretsar och meet-me-platser. För vissa av dina användarplatser kanske den kortaste/mest optimala sökvägen till Microsoft-nätverket och Microsoft 365 inte är via dina interna WAN- och ExpressRoute-mötespunkter, utan via Internet.
Det finns ofta flera meet-me-platser som kan väljas i en region med relativ närhet till dina användare. Fyll i följande tabell för att vägleda dina beslut.
Planerade ExpressRoute-möten i Kalifornien och New York
| Plats |
Antal personer |
Förväntad svarstid till Microsoft-nätverk via Internet-utgående trafik |
Förväntad svarstid till Microsoft-nätverk via ExpressRoute |
|---|---|---|---|
| Los Angeles |
10 000 |
~15 ms |
~10 ms (via Silicon Valley) |
| Washington DC |
15 000 |
~20 ms |
~10 ms (via New York) |
| Dallas |
5,000 |
~15 ms |
~40 ms (via New York) |
När den globala nätverksarkitekturen som visar Microsoft 365-regionen, ExpressRoute-nätverkstjänstleverantörens meet-me-platser och antalet personer efter plats har utvecklats, kan den användas för att identifiera om några optimeringar kan göras. Det kan också visa globala nätverksanslutningar för hårnålar där trafiken dirigeras till en avlägsen plats för att få platsen meet-me. Om en hårnål i det globala nätverket identifieras bör den åtgärdas innan du fortsätter. Antingen hitta en annan meet-me plats, eller använda selektiv Internet breakout utgående punkter för att undvika hårnålen.
Det första diagrammet visar ett exempel på en kund med två fysiska platser i Nordamerika. Du kan se information om kontorsplatser, Microsoft 365-klientplatser och flera alternativ för ExpressRoute meet-me-platser. I det här exemplet har kunden valt platsen meet-me baserat på två principer i ordning:
Närmaste närhet till personerna i organisationen.
Närmast i närheten av ett Microsoft-datacenter där Microsoft 365 finns.
Det andra diagrammet utökar det här konceptet något ytterligare och visar ett exempel på en flernationskund med liknande information och beslutsfattande. Den här kunden har ett litet kontor i Bangladesh med endast ett litet team på 10 personer som fokuserar på att öka sitt fotavtryck i regionen. Det finns en meet-me-plats i Chennai och ett Microsoft-datacenter med Microsoft 365 i Chennai så att en meet-me-plats skulle vara meningsfull; Men för 10 personer är kostnaden för den extra kretsen betungande. När du tittar på nätverket måste du avgöra om svarstiden för att skicka nätverkstrafiken i nätverket är effektivare än att spendera kapitalet för att hämta en annan ExpressRoute-krets.
Alternativt kan de 10 personerna i Bangladesh uppleva bättre prestanda med sin nätverkstrafik som skickas via Internet till Microsoft-nätverket än de skulle dirigera på sitt interna nätverk som vi visade i de inledande diagrammen och som återges nedan.
Skapa din ExpressRoute för Microsoft 365-implementeringsplan
Implementeringsplanen bör omfatta både teknisk information om hur du konfigurerar ExpressRoute och information om hur du konfigurerar all annan infrastruktur i nätverket, till exempel följande.
Planera vilka tjänster som delas mellan ExpressRoute och Internet.
Planera för bandbredd, säkerhet, hög tillgänglighet och redundans.
Utforma inkommande och utgående routning, inklusive rätt optimering av routningsvägar för olika platser
Bestäm hur långt ExpressRoute-vägar ska annonseras till nätverket och vilken mekanism som klienterna ska använda för att välja Internet- eller ExpressRoute-sökväg. till exempel direktroutning eller programproxy.
Planera ändringar av DNS-poster, inklusive posterna i Sender Policy Framework .
Planera NAT-strategi, inklusive utgående och inkommande käll-NAT.
Planera din routning med både Internet- och ExpressRoute-nätverkssökvägar
För den första distributionen rekommenderas alla inkommande tjänster, till exempel inkommande e-post eller hybridanslutning, att använda Internet.
Planera LAN-routning för slutanvändarklienten, till exempel konfigurera en PAC/WPAD-fil, standardväg, proxyservrar och BGP-vägannonser.
Planera perimeterroutning, inklusive proxyservrar, brandväggar och molnproxyservrar.
Planera bandbredd, säkerhet, hög tillgänglighet och redundans
Skapa en plan för bandbredd som krävs för varje större Microsoft 365-arbetsbelastning. Uppskatta bandbreddskraven för Exchange Online, SharePoint och Skype för företag Online separat. Du kan använda de beräkningskalkylatorer som vi har angett för Exchange Online och Skype för företag som startplats. Ett pilottest med ett representativt urval av användarprofiler och platser krävs dock för att fullt ut förstå organisationens bandbreddsbehov.
Lägg till hur säkerheten hanteras på varje internet- och ExpressRoute-utgående plats i planen, kom ihåg att alla ExpressRoute-anslutningar till Microsoft 365 använder offentlig peering och måste fortfarande skyddas i enlighet med företagets säkerhetsprinciper för anslutning till externa nätverk.
Lägg till information i din plan om vilka personer som påverkas av vilken typ av avbrott och hur dessa personer kommer att kunna utföra sitt arbete med full kapacitet på enklaste sätt.
Planera bandbreddskrav inklusive Skype för företag krav på jitter, svarstid, överbelastning och utrymme
Skype för företag Online har också specifika extra nätverkskrav, som beskrivs i artikeln Media Quality and Network Connectivity Performance in Skype för företag Online.
Läs avsnittet Bandbreddsplanering för Azure ExpressRoute. När du utför en bandbreddsbedömning med pilotanvändare kan du använda vår guide microsoft 365 prestandajustering med hjälp av baslinjer och prestandahistorik.
Planera för krav på hög tillgänglighet
Skapa en plan för hög tillgänglighet för att uppfylla dina behov och införliva detta i ditt uppdaterade nätverkstopologidiagram. Läs avsnittet Hög tillgänglighet och redundans med Azure ExpressRoute.
Planera för nätverkssäkerhetskrav
Skapa en plan för att uppfylla nätverkssäkerhetskraven och införliva detta i ditt uppdaterade diagram över nätverkstopologi. Läs avsnittet Tillämpa säkerhetskontroller på Azure ExpressRoute för Microsoft 365-scenarier.
Utforma utgående tjänstanslutning
ExpressRoute för Microsoft 365 har utgående nätverkskrav som kanske inte är bekanta. Mer specifikt måste DE IP-adresser som representerar dina användare och nätverk för Microsoft 365 och fungerar som källslutpunkter för utgående nätverksanslutningar till Microsoft följa specifika krav som beskrivs nedan.
Slutpunkterna måste vara offentliga IP-adresser som är registrerade i ditt företag eller till ett transportföretag som tillhandahåller ExpressRoute-anslutning till dig.
Slutpunkterna måste annonseras till Microsoft och verifieras/godkännas av ExpressRoute.
Slutpunkterna får inte annonseras till Internet med samma eller flera prioriterade routningsmått.
Slutpunkterna får inte användas för anslutning till Microsoft-tjänster som inte har konfigurerats via ExpressRoute.
Om din nätverksdesign inte uppfyller dessa krav finns det en hög risk för att användarna får anslutningsfel till Microsoft 365 och andra Microsoft-tjänster på grund av routning av svart holing eller asymmetrisk routning. Detta inträffar när begäranden till Microsoft-tjänster dirigeras via ExpressRoute, men svar dirigeras tillbaka via Internet, eller vice versa, och svaren tas bort av tillståndskänsliga nätverksenheter som brandväggar.
Den vanligaste metoden som du kan använda för att uppfylla ovanstående krav är att använda käll-NAT, antingen implementerat som en del av ditt nätverk eller tillhandahålls av din ExpressRoute-operatör. Med käll-NAT kan du abstrahera information och privata IP-adresser för ditt Internetnätverk från ExpressRoute och; tillsammans med rätt IP-väg annonser, ger en enkel mekanism för att säkerställa sökväg symmetri. Om du använder tillståndskänsliga nätverksenheter som är specifika för ExpressRoute-peeringplatser måste du implementera separata NAT-pooler för varje ExpressRoute-peering för att säkerställa sökvägssymmetri.
Läs mer om NAT-kraven för ExpressRoute.
Lägg till ändringarna för den utgående anslutningen till nätverkstopologidiagrammet.
Utforma inkommande tjänstanslutningar
De flesta Microsoft 365-företagsdistributioner förutsätter någon form av inkommande anslutning från Microsoft 365 till lokala tjänster, till exempel för Exchange, SharePoint och Skype för företag hybridscenarier, postlådemigreringar och autentisering med hjälp av ADFS-infrastruktur. När Du aktiverar en extra routningsväg mellan ditt lokala nätverk och Microsoft för utgående anslutning kan dessa inkommande anslutningar oavsiktligt påverkas av asymmetrisk routning, även om du tänker låta dessa flöden fortsätta att använda Internet. Några försiktighetsåtgärder som beskrivs nedan rekommenderas för att säkerställa att internetbaserade inkommande flöden från Microsoft 365 till lokala system inte påverkas.
För att minimera riskerna med asymmetrisk routning för inkommande nätverkstrafikflöden bör alla inkommande anslutningar använda NAT-källan innan de dirigeras till segment i nätverket, som har routningssynlighet i ExpressRoute. Om inkommande anslutningar tillåts till ett nätverkssegment med routningssynlighet i ExpressRoute utan käll-NAT, kommer begäranden från Microsoft 365 att komma in från Internet, men svaret som går tillbaka till Microsoft 365 föredrar ExpressRoute-nätverkssökvägen tillbaka till Microsoft-nätverket, vilket orsakar asymmetrisk routning.
Du kan överväga något av följande implementeringsmönster för att uppfylla det här kravet:
Utför KÄLL-NAT innan begäranden dirigeras till ditt interna nätverk med hjälp av nätverksutrustning som brandväggar eller lastbalanserare på sökvägen från Internet till dina lokala system.
Se till att ExpressRoute-vägar inte sprids till de nätverkssegment där inkommande tjänster, till exempel klientdelsservrar eller omvända proxysystem, hanterar Internetanslutningar.
Om du uttryckligen redovisar dessa scenarier i nätverket och behåller alla inkommande nätverkstrafikflöden via Internet kan du minimera distributions- och driftrisken för asymmetrisk routning.
Det kan finnas fall där du kan välja att dirigera vissa inkommande flöden via ExpressRoute-anslutningar. I dessa scenarier bör du ta hänsyn till följande extra överväganden.
Microsoft 365 kan bara rikta in sig på lokala slutpunkter som använder offentliga IP-adresser. Det innebär att även om den lokala inkommande slutpunkten endast exponeras för Microsoft 365 via ExpressRoute måste den fortfarande ha en offentlig IP-adress associerad med den.
All DNS-namnmatchning som Microsoft 365-tjänster utför för att lösa lokala slutpunkter sker med hjälp av offentlig DNS. Det innebär att du måste registrera inkommande tjänstslutpunkters FQDN till IP-mappningar på Internet.
För att kunna ta emot inkommande nätverksanslutningar via ExpressRoute måste de offentliga IP-undernäten för dessa slutpunkter annonseras till Microsoft via ExpressRoute.
Utvärdera noggrant dessa inkommande nätverkstrafikflöden för att säkerställa att rätt säkerhets- och nätverkskontroller tillämpas på dem i enlighet med företagets säkerhets- och nätverksprinciper.
När dina lokala inkommande slutpunkter annonseras till Microsoft via ExpressRoute blir ExpressRoute i praktiken den föredragna routningsvägen till dessa slutpunkter för alla Microsoft-tjänster, inklusive Microsoft 365. Det innebär att dessa slutpunktsundernät endast får användas för kommunikation med Microsoft 365-tjänster och inga andra tjänster i Microsoft-nätverket. Annars orsakar din design asymmetrisk routning där inkommande anslutningar från andra Microsoft-tjänster föredrar att dirigera inkommande trafik via ExpressRoute, medan retursökvägen använder Internet.
Om en ExpressRoute-krets eller meet-me-plats ligger nere måste du se till att de lokala inkommande slutpunkterna fortfarande är tillgängliga för att acceptera begäranden via en separat nätverkssökväg. Detta kan innebära annonsering av undernät för dessa slutpunkter via flera ExpressRoute-kretsar.
Vi rekommenderar att du tillämpar käll-NAT för alla inkommande nätverkstrafikflöden som kommer in i nätverket via ExpressRoute, särskilt när dessa flöden korsar tillståndskänsliga nätverksenheter, till exempel brandväggar.
Vissa lokala tjänster, till exempel ADFS-proxy eller automatisk upptäckt av Exchange, kan ta emot inkommande begäranden från både Microsoft 365-tjänster och användare från Internet. För dessa begäranden kommer Microsoft 365 att rikta samma FQDN som användarbegäranden via Internet. Att tillåta inkommande användaranslutningar från Internet till dessa lokala slutpunkter, samtidigt som Microsoft 365-anslutningar tvingas använda ExpressRoute, representerar betydande routningskomplexitet. För de allra flesta kunder som implementerar sådana komplexa scenarier via ExpressRoute rekommenderas inte på grund av driftsöverväganden. Den här extra kostnaden omfattar hantering av risker för asymmetrisk routning och kräver att du noggrant hanterar routningsannonser och principer över flera dimensioner.
Uppdatera din nätverkstopologiplan för att visa hur du skulle undvika asymmetriska vägar
Du vill undvika asymmetrisk routning för att säkerställa att personer i din organisation sömlöst kan använda Microsoft 365 och andra viktiga tjänster på Internet. Det finns två vanliga konfigurationer som kunder har som orsakar asymmetrisk routning. Nu är ett bra tillfälle att granska nätverkskonfigurationen som du planerar att använda och kontrollera om något av dessa asymmetriska routningsscenarier kan finnas.
Till att börja med undersöker vi några olika situationer som är associerade med följande nätverksdiagram. I det här diagrammet finns alla servrar som tar emot inkommande begäranden, till exempel ADFS eller lokala hybridservrar, i Data Center i New Jersey och annonseras till Internet.
Även om perimeternätverket är säkert finns det ingen käll-NAT tillgänglig för inkommande begäranden.
Servrarna i Data Center i New Jersey kan se både internet- och ExpressRoute-vägar.
Vi har också förslag på hur du åtgärdar dem.
Problem 1: Moln till lokal anslutning via Internet
Följande diagram illustrerar den asymmetriska nätverkssökvägen när nätverkskonfigurationen inte tillhandahåller NAT för inkommande begäranden från Microsoft-molnet via Internet.
Den inkommande begäran från Microsoft 365 hämtar IP-adressen för den lokala slutpunkten från offentlig DNS och skickar begäran till perimeternätverket.
I den här felaktiga konfigurationen finns det ingen käll-NAT konfigurerad eller tillgänglig i perimeternätverket där trafiken skickas, vilket resulterar i att den faktiska käll-IP-adressen används som returmål.
Servern i nätverket dirigerar returtrafiken till Microsoft 365 via alla tillgängliga ExpressRoute-nätverksanslutningar.
Resultatet är en asymmetrisk sökväg för flödet till Microsoft 365, vilket resulterar i en bruten anslutning.
Lösning 1a: Nat-källa
Att bara lägga till en KÄLL-NAT i den inkommande begäran löser det här felkonfigurerade nätverket. I det här diagrammet:
Den inkommande begäran fortsätter att gå in via Data Center i New Jerseys perimeternätverk. Den här gången är käll-NAT tillgängligt.
Svaret från servern dirigerar tillbaka mot ip-adressen som är associerad med käll-NAT i stället för den ursprungliga IP-adressen, vilket resulterar i att svaret returneras längs samma nätverkssökväg.
Lösning 1b: Omfång för routning
Du kan också välja att inte tillåta att ExpressRoute BGP-prefix annonseras, vilket tar bort den alternativa nätverkssökvägen för dessa datorer. I det här diagrammet:
Den inkommande begäran fortsätter att gå in via Data Center i New Jerseys perimeternätverk. Den här gången är prefixen som annonseras från Microsoft via ExpressRoute-kretsen inte tillgängliga för Data Center i New Jersey.
Svaret från servern dirigerar tillbaka mot ip-adressen som är associerad med den ursprungliga IP-adressen via den enda tillgängliga vägen, vilket resulterar i att svaret returneras längs samma nätverkssökväg.
Problem 2: Moln till lokal anslutning via ExpressRoute
Följande diagram illustrerar den asymmetriska nätverkssökväg som tas när nätverkskonfigurationen inte tillhandahåller NAT för inkommande begäranden från Microsoft-molnet via ExpressRoute.
Den inkommande begäran från Microsoft 365 hämtar IP-adressen från DNS och skickar begäran till perimeternätverket.
I den här felaktiga konfigurationen finns det ingen käll-NAT konfigurerad eller tillgänglig i perimeternätverket där trafiken skickas, vilket resulterar i att den faktiska käll-IP-adressen används som returmål.
Datorn i nätverket dirigerar returtrafiken till Microsoft 365 via alla tillgängliga ExpressRoute-nätverksanslutningar.
Resultatet är en asymmetrisk anslutning till Microsoft 365.
Lösning 2: NAT-källa
Att bara lägga till en KÄLL-NAT i den inkommande begäran löser det här felkonfigurerade nätverket. I det här diagrammet:
Den inkommande begäran fortsätter att gå in via New York-datacentrets perimeternätverk. Den här gången är käll-NAT tillgängligt.
Svaret från servern dirigerar tillbaka mot ip-adressen som är associerad med käll-NAT i stället för den ursprungliga IP-adressen, vilket resulterar i att svaret returneras längs samma nätverkssökväg.
Kontrollera att nätverksdesignen har sökvägssymmetri
Nu måste du på papper kontrollera att implementeringsplanen erbjuder routningssymmetri för de olika scenarier där du kommer att använda Microsoft 365. Du identifierar den specifika nätverksväg som förväntas tas när en person använder olika funktioner i tjänsten. Från det lokala nätverket och WAN-routningen till perimeterenheterna till anslutningssökvägen. ExpressRoute eller Internet och vidare till anslutningen till onlineslutpunkten.
Du måste göra detta för alla Microsoft 365-nätverkstjänster som tidigare har identifierats som tjänster som din organisation kommer att införa.
Det hjälper till att göra detta papper genomgång av vägar med en andra person. Förklara för dem var varje nätverkshopp förväntas hämta nästa väg från och se till att du är bekant med routningsvägarna. Kom ihåg att ExpressRoute alltid tillhandahåller en mer begränsad väg till Microsoft-serverns IP-adresser, vilket ger lägre vägkostnad än en Internetstandardväg.
Utforma klientanslutningskonfiguration
Om du använder en proxyserver för internetbunden trafik måste du justera alla PAC- eller klientkonfigurationsfiler för att säkerställa att klientdatorerna i nätverket är korrekt konfigurerade för att skicka ExpressRoute-trafik som du vill ha till Microsoft 365 utan att överföra proxyservern, och den återstående trafiken, inklusive viss Microsoft 365-trafik, skickas till relevant proxy. Läs vår guide om hur du hanterar Microsoft 365-slutpunkter, till exempel PAC-filer.
Obs!
Slutpunkterna ändras ofta, så ofta som varje vecka. Du bör bara göra ändringar baserat på de tjänster och funktioner som din organisation har infört för att minska antalet ändringar som du behöver göra för att hålla dig uppdaterad. Var uppmärksam på det effektiva datumet i RSS-feeden där ändringarna tillkännages och en post sparas för alla tidigare ändringar, IP-adresser som tillkännages kan inte annonseras eller tas bort från annonsen förrän det effektiva datumet har nåtts.
Säkerställa routningssymmetri
Microsoft 365-klientdelsservrarna är tillgängliga på både Internet och ExpressRoute. Dessa servrar föredrar att dirigera tillbaka till lokal plats via ExpressRoute-kretsar när båda är tillgängliga. På grund av detta finns det en möjlighet att dirigera asymmetri om trafik från nätverket föredrar att dirigeras via dina Internetkretsar. Asymmetriska vägar är ett problem eftersom enheter som utför tillståndskänslig paketgranskning kan blockera returtrafik som följer en annan sökväg än de utgående paket som följs.
Oavsett om du initierar en anslutning till Microsoft 365 via Internet eller ExpressRoute måste källan vara en offentligt dirigerbar adress. Med många kunder som peerkopplar direkt med Microsoft är det inte möjligt att ha privata adresser där duplicering är möjligt mellan kunder.
Följande är scenarier där kommunikation från Microsoft 365 till ditt lokala nätverk initieras. För att förenkla nätverksdesignen rekommenderar vi att du dirigerar följande via Internetsökvägen.
SMTP-tjänster som e-post från en Exchange Online klientorganisation till en lokal värd eller SharePoint Mail som skickas från SharePoint till en lokal värd. SMTP-protokollet används bredare i Microsofts nätverk än de vägprefix som delas över ExpressRoute-kretsar och annonsering av lokala SMTP-servrar via ExpressRoute orsakar fel med dessa andra tjänster.
ADFS under lösenordsverifiering för inloggning.
Skype för företag hybrid- och/eller Skype för företag federation.
För att Microsoft ska kunna dirigera tillbaka till nätverket för dessa dubbelriktade trafikflöden måste BGP-vägarna till dina lokala enheter delas med Microsoft. När du annonserar routningsprefix till Microsoft via ExpressRoute bör du följa dessa metodtips:
Annonsera inte samma offentliga IP-adressvägsprefix till det offentliga Internet och via ExpressRoute. Vi rekommenderar att IP BGP Route Prefix-annonserna till Microsoft via ExpressRoute kommer från ett intervall som inte annonseras till Internet alls. Om detta inte går att uppnå på grund av det tillgängliga IP-adressutrymmet är det viktigt att du annonserar ett mer specifikt intervall över ExpressRoute än några internetkretsar.
Använd separata NAT IP-pooler per ExpressRoute-krets och avgränsa dem med dina Internet-kretsar.
Alla vägar som annonseras till Microsoft kommer att locka nätverkstrafik från alla servrar i Microsofts nätverk, inte bara de för vilka vägar annonseras till ditt nätverk via ExpressRoute. Annonsera endast vägar till servrar där routningsscenarier definieras och förstås väl av ditt team. Annonsera separata IP-adressvägsprefix på var och en av flera ExpressRoute-kretsar från nätverket.
Hög tillgänglighet och redundans med Azure ExpressRoute
Vi rekommenderar att du etablerar minst två aktiva kretsar från varje utgående med ExpressRoute till din ExpressRoute-provider. Det här är den vanligaste platsen där vi ser fel för kunder och du kan enkelt undvika det genom att etablera ett par aktiva/aktiva ExpressRoute-kretsar. Vi rekommenderar också minst två aktiva/aktiva Internet-kretsar eftersom många Microsoft 365-tjänster endast är tillgängliga via Internet.
I nätverkets utgående punkt finns många andra enheter och kretsar som spelar en viktig roll i hur människor uppfattar tillgänglighet. Dessa delar av dina anslutningsscenarier omfattas inte av ExpressRoute- eller Microsoft 365-serviceavtal, men de spelar en viktig roll i tjänsttillgängligheten från slutpunkt till slutpunkt som uppfattas av personer i din organisation.
Fokusera på de personer som använder och driver Microsoft 365, om ett fel i någon komponent skulle påverka användarnas upplevelse av att använda tjänsten, leta efter sätt att begränsa den totala procentandelen personer som påverkas. Om ett redundansläge är driftskomplext bör du tänka på personernas upplevelse av en lång tid för återställning och leta efter driftsenligt enkla och automatiserade redundanslägen.
Utanför nätverket har Microsoft 365, ExpressRoute och ExpressRoute-providern olika tillgänglighetsnivåer.
Tjänsttillgänglighet
Microsoft 365-tjänster omfattas av väldefinierade serviceavtal, som omfattar mått för drifttid och tillgänglighet för enskilda tjänster. En anledning till att Microsoft 365 kan upprätthålla så hög servicetillgänglighet är möjligheten för enskilda komponenter att sömlöst redundansväxla mellan de många Microsoft-datacenter som använder det globala Microsoft-nätverket. Den här redundansväxlingen sträcker sig från datacentret och nätverket till flera utgående Internetpunkter och möjliggör sömlös redundans från de personer som använder tjänsten.
ExpressRoute tillhandahåller ett serviceavtal med 99,9 % tillgänglighet på enskilda dedikerade kretsar mellan Microsoft Network Edge och ExpressRoute-providern eller partnerinfrastrukturen. Dessa tjänstnivåer tillämpas på ExpressRoute-kretsnivå, som består av två oberoende anslutningar mellan den redundanta Microsoft-utrustningen och nätverksproviderns utrustning på varje peeringplats.
Providertillgänglighet
- Microsofts servicenivåarrangemang stoppas hos din ExpressRoute-leverantör eller partner. Det här är också det första stället där du kan göra val som påverkar din tillgänglighetsnivå. Du bör noga utvärdera egenskaperna för arkitektur, tillgänglighet och återhämtning som expressroute-providern erbjuder mellan din nätverksperimeter och din leverantörsanslutning på varje Microsoft-peeringplats. Var uppmärksam på både logiska och fysiska aspekter av redundans, peeringutrustning, wan-kretsar som tillhandahålls av operatören och eventuella extra mervärdestjänster som NAT-tjänster eller hanterade brandväggar.
Utforma din tillgänglighetsplan
Vi rekommenderar starkt att du planerar och utformar hög tillgänglighet och återhämtning i dina anslutningsscenarier från slutpunkt till slutpunkt för Microsoft 365. En design bör inkludera;
Inga enskilda felpunkter, inklusive både Internet- och ExpressRoute-kretsar.
Minimera antalet personer som påverkas och varaktigheten för den påverkan för de flesta förväntade fellägena.
Optimera för enkel, repeterbar och automatisk återställning från de mest förväntade fellägena.
Stöd för alla krav på nätverkstrafik och funktioner via redundanta sökvägar, utan betydande försämring.
Dina anslutningsscenarier bör innehålla en nätverkstopologi som är optimerad för flera oberoende och aktiva nätverkssökvägar till Microsoft 365. Detta ger bättre tillgänglighet från slutpunkt till slutpunkt än en topologi som endast är optimerad för redundans på enskild enhet eller utrustningsnivå.
Tips
Om användarna distribueras över flera kontinenter eller geografiska regioner och var och en av dessa platser ansluter via redundanta WAN-kretsar till en enda lokal plats där en enda ExpressRoute-krets finns, får användarna mindre tjänsttillgänglighet från slutpunkt till slutpunkt än en nätverkstopologidesign som innehåller oberoende ExpressRoute-kretsar som ansluter de olika regionerna till närmaste peeringplats.
Vi rekommenderar att du etablerar minst två ExpressRoute-kretsar med varje krets som ansluter till med en annan geografisk peeringplats. Du bör etablera det här aktiva-aktiva paret kretsar för varje region där personer använder ExpressRoute-anslutning för Microsoft 365-tjänster. Detta gör att varje region kan vara ansluten under en katastrof som påverkar en större plats, till exempel ett datacenter eller en peeringplats. Genom att konfigurera dem som aktiva/aktiva kan slutanvändartrafiken distribueras över flera nätverkssökvägar. Detta minskar omfattningen för personer som påverkas vid avbrott i enheten eller nätverksutrustningen.
Vi rekommenderar inte att du använder en enda ExpressRoute-krets med Internet som en säkerhetskopia.
Exempel: Redundans och hög tillgänglighet
Contosos multigeografiska design har genomgått en granskning av routning, bandbredd, säkerhet och måste nu genomgå en granskning med hög tillgänglighet. Contoso anser att hög tillgänglighet omfattar tre kategorier; återhämtning, tillförlitlighet och redundans.
Återhämtning gör att Contoso snabbt kan återställa från fel. Med tillförlitlighet kan Contoso erbjuda ett konsekvent resultat i systemet. Redundans gör att Contoso kan flytta mellan en eller flera speglade infrastrukturinstanser.
I varje gränskonfiguration har Contoso redundanta brandväggar, proxyservrar och IDS. För Nordamerika har Contoso en gränskonfiguration i sitt Datacenter i Dallas och en annan gränskonfiguration i sitt Datacenter i Virginia. Den redundanta utrustningen på varje plats ger återhämtning till den platsen.
Nätverkskonfigurationen på Contoso bygger på några viktiga principer:
Det finns flera Azure ExpressRoute-kretsar i varje geografisk region.
Varje krets i en region har stöd för all nätverkstrafik inom den regionen.
Routning föredrar helt klart den ena eller den andra sökvägen beroende på tillgänglighet, plats och så vidare.
Redundansväxling mellan Azure ExpressRoute-kretsar sker automatiskt utan ytterligare konfiguration eller åtgärd som krävs av Contoso.
Redundansväxling mellan Internet-kretsar sker automatiskt utan ytterligare konfiguration eller åtgärd som krävs av Contoso.
I den här konfigurationen, med redundans på fysisk och virtuell nivå, kan Contoso erbjuda lokal återhämtning, regional återhämtning och global återhämtning på ett tillförlitligt sätt. Contoso valde den här konfigurationen efter att ha utvärderat en enda Azure ExpressRoute-krets per region samt möjligheten att växla över till Internet.
Om Contoso inte kunde ha flera Azure ExpressRoute-kretsar per region skulle routning av trafik med ursprung i Nordamerika till Azure ExpressRoute-kretsen i Asien och stillahavsområdet lägga till en oacceptabel svarstidsnivå och den nödvändiga DNS-vidarebefordrarkonfigurationen ökar komplexiteten.
Vi rekommenderar inte att du använder Internet som en säkerhetskopieringskonfiguration. Detta bryter contosos tillförlitlighetsprincip, vilket resulterar i en inkonsekvent upplevelse med hjälp av anslutningen. Dessutom krävs manuell konfiguration för att redundansväxla med hänsyn till de BGP-annonser som har konfigurerats, NAT-konfiguration, DNS-konfiguration och proxykonfigurationen. Den här extra redundanskomplexiteten ökar tiden för att återställa och minskar deras möjlighet att diagnostisera och felsöka stegen.
Har du fortfarande frågor om hur du planerar för och implementerar trafikhantering eller Azure ExpressRoute? Läs resten av våra riktlinjer för nätverk och prestanda eller vanliga frågor och svar om Azure ExpressRoute.
Tillämpa säkerhetskontroller på Azure ExpressRoute för Microsoft 365-scenarier
Att skydda Azure ExpressRoute-anslutningen börjar med samma principer som att skydda Internetanslutningen. Många kunder väljer att distribuera nätverks- och perimeterkontroller längs ExpressRoute-sökvägen för att ansluta sitt lokala nätverk till Microsoft 365 och andra Microsoft-moln. Dessa kontroller kan omfatta brandväggar, programproxyservrar, skydd mot dataläckage, intrångsidentifiering, intrångsskyddssystem och så vidare. I många fall tillämpar kunderna olika nivåer av kontroller på trafik som initieras från lokal trafik till Microsoft, jämfört med trafik som initieras från Microsoft som går till kundens lokala nätverk, jämfört med trafik som initieras från en lokal plats som går till ett allmänt Internetmål.
Här är några exempel på hur du integrerar säkerhet med den ExpressRoute-anslutningsmodell som du väljer att distribuera.
| ExpressRoute-integreringsalternativ | Perimetermodell för nätverkssäkerhet |
|---|---|
| Samlokaliserat vid ett molnutbyte |
Installera ny eller använd befintlig säkerhets-/perimeterinfrastruktur i samlokaliseringsanläggningen där ExpressRoute-anslutningen upprättas. Använd samlokaliseringsanläggningen enbart för routnings-/sammanlänkningsändamål och backtransportanslutningar från samlokaliseringsanläggningen till den lokala säkerhets-/perimeterinfrastrukturen. |
| Punkt-till-punkt-Ethernet |
Avsluta ExpressRoute-anslutningen punkt-till-punkt på den befintliga lokala platsen för säkerhet/perimeterinfrastruktur. Installera en ny säkerhets-/perimeterinfrastruktur som är specifik för ExpressRoute-sökvägen och avsluta punkt-till-punkt-anslutningen där. |
| Alla-till-alla IPVPN |
Använd en befintlig lokal säkerhets-/perimeterinfrastruktur på alla platser som går ut i IPVPN som används för ExpressRoute för Microsoft 365-anslutning. Hairpin den IPVPN som används för ExpressRoute för Microsoft 365 till specifika lokala platser som är avsedda att fungera som säkerhet/perimeter. |
Vissa tjänstleverantörer erbjuder även hanterade säkerhets-/perimeterfunktioner som en del av sina integreringslösningar med Azure ExpressRoute.
När du överväger topologiplaceringen av de nätverks-/säkerhetsperimeteralternativ som används för ExpressRoute för Microsoft 365-anslutningar, är följande extra överväganden
Djup- och typkontrollerna för nätverk/säkerhet kan påverka prestanda och skalbarhet för Microsoft 365-användarupplevelsen.
Utgående (lokal-Microsoft>) och inkommande (Microsoft-lokalt>) [om aktiverade] flöden kan ha olika krav. Dessa skiljer sig troligen från utgående till allmänna Internetmål.
Microsoft 365-kraven för portar/protokoll och nödvändiga IP-undernät är desamma, oavsett om trafiken dirigeras via ExpressRoute för Microsoft 365 eller via Internet.
Topologisk placering av kundens nätverks-/säkerhetskontroller avgör det ultimata nätverket från slutpunkt till slutpunkt mellan användaren och Microsoft 365-tjänsten och kan ha en betydande inverkan på nätverksfördröjning och överbelastning.
Kunderna uppmanas att utforma sin säkerhets-/perimetertopologi för användning med ExpressRoute för Microsoft 365 i enlighet med bästa praxis för redundans, hög tillgänglighet och haveriberedskap.
Här är ett exempel på Contoso som jämför de olika Azure ExpressRoute-anslutningsalternativen med de perimetersäkerhetsmodeller som beskrivs ovan.
Exempel: Skydda Azure ExpressRoute
Contoso överväger att implementera Azure ExpressRoute och efter att ha planerat den optimala arkitekturen för ExpressRoute för Microsoft 365 och efter att ha använt ovanstående vägledning för att förstå bandbreddskrav bestämmer de den bästa metoden för att skydda sin perimeter.
För Contoso, en multinationell organisation med platser på flera kontinenter, måste säkerheten omfatta alla perimeterr. Det optimala anslutningsalternativet för Contoso är en anslutning med flera punkter med flera peeringplatser runt om i världen för att tillgodose behoven hos sina anställda på varje kontinent. Varje kontinent innehåller redundanta Azure ExpressRoute-kretsar på kontinenten och säkerheten måste omfatta alla dessa.
Contosos befintliga infrastruktur är tillförlitlig och kan hantera det extra arbetet, vilket innebär att Contoso kan använda infrastrukturen för sin Azure ExpressRoute- och internetperimetersäkerhet. Om så inte var fallet kan Contoso välja att köpa mer utrustning för att komplettera sin befintliga utrustning eller hantera en annan typ av anslutning.
Bandbreddsplanering för Azure ExpressRoute
Varje Microsoft 365-kund har unika bandbreddsbehov beroende på antalet personer på varje plats, hur aktiva de är med varje Microsoft 365-program och andra faktorer som användning av lokal eller hybridutrustning och nätverkssäkerhetskonfigurationer.
För lite bandbredd leder till överbelastning, överföring av data och oförutsägbara fördröjningar. Att ha för mycket bandbredd leder till onödiga kostnader. I ett befintligt nätverk kallas bandbredd ofta för mängden tillgängligt utrymme på kretsen i procent. Att ha 10% utrymme kommer sannolikt att resultera i trängsel och att ha 80% utrymme innebär i allmänhet onödig kostnad. Typiska målallokeringar för huvudkontoret är 20 till 50 %.
För att hitta rätt bandbreddsnivå är den bästa mekanismen att testa din befintliga nätverksförbrukning. Det här är det enda sättet att få ett verkligt mått på användning och behov eftersom varje nätverkskonfiguration och program på vissa sätt är unika. När du mäter bör du vara uppmärksam på den totala bandbreddsförbrukningen, svarstiden och TCP-överbelastningen för att förstå dina nätverksbehov.
När du har en uppskattad baslinje som innehåller alla nätverksprogram kan du testa Microsoft 365 med en liten grupp som består av olika profiler för personer i din organisation för att fastställa den faktiska användningen och använda de två måtten för att uppskatta mängden bandbredd som du behöver för varje kontorsplats. Om det finns problem med svarstid eller TCP-överbelastning i testningen kan du behöva flytta utgående trafik närmare de personer som använder Microsoft 365 eller ta bort intensiv nätverksgenomsökning, till exempel SSL-dekryptering/inspektion.
Alla våra rekommendationer om vilken typ av nätverksbearbetning som rekommenderas gäller för både ExpressRoute- och Internet-kretsar. Detsamma gäller för resten av vägledningen på vår webbplats för prestandajustering.
Skapa dina distributions- och testprocedurer
Implementeringsplanen bör omfatta både testnings- och återställningsplanering. Om implementeringen inte fungerar som förväntat bör planen utformas för att påverka minst antal personer innan problem identifieras. Följande är några övergripande principer som din plan bör överväga.
Mellanlagra nätverkssegmentet och användartjänstens registrering för att minimera störningar.
Planera för att testa vägar med traceroute och TCP connect från en separat Internetansluten värd.
Helst bör testning av inkommande och utgående tjänster utföras i ett isolerat testnätverk med en Microsoft 365-testklientorganisation.
Alternativt kan testning utföras i ett produktionsnätverk om kunden ännu inte använder Microsoft 365 eller är i pilotmiljö.
Alternativt kan testning utföras under ett produktionsstopp som reserveras endast för testning och övervakning.
Du kan också testa genom att kontrollera vägarna för varje tjänst på varje layer 3-routernod. Detta fall back bör endast användas om ingen annan testning är möjlig eftersom brist på fysisk testning medför risker.
Skapa dina distributionsprocedurer
Distributionsprocedurerna bör distribueras till små grupper av personer i steg för att möjliggöra testning innan du distribuerar till större grupper av personer. Följande är flera sätt att mellanlagra distributionen av ExpressRoute.
Konfigurera ExpressRoute med Microsoft-peering och få vägannonserna vidarebefordrade till en enda värd endast i mellanlagrade testsyften.
Annonsera vägar till ExpressRoute-nätverket till ett enda nätverkssegment först och expandera vägannonser efter nätverkssegment eller region.
Om du distribuerar Microsoft 365 för första gången använder du ExpressRoute-nätverksdistributionen som pilot för några få personer.
Om du använder proxyservrar kan du också konfigurera en PAC-testfil för att dirigera några personer till ExpressRoute med testning och feedback innan du lägger till fler.
Implementeringsplanen bör ange var och en av de distributionsprocedurer som måste vidtas eller kommandon som måste användas för att distribuera nätverkskonfigurationen. När nätverkets avbrottstid kommer bör alla ändringar som görs vara från den skriftliga distributionsplanen som skrevs i förväg och peer-granskas. Se vår vägledning om den tekniska konfigurationen av ExpressRoute.
Uppdatera dina SPF TXT-poster om du har ändrat IP-adresser för lokala servrar som fortsätter att skicka e-post.
Uppdatera dns-poster för lokala servrar om du har ändrat IP-adresser för att hantera en ny NAT-konfiguration.
Se till att du prenumererar på RSS-feeden för Microsoft 365-slutpunktsaviseringar för att underhålla eventuella routnings- eller proxykonfigurationer.
När ExpressRoute-distributionen är klar ska procedurerna i testplanen köras. Resultat för varje procedur ska loggas. Du måste inkludera procedurer för att återställa till den ursprungliga produktionsmiljön om testplanens resultat indikerar att implementeringen inte lyckades.
Skapa dina testprocedurer
Dina testprocedurer bör innehålla tester för varje utgående och inkommande nätverkstjänst för Microsoft 365, både som använder ExpressRoute och de som inte kommer att göra det. Procedurerna bör omfatta testning från varje unik nätverksplats, inklusive användare som inte är lokala i företagets LAN.
Några exempel på testaktiviteter är följande.
Pinga från din lokala router till din nätverksoperatörsrouter.
Verifiera att ip-adressannonserna 500+ Microsoft 365 och CRM Online tas emot av din lokala router.
Kontrollera att din inkommande och utgående NAT fungerar mellan ExpressRoute och det interna nätverket.
Kontrollera att vägar till din NAT annonseras från routern.
Kontrollera att ExpressRoute har accepterat dina annonserade prefix.
- Använd följande cmdlet för att verifiera peering-annonser:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringVerifiera att ditt offentliga NAT IP-intervall inte annonseras till Microsoft via någon annan ExpressRoute- eller offentlig Internet-nätverkskrets om det inte är en specifik delmängd av ett större intervall som i föregående exempel.
ExpressRoute-kretsar är kopplade och verifierar att båda BGP-sessionerna körs.
Konfigurera en enda värd på insidan av din NAT och använd ping, tracert och tcpping för att testa anslutningen över den nya kretsen till värden outlook.office365.com. Du kan också använda ett verktyg som Wireshark eller Microsoft Network Monitor 3.4 på en speglad port till MSEE för att verifiera att du kan ansluta till den IP-adress som är associerad med outlook.office365.com.
Testa funktionerna på programnivå för Exchange Online.
Test Outlook kan ansluta till Exchange Online och skicka/ta emot e-post.
Test Outlook kan använda onlineläge.
Testa smartphone-anslutningen och funktionen skicka/ta emot.
- Testa funktioner på programnivå för SharePoint
Testa OneDrive för företag synkroniseringsklient.
Testa SharePoint-webbåtkomst.
- Testa funktioner på programnivå för Skype för företag samtalsscenarier:
Anslut till konferenssamtal som autentiserad användare [inbjudan initierad av slutanvändaren].
Bjud in användare till konferenssamtal [inbjudan skickas från MCU].
Delta i konferensen som anonym användare med hjälp av Skype för företag-webbappen.
Anslut samtalet från din kabelanslutna datoranslutning, IP-telefon och mobila enhet.
Samtal till federerad användare o Samtal till PSTN-validering: samtalet har slutförts, samtalskvaliteten är acceptabel, anslutningstiden är acceptabel.
Kontrollera att närvarostatusen för kontakter har uppdaterats för både medlemmar i klientorganisationen och federerade användare.
Vanliga problem
Asymmetrisk routning är det vanligaste implementeringsproblemet. Här är några vanliga källor att leta efter:
Använda en öppen eller platt nätverksroutningstopologi utan käll-NAT på plats.
Använder inte SNAT för att dirigera till inkommande tjänster via både Internet- och ExpressRoute-anslutningar.
Testa inte inkommande tjänster på ExpressRoute i ett testnätverk innan du distribuerar brett.
Distribuera ExpressRoute-anslutning via nätverket
Mellanlagra distributionen till ett segment av nätverket i taget och distribuera anslutningen till olika delar av nätverket progressivt med en plan för att återställa för varje nytt nätverkssegment. Om distributionen är i linje med en Microsoft 365-distribution distribuerar du först till dina Microsoft 365 pilotanvändare och utökar därifrån.
Först för testet och sedan för produktion:
Kör distributionsstegen för att aktivera ExpressRoute.
Testa att nätverksvägarna är som förväntat.
Utför testning på varje inkommande och utgående tjänst.
Återställ om du upptäcker några problem.
Konfigurera en testanslutning till ExpressRoute med ett testnätverkssegment
Nu när du har den färdiga planen på papper är det dags att testa i liten skala. I det här testet upprättar du en enda ExpressRoute-anslutning med Microsoft-peering till ett testundernät i ditt lokala nätverk. Du kan konfigurera en utvärderingsversion av Microsoft 365-klientorganisationen med anslutning till och från testundernätet och inkludera alla utgående och inkommande tjänster som du kommer att använda i produktion i testundernätet. Konfigurera DNS för testnätverkssegmentet och upprätta alla inkommande och utgående tjänster. Kör testplanen och se till att du är bekant med routningen för varje tjänst och routningsspridningen.
Köra distributions- och testplaner
När du slutför objekten som beskrivs ovan kan du checka av de områden som du har slutfört och se till att du och ditt team har granskat dem innan du kör distributions- och testningsplanerna.
Lista över utgående och inkommande tjänster som ingår i nätverksändringen.
Diagram över global nätverksarkitektur som visar både internetutgående och ExpressRoute meet-me-platser.
Diagram över nätverksroutning som visar de olika nätverkssökvägar som används för varje distribuerad tjänst.
En distributionsplan med steg för att implementera ändringarna och återställningen om det behövs.
En testplan för testning av varje Microsoft 365- och nätverkstjänst.
Slutförd pappersvalidering av produktionsvägar för inkommande och utgående tjänster.
Ett slutfört test i ett testnätverkssegment, inklusive tillgänglighetstestning.
Välj ett avbrottsfönster som är tillräckligt långt för att köras genom hela distributionsplanen och testplanen, har viss tid tillgänglig för felsökning och tid för återställning om det behövs.
Försiktighet
På grund av den komplexa typen av routning över både Internet och ExpressRoute rekommenderar vi att ytterligare bufferttid läggs till i det här fönstret för att hantera felsökning av komplex routning.
Konfigurera QoS för Skype för företag Online
QoS är nödvändigt för att få röst- och mötesförmåner för Skype för företag Online. Du kan konfigurera QoS när du har kontrollerat att ExpressRoute-nätverksanslutningen inte blockerar någon av dina andra Microsoft 365-tjänståtkomster. Konfiguration för QoS beskrivs i artikeln ExpressRoute och QoS i Skype för företag Online .
Felsöka implementeringen
Det första stället att titta på är stegen i den här implementeringsguiden, saknades några i implementeringsplanen? Gå tillbaka och kör ytterligare små nätverkstester om möjligt för att replikera felet och felsöka det där.
Identifiera vilka inkommande eller utgående tjänster som misslyckades under testningen. Hämta specifikt IP-adresser och undernät för var och en av de tjänster som misslyckades. Gå vidare och gå igenom diagrammet över nätverkstopologin på papper och verifiera routningen. Verifiera specifikt var ExpressRoute-routningen annonseras till, Testa routningen under avbrottet om möjligt med spårningar.
Kör PSPing med en nätverksspårning till varje kundslutpunkt och utvärdera källans och målets IP-adresser för att verifiera att de är som förväntat. Kör telnet till valfri e-postvärd som du exponerar på port 25 och kontrollera att SNAT döljer den ursprungliga käll-IP-adressen om det är förväntat.
Tänk på att när du distribuerar Microsoft 365 med en ExpressRoute-anslutning måste du se till att både nätverkskonfigurationen för ExpressRoute är optimalt utformad och att du även har optimerat de andra komponenterna i nätverket, till exempel klientdatorer. Förutom att använda den här planeringsguiden för att felsöka de steg som du kanske har missat har vi också skrivit en prestandafelsökningsplan för Microsoft 365 .
Här är en kort länk som du kan använda för att komma tillbaka: https://aka.ms/implementexpressroute365
Relaterade ämnen
Utvärdera Microsoft 365 nätverksanslutningar
Azure ExpressRoute för Microsoft 365
Prestanda för mediekvalitet och nätverksanslutning i Skype för företag – Online
Optimera ditt nätverk för Skype för företag – Online
ExpressRoute och QoS i Skype för företag Online
Prestandajustering i Microsoft 365 med baslinjer och prestandahistorik
Prestandafelsökningsplan för Microsoft 365
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för