ExpressRoute implementeren voor Microsoft 365

Dit artikel is van toepassing op Microsoft 365 Enterprise.

ExpressRoute voor Microsoft 365 biedt een alternatief routeringspad naar veel internetgerichte Microsoft 365-services. De architectuur van ExpressRoute voor Microsoft 365 is gebaseerd op het adverteren van openbare IP-voorvoegsels van Microsoft 365-services die al toegankelijk zijn via internet in uw ingerichte ExpressRoute-circuits voor latere herdistributie van deze IP-voorvoegsels in uw netwerk. Met ExpressRoute schakelt u voor veel Microsoft 365-services effectief verschillende routeringspaden in, via internet en via ExpressRoute. Deze routeringsstatus op uw netwerk kan een belangrijke wijziging betekenen in de wijze waarop uw interne netwerktopologie is ontworpen.

Opmerking

ExpressRoute voor Microsoft 365 wordt afgeraden omdat dit in de meeste gevallen niet het beste connectiviteitsmodel voor de service biedt. Daarom is Microsoft-autorisatie vereist om dit connectiviteitsmodel te gebruiken. We beoordelen elke klantaanvraag en autoriseren ExpressRoute voor Microsoft 365 alleen in de zeldzame scenario's waar dit nodig is. Lees de ExpressRoute voor Microsoft 365-handleiding voor meer informatie en na een uitgebreide beoordeling van het document met uw productiviteits-, netwerk- en beveiligingsteams kunt u zo nodig samenwerken met uw Microsoft-accountteam om een uitzondering in te dienen. Niet-geautoriseerde abonnementen die routefilters voor Microsoft 365 proberen te maken, ontvangen een foutbericht.

U moet uw ExpressRoute voor Microsoft 365-implementatie zorgvuldig plannen om tegemoet te komen aan de netwerkcomplexiteit van routering via zowel een toegewezen circuit met routes die in uw kernnetwerk als op internet worden geïnjecteerd. Als u en uw team de gedetailleerde planning en tests in deze handleiding niet uitvoeren, is er een hoog risico dat u af en toe last krijgt of een totaal verlies van connectiviteit met Microsoft 365-services wanneer het ExpressRoute-circuit is ingeschakeld.

Voor een succesvolle implementatie moet u uw infrastructuurvereisten analyseren, gedetailleerde netwerkevaluatie en -ontwerp doorlopen, de implementatie zorgvuldig plannen op een gefaseerde en gecontroleerde manier en een gedetailleerd validatie- en testplan maken. Voor een grote, gedistribueerde omgeving is het niet ongebruikelijk dat implementaties enkele maanden duren. Deze handleiding is ontworpen om u te helpen vooruit te plannen.

Grote succesvolle implementaties kunnen zes maanden in beslag nemen in de planning en omvatten vaak teamleden uit veel gebieden in de organisatie, waaronder netwerkbeheerders, firewall- en proxyserverbeheerders, Microsoft 365-beheerders, beveiliging, ondersteuning voor eindgebruikers, projectbeheer en executive sponsorship. Uw investering in het planningsproces vermindert de kans dat implementatiefouten optreden, wat resulteert in downtime of complexe en dure probleemoplossing.

We verwachten dat aan de volgende vereisten is voldaan voordat deze implementatiehandleiding wordt gestart.

1. U hebt een netwerkevaluatie voltooid om te bepalen of ExpressRoute wordt aanbevolen en goedgekeurd.

2. U hebt een ExpressRoute-netwerkserviceprovider geselecteerd. Meer informatie over de ExpressRoute-partners en peeringlocaties.

3. U hebt de ExpressRoute-documentatie al gelezen en begrepen en uw interne netwerk kan end-to-end voldoen aan de ExpressRoute-vereisten.

4. Uw team heeft alle openbare richtlijnen en documentatie gelezen op https://aka.ms/expressrouteoffice365, https://aka.ms/erten heeft de Azure ExpressRoute voor Microsoft 365 Training-serie op Channel 9 bekeken om inzicht te krijgen in essentiële technische details, waaronder:

   • De internetafhankelijkheden van SaaS-services.

   • Asymmetrische routes voorkomen en complexe routering afhandelen.

   • Perimeterbeveiliging, beschikbaarheid en besturingselementen op toepassingsniveau opnemen.

Begin met het verzamelen van vereisten

Bepaal eerst welke functies en services u wilt gebruiken binnen uw organisatie. U moet bepalen welke functies van de verschillende Microsoft 365-services worden gebruikt en op welke locaties in uw netwerk personen worden gehost die deze functies gebruiken. Met de catalogus met scenario's moet u de netwerkkenmerken toevoegen die voor elk van deze scenario's zijn vereist. zoals binnenkomende en uitgaande netwerkverkeersstromen en of de Microsoft 365-eindpunten al dan niet beschikbaar zijn via ExpressRoute.

Ga als volgt te werk om de vereisten van uw organisatie te verzamelen:

• Catalogiseer het binnenkomende en uitgaande netwerkverkeer voor de Microsoft 365-services die uw organisatie gebruikt. Raadpleeg de pagina Microsoft 365-URL's en IP-adresbereiken voor de beschrijving van stromen die verschillende Microsoft 365-scenario's vereisen.

• Verzamel documentatie van bestaande netwerktopologie met details van uw interne WAN-backbone en -topologie, connectiviteit van satellietsites, laatste mijl gebruikersconnectiviteit, routering naar uitgaande netwerkperimeterpunten en proxyservices.

  • Identificeer inkomende service-eindpunten in de netwerkdiagrammen waarmee Microsoft 365 en andere Microsoft-services verbinding maken, waarbij zowel internet- als voorgestelde ExpressRoute-verbindingspaden worden weergegeven.

  • Identificeer alle geografische gebruikerslocaties en WAN-connectiviteit tussen locaties, samen met welke locaties momenteel een uitgaand verkeer naar internet hebben en welke locaties worden voorgesteld om een uitgaand verkeer naar een ExpressRoute-peeringlocatie te hebben.

  • Identificeer alle edge-apparaten, zoals proxy's, firewalls, enzovoort, en catalogiseer hun relatie met stromen die via internet en ExpressRoute gaan.

  • Documenteer of eindgebruikers toegang hebben tot Microsoft 365-services via directe routering of indirecte toepassingsproxy voor zowel internet- als ExpressRoute-stromen.

• Voeg de locatie van uw tenant en meet-me-locaties toe aan uw netwerkdiagram.

• Maak een schatting van de verwachte en waargenomen netwerkprestaties en latentiekenmerken van belangrijke gebruikerslocaties naar Microsoft 365. Houd er rekening mee dat Microsoft 365 een wereldwijde en gedistribueerde set services is en dat gebruikers verbinding maken met locaties die mogelijk afwijken van de locatie van hun tenant. Daarom wordt aanbevolen om de latentie tussen de gebruiker en de dichtstbijzijnde rand van het wereldwijde Microsoft-netwerk te meten en te optimaliseren via ExpressRoute- en internetverbindingen. U kunt uw bevindingen uit de netwerkevaluatie gebruiken om u te helpen bij deze taak.

• Vermeld de vereisten voor bedrijfsnetwerkbeveiliging en hoge beschikbaarheid waaraan moet worden voldaan met de nieuwe ExpressRoute-verbinding. Hoe krijgen gebruikers bijvoorbeeld toegang tot Microsoft 365 in het geval van een storing in het internetuitgangs- of ExpressRoute-circuit.

• Documenteer welke inkomende en uitgaande Microsoft 365-netwerkstromen het internetpad gebruiken en welke gebruikmaken van ExpressRoute. Voor de specifieke geografische locaties van uw gebruikers en de details van uw on-premises netwerktopologie moet het plan mogelijk verschillen van de ene gebruikerslocatie naar de andere.

Uw uitgaande en binnenkomende netwerkverkeer catalogiseren

Om routering en andere netwerkcomplexiteiten te minimaliseren, raden we u aan expressRoute voor Microsoft 365 alleen te gebruiken voor de netwerkverkeersstromen die via een toegewezen verbinding moeten gaan vanwege wettelijke vereisten of als resultaat van de netwerkevaluatie. Daarnaast raden we u aan het bereik van ExpressRoute-routering te fasering en uitgaande en binnenkomende netwerkverkeersstromen te benaderen als verschillende en afzonderlijke fasen van het implementatieproject. ExpressRoute voor Microsoft 365 implementeren voor alleen door de gebruiker geïnitieerde uitgaande netwerkverkeersstromen en binnenkomende netwerkverkeersstromen via internet laten staan, kan helpen de toename van topologische complexiteit en risico's van het introduceren van extra asymmetrische routeringsmogelijkheden te beheersen.

Uw catalogus met netwerkverkeer moet lijsten bevatten van alle binnenkomende en uitgaande netwerkverbindingen die u hebt tussen uw on-premises netwerk en Microsoft.

• Uitgaande netwerkverkeersstromen zijn scenario's waarbij een verbinding wordt geïnitieerd vanuit uw on-premises omgeving, zoals vanaf interne clients of servers, met een doel van de Microsoft-services. Deze verbindingen kunnen rechtstreeks naar Microsoft 365 of indirect zijn, bijvoorbeeld wanneer de verbinding via proxyservers, firewalls of andere netwerkapparaten op het pad naar Microsoft 365 gaat.

• Binnenkomende netwerkverkeersstromen zijn scenario's waarbij een verbinding wordt geïnitieerd vanuit de Microsoft-cloud naar een on-premises host. Deze verbindingen moeten doorgaans via de firewall en andere beveiligingsinfrastructuur gaan die door het beveiligingsbeleid van de klant is vereist voor extern afkomstige stromen.

Lees de sectie Routesymmetrie garanderen om te bepalen welke services binnenkomend verkeer verzenden en zoek naar de kolom ExpressRoute voor Microsoft 365 in het referentieartikel Microsoft 365-eindpunten om de rest van de connectiviteitsgegevens te bepalen.

Voor elke service waarvoor een uitgaande verbinding is vereist, moet u de geplande connectiviteit voor de service beschrijven, inclusief netwerkroutering, proxyconfiguratie, pakketinspectie en bandbreedtebehoeften.

Voor elke service waarvoor een binnenkomende verbinding is vereist, hebt u aanvullende informatie nodig. Servers in de Microsoft-cloud maken verbinding met uw on-premises netwerk. Om ervoor te zorgen dat de verbindingen correct worden gemaakt, moet u alle aspecten van deze connectiviteit beschrijven, inclusief; de openbare DNS-vermeldingen voor de services die deze binnenkomende verbindingen accepteren, de IPv4-IP-adressen met CIDR-indeling, welke ISP-apparatuur betrokken is en hoe binnenkomende NAT of bron-NAT wordt verwerkt voor deze verbindingen.

Binnenkomende verbindingen moeten worden gecontroleerd, ongeacht of ze verbinding maken via internet of ExpressRoute om ervoor te zorgen dat asymmetrische routering niet is geïntroduceerd. In sommige gevallen moeten on-premises eindpunten waarmee Microsoft 365-services binnenkomende verbindingen initiëren, mogelijk ook worden geopend door andere Microsoft- en niet-Microsoft-services. Het is van het grootste belang dat het inschakelen van ExpressRoute-routering naar deze services voor Microsoft 365-doeleinden andere scenario's niet onderbreekt. In veel gevallen moeten klanten mogelijk specifieke wijzigingen in hun interne netwerk implementeren, zoals nat op basis van bron, om ervoor te zorgen dat binnenkomende stromen van Microsoft symmetrisch blijven nadat ExpressRoute is ingeschakeld.

Hier volgt een voorbeeld van het vereiste detailniveau. In dit geval wordt Exchange Hybrid gerouteerd naar het on-premises systeem via ExpressRoute.

Verbindingseigenschap	Waarde
Richting netwerkverkeer	Inkomende
Service	Hybride versie van Exchange
Openbaar Microsoft 365-eindpunt (bron)	Exchange Online (IP-adressen)
Openbaar on-premises eindpunt (doel)	5.5.5.5
Openbare (internet) DNS-vermelding	Autodiscover.contoso.com
Wordt dit on-premises eindpunt gebruikt door andere (niet-Microsoft 365) Microsoft-services	Neen
Wordt dit on-premises eindpunt gebruikt door gebruikers/systemen op internet?	Ja
Interne systemen die zijn gepubliceerd via openbare eindpunten	Exchange Server clienttoegangsrol (on-premises) 192.168.101, 192.168.102, 192.168.103
IP-advertentie van het openbare eindpunt	Naar internet: 5.5.0.0/16 Naar ExpressRoute: 5.5.5.0/24
Beveiliging/perimeterbesturingselementen	Internetpad: DeviceID_002 ExpressRoute-pad: DeviceID_003
Hoge beschikbaarheid	Actief/actief in 2 geografisch redundante/ExpressRoute-circuits - Chicago en Dallas
Padsymmetriebeheer	Methode: Bron-NAT-internetpad: Binnenkomende bron-NAT-verbindingen naar 192.168.5.5 ExpressRoute-pad: bron-NAT-verbindingen naar 192.168.1.0 (Chicago) en 192.168.2.0 (Dallas)

Hier volgt een voorbeeld van een service die alleen uitgaand is:

Verbindingseigenschap	Value
Richting netwerkverkeer	Uitgaand
Service	SharePoint
On-premises eindpunt (bron)	Gebruikerswerkstation
Openbaar Microsoft 365-eindpunt (doel)	SharePoint (IP-adressen)
Openbare (internet) DNS-vermelding	*.sharepoint.com (en meer FQDN's)
CDN-verwijzingen	cdn.sharepointonline.com (en meer FQDN's) - IP-adressen die worden onderhouden door CDN-providers)
IP-advertentie en NAT in gebruik	Internetpad/bron-NAT: 1.1.1.0/24 ExpressRoute-pad/bron-NAT: 1.1.2.0/24 (Chicago) en 1.1.3.0/24 (Dallas)
Connectiviteitsmethode	Internet: via laag 7-proxy (.pac-bestand) ExpressRoute: directe routering (geen proxy)
Beveiliging/perimeterbesturingselementen	Internetpad: DeviceID_002 ExpressRoute-pad: DeviceID_003
Hoge beschikbaarheid	Internetpad: redundante internetuitgang ExpressRoute-pad: Actieve/actieve 'hot potato'-routering over 2 geografisch redundante ExpressRoute-circuits - Chicago en Dallas
Padsymmetriebeheer	Methode: Bron-NAT voor alle verbindingen

Uw netwerktopologieontwerp met regionale connectiviteit

Zodra u de services en de bijbehorende netwerkverkeersstromen begrijpt, kunt u een netwerkdiagram maken met deze nieuwe connectiviteitsvereisten en de wijzigingen die u gaat aanbrengen voor het gebruik van ExpressRoute voor Microsoft 365. Het diagram moet het volgende bevatten:

1. Alle gebruikerslocaties van waaruit Microsoft 365 en andere services worden geopend.

2. Alle internet- en ExpressRoute-uitgaande punten.

3. Alle uitgaande en binnenkomende apparaten die de connectiviteit in en uit het netwerk beheren, inclusief routers, firewalls, toepassingsproxyservers en inbraakdetectie/-preventie.

4. Interne bestemmingen voor al het binnenkomende verkeer, zoals interne ADFS-servers die verbindingen van de ADFS-webtoepassingsproxyservers accepteren.

5. Catalogus van alle IP-subnetten die worden geadverteerd

6. Identificeer elke locatie waar mensen toegang hebben tot Microsoft 365 en vermeld de meet-me-locaties die worden gebruikt voor ExpressRoute.

7. Locaties en gedeelten van uw interne netwerktopologie, waar Microsoft IP-voorvoegsels die zijn geleerd van ExpressRoute, worden geaccepteerd, gefilterd en doorgegeven aan.

8. De netwerktopologie moet de geografische locatie van elk netwerksegment illustreren en hoe deze verbinding maakt met het Microsoft-netwerk via ExpressRoute en/of internet.

In het onderstaande diagram ziet u elke locatie waar mensen Microsoft 365 gaan gebruiken, samen met de binnenkomende en uitgaande routeringsadvertenties naar Microsoft 365.

Voor uitgaand verkeer hebben de personen op drie manieren toegang tot Microsoft 365:

1. Via een meet-me-locatie in Noord-Amerika voor de mensen in Californië.

2. Via een meet-me locatie in Hong Kong Special Administrative Region voor de mensen in Hong Kong SAR.

3. Via internet in Bangladesh waar minder mensen zijn en geen ExpressRoute-circuit ingericht.

Op dezelfde manier retourneert het binnenkomende netwerkverkeer van Microsoft 365 op een van de volgende drie manieren:

1. Via een meet-me-locatie in Noord-Amerika voor de mensen in Californië.

2. Via een meet-me locatie in Hong Kong Special Administrative Region voor de mensen in Hong Kong SAR.

3. Via internet in Bangladesh waar minder mensen zijn en geen ExpressRoute-circuit ingericht.

De juiste meet-me-locatie bepalen

De selectie van meet-me-locaties, de fysieke locatie waar uw ExpressRoute-circuit uw netwerk verbindt met het Microsoft-netwerk, wordt beïnvloed door de locaties waar mensen toegang hebben tot Microsoft 365. Als SaaS-aanbieding werkt Microsoft 365 niet op dezelfde manier als Azure onder het regionale IaaS- of PaaS-model. In plaats daarvan is Microsoft 365 een gedistribueerde set samenwerkingsservices, waarbij gebruikers mogelijk verbinding moeten maken met eindpunten in meerdere datacenters en regio's, die zich niet noodzakelijkerwijs in dezelfde locatie of regio bevinden waar de tenant van de gebruiker wordt gehost.

Dit betekent dat de belangrijkste overweging die u moet maken bij het selecteren van meet-me-locaties voor ExpressRoute voor Microsoft 365, is waar de personen in uw organisatie verbinding maken. De algemene aanbeveling voor optimale Microsoft 365-connectiviteit is om routering te implementeren, zodat gebruikersaanvragen aan Microsoft 365-services via het kortste netwerkpad worden doorgegeven aan het Microsoft-netwerk. Dit wordt ook vaak 'hot potato'-routering genoemd. Als de meeste Microsoft 365-gebruikers zich bijvoorbeeld op een of twee locaties bevinden, wordt het optimale ontwerp gemaakt door meet-me-locaties te selecteren die zich het dichtst bij de locatie van die gebruikers bevinden. Als uw bedrijf grote gebruikerspopulaties in veel verschillende regio's heeft, kunt u overwegen om meerdere ExpressRoute-circuits en meet-me-locaties te hebben. Voor sommige gebruikerslocaties is het kortste/meest optimale pad naar het Microsoft-netwerk en Microsoft 365 mogelijk niet via uw interne WAN- en ExpressRoute-meet-me-punten, maar via internet.

Vaak zijn er meerdere meet-me-locaties die kunnen worden geselecteerd binnen een regio met relatieve nabijheid van uw gebruikers. Vul de volgende tabel in om uw beslissingen te nemen.

Geplande ExpressRoute-meet-me-locaties in Californië en New York

Locatie	Aantal personen	Verwachte latentie voor Microsoft-netwerk via internetuitgang	Verwachte latentie voor Microsoft-netwerk 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)

Zodra de globale netwerkarchitectuur met de Microsoft 365-regio, meet-me-locaties van ExpressRoute-netwerkserviceprovider en het aantal personen per locatie is ontwikkeld, kan deze worden gebruikt om te bepalen of er optimalisaties kunnen worden aangebracht. Het kan ook wereldwijde hairpin-netwerkverbindingen weergeven waarbij verkeer naar een verre locatie wordt gerouteerd om de meet-me-locatie te krijgen. Als er een hairpin op het wereldwijde netwerk wordt gedetecteerd, moet deze worden hersteld voordat u doorgaat. Zoek een andere meet-me-locatie of gebruik selectieve internetuitvalpunten om de hairpin te vermijden.

In het eerste diagram ziet u een voorbeeld van een klant met twee fysieke locaties in Noord-Amerika. U kunt informatie bekijken over kantoorlocaties, Microsoft 365-tenantlocaties en verschillende opties voor ExpressRoute-meet-me-locaties. In dit voorbeeld heeft de klant de meet-me-locatie geselecteerd op basis van twee principes, in volgorde:

1. De nabijheid van de personen in hun organisatie.

2. Het dichtst bij een Microsoft-datacenter waar Microsoft 365 wordt gehost.

Door dit concept iets verder uit te breiden, toont het tweede diagram een voorbeeld van een multi-nationale klant die te maken heeft met vergelijkbare informatie en besluitvorming. Deze klant heeft een klein kantoor in Bangladesh met slechts een klein team van 10 mensen dat zich richt op het uitbreiden van hun voetafdruk in de regio. Er is een meet-me-locatie in Chennai en een Microsoft-datacenter met Microsoft 365 gehost in Chennai, dus een meet-me-locatie zou logisch zijn; voor 10 personen zijn de kosten van het extra circuit echter zwaar. Als u naar uw netwerk kijkt, moet u bepalen of de latentie bij het verzenden van uw netwerkverkeer via uw netwerk effectiever is dan het uitgeven van het kapitaal om een ander ExpressRoute-circuit te verkrijgen.

Als alternatief kunnen de tien mensen in Bangladesh betere prestaties ervaren met hun netwerkverkeer dat via internet naar het Microsoft-netwerk wordt verzonden, dan ze zouden routeren op hun interne netwerk, zoals we hebben laten zien in de inleidende diagrammen en hieronder weergegeven.

Creatie uw ExpressRoute voor Microsoft 365-implementatieplan

Uw implementatieplan moet zowel de technische details van het configureren van ExpressRoute als de details van het configureren van alle andere infrastructuur op uw netwerk omvatten, zoals het volgende.

• Plan welke services worden gesplitst tussen ExpressRoute en Internet.

• Plan bandbreedte, beveiliging, hoge beschikbaarheid en failover.

• Binnenkomende en uitgaande routering ontwerpen, inclusief de juiste optimalisaties van routeringspaden voor verschillende locaties

• Bepaal hoe ver ExpressRoute-routes in uw netwerk worden geadverteerd en wat het mechanisme is voor clients om internet- of ExpressRoute-pad te selecteren; bijvoorbeeld directe routering of toepassingsproxy.

• Dns-recordwijzigingen plannen, inclusief Sender Policy Framework-vermeldingen .

• PLAN NAT-strategie, inclusief uitgaande en binnenkomende bron-NAT.

Plan uw routering met zowel internet- als ExpressRoute-netwerkpaden

• Voor uw eerste implementatie wordt het gebruik van internet aanbevolen voor alle binnenkomende services, zoals binnenkomende e-mail of hybride connectiviteit.

• Plan LAN-routering van eindgebruikersclients, zoals het configureren van een PAC/WPAD-bestand, standaardroute, proxyservers en BGP-routeadvertenties.

• Plan perimeterroutering, inclusief proxyservers, firewalls en cloudproxy's.

Uw bandbreedte, beveiliging, hoge beschikbaarheid en failover plannen

Creatie een plan voor de vereiste bandbreedte voor elke grote Microsoft 365-workload. Schat de bandbreedtevereisten voor Exchange Online, SharePoint en Skype voor Bedrijven Online afzonderlijk. U kunt de schattingscalculators gebruiken die we hebben verstrekt voor Exchange Online en Skype voor Bedrijven als uitgangspunt. Een testtest met een representatieve steekproef van de gebruikersprofielen en locaties is echter vereist om de bandbreedtebehoeften van uw organisatie volledig te begrijpen.

Voeg aan uw abonnement toe hoe beveiliging wordt afgehandeld op elke locatie van internet en ExpressRoute-uitgaand verkeer. Onthoud dat alle ExpressRoute-verbindingen met Microsoft 365 gebruikmaken van openbare peering en nog steeds moeten worden beveiligd in overeenstemming met het beveiligingsbeleid van uw bedrijf voor het maken van verbinding met externe netwerken.

Voeg details toe aan uw plan over welke personen worden beïnvloed door welk type storing en hoe deze personen hun werk op de eenvoudigste manier volledig kunnen uitvoeren.

Bandbreedtevereisten plannen, waaronder Skype voor Bedrijven vereisten voor Jitter, Latentie, Congestie en Headroom

Skype voor Bedrijven Online heeft ook specifieke extra netwerkvereisten, die worden beschreven in het artikel Mediakwaliteit en netwerkconnectiviteitsprestaties in Skype voor Bedrijven Online.

Lees de sectie Bandbreedteplanning voor Azure ExpressRoute. Wanneer u een bandbreedte-evaluatie uitvoert met uw testgebruikers, kunt u onze handleiding Microsoft 365-prestatieafstemming gebruiken met behulp van basislijnen en prestatiegeschiedenis.

Vereisten voor hoge beschikbaarheid plannen

Creatie een plan voor hoge beschikbaarheid om aan uw behoeften te voldoen en neem dit op in uw bijgewerkte netwerktopologiediagram. Lees de sectie Hoge beschikbaarheid en failover met Azure ExpressRoute.

Netwerkbeveiligingsvereisten plannen

Creatie een plan om te voldoen aan uw netwerkbeveiligingsvereisten en neem dit op in uw bijgewerkte netwerktopologiediagram. Lees de sectie Beveiligingsbesturingselementen toepassen op Azure ExpressRoute voor Microsoft 365-scenario's.

Uitgaande serviceconnectiviteit ontwerpen

ExpressRoute voor Microsoft 365 heeft uitgaande netwerkvereisten die mogelijk onbekend zijn. Met name de IP-adressen die uw gebruikers en netwerken voor Microsoft 365 vertegenwoordigen en fungeren als de broneindpunten voor uitgaande netwerkverbindingen met Microsoft, moeten voldoen aan specifieke vereisten die hieronder worden beschreven.

1. De eindpunten moeten openbare IP-adressen zijn die zijn geregistreerd bij uw bedrijf of voor de provider die ExpressRoute-connectiviteit aan u biedt.

2. De eindpunten moeten worden aangekondigd aan Microsoft en worden gevalideerd/geaccepteerd door ExpressRoute.

3. De eindpunten mogen niet worden geadverteerd op internet met dezelfde of meer voorkeursrouteringsmetrieken.

4. De eindpunten mogen niet worden gebruikt voor connectiviteit met Microsoft-services die niet zijn geconfigureerd via ExpressRoute.

Als uw netwerkontwerp niet aan deze vereisten voldoet, is er een groot risico dat uw gebruikers verbindingsproblemen ondervinden met Microsoft 365 en andere Microsoft-services vanwege zwarte routering of asymmetrische routering. Dit gebeurt wanneer aanvragen naar Microsoft-services worden gerouteerd via ExpressRoute, maar antwoorden via internet of omgekeerd worden doorgestuurd en de antwoorden worden verwijderd door stateful netwerkapparaten zoals firewalls.

De meest voorkomende methode die u kunt gebruiken om aan de bovenstaande vereisten te voldoen, is het gebruik van bron-NAT, geïmplementeerd als onderdeel van uw netwerk of geleverd door uw ExpressRoute-provider. Met bron-NAT kunt u de details en privé-IP-adressen van uw internetnetwerk abstraheren van ExpressRoute en; in combinatie met de juiste IP-routeadvertenties, bieden een eenvoudig mechanisme om padsymmetrie te garanderen. Als u stateful netwerkapparaten gebruikt die specifiek zijn voor ExpressRoute-peeringlocaties, moet u afzonderlijke NAT-pools implementeren voor elke ExpressRoute-peering om padsymmetrie te garanderen.

Lees meer over de Nat-vereisten voor ExpressRoute.

Voeg de wijzigingen voor de uitgaande connectiviteit toe aan het netwerktopologiediagram.

Binnenkomende serviceconnectiviteit ontwerpen

De meeste zakelijke Microsoft 365-implementaties gaan uit van een vorm van binnenkomende connectiviteit van Microsoft 365 naar on-premises services, zoals voor Exchange, SharePoint en Skype voor Bedrijven hybride scenario's, postvakmigraties en verificatie met behulp van ADFS-infrastructuur. Wanneer ExpressRoute een extra routeringspad inschakelt tussen uw on-premises netwerk en Microsoft voor uitgaande connectiviteit, kunnen deze binnenkomende verbindingen onbedoeld worden beïnvloed door asymmetrische routering, zelfs als u wilt dat deze stromen internet blijven gebruiken. Een paar voorzorgsmaatregelen die hieronder worden beschreven, worden aanbevolen om ervoor te zorgen dat er geen gevolgen zijn voor internetgebaseerde binnenkomende stromen van Microsoft 365 naar on-premises systemen.

Om de risico's van asymmetrische routering voor binnenkomende netwerkverkeersstromen te minimaliseren, moeten alle binnenkomende verbindingen bron-NAT gebruiken voordat ze worden gerouteerd naar segmenten van uw netwerk, die routeringszichtbaarheid hebben in ExpressRoute. Als de binnenkomende verbindingen zijn toegestaan in een netwerksegment met routeringszichtbaarheid in ExpressRoute zonder bron-NAT, worden aanvragen die afkomstig zijn van Microsoft 365 ingevoerd vanaf internet, maar het antwoord dat teruggaat naar Microsoft 365 geeft de voorkeur aan het ExpressRoute-netwerkpad terug naar het Microsoft-netwerk, waardoor asymmetrische routering wordt veroorzaakt.

U kunt een van de volgende implementatiepatronen overwegen om aan deze vereiste te voldoen:

1. Voer bron-NAT uit voordat aanvragen worden gerouteerd naar uw interne netwerk met behulp van netwerkapparatuur zoals firewalls of load balancers op het pad van internet naar uw on-premises systemen.

2. Zorg ervoor dat ExpressRoute-routes niet worden doorgegeven aan de netwerksegmenten waar zich inkomende services bevinden, zoals front-endservers of omgekeerde proxysystemen, die internetverbindingen verwerken.

Als u expliciet rekening houdt met deze scenario's in uw netwerk en alle binnenkomende netwerkverkeersstromen via internet houdt, kunt u de implementatie en het operationele risico van asymmetrische routering minimaliseren.

Er kunnen gevallen zijn waarin u bepaalde binnenkomende stromen wilt omleiden via ExpressRoute-verbindingen. Houd voor deze scenario's rekening met de volgende extra overwegingen.

1. Microsoft 365 kan zich alleen richten op on-premises eindpunten die gebruikmaken van openbare IP-adressen. Dit betekent dat zelfs als het on-premises binnenkomende eindpunt alleen beschikbaar is voor Microsoft 365 via ExpressRoute, er nog steeds een openbaar IP-adres aan moet zijn gekoppeld.

2. Alle DNS-naamomzetting die Microsoft 365-services uitvoeren om on-premises eindpunten om te zetten, worden uitgevoerd met behulp van openbare DNS. Dit betekent dat u de FQDN van binnenkomende service-eindpunten moet registreren voor IP-toewijzingen op internet.

3. Als u binnenkomende netwerkverbindingen via ExpressRoute wilt ontvangen, moeten de openbare IP-subnetten voor deze eindpunten worden aangekondigd bij Microsoft via ExpressRoute.

4. Evalueer deze binnenkomende netwerkverkeersstromen zorgvuldig om ervoor te zorgen dat de juiste beveiligings- en netwerkcontroles op hen worden toegepast in overeenstemming met het beveiligings- en netwerkbeleid van uw bedrijf.

5. Zodra uw on-premises binnenkomende eindpunten via ExpressRoute aan Microsoft worden geadverteerd, wordt ExpressRoute in feite het voorkeursrouteringspad naar deze eindpunten voor alle Microsoft-services, inclusief Microsoft 365. Dit betekent dat deze eindpuntsubnetten alleen mogen worden gebruikt voor communicatie met Microsoft 365-services en geen andere services op het Microsoft-netwerk. Anders veroorzaakt uw ontwerp asymmetrische routering waarbij binnenkomende verbindingen van andere Microsoft-services de voorkeur geven aan binnenkomende verbindingen via ExpressRoute, terwijl het retourpad internet gebruikt.

6. Als een ExpressRoute-circuit of meet-me-locatie offline is, moet u ervoor zorgen dat de on-premises binnenkomende eindpunten nog steeds beschikbaar zijn om aanvragen te accepteren via een afzonderlijk netwerkpad. Dit kan betekenen dat u subnetten voor deze eindpunten adverteert via meerdere ExpressRoute-circuits.

7. We raden u aan bron-NAT toe te passen voor alle binnenkomende netwerkverkeersstromen die uw netwerk binnenkomen via ExpressRoute, met name wanneer deze stromen stateful netwerkapparaten zoals firewalls kruisen.

8. Sommige on-premises services, zoals ADFS-proxy of Exchange Autodiscover, ontvangen mogelijk binnenkomende aanvragen van zowel Microsoft 365-services als gebruikers van internet. Voor deze aanvragen richt Microsoft 365 zich op dezelfde FQDN als gebruikersaanvragen via internet. Het toestaan van binnenkomende gebruikersverbindingen van internet naar die on-premises eindpunten, terwijl Microsoft 365-verbindingen worden gedwongen ExpressRoute te gebruiken, vertegenwoordigt een aanzienlijke routeringscomplexiteit. Voor de overgrote meerderheid van klanten wordt het implementeren van dergelijke complexe scenario's via ExpressRoute niet aanbevolen vanwege operationele overwegingen. Deze extra overhead omvat het beheren van risico's van asymmetrische routering en vereist dat u advertenties en beleidsregels voor routering in meerdere dimensies zorgvuldig beheert.

Werk uw netwerktopologieplan bij om te laten zien hoe u asymmetrische routes zou voorkomen

U wilt asymmetrische routering voorkomen om ervoor te zorgen dat personen in uw organisatie naadloos Microsoft 365 en andere belangrijke services op internet kunnen gebruiken. Er zijn twee algemene configuraties die klanten hebben die asymmetrische routering veroorzaken. Dit is een goed moment om de netwerkconfiguratie te bekijken die u wilt gebruiken en te controleren of een van deze asymmetrische routeringsscenario's kan bestaan.

Om te beginnen gaan we enkele verschillende situaties onderzoeken die betrekking hebben op het volgende netwerkdiagram. In dit diagram bevinden alle servers die binnenkomende aanvragen ontvangen, zoals ADFS of on-premises hybride servers, zich in het datacenter van New Jersey en worden ze op internet geadverteerd.

1. Hoewel het perimeternetwerk beveiligd is, is er geen bron-NAT beschikbaar voor binnenkomende aanvragen.

2. De servers in het datacenter van New Jersey kunnen zowel internet- als ExpressRoute-routes zien.

We hebben ook suggesties voor het oplossen van deze problemen.

Probleem 1: Cloud-naar-on-premises verbinding via internet

In het volgende diagram ziet u het asymmetrische netwerkpad dat is gemaakt wanneer uw netwerkconfiguratie geen NAT biedt voor binnenkomende aanvragen van de Microsoft-cloud via internet.

1. De binnenkomende aanvraag van Microsoft 365 haalt het IP-adres van het on-premises eindpunt op van openbare DNS en verzendt de aanvraag naar uw perimeternetwerk.

2. In deze foutieve configuratie is er geen bron-NAT geconfigureerd of beschikbaar in het perimeternetwerk waar het verkeer wordt verzonden, waardoor het werkelijke bron-IP-adres wordt gebruikt als retourbestemming.

• De server op uw netwerk stuurt het retourverkeer naar Microsoft 365 via een beschikbare ExpressRoute-netwerkverbinding.

• Het resultaat is een asymmetrisch pad voor die stroom naar Microsoft 365, wat resulteert in een verbroken verbinding.

Oplossing 1a: Bron-NAT

Als u een bron-NAT toevoegt aan de binnenkomende aanvraag, wordt dit onjuist geconfigureerde netwerk opgelost. In dit diagram:

1. De binnenkomende aanvraag blijft binnenkomen via het perimeternetwerk van het datacenter in New Jersey. Deze keer is bron-NAT beschikbaar.

2. Het antwoord van de server gaat terug naar het IP-adres dat is gekoppeld aan de bron-NAT in plaats van het oorspronkelijke IP-adres, waardoor het antwoord langs hetzelfde netwerkpad wordt geretourneerd.

Oplossing 1b: Bereik routeren

U kunt er ook voor kiezen om niet toe te staan dat de ExpressRoute BGP-voorvoegsels worden geadverteerd, waardoor het alternatieve netwerkpad voor deze computers wordt verwijderd. In dit diagram:

1. De binnenkomende aanvraag blijft binnenkomen via het perimeternetwerk van het datacenter in New Jersey. Deze keer zijn de voorvoegsels die door Microsoft via het ExpressRoute-circuit worden geadverteerd, niet beschikbaar voor het datacenter van New Jersey.

2. Het antwoord van de server gaat terug naar het IP-adres dat is gekoppeld aan het oorspronkelijke IP-adres via de enige beschikbare route, waardoor het antwoord via hetzelfde netwerkpad wordt geretourneerd.

Probleem 2: Cloud-naar-on-premises verbinding via ExpressRoute

In het volgende diagram ziet u het asymmetrische netwerkpad dat is gemaakt wanneer uw netwerkconfiguratie geen NAT biedt voor binnenkomende aanvragen van de Microsoft-cloud via ExpressRoute.

1. De binnenkomende aanvraag van Microsoft 365 haalt het IP-adres op van DNS en verzendt de aanvraag naar uw perimeternetwerk.

2. In deze foutieve configuratie is er geen bron-NAT geconfigureerd of beschikbaar in het perimeternetwerk waar het verkeer wordt verzonden, waardoor het werkelijke bron-IP-adres wordt gebruikt als retourbestemming.

• De computer op uw netwerk stuurt het retourverkeer naar Microsoft 365 via een beschikbare ExpressRoute-netwerkverbinding.

• Het resultaat is een asymmetrische verbinding met Microsoft 365.

Oplossing 2: Bron-NAT

Als u een bron-NAT toevoegt aan de binnenkomende aanvraag, wordt dit onjuist geconfigureerde netwerk opgelost. In dit diagram:

1. De binnenkomende aanvraag blijft binnenkomen via het perimeternetwerk van het datacenter in New York. Deze keer is bron-NAT beschikbaar.

2. Het antwoord van de server gaat terug naar het IP-adres dat is gekoppeld aan de bron-NAT in plaats van het oorspronkelijke IP-adres, waardoor het antwoord langs hetzelfde netwerkpad wordt geretourneerd.

Papier controleert of het netwerkontwerp padsymmetrie heeft

Op dit moment moet u op papier controleren of uw implementatieplan routesymmetrie biedt voor de verschillende scenario's waarin u Microsoft 365 gaat gebruiken. U identificeert de specifieke netwerkroute die naar verwachting moet worden genomen wanneer een persoon verschillende functies van de service gebruikt. Van het on-premises netwerk en WAN-routering naar de perimeterapparaten tot het verbindingspad; ExpressRoute of internet, en aan de verbinding met het online-eindpunt.

U moet dit doen voor alle Microsoft 365-netwerkservices die eerder zijn geïdentificeerd als services die uw organisatie gaat gebruiken.

Het helpt om dit papieren overzicht van routes te doen met een tweede persoon. Leg uit waar elke netwerkhop naar verwachting de volgende route vandaan krijgt en zorg ervoor dat u bekend bent met de routeringspaden. Houd er rekening mee dat ExpressRoute altijd een route met een groter bereik naar IP-adressen van Microsoft-servers biedt, waardoor de routekosten lager zijn dan een standaardroute op internet.

Configuratie van clientconnectiviteit ontwerpen

Als u een proxyserver gebruikt voor internetverkeer, moet u eventuele PAC- of clientconfiguratiebestanden aanpassen om ervoor te zorgen dat clientcomputers op uw netwerk correct zijn geconfigureerd om het Gewenste ExpressRoute-verkeer naar Microsoft 365 te verzenden zonder uw proxyserver te verzenden, en het resterende verkeer, inclusief sommige Microsoft 365-verkeer, wordt verzonden naar de relevante proxy. Lees onze handleiding over het beheren van Microsoft 365-eindpunten, bijvoorbeeld PAC-bestanden.

Opmerking

De eindpunten veranderen regelmatig, zo vaak als wekelijks. U moet alleen wijzigingen aanbrengen op basis van de services en functies die uw organisatie heeft gebruikt om het aantal wijzigingen te verminderen dat u moet aanbrengen om up-to-date te blijven. Let goed op de ingangsdatum in de RSS-feed waar de wijzigingen worden aangekondigd en een record wordt bijgehouden van alle eerdere wijzigingen, IP-adressen die worden aangekondigd, mogen niet worden geadverteerd of verwijderd uit de advertentie, totdat de ingangsdatum is bereikt.

Routesymmetrie garanderen

De front-endservers van Microsoft 365 zijn toegankelijk via internet en ExpressRoute. Deze servers geven er de voorkeur aan om terug te keren naar on-premises via ExpressRoute-circuits wanneer beide beschikbaar zijn. Hierdoor is er een mogelijkheid van routeasymmetrie als verkeer van uw netwerk liever via uw internetcircuits wordt gerouteerd. Asymmetrische routes vormen een probleem omdat apparaten die stateful pakketinspectie uitvoeren, het retourverkeer kunnen blokkeren dat een ander pad volgt dan de uitgaande pakketten die worden gevolgd.

Ongeacht of u verbinding maakt met Microsoft 365 via internet of ExpressRoute, moet de bron een openbaar routeerbaar adres zijn. Omdat veel klanten rechtstreeks peeren met Microsoft, is het niet haalbaar om privéadressen te hebben waar duplicatie tussen klanten mogelijk is.

Hier volgen scenario's waarin communicatie van Microsoft 365 naar uw on-premises netwerk wordt gestart. Om uw netwerkontwerp te vereenvoudigen, raden we u aan het volgende via het internetpad te routeren.

• SMTP-services zoals e-mail van een Exchange Online tenant naar een on-premises host of SharePoint Mail verzonden van SharePoint naar een on-premises host. HET SMTP-protocol wordt breder gebruikt binnen het netwerk van Microsoft dan de routevoorvoegsels die worden gedeeld via ExpressRoute-circuits en het adverteren van on-premises SMTP-servers via ExpressRoute veroorzaakt fouten met deze andere services.

• ADFS tijdens wachtwoordvalidatie voor aanmelden.

• Exchange Server hybride implementaties.

• SharePoint gefedereerde hybride zoekopdrachten.

• Hybride BCS van SharePoint.

• Skype voor Bedrijven hybride en/of Skype voor Bedrijven federatie.

• Skype voor Bedrijven Cloud Connector.

Microsoft kan alleen terugleiden naar uw netwerk voor deze tweerichtingsverkeersstromen als de BGP-routes naar uw on-premises apparaten worden gedeeld met Microsoft. Wanneer u routevoorvoegsels aan Microsoft adverteert via ExpressRoute, moet u deze aanbevolen procedures volgen:

1. Publiceer niet hetzelfde routevoorvoegsel van het openbare IP-adres naar het openbare internet en via ExpressRoute. Het wordt aanbevolen dat de IP BGP Route Voorvoegsel-advertenties voor Microsoft via ExpressRoute afkomstig zijn van een bereik dat helemaal niet op internet wordt geadverteerd. Als dit niet mogelijk is vanwege de beschikbare IP-adresruimte, is het essentieel om ervoor te zorgen dat u een specifieker bereik via ExpressRoute adverteert dan internetcircuits.

2. Gebruik afzonderlijke NAT IP-pools per ExpressRoute-circuit en gescheiden van die van uw internetcircuits.

3. Elke route die aan Microsoft wordt aangekondigd, trekt netwerkverkeer aan van elke server in het netwerk van Microsoft, niet alleen die waarvoor routes via ExpressRoute naar uw netwerk worden geadverteerd. Publiceer alleen routes naar servers waar routeringsscenario's zijn gedefinieerd en goed worden begrepen door uw team. Publiceer afzonderlijke IP-adresroutevoorvoegsels op elk van meerdere ExpressRoute-circuits van uw netwerk.

Hoge beschikbaarheid en failover met Azure ExpressRoute

U wordt aangeraden ten minste twee actieve circuits van elk uitgaand verkeer met ExpressRoute in te richten op uw ExpressRoute-provider. Dit is de meest voorkomende plaats waar we fouten zien voor klanten en u kunt dit eenvoudig voorkomen door een paar actieve/actieve ExpressRoute-circuits in te richten. We raden ook ten minste twee actieve/actieve internetcircuits aan, omdat veel Microsoft 365-services alleen beschikbaar zijn via internet.

In het beginpunt van uw netwerk bevinden zich veel andere apparaten en circuits die een essentiële rol spelen in hoe mensen beschikbaarheid ervaren. Deze gedeelten van uw connectiviteitsscenario's worden niet gedekt door ExpressRoute- of Microsoft 365-SLA's, maar ze spelen een essentiële rol in de end-to-end-beschikbaarheid van de service, zoals wordt waargenomen door personen in uw organisatie.

Richt u op de personen die Microsoft 365 gebruiken en gebruiken. Als een storing van een onderdeel de ervaring van gebruikers met de service zou beïnvloeden, zoekt u naar manieren om het totale percentage getroffen personen te beperken. Als een failovermodus operationeel complex is, moet u rekening houden met de ervaring van mensen met een lange hersteltijd en zoeken naar operationeel eenvoudige en geautomatiseerde failovermodi.

Buiten uw netwerk hebben Microsoft 365, ExpressRoute en uw ExpressRoute-provider allemaal verschillende beschikbaarheidsniveaus.

Beschikbaarheid van service

• Microsoft 365-services vallen onder goed gedefinieerde serviceovereenkomsten, waaronder metrische gegevens over uptime en beschikbaarheid voor afzonderlijke services. Een van de redenen waarom Microsoft 365 dergelijke hoge service-beschikbaarheidsniveaus kan handhaven, is de mogelijkheid voor afzonderlijke onderdelen om naadloos een failover uit te voeren tussen de vele Microsoft-datacenters, met behulp van het wereldwijde Microsoft-netwerk. Deze failover gaat van het datacenter en het netwerk naar de meerdere internetuitgangspunten en maakt failover naadloos mogelijk vanuit het perspectief van de personen die de service gebruiken.

• ExpressRoute biedt een SLA voor beschikbaarheid van 99,9% op afzonderlijke toegewezen circuits tussen Microsoft Network Edge en de ExpressRoute-provider of partnerinfrastructuur. Deze serviceniveaus worden toegepast op het niveau van het ExpressRoute-circuit, dat bestaat uit twee onafhankelijke interconnects tussen de redundante Microsoft-apparatuur en de netwerkproviderapparatuur op elke peeringlocatie.

Beschikbaarheid van provider

• De serviceniveauregelingen van Microsoft stoppen bij uw ExpressRoute-provider of -partner. Dit is ook de eerste plaats waar u keuzes kunt maken die van invloed zijn op uw beschikbaarheidsniveau. U moet de architectuur, beschikbaarheid en tolerantiekenmerken die uw ExpressRoute-provider biedt tussen uw netwerkperimeter en de verbinding van uw providers op elke Microsoft-peeringlocatie nauwkeurig evalueren. Let goed op zowel de logische als fysieke aspecten van redundantie, peering-apparatuur, door de provider geleverde WAN-circuits en eventuele extra toegevoegde waarde-services, zoals NAT-services of beheerde firewalls.

Uw beschikbaarheidsplan ontwerpen

We raden u ten zeerste aan om hoge beschikbaarheid en tolerantie te plannen en te ontwerpen in uw end-to-end-connectiviteitsscenario's voor Microsoft 365. Een ontwerp moet omvatten;

• Geen single points of failure, inclusief internet- en ExpressRoute-circuits.

• Het minimaliseren van het aantal getroffen personen en de duur van die impact voor de meest verwachte foutmodi.

• Optimaliseren voor een eenvoudig, herhaalbaar en automatisch herstelproces vanuit de meest verwachte foutmodi.

• Ondersteuning van de volledige vereisten van uw netwerkverkeer en -functionaliteit via redundante paden, zonder aanzienlijke achteruitgang.

Uw connectiviteitsscenario's moeten een netwerktopologie bevatten die is geoptimaliseerd voor meerdere onafhankelijke en actieve netwerkpaden naar Microsoft 365. Dit levert een betere end-to-end beschikbaarheid op dan een topologie die alleen is geoptimaliseerd voor redundantie op het niveau van afzonderlijke apparaten of apparatuur.

Tip

Als uw gebruikers zijn verdeeld over meerdere continenten of geografische regio's en elk van deze locaties via redundante WAN-circuits verbinding maakt met één on-premises locatie waar zich één ExpressRoute-circuit bevindt, ervaren uw gebruikers minder end-to-end-servicebeschikbaarheid dan een netwerktopologieontwerp dat onafhankelijke ExpressRoute-circuits bevat die de verschillende regio's verbinden met de dichtstbijzijnde peeringlocatie.

U wordt aangeraden ten minste twee ExpressRoute-circuits in te richten waarbij elk circuit verbinding maakt met een andere geografische peeringlocatie. U moet dit paar actief-actief-circuits inrichten voor elke regio waar mensen ExpressRoute-connectiviteit gebruiken voor Microsoft 365-services. Hierdoor kan elke regio verbonden blijven tijdens een noodgeval dat van invloed is op een belangrijke locatie, zoals een datacenter of peeringlocatie. Als u ze configureert als actief/actief, kan het verkeer van eindgebruikers worden verdeeld over meerdere netwerkpaden. Dit vermindert het bereik van personen die worden getroffen tijdens storingen van apparaten of netwerkapparatuur.

We raden u af om één ExpressRoute-circuit met internet als back-up te gebruiken.

Voorbeeld: failover en hoge beschikbaarheid

Het multi-geografische ontwerp van Contoso heeft een beoordeling van routering, bandbreedte en beveiliging ondergaan en moet nu worden beoordeeld op hoge beschikbaarheid. Contoso beschouwt hoge beschikbaarheid als drie categorieën; tolerantie, betrouwbaarheid en redundantie.

Met tolerantie kan Contoso snel herstellen van fouten. Dankzij betrouwbaarheid kan Contoso een consistent resultaat bieden binnen het systeem. Met redundantie kan Contoso schakelen tussen een of meer gespiegelde exemplaren van de infrastructuur.

Binnen elke edge-configuratie heeft Contoso redundante firewalls, proxy's en id's. Voor Noord-Amerika heeft Contoso één edge-configuratie in hun datacenter in Dallas en een andere edge-configuratie in hun datacenter in Virginia. De redundante apparatuur op elke locatie biedt tolerantie voor die locatie.

De netwerkconfiguratie bij Contoso is gebouwd op basis van enkele belangrijke principes:

• Binnen elke geografische regio zijn er meerdere Azure ExpressRoute-circuits.

• Elk circuit binnen een regio kan al het netwerkverkeer binnen die regio ondersteunen.

• Routering geeft duidelijk de voorkeur aan het ene of het andere pad, afhankelijk van beschikbaarheid, locatie, enzovoort.

• Failover tussen Azure ExpressRoute-circuits vindt automatisch plaats zonder aanvullende configuratie of actie die door Contoso is vereist.

• Failover tussen internetcircuits vindt automatisch plaats zonder aanvullende configuratie of actie die door Contoso is vereist.

In deze configuratie, met redundantie op fysiek en virtueel niveau, kan Contoso lokale tolerantie, regionale tolerantie en wereldwijde tolerantie op een betrouwbare manier bieden. Contoso heeft deze configuratie gekozen na het evalueren van één Azure ExpressRoute-circuit per regio, evenals de mogelijkheid van failover naar internet.

Als Contoso geen meerdere Azure ExpressRoute-circuits per regio kon hebben, zou het routeren van verkeer afkomstig uit Noord-Amerika naar het Azure ExpressRoute-circuit in Azië en Stille Oceaan een onaanvaardbaar latentieniveau toevoegen en voegt de vereiste configuratie van dns-doorstuurserver complexiteit toe.

Het gebruik van internet als back-upconfiguratie wordt afgeraden. Hierdoor wordt het betrouwbaarheidsprincipe van Contoso verbroken, wat resulteert in een inconsistente ervaring met het gebruik van de verbinding. Daarnaast is handmatige configuratie vereist voor een failover, rekening houdend met de BGP-advertenties die zijn geconfigureerd, NAT-configuratie, DNS-configuratie en de proxyconfiguratie. Deze extra failovercomplexiteit verhoogt de tijd om te herstellen en vermindert de mogelijkheid om de betrokken stappen te diagnosticeren en op te lossen.

Hebt u nog vragen over het plannen en implementeren van verkeersbeheer of Azure ExpressRoute? Lees de rest van onze richtlijnen voor netwerk en prestaties of de veelgestelde vragen over Azure ExpressRoute.

Beveiligingscontroles toepassen op Azure ExpressRoute voor Microsoft 365-scenario's

Het beveiligen van Azure ExpressRoute-connectiviteit begint met dezelfde principes als het beveiligen van de internetverbinding. Veel klanten kiezen ervoor om netwerk- en perimeterbesturingselementen te implementeren langs het ExpressRoute-pad dat hun on-premises netwerk verbindt met Microsoft 365 en andere Microsoft-clouds. Deze besturingselementen kunnen firewalls, toepassingsproxy's, preventie van gegevenslekken, inbraakdetectie, inbraakpreventiesystemen, enzovoort omvatten. In veel gevallen passen klanten verschillende niveaus van besturingselementen toe op verkeer dat is geïnitieerd van on-premises naar Microsoft, versus verkeer dat is geïnitieerd van Microsoft naar het on-premises netwerk van de klant, versus verkeer dat is geïnitieerd van on-premises naar een algemene internetbestemming.

Hier volgen enkele voorbeelden van het integreren van beveiliging met het ExpressRoute-connectiviteitsmodel dat u wilt implementeren.

ExpressRoute-integratieoptie	Perimetermodel voor netwerkbeveiliging
Colocated bij een clouduitwisseling	Installeer nieuwe of gebruik bestaande beveiligings-/perimeterinfrastructuur in de colocatiefaciliteit waar de ExpressRoute-verbinding tot stand is gebracht. Gebruik colocatiefaciliteit uitsluitend voor routerings-/interconnect-doeleinden en back-haul-verbindingen van de colocatiefaciliteit naar de on-premises beveiligings-/perimeterinfrastructuur.
Punt-naar-punt-Ethernet	Beëindig de punt-naar-punt-ExpressRoute-verbinding op de bestaande on-premises locatie van de beveiligings-/perimeterinfrastructuur. Installeer een nieuwe beveiligings-/perimeterinfrastructuur die specifiek is voor het ExpressRoute-pad en beëindig de punt-naar-punt-verbinding daar.
Any-to-Any IPVPN	Gebruik een bestaande on-premises beveiligings-/perimeterinfrastructuur op alle locaties die uitgaan naar de IPVPN die wordt gebruikt voor ExpressRoute voor Microsoft 365-connectiviteit. De IPVPN die wordt gebruikt voor ExpressRoute voor Microsoft 365, vastmaken aan specifieke on-premises locaties die zijn aangewezen om te dienen als de beveiliging/perimeter.

Sommige serviceproviders bieden ook beheerde beveiligings-/perimeterfunctionaliteit als onderdeel van hun integratieoplossingen met Azure ExpressRoute.

Bij het overwegen van de topologieplaatsing van de netwerk-/beveiligingsperimeteropties die worden gebruikt voor ExpressRoute voor Microsoft 365-verbindingen, zijn hier extra overwegingen

• De diepte en type netwerk-/beveiligingsbesturingselementen kunnen van invloed zijn op de prestaties en schaalbaarheid van de Microsoft 365-gebruikerservaring.

• Uitgaande stromen (on-premises-Microsoft>) en inkomende (Microsoft-on-premises>) [indien ingeschakeld] kunnen verschillende vereisten hebben. Deze zijn waarschijnlijk anders dan uitgaand naar algemene internetbestemmingen.

• Microsoft 365-vereisten voor poorten/protocollen en benodigde IP-subnetten zijn hetzelfde, ongeacht of verkeer wordt gerouteerd via ExpressRoute voor Microsoft 365 of via internet.

• Topologische plaatsing van de netwerk-/beveiligingscontroles van de klant bepaalt het ultieme end-to-end-netwerk tussen de gebruiker en de Microsoft 365-service en kan een aanzienlijke invloed hebben op de netwerklatentie en congestie.

• Klanten worden aangemoedigd om hun beveiligings-/perimetertopologie te ontwerpen voor gebruik met ExpressRoute voor Microsoft 365 in overeenstemming met best practices voor redundantie, hoge beschikbaarheid en herstel na noodgevallen.

Hier volgt een voorbeeld van Contoso dat de verschillende Azure ExpressRoute-connectiviteitsopties vergelijkt met de perimeterbeveiligingsmodellen die hierboven zijn besproken.

Voorbeeld: Azure ExpressRoute beveiligen

Contoso overweegt de implementatie van Azure ExpressRoute en na het plannen van de optimale architectuur voor ExpressRoute voor Microsoft 365 en na het gebruik van de bovenstaande richtlijnen om inzicht te hebben in bandbreedtevereisten, bepalen ze de beste methode voor het beveiligen van hun perimeter.

Voor Contoso, een multinationale organisatie met locaties op meerdere continenten, moet beveiliging alle perimeters omvatten. De optimale connectiviteitsoptie voor Contoso is een verbinding met meerdere punten met meerdere peeringlocaties over de hele wereld om te voldoen aan de behoeften van hun werknemers op elk continent. Elk continent bevat redundante Azure ExpressRoute-circuits binnen het continent en de beveiliging moet al deze circuits omvatten.

De bestaande infrastructuur van Contoso is betrouwbaar en kan het extra werk afhandelen, waardoor Contoso de infrastructuur kan gebruiken voor hun Azure ExpressRoute- en internetperimeterbeveiliging. Als dit niet het geval is, kan Contoso ervoor kiezen om meer apparatuur aan te schaffen om hun bestaande apparatuur aan te vullen of om een ander type verbinding te verwerken.

Bandbreedteplanning voor Azure ExpressRoute

Elke Microsoft 365-klant heeft unieke bandbreedtebehoeften, afhankelijk van het aantal personen op elke locatie, hoe actief ze zijn met elke Microsoft 365-toepassing en andere factoren, zoals het gebruik van on-premises of hybride apparatuur en netwerkbeveiligingsconfiguraties.

Als u te weinig bandbreedte hebt, leidt dit tot congestie, hertransmissies van gegevens en onvoorspelbare vertragingen. Te veel bandbreedte leidt tot onnodige kosten. Op een bestaand netwerk wordt bandbreedte vaak aangeduid in termen van de hoeveelheid beschikbare ruimte op het circuit als percentage. Het hebben van 10% hoofdruimte zal waarschijnlijk leiden tot congestie en het hebben van 80% hoofdruimte betekent over het algemeen onnodige kosten. Typische hoofdruimtedoeltoewijzingen zijn 20% tot 50%.

Om het juiste bandbreedteniveau te vinden, kunt u het beste uw bestaande netwerkverbruik testen. Dit is de enige manier om een echte meting van het gebruik en de behoefte te krijgen, omdat elke netwerkconfiguratie en -toepassingen in sommige opzichten uniek zijn. Bij het meten moet u goed letten op het totale bandbreedteverbruik, de latentie en de TCP-congestie om inzicht te krijgen in uw netwerkbehoeften.

Zodra u een geschatte basislijn hebt die alle netwerktoepassingen omvat, test u Microsoft 365 uit met een kleine groep die de verschillende profielen van personen in uw organisatie omvat om het werkelijke gebruik te bepalen en gebruikt u de twee metingen om de hoeveelheid bandbreedte te schatten die u nodig hebt voor elke kantoorlocatie. Als er sprake is van latentie- of TCP-congestieproblemen in uw test, moet u mogelijk de uitgaand verkeer dichter bij de personen die Microsoft 365 gebruiken, verplaatsen of intensieve netwerkscans verwijderen, zoals SSL-ontsleuteling/-inspectie.

Al onze aanbevelingen over welk type netwerkverwerking wordt aanbevolen, zijn van toepassing op zowel ExpressRoute- als internetcircuits. Hetzelfde geldt voor de rest van de richtlijnen op onze site voor het afstemmen van prestaties.

Uw implementatie- en testprocedures bouwen

Uw implementatieplan moet zowel test- als terugdraaiplanning bevatten. Als uw implementatie niet werkt zoals verwacht, moet het plan zijn ontworpen om het minste aantal personen te beïnvloeden voordat problemen worden gedetecteerd. Hier volgen enkele principes op hoog niveau voor uw plan.

1. Faseer het onboarden van het netwerksegment en de gebruikersservice om onderbrekingen te minimaliseren.

2. Plan het testen van routes met traceroute en TCP-verbinding vanaf een afzonderlijke host met internetverbinding.

3. Het testen van binnenkomende en uitgaande services moet bij voorkeur worden uitgevoerd op een geïsoleerd testnetwerk met een test-Microsoft 365-tenant.

   • U kunt ook tests uitvoeren op een productienetwerk als de klant Microsoft 365 nog niet gebruikt of zich in de testfase bevindt.

   • U kunt ook testen tijdens een productiestoring die alleen is gereserveerd voor test en bewaking.

   • U kunt ook testen door routes te controleren voor elke service op elk layer 3-routerknooppunt. Deze terugval mag alleen worden gebruikt als er geen andere tests mogelijk zijn, omdat een gebrek aan fysieke tests risico's met zich mee brengt.

Uw implementatieprocedures bouwen

Uw implementatieprocedures moeten in fasen worden geïmplementeerd voor kleine groepen mensen, zodat u deze kunt testen voordat ze worden geïmplementeerd voor grotere groepen personen. Hier volgen verschillende manieren om de implementatie van ExpressRoute te fasereren.

1. Stel ExpressRoute in met Microsoft-peering en laat de routeadvertenties alleen voor gefaseerde testdoeleinden doorsturen naar één host.

2. Publiceer in eerste instantie routes naar het ExpressRoute-netwerk naar één netwerksegment en breid de routeadvertenties uit per netwerksegment of regio.

3. Als u Microsoft 365 voor de eerste keer implementeert, gebruikt u de ExpressRoute-netwerkimplementatie als testfase voor een paar personen.

4. Als u proxyservers gebruikt, kunt u ook een PAC-testbestand configureren om een paar personen naar ExpressRoute te leiden met tests en feedback voordat u meer toevoegt.

Uw implementatieplan moet een lijst bevatten van alle implementatieprocedures die moeten worden uitgevoerd of opdrachten die moeten worden gebruikt om de netwerkconfiguratie te implementeren. Wanneer de netwerkstoringstijd binnenkomt, moeten alle wijzigingen die worden aangebracht afkomstig zijn van het schriftelijke implementatieplan dat vooraf is geschreven en door peers is beoordeeld. Zie onze richtlijnen voor de technische configuratie van ExpressRoute.

• Uw SPF TXT-records bijwerken als u IP-adressen hebt gewijzigd voor on-premises servers die e-mail blijven verzenden.

• Eventuele DNS-vermeldingen voor on-premises servers bijwerken als u IP-adressen hebt gewijzigd voor een nieuwe NAT-configuratie.

• Zorg ervoor dat u bent geabonneerd op de RSS-feed voor Microsoft 365-eindpuntmeldingen om eventuele routerings- of proxyconfiguraties te onderhouden.

Nadat uw ExpressRoute-implementatie is voltooid, moeten de procedures in het testplan worden uitgevoerd. De resultaten voor elke procedure moeten worden vastgelegd. U moet procedures opnemen voor het terugdraaien naar de oorspronkelijke productieomgeving in het geval de resultaten van het testplan aangeven dat de implementatie niet is geslaagd.

Uw testprocedures bouwen

Uw testprocedures moeten tests bevatten voor elke uitgaande en binnenkomende netwerkservice voor Microsoft 365 die expressroute gebruiken en die niet. De procedures moeten het testen van elke unieke netwerklocatie omvatten, inclusief gebruikers die zich niet on-premises in het bedrijfs-LAN bevinden.

Enkele voorbeelden van testactiviteiten zijn het volgende.

1. Ping van uw on-premises router naar de router van uw netwerkoperator.

2. Controleer of de 500+ Microsoft 365- en CRM Online IP-adresadvertenties zijn ontvangen door uw on-premises router.

3. Controleer of uw binnenkomende en uitgaande NAT werkt tussen ExpressRoute en het interne netwerk.

4. Controleer of routes naar uw NAT worden geadverteerd vanaf uw router.

5. Controleer of ExpressRoute uw geadverteerde voorvoegsels heeft geaccepteerd.

   • Gebruik de volgende cmdlet om peeringadvertenties te controleren:

   Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
   

6. Controleer of uw openbare NAT-IP-bereik niet wordt geadverteerd naar Microsoft via een ander ExpressRoute- of openbaar internetnetwerkcircuit, tenzij het een specifieke subset van een groter bereik is, zoals in het vorige voorbeeld.

7. ExpressRoute-circuits zijn gekoppeld, controleer of beide BGP-sessies worden uitgevoerd.

8. Stel één host in aan de binnenkant van uw NAT en gebruik ping, tracert en tcpping om de connectiviteit tussen het nieuwe circuit en de host outlook.office365.com te testen. U kunt ook een hulpprogramma zoals Wireshark of Microsoft Network Monitor 3.4 op een gespiegelde poort naar de MSEE gebruiken om te controleren of u verbinding kunt maken met het IP-adres dat is gekoppeld aan outlook.office365.com.

9. Functionaliteit op toepassingsniveau testen voor Exchange Online.

• Test outlook kan verbinding maken met Exchange Online en e-mail verzenden/ontvangen.

• Test Outlook kan de onlinemodus gebruiken.

• Smartphoneconnectiviteit en verzend-/ontvangstfunctionaliteit testen.

10. Functionaliteit op toepassingsniveau testen voor SharePoint

• Test OneDrive voor Bedrijven synchronisatieclient.

• SharePoint-webtoegang testen.

11. Functionaliteit op toepassingsniveau testen voor Skype voor Bedrijven aanroepende scenario's:

• Deelnemen aan telefonische vergadering als geverifieerde gebruiker [uitnodiging geïnitieerd door eindgebruiker].

• Nodig de gebruiker uit voor telefonische vergadering [uitnodiging verzonden vanuit MCU].

• Neem deel aan de vergadering als anonieme gebruiker met behulp van de webtoepassing Skype voor Bedrijven.

• Neem deel aan een gesprek vanaf uw bekabelde pc-verbinding, IP-telefoon en mobiele apparaat.

• Aanroep naar federatieve gebruiker o Aanroep naar PSTN-validatie: oproep is voltooid, gesprekskwaliteit is acceptabel, verbindingstijd is acceptabel.

• Controleer of de aanwezigheidsstatus voor contactpersonen is bijgewerkt voor zowel leden van de tenant als federatieve gebruikers.

Veelvoorkomende problemen

Asymmetrische routering is het meest voorkomende implementatieprobleem. Hier volgen enkele veelvoorkomende bronnen die u kunt zoeken:

• Een open of platte netwerkrouteringstopologie gebruiken zonder bron-NAT.

• Geen gebruik van SNAT om naar binnenkomende services te routeren via zowel internet- als ExpressRoute-verbindingen.

• Binnenkomende services niet testen op ExpressRoute op een testnetwerk voordat ze algemeen worden geïmplementeerd.

ExpressRoute-connectiviteit implementeren via uw netwerk

Faseer uw implementatie naar één segment van het netwerk tegelijk, waarbij de connectiviteit naar verschillende onderdelen van het netwerk geleidelijk wordt geïmplementeerd met een plan om terug te draaien voor elk nieuw netwerksegment. Als uw implementatie is afgestemd op een Microsoft 365-implementatie, implementeert u eerst naar uw Microsoft 365-testgebruikers en kunt u van daaruit uitbreiden.

Eerst voor uw test en vervolgens voor productie:

• Voer de implementatiestappen uit om ExpressRoute in te schakelen.

• Test of u ziet dat de netwerkroutes zijn zoals verwacht.

• Voer tests uit op elke binnenkomende en uitgaande service.

• Terugdraaien als u problemen ontdekt.

Een testverbinding met ExpressRoute instellen met een testnetwerksegment

Nu u het voltooide plan op papier hebt, is het tijd om op kleine schaal te testen. In deze test maakt u één ExpressRoute-verbinding met Microsoft Peering naar een testsubnet op uw on-premises netwerk. U kunt een proeftenant van Microsoft 365 configureren met connectiviteit van en naar het testsubnet en alle uitgaande en binnenkomende services opnemen die u in productie gaat gebruiken in het testsubnet. Stel DNS in voor het testnetwerksegment en stel alle binnenkomende en uitgaande services in. Voer uw testplan uit en zorg ervoor dat u bekend bent met de routering voor elke service en de doorgifte van de route.

De implementatie- en testplannen uitvoeren

Als u de hierboven beschreven items voltooit, controleert u de gebieden die u hebt voltooid en controleert u of u en uw team deze hebben gecontroleerd voordat u uw implementatie- en testplannen uitvoert.

• Lijst met uitgaande en binnenkomende services die betrokken zijn bij de netwerkwijziging.

• Diagram van globale netwerkarchitectuur met zowel internetuitgangen als ExpressRoute-meet-me-locaties.

• Netwerkrouteringsdiagram met de verschillende netwerkpaden die worden gebruikt voor elke geïmplementeerde service.

• Een implementatieplan met stappen om de wijzigingen te implementeren en indien nodig terug te draaien.

• Een testplan voor het testen van elke Microsoft 365- en netwerkservice.

• Voltooide papieren validatie van productieroutes voor binnenkomende en uitgaande services.

• Een voltooide test in een testnetwerksegment, inclusief beschikbaarheidstests.

Kies een onderbrekingsvenster dat lang genoeg is om het volledige implementatieplan en het testplan te doorlopen, enige tijd beschikbaar heeft voor probleemoplossing en tijd voor het terugdraaien indien nodig.

Voorzichtigheid

Vanwege de complexe aard van routering via zowel internet als ExpressRoute, is het raadzaam om extra buffertijd toe te voegen aan dit venster om problemen met complexe routering te verwerken.

QoS configureren voor Skype voor Bedrijven Online

QoS is nodig om voordelen voor spraak en vergaderingen te verkrijgen voor Skype voor Bedrijven Online. U kunt QoS configureren nadat u ervoor hebt gezorgd dat de ExpressRoute-netwerkverbinding geen van uw andere Microsoft 365-servicetoegang blokkeert. Configuratie voor QoS wordt beschreven in het artikel ExpressRoute en QoS in Skype voor Bedrijven Online .

Problemen met uw implementatie oplossen

De eerste plaats om te kijken is de stappen in deze implementatiehandleiding, zijn er gemist in uw implementatieplan? Terug en voer indien mogelijk verdere kleine netwerktests uit om de fout te repliceren en daar fouten op te sporen.

Bepaal welke binnenkomende of uitgaande services zijn mislukt tijdens het testen. Haal specifiek de IP-adressen en subnetten op voor elk van de services die zijn mislukt. Ga verder met het netwerktopologiediagram op papier en valideer de routering. Controleer specifiek waar de ExpressRoute-routering wordt geadverteerd, test deze routering tijdens de storing, indien mogelijk met traceringen.

Voer PSPing uit met een netwerktracering naar elk klanteindpunt en evalueer bron- en doel-IP-adressen om te controleren of ze naar verwachting zijn. Voer telnet uit op een e-mailhost die u beschikbaar maakt op poort 25 en controleer of SNAT het oorspronkelijke bron-IP-adres verbergt als dit wordt verwacht.

Houd er rekening mee dat u tijdens het implementeren van Microsoft 365 met een ExpressRoute-verbinding ervoor moet zorgen dat zowel de netwerkconfiguratie voor ExpressRoute optimaal is ontworpen als dat u ook de andere onderdelen op uw netwerk hebt geoptimaliseerd, zoals clientcomputers. Naast het gebruik van deze planningshandleiding voor het oplossen van problemen met de stappen die u mogelijk hebt gemist, hebben we ook een plan voor het oplossen van prestatieproblemen geschreven voor Microsoft 365 .

Met deze korte koppeling kunt u teruggaan: https://aka.ms/implementexpressroute365

Verwante onderwerpen

Microsoft 365-netwerkverbindingen evalueren

Azure ExpressRoute voor Microsoft 365

Mediakwaliteit en prestaties van de netwerkverbinding in Skype voor Bedrijven Online

Uw netwerk instellen voor Skype voor Bedrijven Online

ExpressRoute en QoS in Skype voor Bedrijven Online

Oproepstroom met Behulp van ExpressRoute

Microsoft 365-prestaties afstemmen met basislijnen en prestatiegeschiedenis

Plan voor het oplossen van problemen met prestaties voor Microsoft 365

Microsoft 365-URL's en IP-adresbereiken

Microsoft 365-netwerk en prestaties afstemmen